SegWit (26.8%) vs Bitcoin Unlimited (32.2%)

[AngryDwarf]

Would someone build me a version which runs both SegWit and BU?  Please.

One outcome is that the cold war will de-esculate and you will get exactly that.

[1714615864]

1714615864

[1714615864]

1714615864

[1714615864]

1714615864

[franky1]

I run a 0.13.2 Core full node with 8 outgoing and 52 incoming connections and am thinking about going to 0.14.0 soon.  I have run a BU version in the not too distant past but I really want both SegWit and BU.  I suppose I could alternate every so often but that seems cumbersome.  I could run two full nodes but I just want to run one.  Would someone build me a version which runs both SegWit and BU?  Please.

trying to be my very unbiased

no point running v0.14
... unless you want to do tests on testnet. as thats the only way to really play with segwit.

if you want a node just for normal usage on bitcoins mainnet, no point running v0.14

and lets say sgwit activated later. it does not fix anything at activation.
however WEEKS after activation core will release a version that includes the segwit wallet (yep segwit keys cannot be used in 0.13.X or 0.14).
v14 only includes native key usage on mainnet.

normally best to wait it out. for that post activation version to save you hassle of redownloading twice in x months

0.13.2 shows the 'support' if thats what your hoping. and 0.14 doesnt support any less or more the 'vote'
all im saying is if your just a normal user and not looking to do tests on testnet involving segwit. no point downloading an update now to just download again another later if your hope was to use segwit on the mainnet

[AngryDwarf]

I've run 0.13.2 or BU over the same blockchain/wallet directory without issue. I run BU to show my support for the need for larger blocksizes.

[franky1]

BU isn't the way to solve the block problem, and it is becoming less of a problem as spending habits change for bitcoin. My worry is a split and a crash in value.

learn consensus.

oh did you know that segwit at activation bans certain nodes from being upstream and bans certain blocks that are not in a segwit format.

its worth learning these things.

soft doesnt mean safe. soft just means node bypassed

[AngryDwarf]

Not doing anything does not solve the block problem either. Over 16m BTC are held on native keys, so segwit doesn't even solve the solution in the near term.
We are talking years of effective 1MB blocks even if segwit gets approved.

[Carlton Banks]

I've run 0.13.2 or BU over the same blockchain/wallet directory without issue. I run BU to show my support for the need for larger blocksizes.

That makes little sense Dwarf.

BU comes with no guarantees about larger blocks, it simply moves the shouting from the forums onto the network. Guess what? Wildly diverging opinions will be expressed, and that can only be resolved with forking into separate chains, which is what BU more or less does guarantee. You'll get bigger blocks. And several forked BU coins with which to use them. And an exchange rate to reflect that volatility.



Segwit literally does guarantee larger blocks, it's a defined 4MB hard limit. But because it upholds consensus instead of making it easy to break, there is no added risk of forking along blocksize lines.



It's true that the Bitcoin Core wallet doesn't support Segwit keys out of the box right now. That's because the Core devs want to use the initial few weeks after activation to continue testing, and to make sure that a large enough proportion of regular nodes are ready to accept the new, bigger blocks.

Over 16m BTC are held on native keys, so segwit doesn't even solve the solution in the near term.
We are talking years of effective 1MB blocks even if segwit gets approved.

What makes you think that?

[franky1]

It's true that the Bitcoin Core wallet doesn't support Segwit keys out of the box right now. That's because the Core devs want to use the initial few weeks after activation to continue testing, and to make sure that a large enough proportion of regular nodes are ready to accept the new, bigger blocks.

be honeest, if you dont know, just try not to act lik you know.

the reason they havnt added the ability. is the risk of an 'anyoncanspend' attack if segwit keys were used prior to activation.
the delay of weeks is to ensure enough segwit blocks are produced to avoid deactivating. and also to get the native nodes reset as downstream by banning the upstream nodes to ensure other attacks cant be played out

Over 16m BTC are held on native keys, so segwit doesn't even solve the solution in the near term.
We are talking years of effective 1MB blocks even if segwit gets approved.

What makes you think that?

46million unspent outputs

[AngryDwarf]

Over 16m BTC are held on native keys, so segwit doesn't even solve the solution in the near term.
We are talking years of effective 1MB blocks even if segwit gets approved.

What makes you think that?

46million unspent outputs

Thanks. I think this has been explained several times in several threads already, but I suppose some people either do not read what they are not willing to read, or they do not understand how to explain why it is not the case.

[Carlton Banks]

46million unspent outputs

Thanks. I think this has been explained several times in several threads already, but I suppose some people either do not read what they are not willing to read, or they do not understand how to explain why it is not the case.

You haven't thought through the implications, there's no need to scare yourself.

At 46 million outputs, that's probably around 300 B each (some will be using compressed keys, others uncompressed keys, others multisig). That's roughly 13 GB of transactions in total. At 1MB blocks, it takes 13,000 blocks to move them all across. That's only around 6-8 weeks.

Not everyone will move (Satoshi's coins may never move, for instance). And everyday commerce isn't going to hold that back; I'll be giving out Segwit addresses for people to pay me, for instance. The shift to Segwit keys can and will be folded into everyday use, there's not much incentive to continue to use the legacy keys, so people will stop providing them for others to use.


So, you're scaring yourself unnecessarily. I think the price action might be getting to your nerves, calm down.

[AngryDwarf]

So, you're scaring yourself unnecessarily. I think the price action might be getting to your nerves, calm down.

Must be https://bitcointalk.org/index.php?topic=1820153.msg18140189#msg18140189

[franky1]

That's only around 6-8 weeks.

basic maths already done of 2 months(if everyone moved at same time).
but as CB said due to normal transactions wanting their space too . it will be more than 2 months.

oh. and need we forget malicious spam attackers WILL stick with native keys. after all why would they give up their weapon and disarm themselves

[Carlton Banks]

So, you're scaring yourself unnecessarily. I think the price action might be getting to your nerves, calm down.

Must be https://bitcointalk.org/index.php?topic=1820153.msg18140189#msg18140189

Then why are you so frightened of the truth about Segwit keys?

Like I said, 6-8 weeks is all it would take to move all 14 million outputs, and not all will move straight away anyway, so it will take less than that. No-one will want the old P2PKH & P2SH keys, as they'll be more expensive to spend from once you get your money. Regular business will switch to providing Segwit keys very quickly. So there's very little to worry yourself about

In a month or so, a majority of outputs will be moved to Segwit keys already. No need to worry about Sigops attacks, the exact same attack is possible now, as it's limited to 1MB now and after Segwit. Spamming with old keys won't really work, miners will happily accept higher fees for old keys, or reject old keys (they can make more money if they choose to confirm transactions that fill the whole 4MB limit). Nothing forces miners to accept spammy or attack transactions, as you can see by how much spam gets kicked out of miner's mempools right now.


You're all a bunch of worriers here, you just need the correct information to set your hearts at rest We'll be able to enjoy the ~2MB blocks that Segwit keys will initially yield after only a few weeks, those are the facts.

[franky1]

Then why are you so frightened of the truth about Segwit keys?

Like I said, 6-8 weeks is all it would take to move all 14 million outputs, and not all will move straight away anyway, so it will take less than that. No-one will want the old P2PKH & P2SH keys, as they'll be more expensive to spend from once you get your money. Regular business will switch to providing Segwit keys very quickly. So there's very little to worry yourself about

In a month or so, a majority of outputs will be moved to Segwit keys already. No need to worry about Sigops attacks, the exact same attack is possible now, as it's limited to 1MB now and after Segwit.


You're all a bunch of worriers here, you just need the correct information to set your hearts at rest We'll be able to enjoy the ~2MB blocks that Segwit keys will initially yield after only a few weeks, those are the facts.

^ failing to stroke the sheep to sleep

if spammers fill the base block with native keys. there is no "extra" room

the witness is just a ratio of the base.
its not like the whole segwit tx can sit in the 1mb witness area safe as a separate room of a house.

its analogically more like more footspace on a plane, rather than needing to buy 2 seats to put ur feet up
(base=seats, witness=foot area, other weight left=baggage area (for future features that can append onto the witnes later but useless now)
the issue is:
1.stampede for seats fills the plane
2.the new tx's doesnt reduce mempool utility (full txdata and witness still take up mempool space)
3. if fat natives buying up 2 seats to put their feet up, then anorexic segwiters have to wait longer at the terminal

seems CB thinks he can just not worry about the seats (base block) and just have his entire body on the floor (witness area) or sit in the baggage area (empty weight)

not even sure why he brings up the 4mb number as thats just an un-utilised buffer that cant be filled with anything for a long while.. at best hope is ~2mb
the 4mb weight is not 4mb of capacity. its just extra baggage space for future features

[AngryDwarf]

not even sure why he brings up the 4mb number as thats just an un-utilised buffer that cant be filled with anything for a long while.. at best hope is ~2mb
the 4mb weight is not 4mb of capacity. its just extra baggage space for future features

I'm sure that 4MB buffer won't be fully utilised by midnight, unless somebody works out another exploit.

[AliceWonderMiscreations]

My understanding is a one line patch to core will make it compatible with block created by BU miners.

So those who do not trust the BU developers can still use a core client with bigger block nodes.

[AliceWonderMiscreations]

SegWit does look like is has a tremendous advantage to hardware wallets, so going to SW is something I support even with bigger blocks, hence why I very well may run a core client but with support for bigger blocks. I build my own from source (have for years) so that's not hard for me, perhaps we should start making some binaries built from core code but supporting bigger blocks available alongside the BU binaries.

[AgentofCoin]

My understanding is a one line patch to core will make it compatible with block created by BU miners.

So those who do not trust the BU developers can still use a core client with bigger block nodes.

Not really. The BU client protocol changes are more complex than just a CORE "blocksize" patch.
Also, CORE currently has things implemented that are not in or not allowed in BU.

In theory, after a BU hardfork with a surviving chain, certain implementations like CPFP and RBF
are not allowed to be used since they "harm" the reliability of zero confirmation txs (oxymoron IMO).

This is my understanding.

[AngryDwarf]

SegWit does look like is has a tremendous advantage to hardware wallets, so going to SW is something I support even with bigger blocks, hence why I very well may run a core client but with support for bigger blocks. I build my own from source (have for years) so that's not hard for me, perhaps we should start making some binaries built from core code but supporting bigger blocks available alongside the BU binaries.

My unease of segwit as a soft fork is that it creates a two tier node network and introduces a lot of technical debt. Plus non mining nodes need to advertise the fact that they are willing to accept bigger blocks to give the confidence to miners that they can create them without them being orphaned.

[franky1]

SegWit does look like is has a tremendous advantage to hardware wallets, so going to SW is something I support even with bigger blocks, hence why I very well may run a core client but with support for bigger blocks. I build my own from source (have for years) so that's not hard for me, perhaps we should start making some binaries built from core code but supporting bigger blocks available alongside the BU binaries.

the funny part is.

making bigger blocks doesnt need rocket science.
as you say its just a couple lines.

so when you hear "its just a clone of core with some tweaks" turned into "they cant code"
the real mindset should be

simple fixes dont need complete re-writes.

so although aliceWM you may run a core client with support of bigger blocks . your essentially making XT or classic.
if you make it dynamic. thats essentially BU

and instead of people seeing it as 'simple solutions dont need complete re-writes'. you will be hit with the same 'you cant code' rhetoric
and if you did rewrite ever line.. youll then be hit with 'not peer reviewed by king gmaxwell'

..
what you want to do is exactly what has been done.. take core tweak it and release it.
but all its been met with is doomsday rhetoric because king gmaxwell has not approved it

[franky1]

Plus non mining nodes need to advertise the fact that they are willing to accept bigger blocks to give the confidence to miners that they can create them without them being orphaned.

soft consensus (pool only)
or hard consensus (node or pool)

both actually need node approval. otherwise its orphan hell.(yep after activation segwit will stop native blocks bing built ontop of segwit blocks)

going soft just means only pools get to OFFICIALLY vote. but pools will UNOFFICIALLY wait for safe number of nodes even if nodes dont get OFFICIAL vote

segwit going soft is more about segwit alligned at the top of the network as the upstream filters(already set up (FIBRE).
segwit nodes will also white list other segwit nodes to receive segwit blocks blacklisting non segwit nodes(thus no old node being upstream)to then white or blacklist non segwit nodes downstream of who segwit wants to filter a block to. into a sesspool of nodes where some have been pruned. some have witness some dont. why by those nodes wont really communicate with each other due to lack of full data and other things.
(hense sesspool)

meaning the only true real validators are the upstream filters.
leaving the other nodes downstream as just unnecessary nodes, faking the true FULL VALIDATION node count. right up and to the point where the upstream nodes just blacklist all native nodes because their "old, pruned non full validators".. to then force native nodes to upgrade to segwit or be dropped out. (much like nodes refuse to talk to anything prior to v0.8 )

however because a bigger blocksize node uses normal block formation that doesnt need to be translated. doesnt need nodes to be in a certain order doesnt need to intentionally ban nodes nor does it need to PREVENT relaying new style unconfirmed tx's to old nodes to avoid new attack vectors.

the network of nodes allowing bigger blocks are all on an even playing field.

and all of this could have been achieved years ago in either GUI as an new options tab where users could adjust acceptable blocksize or a new RPC call in the debug console to change settings. thus users wouldnt need to beg devs after that for constant tweaks everytime the size increases because users could have done it themselves to stay on the network rather then becoming unsynced if a blocksize change occured


basically if segwit activated now
their would only be 3000~ true full validation nodes, other 3000 deemed as non full validation relay nodes
and also 75% of pools blocks would get orphaned and 75% of pools own nodes would be banned
..
if segwit waited for 95% pools(where by node count didnt change). 5% of blocks wold be orphaned and 5% of pools would be banned
and still only 3000~ real full validation nodes.. other 3000 deemed as non full validation relay nodes