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

Yes, any one of these parameters could be changed with consensus. Block times are less important than ensuring that transactions eventually get confirmed. The zero confirmation economic risk has shifted from the disadvantaged malicious double spend propagation attempt, to one of not getting confirmed at all due to full block capacity and forgetful mempools, or selective transaction node relay.


Most miners are not short sighted evil entities. They would rather process more transactions with lower fees as this increases the utility value of what they are mining.

Transaction capacity and confirmation time effects are part of the liquidity value of bitcoin.

Well, in the same way that it is not impossible that one decides to postpone the next halving, or to have blocks every 2 minutes.
BTW, that would be a much smarter solution: decreasing the block times.  10 minutes is awfully long.  Many newer coins have times of 1 or 2 minutes.  (note that this increases the amount of bitcoin in the end too if the block rewards remain...)

It becomes *more and more* difficult as fees rise and this parameter plays a bigger and bigger role in miner revenue.  It was 10 times easier to solve that issue one year ago than now.  Because the financial implications become more and more important every day.

I disagree with IMPOSSIBLE. I think the situation makes it difficult, and so potentially highly unlikely that protocol change can be implemented. That is not the same as impossible.

No, the fee war is a symptom of immutability dynamics.  When an economic parameter is established (number of bitcoins, block reward, block time of 10 minutes, block size....), any way of trying to modify it will give rise to non-consensus, meaning, disputes over ways to do so.  It will look as if the antagonists in the dispute are "holding back progress", but the disputes themselves ARE the trustless distributed consensus mechanism at work, that makes it IMPOSSIBLE to change the parameter.

we cannot 'give'. they take because they can due to their role and investment. you would do the same in their place.

Look, I think that BU is not a bad solution (I don't know exactly how the consensus mechanism works, I've read there are big fuck ups there, but this can be solved).  Monero is a crypto that has such a dynamic block size adaptation.  So this kind of technology not only exists, it is active and it works.

But my point is that BU, or any other solution (like Segwit), WILL NOT BE ADOPTED by consensus.  Not because it is bad, but because of the immutability dynamics.  I'm not saying that this is "good".  I think that it *will be like that*, because some people involved will always find their profit from NOT changing the block size, and because different groups will see their advantage in different ways of solving this problem.  And for exactly the same reason that me wanting to reverse my transaction to you, and you wanting to reverse your transaction to me, none of us can, and the block chain is immutable because of that, there will never be a consensus on changing the finite block size.  The imaginable bitcoin that would have BU included would probably work better, but it will not happen, because that is not the real bitcoin, and the transition to BU will be against the advantages of enough people to avoid it.

you were not understanding my sarcasm to bring up the point

the punchline being someone from nintendo being the activision insider saying to activision not to expand passed nintendo limits. because X,Y,Z reasons.

also the technical limits of 1996 are not the technical limits of 2016
so stating activision should not progressively grow into 3D gaming and then as years go on increase to HD 3d gaming.. and instead only ever stick to nintendo rules of 2d...

is stupid.

---

ofcourse logic dictates dont make call of duty:MD in 1997..
but bringing the logic to bitcoin.. "gigabytes by midnight cant happen"

but..
PROGRESSIVE, dynamic, NATURAL GROWTH. where NODES define the parameters of what they can cope with. (even BU know this and know/use consensus) will allow growth and scaling.

all you need to do is ignore the fake doomsdays of "gigabytes by midnight" and replace that scripted mindset with "natural growth over time (months, years, decades)

then you see the difference.

in short we WILL NOT suddenly get 1billion people over night. so ignore the "overnight capability" doomsday.. as the fake reason to halt real scaling

imagine if everyone ignored the "gigabytes per midnight"
we could have been at 2mb REAL blocksize in 2015(nodes can cope with)
we could have been aiming for 4mb REAL blocksize in 2017(nodes can cope with)
and then by 2019ish 8mb (nodes can cope with*)

*telecommunications company have a 5 year plan they are in the middle of. (landline: fibre optic, mobile: 5G) so by 2019 things will be different then now
*hardware capability, moves on too.. (raspberry pi min specs of RPi1 vs RPi3 have scaled 20-60 fold for bitcoin capability)
*people on average upgrade hardware between 1year-4 years average

---

we should not halt natural scaling onchain just to FORCE users offchain. there can be a symbiotic relationship where LN is voluntary side service. and not an essential only utility to spend.

the fee war is not due to natural scaling not coping but due to DEV decision to halt and delay scaling to push LN to become 'essential'

You have a misunderstanding about the notion "scale".   You confuse it with "is currently not within reach of technology".
In any case, bitcoin cannot scale, because it limited itself, independent of the scaling problem of single block chain technology.

The scaling problem a block chain faces, is that for "n" participants, over time T, it needs to store/process/.... ~n^2 T data.
If we presume that transactions per entity rise with the number of potential partners they have on the network and that ALL nodes need to process ALL transactions of ALL participants over ALL of history.   This runs into technical limits at a certain point.  

But bitcoin put itself a much, much more severe and hard limit: 3 transactions per second.  Making transactions themselves an expensive resource.

1. in segwits case . BLOCKSTREAM GAVE only pools the vote. so dont blame pools for it

2. in any vote.(for any change to rules, consensus, network protocol) without nodes being ready, pools wont do anything due to orphan risk and network safety and other things.
so whether nodes get an official vote or not, smart pools would hold off voting for anything unless they see a good node count to cope with the network change

yep

but thats 2 months at best assumming ALL tx's were segwit migrators. remember usual tx flow of people paying people and spam fill blocks too. so imagine it like many months of mempool crashing and fee war price increases with still no guarantee's

other proposals of just blocksize increases (real blocksize increases) either dynamic or spoonfed fixed amount, dont rely on moving funds to cause it. so those options dont cause months of mempool bloating.

Well you dont want to give too much power to miners otherwise they will act like a pseudo government.

Of course I dont know how good the 2nd layer will be and how decentralized.

It seems to me that neither Segwit nor BU is good.

That is why they have only 25% approval.

imagine if: activition 1996 said
"we cannot scale passed 2d shoot-em-ups' on a nintendo and Call of duty:MW because 56k internet and 4gb hard drives. we should never make call of dutyMW, never work on growing gaming passed nintendoNES and instead build plastic figurines that dont require electronics so the kids have something to play with that has no limitations."

Either back of the fag packet calculations gives a good idea of a 2 month migration cost being added to the chain, assuming everybody voluntarily moves over. So we do not get that promised transaction rate increase for a very long time in practice.

not an exact science. i used the average of 2100tx per block*144 block with the 18mill tx average
18m/144/2100=59days

---

but think about it. 18million transactions (46mill outputs) all trying to rush to 'opt-in'
... mempool crash

but think about it. will malicious users 'opt-in' or see a good oppertunity to stick with native-to-native and cause further disruption while the sheep think they can achieve 100% voluntarily.

I calculate that to be between a 70 day operation for average transactions at 3 tps, to 76 days for 1 input to output at 7 tps. Or maybe I need another cup of coffee to wake up if I have calculated it wrong.

Someone got it.

However, between "cannot scale" because of technological limitations, and "cannot scale" because frozen into the protocol for ever, there's still some room

Bitcoin is frozen in far before the technological (and moving) limits are reached.

46million outputs
http://statoshi.info/dashboard/db/unspent-transaction-output-set

on average equates to about 18million transactions

if every user voluntarily moved their funds (including the oldtimers and satoshi)
if every block was filled with ONLY the 'opt-in' to segwit (average native tx to a segwit tx)

AT BEST. 2 months of constantly filled blocks just to pay themselves just to 'opt-in' to segwit

No - it's not your fault.  We've been told right before the start: It just cannot scale - and we tired anyway:

http://www.mail-archive.com/[email protected]/msg09963.html

Hello class ..can we say "pending train wreck"



Lets face it guys it is ALL my fault....if BTC tanks to 'beanie baby status". My one shot at making a killing.

The ASIC/CRYPTO gods shall likely 'smite' me and I will take you all with me...

(hey its a gift ..if there is money to be made..I can inverse that puppy in no time at all)

But only if all UTXO's are moved from native keys to segwit keys, I have understood this right? If all UTXO's where moved from native keys to segwit keys, one input to one output, how long would it take move all UTXO's over, assuming there are no other transactions to process?