Pages:
Author

Topic: The Barry Silbert segwit2x agreement with >80% miner support. - page 43. (Read 120014 times)

legendary
Activity: 3892
Merit: 11105
Self-Custody is a right. Say no to"Non-custodial"
Strangely, it seems BTCC and BTC.com have changed their minds and are no longer signalling New York Agreement in their blocks.  Still above 80% in total, but only just.  Anyone have any news on the sudden change of heart?


From where do you get your information?

Both of them show up on the coin.dance listings.

https://coin.dance/blocks
 
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
Strangely, it seems BTCC and BTC.com have changed their minds and are no longer signalling New York Agreement in their blocks.  Still above 80% in total, but only just.  Anyone have any news on the sudden change of heart?
legendary
Activity: 2674
Merit: 2965
Terminated.
This should help at least to understand that SW is NOT a long term on-chain scaling solution at all, rather a compromise and a tech sneak to get in bitcoin with a soft fork, rather than a hard upgrade.  Might buy time, for what sake?
If you ever thought this, you're an idiot. SW is the first stepping stone towards long term scaling. A block size increase, in comparison, is nothing and aside of throughput effectively useless. Sacrificing a part of decentralization for the sake of some profit is what "big blockers" is all about.

BW Pool has started signaling Segwit: https://www.blocktrail.com/BTC/block/0000000000000000006738d26d61dfa2020379104d55d5e77a3b5ae90fe34787
hv_
legendary
Activity: 2534
Merit: 1055
Clean Code and Scale
I first thouht this segwit thing is a simple thing but it's much more complicated than I've ever guessed. And the block size thing is also very hard to understand and I'm still looking a an easy source to understand the whole idea.

In simple terms.
  • There is a limit to the amount of information a block is allowed to contain.
  • Segwit changes how we calculate the amount of information in a block
  • By doing so, segwit allows for the creation of a block that contains more information than current blocks do.
  • Because a 1MB block will still be 1MB (with or without segwit), many people want to add an actual increase in block size (not just a reformulation of how size is calculated)
  • When you hear "Segwit will give us 3 MB blocks" it means the amount of information in a block will be the amount of information that would previously have been counted as 3MB (as the signatures are not part of the segwit counting)
That help any?

This should help at least to understand that SW is NOT a long term on-chain scaling solution at all, rather a compromise and a tech sneak to get in bitcoin with a soft fork, rather than a hard upgrade.  Might buy time, for what sake?
copper member
Activity: 2898
Merit: 1465
Clueless!
So what is the reasonable time for the network to be ready for a 2MB hark fork? 1 year? 2 year? 3 years?

Assuming bitcoin core just says 'thank you' for seg witness and then blocks any future 2mb block, 4 months down the road. (Sorry it is bitcoin devs of any flavor it is how they roll) Sad



legendary
Activity: 3808
Merit: 1723
So what is the reasonable time for the network to be ready for a 2MB hark fork? 1 year? 2 year? 3 years?
hero member
Activity: 574
Merit: 502
waiting to explode
I first thouht this segwit thing is a simple thing but it's much more complicated than I've ever guessed. And the block size thing is also very hard to understand and I'm still looking a an easy source to understand the whole idea.

In simple terms.
  • There is a limit to the amount of information a block is allowed to contain.
  • Segwit changes how we calculate the amount of information in a block
  • By doing so, segwit allows for the creation of a block that contains more information than current blocks do.
  • Because a 1MB block will still be 1MB (with or without segwit), many people want to add an actual increase in block size (not just a reformulation of how size is calculated)
  • When you hear "Segwit will give us 3 MB blocks" it means the amount of information in a block will be the amount of information that would previously have been counted as 3MB (as the signatures are not part of the segwit counting)
That help any?

Thanks, that helps.

And SegWit2x proposes to increase the block size too (not only information) to 2MB. Is that correct?
hero member
Activity: 1092
Merit: 552
Retired IRCX God
I first thouht this segwit thing is a simple thing but it's much more complicated than I've ever guessed. And the block size thing is also very hard to understand and I'm still looking a an easy source to understand the whole idea.

In simple terms.
  • There is a limit to the amount of information a block is allowed to contain.
  • Segwit changes how we calculate the amount of information in a block
  • By doing so, segwit allows for the creation of a block that contains more information than current blocks do.
  • Because a 1MB block will still be 1MB (with or without segwit), many people want to add an actual increase in block size (not just a reformulation of how size is calculated)
  • When you hear "Segwit will give us 3 MB blocks" it means the amount of information in a block will be the amount of information that would previously have been counted as 3MB (as the signatures are not part of the segwit counting)
That help any?
full member
Activity: 225
Merit: 100
I first thouht this segwit thing is a simple thing but it's much more complicated than I've ever guessed. And the block size thing is also very hard to understand and I'm still looking a an easy source to understand the whole idea.
hero member
Activity: 1092
Merit: 552
Retired IRCX God
...With Segwit+schnorr+2mb+Lightning+RSK+Mimblewimble+TumbleBit+Factom and more side-chains to come Bitcoin is settled for years to come...
It's a damn shame that most of that is not Bitcoin and meaningless.  Undecided
legendary
Activity: 4410
Merit: 4766
this week has proved one thing

89% pool agreement flagging is possible

segwit alone only got 10% in the first week and stalled around the 34% average of 6 months

2mb and segwit getting 89% in a week just goes to show all the chest beating from a particular group refusing to code 2mb was just wasting time. if only they released a 2mbsegwit in summer 2016 alot of drama could have been avoided


Your last paragraph is misleading.

The 89% is not signaling 2mb first.  They are signaling segwit first, and there is some contingency regarding the 2mb aspect of it, but don't mislead with your attempt to spin what is actually being signaled.  

By the way, a lot of us understand the whole ambiguity of this situation - in that some of the folks within the segwit2x are in fact wanting to argue that 2x is a given, when the only part that seems to be a given is the seg wit portion..

As already stated many times in this thread, the 2x part is contingent upon passage of time, code writing, testing and consensus.... the consensus component of the 2x, that you and some other big block nutjobs seem inclined to do, should not be assumed.

34% signalled from november2016-now for segwit first.. and 2mb at some unknown time in the future(no promise/hope)

now a new proposals has within just one week got over 89% signalling for segwit AND 2mb within 3 months of segwit.

meaning the desire for 2mb exists and the majority is happy to have it activated within 3 months.

though i agree there is a major difference between "flagging" and "handling".. meaning the 89% may flag purely to get segwit activated but only a small percentage may have the actual codebase running to cope with the 2mb part. (EG they just running core 0.14.x while false flagging for segwit2x just to get segwit active. but then backtrack during the 3 month grace of 2mb)

but thats something i highlighted in a few messages that got deleted. so it seems the only way to avoid deletion is if i word things a certain way.

Edit:
seems one of my messages didnt get deleted

now we just have to see if we can get nodes to download it (once its finalised and reviewed for RC) to then get a NODE consensus... for pools to have confidence that if they made such blocks.. the nodes wont still be running old code to reject blocks bigger than (1*1000*1000).

what people seem to forget is its not simply about waving a flag in a block.. its about consensus of nodes actually running code rules that allow bigger base blocks and consensus of pools creating bigger base blocks.


at this moment the empty sybil flag waving will just cause segwit to activate, but no guarantee of base blocks over (1*1000*1000) being accepted because from bitnodes stats, it shows no one is actually running the segwit2x (btc1) codebase to enforce it

i just wonder how many blocks are waving flags.. but not running the actual implementation that has the code. thus basically sybil flagging

real funny part is

all these bips pushing hard to "activate" segwit..

but no one will be able to actually make a segwit transaction when activated...
there will be delays and excuses of why people have to wait for blockstream to code a version which allows the segwit keypair wallet function on mainnet

so dont expect utopia on activation day.. plenty more drama after that of getting people to download yet another version after activation and then the cluster f**k of drama of getting people to move funds from legacy keypairs over to segwit keypairs
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
All said and done, if SegWit2x is implemented, how much does it increase the current network capacity? 2x? 4x? How much?
The most pessimistic estimates put segwit alone as averaging 1.7MB and then 2x will double it. The most possible would be 4MB from segwit (with all segwit transactions) and then 2x doubling that.
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
All said and done, if SegWit2x is implemented, how much does it increase the current network capacity? 2x? 4x? How much?

That largely depends on how quickly people make the switch to the new SegWit keypairs and utilise the new Witness space.  The minimum throughput increase is 2x, but I think we can realistically expect something like 3.5x in the near future (although not necessarily straight away) and possibly even more later as more people migrate keys.  Once people create the new format addresses, they will also have to transfer their funds from the old format to the new one (or to clarify, they don't have to, but if they want to transact more efficiently then it will help).  But everyone can't do it all at once, or it would likely create a backlog and jam up the network.  Probably best to wait for a quiet period before transferring your funds to P2WPKH addresses, if you feel inclined to do so.
hero member
Activity: 1092
Merit: 552
Retired IRCX God
All said and done, if SegWit2x is implemented, how much does it increase the current network capacity? 2x? 4x? How much?
Network capacity is infinite, and thus cannot be increased over the capacity of any given time.  Roll Eyes
hero member
Activity: 574
Merit: 502
waiting to explode
All said and done, if SegWit2x is implemented, how much does it increase the current network capacity? 2x? 4x? How much?
sr. member
Activity: 686
Merit: 320
83.3% support now with NYA in their coinbase so it's reached activation levels. This has been helped by bitclubnetwork joining them, however they've also actually started the real signalling on bit4/1 that activates it in mid-july. The reason is that the admin of that pool is the one that defined BIP91 and wrote the code for it so he's the first to use it as more than just proof of concept.

Well this is good news for a change!

You know, at this point Segwit2x is better than a chain split. Let's hope for the best.
With the segwit component assured now, indeed it is at this point, until we get to the 2x part of it. That's when the next battle begins.
As long as the segwit2x code gets released and has no major bugs, I doubt there will be a battle. People will take the path of least resistance and they're sick of this entire debate.

What I just don't get is that, as far as I've seen, "core" (at least some portion of it), doesn't have an issue with increasing the block size, just "slower". But they had lots of time to do that. I know they're trying to come up with some solution that would not require a hard fork but for some of us, we still view bitcoin as very young and experimental and don't really have a problem with hard forks. In fact, as a developer myself, I think not doing these sorts of things is a mistake as you limit your options and fail to learn any lessons from doing them. Some of the developers talk about doing emergency hard forks if required but if you haven't done some in a controlled manner, then you increase the risk of screwing things up. But I'm just one tiny opinion among many so not like my opinion really matters.
legendary
Activity: 3512
Merit: 4557
Impressive number so far, only 4% left.

I wonder what will happen after we get Segwit this summer and a smoooth HF 3 months 6 months later? War is finally over ore will Jihan push again for bigger blocks?

With Segwit+schnorr+2mb+Lightning+RSK+Mimblewimble+TumbleBit+Factom and more side-chains to come Bitcoin is settled for years to come.


legendary
Activity: 3892
Merit: 11105
Self-Custody is a right. Say no to"Non-custodial"
this week has proved one thing

89% pool agreement flagging is possible

segwit alone only got 10% in the first week and stalled around the 34% average of 6 months

2mb and segwit getting 89% in a week just goes to show all the chest beating from a particular group refusing to code 2mb was just wasting time. if only they released a 2mbsegwit in summer 2016 alot of drama could have been avoided


Your last paragraph is misleading.

The 89% is not signaling 2mb first.  They are signaling segwit first, and there is some contingency regarding the 2mb aspect of it, but don't mislead with your attempt to spin what is actually being signaled. 

By the way, a lot of us understand the whole ambiguity of this situation - in that some of the folks within the segwit2x are in fact wanting to argue that 2x is a given, when the only part that seems to be a given is the seg wit portion..

As already stated many times in this thread, the 2x part is contingent upon passage of time, code writing, testing and consensus.... the consensus component of the 2x, that you and some other big block nutjobs seem inclined to do, should not be assumed.
legendary
Activity: 4410
Merit: 4766
this week has proved one thing

89% pool agreement flagging is possible

segwit alone only got 10% in the first week and stalled around the 34% average of 6 months

2mb and segwit getting 89% in a week just goes to show all the chest beating from a particular group refusing to code 2mb was just wasting time. if only they released a 2mbsegwit in summer 2016 alot of drama could have been avoided
legendary
Activity: 3080
Merit: 1080
I hope Slush starts offering a voting option for SegWit2x soon. At the moment I don't see that option in the voting selection box. I previously voted for USAF but I will change it to SegWit2x once that choice becomes available to me.

Pages:
Jump to: