Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> block size increase is in fact very urgently needed [...] segwit's adoption is too low (7%)

7% in two months. What kind of adoption had you expected? Everyone won't switch over night, that's the whole problem behind why flag dates in distributed systems are hard, and why many people adocate backwards compatible changes whenever possible.

> if Core simply agreed to double the block size

Core is the name of the Bitcoin software. Perhaps you mean the Bitcoin community? The functionality needed to roughly double the block size was released last year and finally took effect in August. If that's too slow for your use case, then you are probably on the edge of where Bitcoin is useful anyway. It's hard to imagine any sort non-contentious hard fork planned and executed in less time than that, without endangering other people's money.



Ethereum has pulled off several hard forks, which they ran within weeks of finalizing the software. There's no reason Bitcoin couldn't do the same, especially for non-contentious forks.


Absolutely, and Bitcoin sort of had too. That knowledge isn't very helpful for managing changes today unfortunately. Today people actually buy stuff for Bitcoin and it's not very helpful to ask all economic activity to cease until a fork has settled down.

None of this is very relevant to the uptake of segwit transactions however, unless as a what-if scenario had segwit been done as a hard fork instead. That was the original intent of the proposal, if I remember correctly, and there was a lot of discussion at the mailing list exactly how this should best be deployed. Looking back at it, it is quite clear it could have been deployed quicker had another mechanism been chosen.


There's no need for economic activity to cease; hard forks can be very smooth. I agree that segwit should have been a hard fork.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: