Topic: Could the need of Bitcoin being more divisible lead to a hard fork? (Read 518 times)

thanks for all the answers!

it really shed light into some deeper issues I hand't think about

Thinking more carefully, $1 for satoshi is a very high price even in the long term.
As a bullish bitcoiner, I guess we may reach $0.1 for satoshi considering the purchashing power of the dollar today. I say "considering the purchasing power of the dollar today" because all fiat currencies tend to severe devaluation in the long run, which means that $100 in 100 years could be worth less than $5 today.

Anyway, I don't think there would be a need for bitcoin to be more divisible in the next decades.
Moreover, it would be a complete mess to try to make bitcoin more divisible because the software would have to handle past transactions and future transactions differently, introducing a lot of complexity.

Thank you all for the answers. It clarified my doubes

you are aimlessly pretending its a "users fault" if the network changed its unit measure..(THIS TOPIC)
the analogy i made was.. (if you were not ignorant you would understand)
if there was a more then one users using a software because a subnetwork or group demanded a certain software to be used. those rules of that software becomes the rules of that network/community.. which affect more then one users. where you are ignorantly pretending its ok to have malicious code because you pretend only one user would be affected

the point was if BITCOIN changed its units of conversion (the peg) from 100,000,000 to 100,000,000,000 it changes the rules for everyone!!

your silly inept thoughts that the LN analogy of its peg would only affect 1 users. is flawed again because it can and does affect many users and LN has no network security facility(it could but doesnt bother) to prevent such things. . as has the thor turbo flaw(you lot called "feature") affected many users.

you are really trying too hard to break bitcoin(this topic of changing bitcoins unit of measure) and then pretend its no harm that it breaks and then pretend only 1 user would be affected.. you are seriously misleading and very malicious when you try to undermine the security of bitcoin by pretending its of no harm by changing/breaking it

seriously you are ignoring the whole unit measure just to talk about a GUI thing(facepalm)

sorry but actually look at the units of measure at the data level of a raw tx/blockchain utxo value/block coinbase reward and how things would change

EG paying someone in bitcoin of 11 decimals. requires changing the transaction and blockchain rules to allow such unit accounting

now go and do some research and math on it.

and dont respond unless you can understand things like

GUI: 3.12500000
bin:10010101000000101111100100000
hex:12A05F20
dec:312500000

change to:

GUI: 3.12500000000
bin: 100100011000010011100111001010100000000
hex: 48C2739500
dec: 312500000000

where you can try to articulate the many things that break and change due to that change

These flaws affect only the user. Just as any malware (on-chain and off-chain) affects only the user that installs it.

Sure, but this is like saying Bitcoin is a scam, because some people forfeit their ownership to centralized exchanges. People have the freedom to do whatever they want with their money. Some might choose to forfeit their custody to a lightning hub. Some others might just run their own node, and lose no custody.

You went off the deep end this time. You seriously propose we shouldn't have lightning network-- a protocol that is also decentralized, peer-to-peer and self-custody insuring-- just because some people might not use it correctly, contradicting completely the fact that this is already happening in bitcoin, and that it's natural for every protocol.

soft or hard is not how OELEO/doomad pretends its terminology is (he thinks its a Tightening" vs "relaxing" rules thing) (facepalm)

both soft or hard can result in an altcoin creation. it all depends if users want to retain the reject/orphan blocks of a rule change.
both soft or hard can avoid an altcoin creation. it all depends if users want to retain the reject/orphan blocks of a rule change.

soft or hard both can create rejects/orphaned blocks.

both soft and hard are FORKS.. hint is in the name 'soft fork' 'hard fork'

the terminology from 2009-2016 was
a hard fork is a controversial change requiring majority users to upgrade to then support a change/reject out a change thats not wanted
where by a proposed change would need upgrading first to then activate a change when an activation can occur when deemed safe and supported
a soft fork is a change not requiring majority users to upgrade to support.
a hard fork can also present as someone forcing a different block of data that breaks a rule due to a bug in the rules. again requiring a upgrade to make said bug invalid if majority upgrade to invalidate the bugged blocks

in 2017 using (an admitted by core devs) bypass. by rejection before activation. changed the terminology where now certain people think everything is soft and no hards have or will or need to occur

should oeleo/doomad ever dare themselves to do the research on the past they would learn what occurs and know if one happened or not. but it seems by lack of knowledge of past they can only "think" "believe" things happened or not, the way they dream.. because the only insight they have is their dreams

I suppose you could argue that the bug itself was a hard fork, since it allowed the attacker to do something which everyone agreed should be invalid (create 92 billion bitcoin out of thin air). But the successful patch to fix it was a soft fork, as it was simply tightening the rules (by making such overflow incidents invalid). Even BIP50 wasn't really a hard fork, despite often being called such. I don't believe bitcoin has ever had a successful hard fork.

The presence or absence of a chain split does not give an indication as to whether a change was a soft or a hard fork. Although obviously a hard fork could result in a chain split, we could also code a hard fork (such as to fix the 2106 problem) decades in advance which would result in everybody running a compatible client well in advance and there being no chain split.

As an example, I believe block 74,638 back in 2010, well before my time, technically resulted in a hardfork.  There was a serious bug which broke the 21 million BTC limit.  The bug was swiftly patched and everyone switched to the new software version.  That fork would clearly be considered "successful" because it fixed the bug.

//EDIT:  Although I could be mistaken.  Various media outlets describe it as a softfork.  Was there no chain split for that one?

A hard fork does not necessarily imply creation of a new shitcoin, such as in the BCash fork. It is possible to implement a hard fork which the entire network agrees upon, which results in everyone staying on the main chain and no chain split. A hard fork simply means that the rules are being relaxed, and something which was previously invalid is now considered valid.

oh doomad yet again.. you are fooling yourself with your attempts to ignore the obvious

you think these flaws "only affect one user" yet you are foolish to ignore that no one makes an app and gets it put on google play/apple store for just one user.

funny part is..
when thor turbo started its(other flaw) fractional reserve game. many downloaded it and were given msats with no funding utxo. and YOU and your chums called that fractional reserve event of inventing new msats out of nothings as "a feature"

when many users are using mobile apps, where they are stuck using a hub allotting them(giving inbound) value they end up having to use the app the services offers them, where whats not seen on the GUI can affect those users end result they think they are promised. but never get delivered

..
your desires to break the rules of a network structure, and then just say "its the users fault" is your lame scapegoat every time
there needs to be network rules(you dont want there to be network rules) that mitigate the damage
you want a certain app to be able to change rules as they please without anyone able to abstain or veto the devs code. and instead users become just a puppet to a devs code where they also change the network rules to not have a method to prevent a malicious act occurring

again you need to really challenge yourself and realise what consent and abstaining means.
what consensus means..
where by performing an act(ivation) on others, should not occur unless clear consent is given.
your lack of wanting a majority vote or pretending there is not one in the first place is a failure on your part.

oh and if you again pretend bitcoin doesnt have a true consensus then you already debunked yourself in the previous post of other topics when you admit to knowing about the previous versions where you clearly stated you hated the idea of a 6% veto or any veto of a minority.. and then went on to say how you adore that devs can slide in changes without any vote at all due to the non-consent abstaining bypasses put inplace

please go learn what abstaining and non-consent is
learn byzantine generals problem and how consensus actually works
then go learn about what the devs came up with and admitting to performing to bypass consent of the masses
consensus: consent by census(survey of the population )

If someone malicious changed that code, they'd only screw up their own client.  The person receiving funds, assuming they downloaded their client from a legitimate source, would see the real amount being sent or received.  All of your "bugs" seem to involve people downloading malicious code.  That's not the definition of a bug.  That's just malware.  And malware is equally applicable to on-chain clients, so once again, you have failed to present a valid argument against LN.

Every post you make only proves you have no credibility.  You'll say literally anything, no matter how dishonest, to avoid conceding that you have lost.


//EDIT:
And now that franky1's lame and pathetic lies have been decimated, look at how they suddenly change the subject to one of their other equally moronic and flawed interpretations of reality in their next post.  There is no fractional reserve in LN and Thor Turbo channels are funded by BitRefill's own funds.  People can purchase pre-funded channels and this is apparently too complicated a notion for franky1 to comprehend.  See this topic for further details:  https://bitcointalksearch.org/topic/is-franky1-making-libellous-statements-about-bitrefill-5226421 

There has never been in the history of bitcoin that a hard fork bitcoin has ever become successful, the ones they did in the early days of bitcoin and the ones they did in the all-time high price of bitcoin to date have not reached the half potential of bitcoin talk more of doing what they are been created for. A hard fork of bitcoin is not necessary nor indispensable, it will make some bitcoin holders if they airdrop it for them but it will mostly enrich some Cartels who will create such fork coins, we have seen it in the past and they didn't it age well. Look at BitcoinCash creator, Craig Wright, he ended up scamming people with his fake Bitcoin only to come back again to say that he is the real Satoshi, a very dishonest person. 

comments in code. is not the code.
read the code

the division and multiplication is a whole different area of math compared to removing significant figures off the end

its funny how you avoided understand the code and just quoted a comment..

some pseudo code for you
remove(right,3)
is different than
/1000

you can do alot more harm with changing /1000 compared to a "round"

Here's a quote from the comments in the very code that you just linked to:

Which is exactly what I said. If you close a channel which is holding some number of millisats, then the transaction broadcast to the main chain will be rounded down to the nearest whole sat. Or here is another quote from BOLT #3:

So no, what I said is very much not wrong.

lets make it simple

A<>B<>C<>D<>E<>F<>G
A wants to pay G 200sat (200,000msat)
onion payment(b:200,005(c:200,004(d:200,003(e:200,002(f:200,001(g:200,000))))))
here people see in the GUI their msat balance destined for their output appears as +200,000
meaning they presume they will get 300sat by computing the input plus payment

               before                                  after                   conversion
       fund            output                 fund         output          rate              broadcast
a-b  a250,000->a250,000           a250,000->a50,000      1000            a250->a50                
       b100,000->b100,000          b100,000->b300,000     1000            b100->b300

b-c  b250,000->b250,000          b250,000->b50,000       1000             b250->b50                
       c100,000->c100,000          c100,000->c300,000      1000             c100->c300

c-d  c250,000->c250,000         c250,000->c50,000         10,000          c250->c5                
       d100,000->d100,000        d100,000->d300,000      10.000          d100->d30
                                                                                                        tx fee:315

d-e  d250,000->d250,000        d250,000->d50,000        1000             d250->d50                
       e100,000->e100,000        e100,000->e300,000      1000             e100->e300

e-f  e250,000->e250,000        e250,000->e50,000         1000             e250->e50                
      f100,000->f100,000         f100,000->f300,000         1000             f100->f300

f-g  f250,000->f250,000        f250,000->f50,000            200              f250->f250              
      g100,000->g100,000      g100,000->g300,000         10,000         g100->g30
                                                                                                         tx fee:70

as you can see at the "onion payment" of GUI display of IOU balance.. everyone feels they are getting fair 200,000msat channel allocation changes in a routed payment.. meaning 200sat payment belief

but end result at broadcast. due to changing the msat conversion rate
is a couple people are not getting paid the end total belief of their input 100sat + payment 200sat
some are getting just 30sat instead of 300sat

which can be even more finely refined to ensure the missing amount doesnt end up as fee. but instead more income for one side than the other

if it was a trim 3significant figures .. the end broadcast results would be different
..

That will never happen, there is LN. One solution for many problems, though it's not decentralized, it's more like visa and paypal but with less fees.

wrong

its not though
READ SOME CODE about the peg

its not a "trim; 5,000,000 msat to 5,000sat"
its a 5,000,000 / 1000 to CONVERT to msat to sat
its a 5,000,000 * 1000 to CONVERT to sat to msat
https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go
mathematically there is a big difference. between trimming end units vs multiplication/division
 especially when it comes to the lack of a network protocol.where by people can change the /1000 easily


even the blockstream elements version of lightning highlight this is changable
https://github.com/ElementsProject/lightning-charge#post-invoice

Good question.

So the transactions involving millisats aren't broadcast to the main chain. They remain entirely within the Lightning network. Whenever a Lightning channel which has a balance involving millisats is closed, then the transaction which is broadcast to the main chain is rounded down to the nearest whole satoshi.

Think of it like this. You and I each put ten $1 bills in a jar. There are now twenty $1 bills in that jar. You sell me some goods for $5, and so we agree that when we open the jar again, you'll get fifteen of those bills, and I'll get five. All good so far. Then I sell you some goods for $2.50. So now the balance is $12.50 for you, and $7.50 for me. If we open the jar now, then we can't get the exact amounts we are owed, because there are only $1 bills in the jar and no quarters, dimes, etc., so we can't receive 50 cents each. But no matter, we aren't opening the jar yet, so it doesn't matter for now. We can agree that this is what we are each owed, without actually opening the jar. So we do another trade for $2.80, and now the split is $15.30 and $4.70. And another trade, and another, and another. All the time we agree to split the original $20 in different ways, some of which won't actually be possible because we don't have the coins needed to split up a dollar in to smaller parts. When we finally come to open the jar, let's say (for example) the split is $15.30 and $4.70, as above. You would get $15, and I would get $4, with $1 left over in the jar.

The same thing happens with Lightning channels. You open the channel using a whole number of sats, but then can trade in millisats. As long as your channel stays open (i.e. we don't open the jar), you can trade back and forth in millisats as long as you like. When you want to close the channel (i.e. open the jar), then the transaction broadcast to the main chain will only use sats, and so the balance of both parties will be rounded down to the nearest whole satoshi, with the extra satoshi (the $1 left over in the example above) added to the fee of the closing transaction.

Satoshi Nakamoto really created Bitcoin to handle such a thing as this, so for me, no need for any hard forks.
Since satoshi is the smallest unit of Bitcoin, I can say that is already enough. We just familiarize the conversion of 1 satoshi = BTC, like how many decimals.

If LN is the solution for this kind of issue, I am curious if LN indeed accept a fraction of satoshi while the original network rejects such kind of transaction, how can that transaction be presented on Bitcoin network since I believe LN transactions need to be reflected on the original network?  Please kindly enlighten me since I am really confused about this kind of situation. 

In its current form it would only be part of the solution. There are still other stumbling blocks which would need addressed first.

For example, let's say that a satoshi is worth $1 or more. Are people going to be happy spending hundreds of dollars worth of bitcoin just to open a channel? Or do we need something like channel factories to make it possible to open a channel for a fraction of that cost? More importantly, what about if you have an amount on your channel which is currently considered on-chain dust, but which could be worth hundreds of dollars? Most people won't be happy chalking that up as a loss.

Although it is worth repeating that for a satoshi to be worth $1, then the marketcap of bitcoin would be $2.1 quadrillion, which is more than an order of magnitude more than the global monetary supply. It is a crazy hypothetical.

LN is not the solution.. its too buggy even after 5 years

far easier to start from scratch with a different subnetwork designed differently to LN without the bugs or payment model of LN.. but offers a more secure method of pegging to a 1:1000 unit level to use on the sub network

whilst also reminding people to be risk aware of any sub networks and not pretend a subnetwork of any form is the same as the mainnet