Post your SegWit questions here - open discussion - big week for Bitcoin!

[IamNotAnonymous]

Hi
I have a wallet software ( https://github.com/limpbrains/django-cc ) built on top of the bitcoind. It allows you to create multiply wallets and handle their balances separately.
It uses api calls, such as gettransaction, sendmany, getblockhash, listsinceblock and some other.
Will output of api change ?
How do you think, will segwit break something for me, or not ?

You do need a further research to understand how the api change ? It depend on the usefulness.

[1714182870]

1714182870

[squatz1]

Anyone have a site in which we can see the amount of miners / people that have moved to helping to activate Segwit? It'd be nice to actually see this in some graph form.

Hoping for the activation of Segwit though.

[BurtW]

Anyone have a site in which we can see the amount of miners / people that have moved to helping to activate Segwit? It'd be nice to actually see this in some graph form.

Hoping for the activation of Segwit though.

Is this what you are looking for:

http://nodecounter.com/#bitcoin_classic_blocks

[achow101]

Anyone have a site in which we can see the amount of miners / people that have moved to helping to activate Segwit? It'd be nice to actually see this in some graph form.

Hoping for the activation of Segwit though.

This may be helpful: https://bitcoincore.org/en/segwit_adoption/

[Anon TumbleBit]

I assume that SegWit is so perfect, but why most miners refuse to use it? It is 3 months after SegWit released, but only 20% miners agree to switch in SegWit mode, what is wrong? What do they think?

[achow101]

I assume that SegWit is so perfect,

That's a bad assumption to make. No software is perfect, no solution to scaling will be perfect.

but why most miners refuse to use it? It is 3 months after SegWit released, but only 20% miners agree to switch in SegWit mode, what is wrong? What do they think?

A lot of the problems seem to stem from miscommunication and lack of communication between developers and miners. It seems that some miners have taken a grudge against the developers (all of them in general) for not consulting them when devising scaling solutions.

[HostFat]

I assume that SegWit is so perfect, but why most miners refuse to use it? It is 3 months after SegWit released, but only 20% miners agree to switch in SegWit mode, what is wrong? What do they think?

Miners agree on enabling segwit and mostly malleability fix IF the Core client also remove the the current block size limit.
They aren't enabling it because segwit leaves the block size limit in the hand of the devs of Core, and miners don't trust them and their promises anymore.

So, the Bitcoin Unlimited team is trying to give miners what they've requested. (and also segwit fixes)

[hurricandave]

Or maybe its because the developers keep trying to find ways to not share any additional revenue with the miners while increasing the data storage the pools will need and pitting conventional pools against SPV-(EMPTY BLOCK)-miners in china for conformations/propagation time.

[Fatman3001]

but why most miners refuse to use it? It is 3 months after SegWit released, but only 20% miners agree to switch in SegWit mode, what is wrong? What do they think?

A lot of the problems seem to stem from miscommunication and lack of communication between developers and miners. It seems that some miners have taken a grudge against the developers (all of them in general) for not consulting them when devising scaling solutions.

I really appreciate this acknowledgement of the problem. I would still love to hear what, if anything, is being done to remedy the situation.




Also, as I see segwit as a stepping stone towards a solid second layer solution, and part of the resistance in the community against segwit is due to this fact, could someone please give me an insight into the changes in incentives we'll see with such a solution?

I gather that tx's and fees will flow differently. Is there a clear view on how things like decentralization and fee structure will change?

Also, are there some less known positives with such a solution?

[hannusolo]

So the problem of the miners is that segwit won't change the block size, or at least the right to change will remain at the devs. But segwit helps by reducing the size of transactions so more transaction can be included in a block. Right?

Shouldn't it be easier to just vote for segwit to enhance the development of BTC and than later argue about block size?

[achow101]

So the problem of the miners is that segwit won't change the block size, or at least the right to change will remain at the devs. But segwit helps by reducing the size of transactions so more transaction can be included in a block. Right?

No. Segwit actually redefines the block size as block weight and this will increase the block size. The actual size of the block data that your node downloads will be larger. In terms of the current transaction and block definitions, then yes, it reduces the size of the transaction and thus more transactions can fit in a block.

[-ck]

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.

A lot of the problems seem to stem from miscommunication and lack of communication between developers and miners. It seems that some miners have taken a grudge against the developers (all of them in general) for not consulting them when devising scaling solutions.

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.

Miners agree on enabling segwit and mostly malleability fix IF the Core client also remove the the current block size limit.
They aren't enabling it because segwit leaves the block size limit in the hand of the devs of Core, and miners don't trust them and their promises anymore.

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...

Or maybe its because the developers keep trying to find ways to not share any additional revenue with the miners while increasing the data storage the pools will need and pitting conventional pools against SPV-(EMPTY BLOCK)-miners in china for conformations/propagation time.

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.

[hannusolo]

So the problem of the miners is that segwit won't change the block size, or at least the right to change will remain at the devs. But segwit helps by reducing the size of transactions so more transaction can be included in a block. Right?

No. Segwit actually redefines the block size as block weight and this will increase the block size. The actual size of the block data that your node downloads will be larger. In terms of the current transaction and block definitions, then yes, it reduces the size of the transaction and thus more transactions can fit in a block.

Thanks. Now I get it

[classicsucks]

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'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 

[amaclin]

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

... 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?

[Quickseller]

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

... 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?

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.

[-ck]

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'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  

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.)

[bitsolutions]

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 

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.

[amaclin]

there are many large bitcoin related businesses that conduct very large amounts of bitcoin related business

count hashrate, not amounts, not noses

[Seal]

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...