[POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)

[Lauda]

That version didn't gather much support if any. Bitcoin scales very inefficiently on the first layer, that's why it requires a secondary layer.

This is why I propose to use BOTH SegWit and Adaptive Block Size (Bitcoin ABS? XD )

I think only the following client implementations make sense for *compromise*, *consensus* or whatever:
Core: Segwit
Bitpay: SegWit + Adapative Block size - although I don't know how resistant it is to being gamed.
BitcoinEC: SegWit + Emergent Consensus - Already *praised* by ViaBTC (see here: https://twitter.com/ViaBTC/status/842748341767290880) [1].
[1] - Client not released yet.

[1714894924]

1714894924

[1714894924]

1714894924

[1714894924]

1714894924

[1714894924]

1714894924

[franky1]

load of waffle about ifs and maybes of a centralised network..
blah blah

bitcoin needs to remain decentralised. multiple pools. and also the NODES killing off blocks it doesnt like. that way the pools are not just reliant on each other but the nodes too.

if we start going down the rabbit hole of one codebase of nodes
then
one pool

then we might aswell just be using fiat.

bitcoin is different and revolutionary due to diversity where there is not nor should not be any point of failure or control.
EG if one pool drops off the other pools continue.
if one codebase has a bug the others continue while the issues are being sorted by those affected.

consensus is the mechanism that self regulates the network by majority consent .
as long as the majority is not a sybil/shill corporate party, all running the exact same thing(making bitcoin weaker)..
but instead diverse independent consensus. then bitcoins revolution can continue. and bitcoin becomes stronger.

core wanting to split the network or baiting and switching to falsely state all non-core will do it. where by what core have left is their software and using BTCC & slush (their DCG partners) as pools. is centralisation..

it wont matter how good or bad the code is.. by being all part of the DCG portfolio. bitcoin loses its ethos of being revolutionary and will just turn into something like paypal/banking system.

bitcoin should rise above the greed of the banking sector corporate control and stick with consensus by independent diverse community.

[franky1]

That version didn't gather much support if any. Bitcoin scales very inefficiently on the first layer, that's why it requires a secondary layer.

This is why I propose to use BOTH SegWit and Adaptive Block Size (Bitcoin ABS? XD )

I think only the following client implementations make sense for *compromise*, *consensus* or whatever:
Core: Segwit
Bitpay: SegWit + Adapative Block size - although I don't know how resistant it is to being gamed.
BitcoinEC: SegWit + Emergent Consensus - Already *praised* by ViaBTC (see here: https://twitter.com/ViaBTC/status/842748341767290880) [1].

bitcoinEC.. lets just see

hmm
i wonder..
yep another DCG portfolio

oh look bitcoinec maintained by blocktracker.... https://keybase.io/blocktracker/ oh Barry silbert.. of DCG sems to be a follower (edit: now not)
let me guess lauda is ok with..
core (->blockstream ->DCG)
KNots? (luke JR->blockstream ->DCG)
bitcoinEC(silbert->DCG)

i find it funny how lauda shouts loudly in favour of all these DCG portfolio corporations/teams. yet hasnt read the lines of code yet of any implementation

though bitcoinEC is a 'in concept' a step in the right direction wise to move bitcoin forward. by having dynamics. im shocked at the ones jumping in advocating it without peer reviewing first

[Variogam]

BitcoinEC: SegWit + Emergent Consensus - Already *praised* by ViaBTC (see here: https://twitter.com/ViaBTC/status/842748341767290880) [1].

though bitcoinEC is a 'in concept' a step in the right direction wise to move bitcoin forward. by having dynamics. im shocked at the ones jumping in advocating it without peer reviewing first

While the code is not released yet, for those not following up to date news, it seems to be latest Core client patched with BU Emergent Consensus concept:

EB (Excessive Blocks): user is able to set easily how big blocks to accept maximally, default value 1 MB
AD (Acceptance Deepth): BitcoinEC set it always to infinite, so your node can not automatically fall back to bigger blocks than your EB setting. But the BitcoinEC going to monitor where the longest proof of work (PoW) chain is and providing a warning when your not following longest PoW chain anymore because of your low EB setting.

Personally I see it step in the right direction as well.

[franky1]

AD (Acceptance Deepth): BitcoinEC set it always to infinite, so your node can not automatically fall back to bigger blocks than your EB setting. But the BitcoinEC going to monitor where the longest proof of work (PoW) chain is and providing a warning when your not following longest PoW chain anymore because of your low EB setting.

Personally I see it step in the right direction as well.

https://bitcoinec.info/

Will you also have an AD(Accept Depth) parameter like Bitcoin Unlimited?

Instead of Accept Depth we will implement a warning system to alert users if they are not on the longest chain. Implementing AD in the way BU has done appears to be fairly complicated and hard to do correctly, a warning system is simple since we only need the block headers for that.

i still think that non-pool nodes should really utilise policy.H more..

EG Consensus.h node hardwarelimit = something set by the nodes performing its own speed test of what it is physically capable of
for example 8mb
 then policy.h is the PREFERED size the network should work with.
EG 1mb today and maybe 2mb on activation day.

whereby pools see all the policy.h (prefered) in the node useragents.
and pools then
set their own policy.h just below what the majority of nodes prefer.
EG 0.999 today and 1.000250 day of activation. and pools then test the water of orphan risk and other unforseen bugs and increment up to 1.999 before the 'majority/minority' preferences kick in
thus a minority would accept the block but have their policy.h altered by warning system

[Lauda]

bitcoinEC.. lets just see

hmm
i wonder..
yep another DCG portfolio

oh look bitcoinec maintained by blocktracker.... https://keybase.io/blocktracker/ oh Barry silbert.. of DCG

What makes you think 'blocktracker' is Barry Silbert? That's a weird statement.

though bitcoinEC is a 'in concept' a step in the right direction wise to move bitcoin forward. by having dynamics. im shocked at the ones jumping in advocating it without peer reviewing first

There's nothing to peer review yet. People are advocating for the idea.

[dinofelis]

load of waffle about ifs and maybes of a centralised network..
blah blah

bitcoin needs to remain decentralised. multiple pools. and also the NODES killing off blocks it doesnt like. that way the pools are not just reliant on each other but the nodes too.

As usual, not capable of giving any reasoned argument against what I'm telling you.
Why would a POOL be "reliant" on nodes to get them their competitors' blocks on which they decide to build or not ?
What use does another node have for that pool ?  The pool can find out for itself whether that block satisfies its own criteria, doesn't need other blocks to verify that for him.  On the other hand, that pool wants to know that block as fast as it can, in order not to waste hash rate on an orphaned block.  So there is not one single reason why a pool would not connect DIRECTLY to its competitor's nodes.

[dinofelis]

bitcoin is different and revolutionary due to diversity where there is not nor should not be any point of failure or control.
EG if one pool drops off the other pools continue.
if one codebase has a bug the others continue while the issues are being sorted by those affected.

Yes, but that is an "inter-pool" affair only.

consensus is the mechanism that self regulates the network by majority consent .

Majority of proof of work.

as long as the majority is not a sybil/shill corporate party, all running the exact same thing(making bitcoin weaker)..
but instead diverse independent consensus. then bitcoins revolution can continue. and bitcoin becomes stronger.

But then you bloody don't need proof of work !  Why not simply have the nodes keep a big mempool and call that the block chain ??  And each time there's a difference, we let the nodes vote, and the majority is right ?

Why do you think Satoshi introduced proof of work do you think ?  To come to a consensus !  Because if you rely just on nodes, which you could, then this is not secure against a Sybil attack: everyone can fire up 100 000 nodes.  Now, if there is a mechanism to DETECT a Sybil attack and not take it into account, you've just found a new consensus mechanism.  But it is not bitcoins.  Bitcoins consensus mechanism is proof of work.  Not "number of nodes voting".

[Latreetim]

I'm all for compromise, but still feel that any static, fixed size is a clumsy and crude solution.  As many have argued previously, it's merely kicking the can down the road.  SegWit plus a modified hybrid of BIP100 and BIP106 would be more flexible, adaptable and future-proof.  Not only that, but a sudden, arbitrary one-time surge in space leads to uncertainty and the possibility of abuse by spammers.  The change is healthier being gradual and predictable.

I agree with that. I think the scaling should be flexible, adapt to the block size at the time. That is similar to the Monero.

[franky1]

more waffle

your not seeing the bigger picture..

you think because pools can make their blocks that they dont need nodes.. well lets word it this way

you design a new bank note. you include all the security features.. but then you find that although you have a huge stack of bank notes.. no one likes them. they would prefer purple bank notes.. not green.

you could keep making green bank notes and thinking your making money..  but if no one is accepting them... your wasting your time. you cant spend them anywhere

now you start to realise about community consensus. if they dont like your blocks. your wasting your time making them.

[dinofelis]

more waffle

your not seeing the bigger picture..

you think because pools can make their blocks that they dont need nodes.. well lets word it this way

Essentially, yes.
Well, they do need customers (people paying good money for the coins on their chain).  These customers need wallets.  So pools do need customers with wallets.  These wallets can connect directly to the pools' nodes ; or they can connect to those nodes that serve as proxy servers too.  Things like exchanges will probably run a full node, so pools would like these exchanges to take a copy of the block chain they make.

you design a new bank note. you include all the security features.. but then you find that although you have a huge stack of bank notes.. no one likes them. they would prefer purple bank notes.. not green.

You're confusing users and nodes again.  Of course pools need users that pay good money for the coins the pools dump on the users.  But for that, the users need to have a choice.

With alt coins, that's not difficult.  There are other alt coins.  If the alt coin chain doesn't please alt coin users, they simply sell their coins, and buy others.

But with bitcoin it is different because the only thing bitcoin has going for it, is its brand name, its "first mover" image.  So if bitcoin miners only make one bitcoin chain, well, that is bitcoin.  And users have no choice, because there's no OTHER chain to prefer that has this brand image.

But in any case, it is a matter of miners and users, not of nodes. 

Your example of bank notes is also between those printing the notes, and those using it.  Whether the notes come by you through several different postal services (nodes) or they come to you as a user because you go and get them directly where they are printed, is the right analogy.  If the postal service refuses to carry the notes to your place, but you, as a user, want them, then you will go and get them directly where they are printed.

On the other hand, if the only notes that are printed, are green ones and nobody is making purple notes, well, you will still have to use the green ones if you want to use bank notes.   There aren't purple ones, EVEN if the postal service only wants to transport purple notes (that do not exist), and refuses to transport green ones.  You will have to go and get the green ones at the printer's site, if you want bank notes.  Even if you, and the postal service ,prefer purple ones.

[franky1]

waffle

your still not understanding bitcoin.
your looking at things too two-dimensionally.

users are not slaves to pools. just taking what pools hand out. users want to have a say in what is created. and thus they become nodes.
they then via majority consensus and rejecting blocks they dont like, cause pools to form a single chain (stack of bank notes) that the majority accept and are happy to use as currency.

those that object to the majority. can either stay with the network. objecting (orphaning what they get) and being left unsynced because they choose not to keep any blocks.
or
give in to majority and decide to match the majority of nodes choice and use the currency.
or
ban all communications with the ugly nodes and pools to avoid the orphan drama. and find a pool that will make the blocks they prefer and start their own altcoin.

yea there are some users that set themselves up as wallet services for random users that dont care much about the big decisions, and those uncaring users can just use the popular currency via third parties because they trust the third party shares their same basic desire to not need to run a node themselves.
but others want a more active role so become nodes to be part of consensus. knowing the more people voting for a certain thing the less chance some strange lobbied group cant just come in and vote to create something different and force a change.

and thats where majority consensus comes in..
securing bitcoin from random changes and only changing if there is majority consent of the community.

[dinofelis]

users are not slaves to pools. just taking what pools hand out. users want to have a say in what is created. and thus they become nodes.
they then via majority consensus and rejecting blocks they dont like, cause pools to form a single chain (stack of bank notes) that the majority accept and are happy to use as currency.

You are clearly missing the point.  Miners don't need the other nodes to get their blocks and make their chain.  They only need to connect amongst themselves, and they have all reasons to do so for matters of speed.  If miners make one single chain, whether other nodes don't like that chain or not, doesn't matter.  There is only one chain out there.  Nobody's making another one.

If tomorrow, there is consensus between all miners and they ONLY make the segwit chain, then that's it, and whether users like it or not, they have no choice.   If tomorrow, there is consensus about BU between all miners, and they only make the BU chain, then that's it, and users have no choice.  And if tomorrow (like today) miners have consensus and only make the standard chain, that's it, users have no choice.

You are talking about the case when there is no consensus between pools, and when pools make different chains.  Then nodes can pick one of the two (or three or four) chains that are available.  

But non-mining nodes have nothing to say to the blocks that miners put on the chain they build.  They can simply download them, and accept them or not.  That's all non-mining nodes do: download blocks from miners.  They can't stop miners from building chains.

And now we come to users: if miners only make one chain, users have no choice: that's the chain they have to use, there isn't any other.  But of course, users can decide to sell their coins and leave the thing, which is bad for miners, who need users to buy their coins.  So with one chain, users HAVE TO use it, but they can set the absolute market cap.

If there are more chains, users can use the different chains to buy and sell, and DETERMINE THE RELATIVE MARKET CAPS.  But in order for users to be able to do so, miners have to make different chains in the first place (with hard forks).  When  users set different relative market caps, miners will follow these ratios.

So again: miners make block chains, which nodes can download if they like it.  Users can only use the chains that miners make.  But they set the market cap of these chains, which is the ultimate thing miners are after.  If miners are in disagreement, and make hard forks, they leave the choice to the user.  If miners are in consensus and make only one chain, the user has only the choice to stay or to leave.

But, apart from the case of a hard fork and setting the relative market caps, users have nothing to say about WHICH chain(s) miners can make.  And nodes in all this story don't matter AT ALL.

[Searing]

No offense

But this thread may be 'redundant' in that as far as I can tell. Bitcoin Unlimited and Bitcoin Core are not in any negociations anymore.

Bitcoin Unlmited wants a hard blocksize increase,  first before seg witness (if at all) or other measures

Bitcoin Core wants NO hard blocksize increase under any circumstances...don't even mention it

Hard to get anywhere ..if no one will get out their chairs to come to the negociation table

So looking to me like if BU gets 51% they will simply FORK right away to solidify their postion on this as a lever

ie 400 usd btc at that point..imho..and likely some other alt (dash?) will fork over 300 bucks at that point in time

what a cluster


I like the ideas on this thread...but don't seem like it is gonna happen if no one is talking

[dinofelis]

No offense

But this thread may be 'redundant' in that as far as I can tell. Bitcoin Unlimited and Bitcoin Core are not in any negociations anymore.

Bitcoin Unlmited wants a hard blocksize increase,  first before seg witness (if at all) or other measures

Bitcoin Core wants NO hard blocksize increase under any circumstances...don't even mention it

Hard to get anywhere ..if no one will get out their chairs to come to the negociation table

So looking to me like if BU gets 51% they will simply FORK right away to solidify their postion on this as a lever

I'm absolutely not convinced that miners showing support for BU actually want BU.  I think they simply don't want segwit, and they need something to block segwit.  BU or any other thing will do.   This is why they weren't affected by the bug in BU.  Because they don't care, it is not what they really want.  Miners want status quo because that's most profitable for them.  So the good old bitcoin protocol with 1MB will be with us forever.

Also, forking at 51% would be extremely risky, because once the two bitcoins are in the market, you give the choice to the market.  You might very well get seriously punished.  Why on earth would a miner want a bigger block and relieve pressure on the fee market ?  What miner is going to do a silly thing like that, and even risk bitcoin over that ?  

No, nothing of all this is going to happen: the bitcoin you know now, is the same bitcoin that will be running 10 years from now in my opinion.  Apart from the fact that there will maybe only be 1 mining pool  That mining pool can also serve as the big, single Lightning network hub if it wants to.  The LN fees will be identical to the block fees then.

[jbreher]

I'm absolutely not convinced that miners showing support for BU actually want BU.

Certainly plausible, but it seems doubtful to me. What evidence leads you to conclude this?

Also, forking at 51% would be extremely risky

Agreed. Good thing the most-widely-distributed 'plan' for BU cutover is 75%. That would be amongst all compatible clients. Including BU, simple 8MB, the upcoming BitcoinEC, and others. Today's support is at 43.8% + 6.9% - looks like we are well on the way to an end to this war. Some will lick their wounds, but I like to think that the victors will be welcoming of all.

[Cashew]

Of course I would agree with such a proposition. Any sane person would do the same as a split could be the worst thing that could happen to us, and this, people do not understand it.

[BitUsher]

When the largest ASIC manufacturer is making threats like this -

https://twitter.com/JihanWu/status/843341104531427336

I found that the HF future contract of Bitfinex is very unfair against big blocker. 2 support BU supporter, HF should be accelerated.

This is symptomatic of a far greater problem in bitcoin and possibly Jihan is under duress to force a hard fork through. There is no negotiation with hostile cartels trying to attack users without consensus, instead we must further test and develop backup plans for worst case scenarios--

Website: btcpowupdate.org
https://bitcointalk.org/index.php?topic=1833391.0

[paul gatt]

I very much agree with this, but now it can not happen, segwit has not been accepted by everyone, and now it's split into two branches, I do not know if this is good or bad, But it is affecting the bitcoin market, bitcoin is outdated by others, its value is falling sharply. Meanwhile, a lot of alt is growing vigorously. ETH is a typical example, it has taken breakthrough development, which is essential for bitcoin. I am looking forward to this change will bring many benefits to bitcoin. Bitcoin is not allowed to crash

[BitUsher]

ETH is a typical example, it has taken breakthrough development, which is essential for bitcoin.

https://medium.com/@aantonop/i-just-spent-the-last-8-months-working-on-the-second-edition-of-mastering-bitcoin-and-i-couldnt-c63bfdae248d#.wxal6cyyp

I just spent the last 8 months working on the second edition of Mastering Bitcoin and I couldn’t even scratch the surface of all the innovation that is happening in BTC. You don’t see it? You’re not looking.

The idea that Bitcoin is stale and that Ethereum will come to the rescue without stumbling on all the same milestones of growth that Bitcoin has overcome is a fiction.