Topic: SegWit (26.8%) vs Bitcoin Unlimited (32.2%) - page 4. (Read 8430 times)

You need to check your terms & conditions of your investment trusts to see what would happen should a bilateral split occur. Similarly, the same applies for online wallets or exchange accounts I should think.

At the moment there has been no announcement that native UTXO sets will become invalid if segwit activates. Leave your coins unmoved in your desktop or paper wallet and you will have an equal stake in both coins should a bilateral split occur.

Let's suppose SegWit is pretty good stuff but is falling behind in the public relations department.  Is there a way to incorporate SegWit without forcing everyone to move their coins to new SegWit-compatible addresses?  Or am I confused?

I'm lazy and don't want to have to do anything.  Besides which there will be the fees to be paid to get my investment/holdings moved to the new addresses.  If I don't move them then eventually they will become valueless, right?

If all of this is right then Satoshi's coins will either have to move (interesting) or become worthless (interesting).

If forced to chose at this very moment then I would be inclined to chose BU.  I would much rather see the two camps compromise.

How much does the https://bitnodes.21.co/dashboard/ User Agents chart matter to folks?

No, we give them, if we are passive.

It's the nodes who should be in charge, not the miners. Segwit really needs to address that issue, and not give power in miners hands.

If you let the miners take over, then the miners will effectively become the Central Bank of Bitcoin, that's a fact.

BU stays on the same playing field as classic, xt and about a dozen other implementations. and requires core to only rewrite a few lines of code to be on the same playing field

segwit requires everyone to rewrite thousands of lines of code to match segwit. or just download it from the blockstream controlled repo.

the minority(core) avoiding any rewriting/downloading/upgrading to either. will (either BU or SW activates) not remain 'full nodes' and it then becomes useless to be a node as you might aswell just be running an spv(lite) wallet

What I don't understand between Segwit and Bitcoin Unlimited is, whoever wins the race, will they get the complete control over the whole bitcoin network as well as nodes, or is it limited to something specific, like mining?

segwit started as an altcoin(elments project) with its own genesis block
segwit also rewrote thousands of lines of code just to become bitcoin compatible
segwit requires moving people away from native tx addresses to get segwit benefits
segwit requires banning and moving nodes around and orphaning native blocks

where as
BU is just a tweak to bitcoin code and people dont need to move funds just to get BU benefits
BU treats blocks under 1mb just as valid


so segwit should start a new genesis block

It might not be a bad thing.

Those who want it as a reserve currency would have it as a reserve currency and those who want it as use currency would have it as a use currency.

The free market could then decide which use is better.

There is a drawback though, in that the two currencies would have different values yet payment addresses would look the same. That would cause a huge problem for usage, so I I would prefer it if one of the philosophies started with a new genesis block and a different scheme for base58 payment addresses.

However if blockstream went to SegWit and BU did not, SegWit addresses look different so it may not be that confusing except when using non SegWit addresses on the Blockstream chain.

I think it's a horrible idea for exchanges to list BU as an altcoin, that only encourages the splitting of the network... It doesn't really matter if we go with SW or BU IMO, but the whole network needs to agree on one of the two, the network ending up in 2 forks is the worst that can happen to Bitcoin atm.  If it does Bitcoin will lose one of its biggest advantages, all the adoption that it has built up over the years.

It looks like Bitcoin Unlimited is now  28.5% while SegWit is only 26.2%, I'm starting to think that SegWit has no chance sadly. In the meantime, Coinbase, Bitfinex  decided to list BU as an Altcoin after the soft fork which I think is a good thing because If we ever have the exchanges and online services with SegWit, BU won't have much of a chance even though If miners are supporting it.

1mb blocks allow a max blockchain growth of ~52gb a year
over the last 8 years (mainly the very first 6 years) blocks were not full which is why right now 8 years of data is not ~420gb
EG before 2013 blocks were less than half filled

however because demand is at a constant 1mb full now. expect ATLEAST 52gb growth/year
-whereby it would be ~52gb a year if we just stay stuck at 1mb blocks.
-whereby it grows beyond 52gb/year depending on demand with more than 1mb blocks being allowed

When the block size increases, each block will be able to fit more transactions which means the competition to get your transaction into the block will not be as fierce and you will have have shorter confirmation times with smaller fees.

That's what will happen.

Regarding blockchain size, you can use a torrent to speed that up considerably. At least one use to be able to use a torrent to speed that up considerably.

Can someone explain me what will happen with blockchain size after 2MB blocks? Will it start becoming double as big as it is now, or just double as much transactions will happen at a time? Just wondering what will happen with full nodes in year 2020, because setting up full node today require average machine and a week of downloading, and chain doubles its size each year.

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

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

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.

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.

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

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

^ 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