What IF you could change one element of Bitcoins code what would it be and why?

[figmentofmyass]

Not saying I necessarily agree, as I don't believe massive block sizes are not good for the long-term health of the network, but at the same time, block size increases probably shouldn't be this contentious.

that would be nice. and you'd be right if incompatible consensus change were only about technical issues---ie whether bigger blocks cause too much orphaning or eat too much upload bandwidth etc. eventually those technological limitations will be overcome.

the bigger issue is a philosophical one. to use bitcoin, you must agree to the protocol rules; you "opt in" to the protocol. so who are you or i to say that the protocol should incompatibly change such that legacy users are cut off from the network? bitcoin already exists and we're already using it. so i can sympathize with those who believe that hard forkers ought to be seen as using an altcoin. it's a different protocol that copies the original ledger, while legacy users would still be using bitcoin.

[franky1]

massive block sizes are not good for the long-term health of the network,

no one realistically is actually or has ever actually proposed formally and sensibly 'massive block sizes'
the whole "gigabytes by midnight" rhetoric is social drama propaganda over on reddit. which has been circling and used as a lame excuse to even avoid a compromised agreement of 2mb legacy increase in 2015.. or a 8mb weight 2015-2019

the real funny part is that core devs said 4mb was super bad network crashing... right up until the point that they realised that they would want 4mb themselves for their special LN gateway tx format called segwit.

yet the rest of the network is still stuck due to devs wishy washy code where the 3mb extra is not for true tx space, but just the scripts(witness) and all tx's are still stifled by the 1mb legacy limit.. even though the node count services show that the august 2017 controversial hard fork event could have simply just been a flip to 4mb legacy. allowing both legacy and segwit full utility. without causing any extra drama

[hv_]

I see some people mentioning an adaptive block size limit solution, and I'd just like to point out that satoshi has floated something of the sort in the past:

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

Not saying I necessarily agree, as I don't believe massive block sizes are not good for the long-term health of the network, but at the same time, block size increases probably shouldn't be this contentious. A block size increase will be necessary as the userbase grows anyway, so it shouldn't hurt to increase it a little to alleviate some of the short-term confirmation issues.

Better: Remove 'maxblocksize '  at all.   There are so many other and natural coinstrains left acting as a better control than such MAGIC NUMBER in the code....

[jseverson]

massive block sizes are not good for the long-term health of the network,

no one realistically is actually or has ever actually proposed formally and sensibly 'massive block sizes'

I was exaggerating. I meant that I don't believe that Bitcoin could scale solely on big blocks. I'm not very interested in the politics.

the bigger issue is a philosophical one. to use bitcoin, you must agree to the protocol rules; you "opt in" to the protocol. so who are you or i to say that the protocol should incompatibly change such that legacy users are cut off from the network? bitcoin already exists and we're already using it. so i can sympathize with those who believe that hard forkers ought to be seen as using an altcoin. it's a different protocol that copies the original ledger, while legacy users would still be using bitcoin.

Yeah that about sums up the current situation lol. It sucks, and it seems like no change can be implemented without fracturing the community permanently a la BCH (I mean, that's why the community is generally against hard forks right?). I just wish there was a better way, and there probably isn't. It's one way or the highway.

[figmentofmyass]

the real funny part is that core devs said 4mb was super bad network crashing... right up until the point that they realised that they would want 4mb themselves for their special LN gateway tx format called segwit.

you're glossing over the sighash operations issue, among other things. linear scaling of sighash ops has obvious scaling benefits, and prevents malicious validation attacks. simply increase the legacy block size limit would have been much less safe. segwit addressed the problem directly and solved it for the future rather than depending on an awkward kludge like directly limiting sighash ops.

the elephant in the room is that segwit allowed a block size increase without a hard fork. a hard fork at this point isn't nearly as easy to achieve as some of you think it is.

[jademaxsuy]

you're glossing over the sighash operations issue, among other things. linear scaling of sighash ops has obvious scaling benefits, and prevents malicious validation attacks. simply increase the legacy block size limit would have been much less safe. segwit addressed the problem directly and solved it for the future rather than depending on an awkward kludge like directly limiting sighash ops.

the elephant in the room is that segwit allowed a block size increase without a hard fork. a hard fork at this point isn't nearly as easy to achieve as some of you think it is.

Yeah this is what I also think about bitcoin. Hard fork will not be that easy to implement as it seems that it can alter the security features of the block chain. Even if I were to ask I will still be in favor of no hard fork system for bitcoin. It would be better to remain what bitcoin has now.

[hv_]

massive block sizes are not good for the long-term health of the network,

no one realistically is actually or has ever actually proposed formally and sensibly 'massive block sizes'

I was exaggerating. I meant that I don't believe that Bitcoin could scale solely on big blocks. I'm not very interested in the politics.

The entire idea behind Bitcoin is to remove as much politics and middle men by economics and  working tech + PoW.

>> These who try to want keep politics inside and try to gover MUST fail.

Keep blocksize low and inject SW + LN is biggest faliure ever.  > gave altcoins the room to grow

as well as cutting script options > gave ETH & co room to grow

[franky1]

the real funny part is that core devs said 4mb was super bad network crashing... right up until the point that they realised that they would want 4mb themselves for their special LN gateway tx format called segwit.

you're glossing over the sighash operations issue, among other things. linear scaling of sighash ops has obvious scaling benefits, and prevents malicious validation attacks. simply increase the legacy block size limit would have been much less safe. segwit addressed the problem directly and solved it for the future rather than depending on an awkward kludge like directly limiting sighash ops.

the elephant in the room is that segwit allowed a block size increase without a hard fork. a hard fork at this point isn't nearly as easy to achieve as some of you think it is.

1. segwit only activated due to a hard fork.
the august 2017 was a controversial hard fork. you can call a hat a cap. you can call a shovel a spade. but reality is what it is
and it was core that instigated the august 2017 event

2. its a washy washy not true blocksize increase. infact with new scripts and bloated tx formats. the byte per tx average shows that we are not getting any better tx count than before.. EG 2010 even satoshi calculated a potential of 4200tx a block (7tx/s)
show me one day where we got even close to 600k tx a day.
(if 4mb was true increase we would have potential of 2.4m tx a day.. but no segwit cant even aid in surpassing the 600k limit)


3. linear sighash of legacy format is of no issue. the funny part is that core deem it ok that a block can actually contain just 5 tx's of thousands of sigops... but here is the thing. reduce the block sigop limit. reduce the tx sigop limit... linear sigops doomsday is fixed. there is no need at all to give anyone 20% fill of a block. there is no need at all to give anyone thousands of script bloat allowance.

4. segwit has not addressed the problem. the legacy limits and risks are still the same now as 2015. segwit has not fixed legacy issues. it has just told people to stop using legacy transactions. its like war on guns. no on has taken guns away they just made a new neighbourhood that is antigun and telling people to move house.

5. new segwit opcodes have the ability to reintroduce malleation in segwit tx formats, so to pre-empt a reply about that, sorry but malleation is not fixed. plus malleation has not been fixed nor never was fixed for legacy

6. the only purpose of segwit, is a tx format thats compatible with LN's needs. it has nothing to do with all the half baked promises of fixing bitcoin issues. segwit is a gateway tx format to move people to a different network, away from bitcoins blockchain

[figmentofmyass]

its a washy washy not true blocksize increase. infact with new scripts and bloated tx formats. the byte per tx average shows that we are not getting any better tx count than before.. EG 2010 even satoshi calculated a potential of 4200tx a block (7tx/s)
show me one day where we got even close to 600k tx a day.

unwilling to compromise and unwilling to see any of the benefits. this attitude won't get you far, franky. but you already know that.

segwit only activated due to a hard fork.
the august 2017 was a controversial hard fork. you can call a hat a cap. you can call a shovel a spade. but reality is what it is
and it was core that instigated the august 2017 event

i remember it quite well. nobody gave a shit about the bcash hard fork then, and nobody cares about it now. the miners quickly activated segwit under threat from the UASF and once segwit locked in, the price went vertical.

linear sighash of legacy format is of no issue. the funny part is that core deem it ok that a block can actually contain just 5 tx's of thousands of sigops... but here is the thing. reduce the block sigop limit. reduce the tx sigop limit... linear sigops doomsday is fixed.

why would limit sigops across all transactions when we can craft new transaction types that directly solve the scaling problem? i don't understand you big blockers with your insistence on clinging to bad design.

the legacy limits and risks are still the same now as 2015.

that's the point. the risks posed by legacy transactions are fine now but not necessarily at larger block sizes.

plus malleation has not been fixed nor never was fixed for legacy

good luck hard forking bitcoin to accomplish that.

6. the only purpose of segwit, is a tx format thats compatible with LN's needs. it has nothing to do with all the half baked promises of fixing bitcoin issues.

that's one of several purposes. an important one though, no doubt.

[franky1]

seems "figmentofmyass" is as fifth elements quotes him ''super green"

1. i am not a bigblocker(gigabyte by midnight). i am infact informing you of many ways in which more tx's can be performed without needing to "big block"

2. the august 2017 was not a bitcoin cash hard fork.. even you slipped up and admitted that in the very next sentance..
"the miners quickly activated segwit under threat from the UASF."
UASF was not actually a SF. that was the spade calling itself a shovel.

i have no clue why you keep trying to make things sound like bitcoin cash initiated x,y,z.. seems your more intersted in the propaganda politics than BITCOINS FEATURES being stifled.

3. segwit has not solved the scaling problem.. take away the miscount wishy washy code. and actually look at real hard drive bytes per tx. (not the washy vbytes) and you will see segwit has not scaled a dang thing
real hard drive space, real transaction counts. do the math

4. your link.. pfft
malleation not fixed
linear scaling not fixed
reducing UTXO growth not fixed

here is the ultimate funny. segwits sole purpose is a gateway format for LN.
LN requires locking funds. and splitting them up over many 'channels'(addresses)
this actually causes more UTXO's AND those UTXO's being locked and unspendable for longer.

try to run scenarios and use things and check stats. try to avoid promotionally written material made to only suggest half promised benefits. look for the issues. they are not hard to find.

P.S
if segwit is so great and perfect, why does the segwit master himself pieter wuille avoid asking for donations using segwit. why is he only advertising legacy addresses.
bitcoin.sipa.be    bottom right
Tips and donations: 1NrohbDoPkARCGdjvtnXbwFLwoBH86pskX

why did BTCC the main segwit mining pool advocate right up until the day of their demise only want their block rewards on legacy addresses.

if you really think devs are that smart.. read this example from the segwit master
"Nodes can already prune history, and I think in the future nearly every node will. This does not impact security, as they still download and verify everything."

if everyone has pruned. where does everyone get the full data to "still download and verify"

i only mention it as a wakeup call that ignoring bitcoin issues purely to defend developers is foolish as devs are temporary entities that are not actually achieving the community goals of improving bitcoin. hense thir need to push people to other networks

[thecodebear]

i like how this turned into a blocksize scaling debate hahaha

But seriously, the number 1 change to future proof bitcoin and allow for greater adoption would be some sort of gradual increase in blocksize. Not huge blocks, but there is rule of blockchain that says 1mb is the perfect size for 10 minutes blocks. That's just the size that was set years ago. It needs to and should be increased to allow for greater adoption - both on-chain and off-chain. And it is not a reasonable argument to say "just use an altcoin/fork" instead, as that is saying well if you want Bitcoin to be usable in the future it won't be so use something else. The point is to keep bitcoin usable! And hard-forking does not make bitcoin not bitcoin, as long as people accept that it is bitcoin, just like the coins that fork all the time are still the same coin because the community recognizes the updated fork as the new version of the same coin/network.

So yeah, the number one thing to change about bitcoin is absolutely allow for modest blocksize increases to allow bitcoin (and LN) to grow. No bitcoiner should be proud to say we're gonna have triple digit or quadruple digit on-chain tx fees in the future (that or people will just move away from bitcoin because of the fees). With the current blocksize those are the only two options in the future - triple/quadruple-digit fees that make bitcoin on-chain transactions only useful for millionaire/billionaires moving money around or people simply abandon the coin because its unusable at a certain scale. We all want bitcoin to succeed, some of us just want it to still be usable at mass adoption! And no LN will not solve on-chain tx fees because you need to make on-chain txs to get onto the LN. If anything on-chain txs will increase with the adoption of the LN.

[rdluffy]

For me I would change the algo to CPUs and GPUs only, not a single asic mining BTC and the algo would change twice a year to not have any asic mining BTC

[Kakmakr]

I would add some kind of mixer service to increase the anonymity of transactions, because pseudo anonymity is not enough protection against private companies that developed Blockchain analysis tools to track Bitcoin users wealth and private financial data.

I know there are currently people working on projects like this, but I think they will have to hard fork to add a feature like this and we will end up having a new Alt coin or some side-chain solution like the Lightning Network.