Topic: Post your SegWit questions here - open discussion - big week for Bitcoin! - page 19. (Read 84845 times)

I feel sorry for you. You've also been fallen into the BS fee trap.  Do the math: Fees are just not needed for the next years...

The largest river in the world is DENIAL.


At least you're looking for solutions, even if there is "no problem".

You cannot engage because you are continuing to exaggerate and to make things up.  Yes, blocks are still full, but transactions are going through and fees remain relatively low. and we are still achieving secure immutable decentralized value storage and transfer of value.  This bitcoin thingie is world changing, and even if there is no solution (such as seg wit or larger blocks), bitcoin brings a lot of value, even in its current state.  So don't be trying to suggest that bitcoin needs to compete with Visa or with some payment system, when it achieves a whole other level of added value, even in it's current state and even if some variation of its current state were to continue for the next 20 years.

Remember: BU and Segwit are not the only two choices in the world... 2MB hard fork is VERY easy from the software side. The network must consent, but it has been done successfully in the past, in one day. No politics in that statement.


At this point, lines are drawn, and people are unlikely to accept Segwit, regardless of whether a blocksize increase is included or not.


JayGuanGee, [facepalm], I can't even engage with you, please look at this chart and tell me there is no problem again: https://blockchain.info/charts/mempool-size?daysAverageString=7×pan=all  (7-day average mempool size).

In reality SegWit is cleaning up a lot of technical debt with the transaction format and it's simplifying things for wallets that use it. SegWit simplifies transaction handling complexity by fixing the malleability issue fundamentally, this should reduce defects in all wallets that use it.


SegWit(or a similar transaction format fix) is effectively a prerequisite for any block size increase hard fork due to the sighash issue. BIP109(Classic) ended up using the same limiter proposed in BIP101 which has issues(it makes testing of some codepaths more difficult for one), funny enough even Gavin argued against the approach ultimately used in BIP109, they used it anyways after realizing some pools used transactions over 100,000 bytes for payouts. SegWit is also backwards compatible so unlike a hard fork existing software doesn't have to rush code out without a chance to properly test. Rushing and skipping testing/code review is something that certainly increases defects in the software industry.

Ongoing and crazy attempts to shift the burden and to suggest some kind of emergency or facts that do not exist - namely, there is no emergency need to increase the blocksize that seems to be implied.

In other words, if there is no scaling problem, then what is the need for 2mb blocks?  Why implement something that is not needed?

Seg wit addresses issues other than just scaling, and has already been tested and vetted and is there and available to signal for adoption.

No one said that, did they?

On the other hand, "minor" changes in the BU code even before their hard fork activation have already led to invalid block generation.

I agree that Bitcoin core has had a lower rate of bugs per lines of code than industry average, but when you increase complexity, and particularly when you increase the number of lines of code, you create defects. It's a hard and fast rule of the software industry, ask anyone (except a Java programmer).

I find it very hard to believe that implementing Segwit support in existing software will be easier than a 2MB hard fork, please site a source for this.

Wow!!!!!!!   That is a very great explanation of reality, and you were even nice to the purposeful FUD spreader.   

Thanks for the clarification achow101. That gives me a few more questions to ask about Lightning... I'll save those for a more relevant post though. I'm starting to see how clever SegWit is now in what it does. Definitely a strong scaling option... coming from someone who was previously in the 2mb only camp.

You're confusing Segwit with Lightning. Segwit does not touch confirmations or anything like that, it only affects the data itself. The number of confirmations required will still be the same.

Lightning is different and allows instantaneous transactions because the transactions actually happen off chain. The guarantee that your transactions are final are done through incentives and retaliation. The only onchain parts of lightning are the opening and closing of payment channels.

I have a technical question on how SegWit works:

With current transactions, the number of confirmations acts as a guarantee of the Bitcoins deposited. Many services require between 3-6 confirmations to show that funds have been deposited.

With SegWit, does this logic still remain?

I may be confused with what SegWit and Lightning does. I've heard some mention that it can give an instantaneous guarantee of fund transfer, however I don't see how this would work without confirmations of the original transaction...

count hashrate, not amounts, not noses

Bitcoin Core does not follow normal industry standards in regards to defect rates, this is due to a huge emphasis on code review and testing by domain experts in cryptography and secure programming(a large amount of code written for SegWit is testing code), and when it comes to consensus critical code like SegWit extra care is taken during testing to prevent defects beyond what is typically done in areas of the codebase that aren't consensus critical. SegWit in Bitcoin Core is some of the most thoroughly tested code in the Bitcoin industry and is unlikely to have any bugs that would cause serious issues.

When it comes to support for wallets most rely on well reviewed 3rd party libraries that are ready to support SegWit. For some wallets like hardware wallets SegWit helps a lot since it fixes issues with the transaction format.

Interestingly enough a lot of the code that was written for SegWit would also have needed to be written in the event of a hard fork, for example the preferential peering code written for SegWit would also be needed for any hard fork. Due to the difficulty in activation coordination and other issues such as the sigop/sighash scaling issue there's no such thing as a simple 2MB hard fork.

No I can't be 100% confident by myself, but luckily we have far more developers who have been doing almost a year of actual hard testing on testnet validating its stability.

On the other hand you're also grossly exaggerating the simplicity of a hard fork by not describing the work required to make that one line of change work (it's also more than one line but that's irrelevant.)

What you (amaclin) wants, and/or will accept really does not matter, you are just a single user who conducts (from what I can tell) very little business when compared to all of the bitcoin related business conducted.

From what I can tell, there are many large bitcoin related businesses that conduct very large amounts of bitcoin related business, and give bitcoin it's value that support a larger maximum block size. The same appears to be true for a large portion of bitcoin users, who also collectively conduct large amounts of bitcoin related business.

There is also a decently sized minority of Bitcoin miners, who provide security to Bitcoin who are very actively supporting a maximum block size increase -- I suspect this minority will increase over time and eventually become a large majority.

OTOH, a minority of miners are actively supporting SegWit (that is a large enough of a change so that it would probably be a bad idea not to upgrade if implemented, making it not unlike a HF). There are many Bitcoin related businesses who are ready for SegWit, but are not necessarily actively supporting SegWit. I have also seen one or two bitcoin related businesses whose political views make me believe that they are opposed to SegWit have had their name massively slandered on what I consider to be SegWit-friendly media sources, for them to subsequently support SegWit and have their name cease being slandered on said media sources -- well I will just leave it at that.

... aaaaand a requirment for several millions users to accept new consensus rules and install new software.

Why should I accept your new consensus rules? Why do you think that you are smart and I should obey?

I'm sure that you are a solid developer since you run a mining pool. Are you 100% confident that changing 4743 lines of code deep in the Bitcoin codebase won't have any issues?  And what about wallet and 3rd party software? When you add it all up, we're looking at tens of thousands of lines of code changes, which guarantees roughly 150-500 bugs (industry average) in all of this software, of which 2-5 are potentially catastrophic...

A hard fork to 2MB would involve one line of code change and some late-night sweating and swearing for a week 

Thanks. Now I get it

These three posts combined subtly actually have all the issues as to why miners haven't started signalling support and give the best summary for why we're currently in a stalemate.

Not quite true, they have been consulted at various times, and ran their own meetings, and most of the time were unconvinced about segwit and kept pushing for bigger blocks.


While some pools were willing to accept segwit straight up, this was the compromise position a lot more of them adopted - they would be willing to adopt segwit if the promise of bigger blocks was still kept. The fact that there is actually no firm bigger block hard fork on the definite roadmap is why the miners are still sitting on segwit adoption.

As for what the miners objection to segwit is...


Not many people have explicitly said out loud what the miners' real objection is and basically the fact is that transaction volume can increase without a proportionate increase in reward for miners. They've invested hundreds of millions of dollars in hardware to secure the system for us on the basis of relatively predictable rewards as compensation and segwit has the potential to dilute this - lightning network will amplify this issue and segwit makes LN easier. The actual magnitude of loss of reward is greatly exaggerated by many, and adding conspiracy theories of redirecting rewards to blockstream are not helping the situation. Additionally, doubling the block size doesn't mean double the transaction fees since there is less competition for fees with more space available.

Segwit IS a technological advancement, but make no mistake, any arguments about complexity being the issue versus the "simplicity" of just increasing the blocksize are a red herring and diverting attention away for why the miners are reluctant to move forwards with it. I've voted for it, but my pool is less than 0.1% of the network, and I believe the network needs a multi-pronged approach to increasing bitcoin's ability to process more transactions, and that transaction volume will more than offset any theoretical loss of reward from segwit. However that's not what the large pools believe. Campaigning by vocal but powerful mining pools is largely preventing them getting on board.