Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: HostFat on March 12, 2017, 05:33:40 AM



Title: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: HostFat on March 12, 2017, 05:33:40 AM
BIP100: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
Reddit discussion: https://np.reddit.com/r/btc/comments/5yvc58/tom_harding_weve_worked_with_jgarzik_to_update

Code:
==Abstract==

Replace the static 1M block size hard limit with a hard limit set by coinbase vote, conducted on the same schedule as difficulty retargeting.

==Motivation==

Miners directly feel the effects, both positive and negative, of any maximum block size change imposed by their peers.  Larger blocks allow more growth in the on-chain ecosystem, while smaller blocks reduce resource requirements network-wide.  Miners also act as an efficient proxy for the rest of the ecosystem, since they are paid in the tokens collected for the blocks they create.

A simple deterministic system is specified, whereby a 75% mining supermajority may activate a change to the maximum block size each 2016 blocks.  Each change is limited to a 5% increase from the previous block size hard limit, or a decrease of similar magnitude.  Among adopting nodes, there will be no disagreement on the evolution of the maximum block size.

The system is compatible with emergent consensus, but whereas under that system a miner may choose to accept any size block, a miner following BIP100 observes the 75% supermajority rule, and the 5% change limit rule.  Excessive-block values signaled by emergent consensus blocks are considered in the calculation of the BIP100 block size hard limit, and the BIP100 calculated maximum block size is signaled as an excessive-block value for the benefit of all observers.

==Specification==

===Dynamic Maximum Block Size===
# Initial value of <code>hardLimit</code> is 1000000 bytes, preserving current system.
# Changing <code>hardLimit</code> is accomplished by encoding a proposed value, a vote, within a block's coinbase scriptSig, and by processing the votes contained in the previous retargeting period.<br /><br />
## Vote encoding
### A vote is represented as a positive megabyte value using the BIP100 pattern<br /><br /><code>/BIP100/B[0-9]+/</code><br /><br />Example: <code>/BIP100/B8/</code> is a vote for a 8000000-byte <code>hardLimit</code>.<br /><br />
### If the block height is encoded at the start of the coinbase scriptSig, as per BIP34, it is ignored.
### Only the first BIP100 pattern match is processed in "Maximum block size recalculation" below.
### A valid megabyte value is represented by consecutive base-ten digits.
### If no BIP100 pattern is matched, the first matching emergent consensus pattern <code>/EB[0-9]+/</code>, if any, is accepted as the megabyte vote.<br /><br />
## Maximum block size recalculation
### A <code>new hardLimit</code> is calculated after each difficulty adjustment period of 2016 blocks, and applies to the next 2016 blocks.
### Absent/invalid votes are counted as votes for the <code>current hardLimit</code>.
### The votes of the previous 2016 blocks are sorted by megabyte vote.
### Raising <code>hardLimit</code><br /><br />
#### The <code>raise value</code> is defined as the vote of the 1512th highest block, converted to bytes.
#### If the resultant <code>raise value</code> is greater than (<code>current hardLimit</code> * 1.05) rounded down to the nearest byte, it is set to that value.
#### If the resultant <code>raise value</code> is greater than <code>current hardLimit</code>, the <code>raise value</code> becomes the <code>new hardLimit</code> and the recalculation is complete.<br /><br />
### Lowering <code>hardlimit</code><br /><br />
#### The <code>lower value</code> is defined as the vote of the 1512th lowest block, converted to bytes.
#### If the resultant <code>lower value</code> is less than (<code>current hardLimit</code> / 1.05) rounded down to the nearest byte, it is set to that value.
#### If the resultant <code>lower value</code> is less than <code>current hardLimit</code>, the <code>lower value</code> becomes the <code>new hardLimit</code> and the recalculation is complete.<br /><br />
### Otherwise, <code>new hardLimit</code> remains the same as <code>current hardLimit</code>.

===Signature Hashing Operations Limits===
# The per-block signature hashing operations limit is scaled to (<code>hardLimit</code> rounded up to nearest megabyte)/50.
# A maximum serialized transaction size of 1000000 bytes is imposed.

===Publication of <code>hardLimit</code>===
# For the benefit of emergent consensus nodes, <code>hardLimit</code> is published.  Example: a complete coinbase string might read <br /><br /><code>/BIP100/B8/EB2.123456/</code><br /><br /> which indicates a vote for 8M maximum block size, and an enforced <code>hardLimit</code> of 2.123456 megabytes for the block containing the coinbase string.

==Deployment==

This BIP is presumed deployed and activated as of block height 449568 by implementing nodes on the bitcoin mainnet. It has no effect until a raise value different from 1M is observed, which requires at least 1512 of 2016 blocks to vote differently from 1M.

==Backward compatibility==

The first block larger than 1M will create a network partition, as nodes with a fixed 1M hard limit reject that block.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Quickseller on March 12, 2017, 05:47:36 AM
What happens if some miners want to lower the limit and some want to raise the limit? I am not sure the formula in the proposal would work.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: HostFat on March 12, 2017, 05:53:29 AM
This BIP still require the 75% of hashing power, so by following this rule, it is harder to change, in both directions, but it is still possible.
If there isn't 75% of the hashing power voting a direction, the block size will just remain the same. (even the current 1MB limit)

EDIT:
And it can only change by the 5% (upper or lower) of the size of the previous limit, after 2016 blocks with at least 75% of vote.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: AliceWonderMiscreations on March 12, 2017, 05:58:12 AM
I like this, it avoids radical changes and allows easy reversal if a change ends up going too far.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: HostFat on March 13, 2017, 10:06:18 PM
New BIP100 code for Bitcoin Core 0.12
https://github.com/bitcoinxt/bitcoin/pull/1


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 13, 2017, 10:11:07 PM
why are you jackals trying to promote 2 different "Democratic" blocksize proposals at once (this and BU)


is it because user support for BU is so low, despite how many BU nodes you have spread out over so many hosting services


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: -ck on March 13, 2017, 10:19:53 PM
For core version 0.12... why? Presumably to predate all segwit code and be compatible with BU? Since it's a hard fork proposal independent of segwit there is nothing that would prevent this from being made for core 0.14. BIP100 was the most popular choice amongst mining pools when it was first proposed. Don't be surprised if it makes a surprising comeback now. If this was coded up for core instead of BU without any other changes it would be very popular very quickly...


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: HostFat on March 13, 2017, 10:32:57 PM
For core version 0.12... why?
Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: kano on March 13, 2017, 11:02:41 PM
why are you jackals trying to promote 2 different "Democratic" blocksize proposals at once (this and BU)


is it because user support for BU is so low, despite how many BU nodes you have spread out over so many hosting services
Yeah people shouldn't be allowed to promote more than one thing ... and it should only be segwit :P /sarcasm

If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 13, 2017, 11:07:09 PM
If core put a pure BIP100 vote option in a release, I'd expect it would happen.

If that's what you're expecting, you're wrong on both counts


And you know you're wrong, don't you


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: franky1 on March 13, 2017, 11:25:15 PM
why are you jackals trying to promote 2 different "Democratic" blocksize proposals at once (this and BU)


is it because user support for BU is so low, despite how many BU nodes you have spread out over so many hosting services
Yeah people shouldn't be allowed to promote more than one thing ... and it should only be segwit :P /sarcasm

If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.

any dynamic is acceptable to BU, and with for instance. the 5% every 2week max growth. it will take a few years before affecting xt.. so the only one it does affect at activation is core.
(funnily enough a few people have manually taken core and already put in a 2mb+ in their limits to cover any network change and they all run fine on the network)

all core need to do is actually give in and add just the few minimal changes. or be a**hats and orphan&ban the majority if they want to dig their heels in and oppose it.(creating their own altcoin)

i would actually prefer core to have some extra RPC commands or a GUI options tab where users can while LIVE. change settings.
that way users are now slaves to devs digging their heels in by refusing to change something


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: kano on March 14, 2017, 12:05:54 AM
If core put a pure BIP100 vote option in a release, I'd expect it would happen.

If that's what you're expecting, you're wrong on both counts


And you know you're wrong, don't you
LOL you removed the relevant text :)
To be expected - your trolling fails.

...
If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: AngryDwarf on March 14, 2017, 12:06:14 AM
For core version 0.12... why?
Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.

That's one good reason for using bitcoin core 0.12 code as a base for development ideas. The other is the fact that segwit has not been activated and may never be.

So lets say someone spots a good opportunity for a code optimisation that does not affect the existing protocol of nodes. It can peer reviewed by more people. It can be integrated into other nodes such as core/classic/xt/bu easier by the developers who understand the differences from that code base.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: -ck on March 14, 2017, 12:45:15 AM
For core version 0.12... why?
Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.

That's one good reason for using bitcoin core 0.12 code as a base for development ideas. The other is the fact that segwit has not been activated and may never be.

So lets say someone spots a good opportunity for a code optimisation that does not affect the existing protocol of nodes. It can peer reviewed by more people. It can be integrated into other nodes such as core/classic/xt/bu easier by the developers who understand the differences from that code base.
That doesn't make sense for the former reason; the latter (integration with other codebases forked off earlier) does. There are many improvements in 0.13 and 0.14 that are totally unrelated to segwit and if segwit never gets activated the segwit code goes untouched, so forking off 0.12 is just leaving us with ancient code. The problem is everyone's rushing to get on top of each other with new proposals and choosing the shortest cuts possible. Oh well stick around long enough and *someone* will probably create a BIP100 for current core...


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: AngryDwarf on March 14, 2017, 01:20:11 AM
There are many improvements in 0.13 and 0.14 that are totally unrelated to segwit and if segwit never gets activated the segwit code goes untouched, so forking off 0.12 is just leaving us with ancient code.

If segwit does not get activated, then the segwit code should be removed. Sounds like a horrible and potentially dangerous maintenance issue to have unused code lying around.
So then the question is, regarding the non segwit performance improvements in 0.13 and 0.14, is it easier to remove the segwit code, or implement the performance improvements to a pre-segwit version? I suppose only those that are really familiar with the code will know, and it might be a combination of doing both depending on the area of code that needs to be modified.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: bitsolutions on March 14, 2017, 12:22:19 PM
Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.
Core 0.12 should not be used for mining, there are known DoS vectors that were patched later on.

Keep in mind this isn't the original BIP100 proposal, this is hacked up version that's IMO significantly more risky.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Xester on March 14, 2017, 12:27:48 PM
This idea of BIP100 is actually a good one. By using this kind of strategy we would no longer be choosing Segwit or Bitcoin Unlimited but we can solve the mining problems in the natural way. The problem lies on getting a 75% consensus from the miners, there are greedy people who are complicating things so that they can have control over bitcoin production and mining. If we just follow this path then there will be no problems and there is no need to complicate things.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: bitsolutions on March 14, 2017, 12:37:04 PM
The problem lies on getting a 75% consensus from the miners
75% among just miners is way too low a threshold, you need strong economic support as well which is unlikely to happen at this point(SegWit is really the only proposal at this time with a decent level of support from the economy), and even then you probably want 90% or higher miner support in addition to a very long lead time(6-12 months) for any HF.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: kano on March 14, 2017, 02:02:20 PM
The problem lies on getting a 75% consensus from the miners
75% among just miners is way too low a threshold, you need strong economic support as well which is unlikely to happen at this point(SegWit is really the only proposal at this time with a decent level of support from the economy), and even then you probably want 90% or higher miner support in addition to a very long lead time(6-12 months) for any HF.
At least get your info correct.

The 75% he is referring to is if BIP100 was ALREADY activated.
The 75% is required, once BIP100 is activated, to adjust the block size up or down via coinbase voting, to be in the 1MB to 32MB range, with only a small adjustment each time.

Segwit has no such option, it's a "side effect" block size increase, if you use certain addresses.
So all SegWit does in reference to the block size, is give a new, non-adjustable, 'possible' larger block size.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: bitsolutions on March 14, 2017, 06:53:42 PM
The 75% he is referring to is if BIP100 was ALREADY activated.
I don't see any activation threshold, best I can tell is that it's effectively 75% since there isn't anything else.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 14, 2017, 06:58:26 PM
The 75% he is referring to is if BIP100 was ALREADY activated.
I don't see any activation threshold, best I can tell is that it's effectively 75% since there isn't anything else.

kano is a born liar with bizarre business relationships, don't waste your time


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: kano on March 14, 2017, 10:17:59 PM
The 75% he is referring to is if BIP100 was ALREADY activated.
I don't see any activation threshold, best I can tell is that it's effectively 75% since there isn't anything else.
Garzik's BIP100 uses the standard core=95% activation of the BIP.

That's nothing to do with the 'regular' block size changes once BIP100 has activated ... if you understand how BIP100 works.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: d5000 on March 15, 2017, 10:29:02 PM
I could live with this proposal if it was combined with Segwit or FlexTrans.

With some other users we have discussed another BIP 100-based (https://bitcointalk.org/index.php?topic=1817272.msg18159682#msg18159682) proposal. The main difference to this one is that, in addition to the moving block size limit voted by miners, there would be a hard-coded upper bound limit that is manually moved when the developers conclude that it's safe with average Internet bandwidth at the time of the evaluation, as a worst-case maximum block size limit.



Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: kano on March 15, 2017, 11:21:31 PM
I could live with this proposal if it was combined with Segwit or FlexTrans.

With some other users we have discussed another BIP 100-based (https://bitcointalk.org/index.php?topic=1817272.msg18159682#msg18159682) proposal. The main difference to this one is that, in addition to the moving block size limit voted by miners, there would be a hard-coded upper bound limit that is manually moved when the developers conclude that it's safe with average Internet bandwidth at the time of the evaluation, as a worst-case maximum block size limit.


That (in red) is called centralisation.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: d5000 on March 15, 2017, 11:37:36 PM
hard-coded upper bound limit that is manually moved when the developers conclude that it's safe with average Internet bandwidth at the time of the evaluation, as a worst-case maximum block size limit.
That (in red) is called centralisation.

Interesting. So every restriction in the protocol and its modifications / development is "centralization"?

Would you give all the decision power to miners? I tend to think that is not the majority consensus in the Bitcoin community. I prefer the current system with its (at least rudimentary) checks and balances.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: kano on March 17, 2017, 12:32:22 AM
hard-coded upper bound limit that is manually moved when the developers conclude that it's safe with average Internet bandwidth at the time of the evaluation, as a worst-case maximum block size limit.
That (in red) is called centralisation.

Interesting. So every restriction in the protocol and its modifications / development is "centralization"?

Would you give all the decision power to miners? I tend to think that is not the majority consensus in the Bitcoin community. I prefer the current system with its (at least rudimentary) checks and balances.
What checks and balances are they?
A system that requires checks and balances by a centralized power that controls those decisions based on monetary gain is not a consensus at all.

Bitcoin's design is miner control based. Miner consensus.
If you don't like that, then go create an altcoin and play with that.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: d5000 on March 17, 2017, 05:17:17 PM
Bitcoin's design is miner control based. Miner consensus.

No. Bitcoin has three power groups:

- Miners (consensus regarding valid transactions)
- Users (economic power)
- Developers (protocol development)

Very simple model:
Miners have the control over the blockchain. But they can't include only the transactions they want in their blocks, because then their mined coins would not be worth anything. Users can refuse to relay blocks from miners if they misbehave, but if they exaggerate then they risk a network split.
Users can't double spend because miners would not include their transactions in their network.
Developers have the control over the protocol. But they cannot do any protocol change they want, because if miners or users don't like them, they can use another client.

Practical example: If BTU forks off and the majority of the economic power stays with Core, then BTU's coins will be worth much less and miners have lost this gambling round. They can then join Core again, but will have lost a lot of money.

PS: It's funny - in other threads I'm attacked by Core maximalists, and here by a BU maximalist ;) Intermediate positions seem to be the most difficult to sustain in a polarized ecosystem.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 17, 2017, 05:30:23 PM
PS: It's funny - in other threads I'm attacked by Core maximalists

I'll attack the ideas and rhetoric of ANYONE who wants to do something dangerous, particularly people who consistently evade answering the difficult and pertinent questions about their dangerous ideas.


You've got nothing but name-calling smears and playground tactics, just like every other dishonest debater haunting Bitcoin


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: DooMAD on March 17, 2017, 05:32:30 PM
PS: It's funny - in other threads I'm attacked by Core maximalists, and here by a BU maximalist ;) Intermediate positions seem to be the most difficult to sustain in a polarized ecosystem.

You know you've got the balance right when you're getting it in the neck from both sides.   :)


Miners have the control over the blockchain. But they can't include only the transactions they want in their blocks, because then their mined coins would not be worth anything. Users can refuse to relay blocks from miners if they misbehave, but if they exaggerate then they risk a network split.
Users can't double spend because miners would not include their transactions in their network.
Developers have the control over the protocol. But they cannot do any protocol change they want, because if miners or users don't like them, they can use another client.

That's pretty close to my stance, although I'd probably phrase it more that developers guide the protocol rather than control it.  The shift in emphasis is subtle but still significant.  Any developer can make any changes they want, but it's ultimately down to the users if they elect to run that code or not.  And obviously most devs would have a pretty sound idea of which changes the users would likely accept and which ideas would never get off the ground, so things won't get too anarchic.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 17, 2017, 05:50:31 PM
PS: It's funny - in other threads I'm attacked by Core maximalists, and here by a BU maximalist ;) Intermediate positions seem to be the most difficult to sustain in a polarized ecosystem.

You know you've got the balance right when you're getting it in the neck from both sides.   :)


You know you're getting the balance wrong when you're unable to discuss the issues directly, and need to dog-pile your way to a back-slapping false victory.


You've got no proper technical arguments, just like the rest of your buddies. I don't need hype men on the other mics to back up my choruses, because the lines are right


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: DooMAD on March 17, 2017, 06:34:25 PM
PS: It's funny - in other threads I'm attacked by Core maximalists, and here by a BU maximalist ;) Intermediate positions seem to be the most difficult to sustain in a polarized ecosystem.

You know you've got the balance right when you're getting it in the neck from both sides.   :)


You know you're getting the balance wrong when you're unable to discuss the issues directly, and need to dog-pile your way to a back-slapping false victory.


You've got no proper technical arguments, just like the rest of your buddies. I don't need hype men on the other mics to back up my choruses, because the lines are right

People are able to discuss issues directly just fine, only not with you.  Because your first port of call is to insult their character, call them dishonest and then refuse to actually have a discussion at all unless they agree to join your little circlejerk echochamber.  You don't make technical arguments, you just shout about it being dangerous to even utter the word blocksize and then throw more insults around.

If the "ideal" scaling solution involves significant off-chain activity and smaller percentage of transactions on-chain, where are the network fees coming from as the block reward diminishes?  The general notion is that fees have to increase over time to compensate for a reduction in mining rewards.  If the cost for an individual to settle their payment channel is prohibitive or excessively time consuming because they have to wait for a block, not only does that mean off-chain doesn't work, it also potentially diminishes network fees because all it serves to do is prompt users to explore other options.

The biggest argument, which for as long as the scaling debate has been raging, no one has ever overcome, is that users will not support a system that does not support them.  If you turn Bitcoin into a gold 2.0 settlement layer, it could either fail to generate sufficient tx fees to support the network, or the fees will become so excessive that only corporations and banks can afford to use it and its utility is vastly diminished.  At the end of the day Bitcoin provides a service.  Services that don't meet customer demand die in favour of those that do in an open market.

If Bitcoin's main chain achieves a greater capacity, the cost can be spread over a greater number of participants and fees shouldn't rise to the point where most users are unable to afford it.  Bitcoin retains its competitive edge.  This is a perfectly valid argument as to why we shouldn't rule out on-chain scaling.

Tread carefully with your "I know best" condescension, because you have no way of foreseeing the outcome of your beliefs and direction any more than the rest of us.  Depending on how the system develops or evolves, your supposed "technical superiority" hardline totalitarianism could prove just as short-sighted and dangerous as the "gigablocks by midnight" crowd.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 17, 2017, 06:54:50 PM
If the "ideal" scaling solution involves significant off-chain activity and smaller percentage of transactions on-chain, where are the network fees coming from as the block reward diminishes?  The general notion is that fees have to increase over time to compensate for a reduction in mining rewards.  If the cost for an individual to settle their payment channel is prohibitive or excessively time consuming because they have to wait for a block, not only does that mean off-chain doesn't work, it also potentially diminishes network fees because all it serves to do is prompt users to explore other options.

I agree with you. I don't expect you to continue to be reasonable, but I suppose I will try.

Do not exaggerate my position,  sidestep, divert, answer questions with unrelated questions, or use non pertinent slander. Not that it should need saying


So, I agree. But you're starting by implying that I want 100% offchain transaction, with only channel opening tx's for fees. I've never said any such thing, and so your dangerously close to behaving in bad faith already.


The biggest argument, which for as long as the scaling debate has been raging, no one has ever overcome, is that users will not support a system that does not support them.  If you turn Bitcoin into a gold 2.0 settlement layer, it could either fail to generate sufficient tx fees to support the network, or the fees will become so excessive that only corporations and banks can afford to use it and its utility is vastly diminished.  At the end of the day Bitcoin provides a service.  Services that don't meet customer demand die in favour of those that do an open market.

You're right. Again, you're implicitly suggesting that's what I want; it isn't. Careful.


There is a balance to be struck between on-chain and off-chain, this is correct. That's what we're really arguing about, so it's good that someone has outlined it (and no, not you, me. This is the first time you've even gone near talking about the overall long term of late, and it's me that's summed that up in simple terms here)


If Bitcoin's main chain achieves a greater capacity, the cost can be spread over a greater number of participants and fees shouldn't rise to the point where most users are unable to afford it.  Bitcoin retains its competitive edge.  This is a perfectly valid argument as to why we shouldn't rule out on-chain scaling.


You're still having this problem. I've never once said that on-chain should be ruled out.

I have said that on-chain scaling and blocksize increases do not correspond to one another, at all.


Read my lips: increasing the blocksize does not change the scale, it adds more resource usage at precisely the same scale. Stop arguing that blocksize increases are on-chain scaling, it's very very simple logic that blocksize changes are resource increases, not scaling increases.


Do not make me repeat this to you, I am fully expecting you to exploit the subtlety between adding resources and increasing scaling


And so my argument is simple: there are ways to scale on-chain. Let's do those, and achieve a sustainable balance between on-chain and off-chain transactions that has provable longevity. Any problems?


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: David Rabahy on March 17, 2017, 07:25:24 PM
It seems to me we are grappling with a multi-dimensional problem and there might not be any one "perfect" set of parameters and certainly what might have been good enough at one time could be less than good at a later time.  I shall attempt to list the dimensions;

  • strategic intent
  • functional goal
  • durability
  • stability
  • robustness
  • participants & their roles
  • consensus
  • PoW vs. PoS vs. TaPoS vs., etc. {what is the general name of this?}
  • block size
  • transaction fee
  • block reward
  • target time between blocks

I just bet there are others.  It seems unreasonable to expect everyone to agree on a common set of parameters across all of the dimensions and across time.  Many/most/all of these dimensions are interrelated.  Someone/anyone espousing a parameter choice for a single dimension risks being misunderstood/abused.

Given that no one set of parameters could possibly satisfy everyone, it is completely natural to have multiple solutions.  To resist this natural process and attempt to "force" everyone to agree is a disagreeable thing to watch.  Moreover, I think it will lead to disillusionment both within and outside the community.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 17, 2017, 07:35:05 PM
Given that no one set of parameters could possibly satisfy everyone, it is completely natural to have multiple solutions.  To resist this natural process and attempt to "force" everyone to agree is a disagreeable thing to watch.  Moreover, I think it will lead to disillusionment both within and outside the community.

Indeed.

The diversity you're seeking is to be found in the other cryptocurrencies on the market.

This observation lies behind my objection to all the competing Bitcoin dev teams; the cryptocurrency marketplace is where the competition of ideas can legitimately and productively take place, not within Bitcoin's development itself, where it's obvious that only one development team can be in charge at any one time. Hence the fierce debate.

If a modification of the Bitcoin client is not accepted by the team of coders doing Bitcoin development, it can compete on it's own merits as a separate cryptocurrency. All competing Bitcoin development ideas (XT, Classic etc) always took the line that Bitcoin must be their vision, and that they must depose the "negligent" or "corrupt" etc incumbent team with a hard fork.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: David Rabahy on March 17, 2017, 08:21:13 PM
I think, if it is even functionally possible, we might end up with three coins;

1) Bitcoin as it is running right now with no significant development team to love it at first
2) Bitcoin-SW as envisioned by the "Core" development team
3) Bitcoin-BU ...

One thing I know for sure; I will continue to run my own full node (which variant I need to think about).  If SW does indeed soft fork then I will need to remain vigilant and either move my non-SW-UXTO to SW-UXTO (it's too early for that, right?) or move it to the -BU coin (how is that done or am I confused?).  I don't want to lose my investment.  All this debating/fighting is undermining my confidence.  Maybe I should punt it all over to ETH (although I may have missed the majority of the run up already but at least maybe I could hold value there).  Otherwise maybe I should just take my profits back to the fiat world (yuk).


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: AngryDwarf on March 17, 2017, 08:31:31 PM
I think, if it is even functionally possible, we might end up with three coins;

1) Bitcoin as it is running right now with no significant development team to love it at first
2) Bitcoin-SW as envisioned by the "Core" development team
3) Bitcoin-BU ...

One thing I know for sure; I will continue to run my own full node (which variant I need to think about).  If SW does indeed soft fork then I will need to remain vigilant and either move my non-SW-UXTO to SW-UXTO (it's too early for that, right?) or move it to the -BU coin (how is that done or am I confused?).  I don't want to lose my investment.  All this debating/fighting is undermining my confidence.  Maybe I should punt it all over to ETH (although I may have missed the majority of the run up already but at least maybe I could hold value there).  Otherwise maybe I should just take my profits back to the fiat world (yuk).

In the case of a bilateral split:

Make a copy of the blockchain/wallet directory
Install both Bitcoin Core and Bitcoin Unlimited (Might need to make a Program Files directory copy, or change the name of the binaries if they conflict)
Change the ports in one of the blockchain directories in bitcoin.conf to prevent conflict.
Now you can run both Bitcoin Core and Bitcoin Unlimited using the -datadir option. You are automatically hedged at this point by doing nothing.
You do not need to move Bitcoin Core UTXO's to SW-UTXO's unless there is an announcement to retire native UTXO's by Bitcoin Core.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 17, 2017, 08:52:44 PM
I think, if it is even functionally possible, we might end up with three coins;

1) Bitcoin as it is running right now with no significant development team to love it at first
2) Bitcoin-SW as envisioned by the "Core" development team
3) Bitcoin-BU ...

Will you explain why you think 1 will happen? I am non-plussed
 

Maybe I should punt it all over to ETH (although I may have missed the majority of the run up already but at least maybe I could hold value there).

Ethereum is not a good crypto to my mind. PoS is just not viable incentive wise, and the overall design of Ethereum is flawed in many other ways.


Otherwise maybe I should just take my profits back to the fiat world (yuk).

I wouldn't recommend that, cryptocurrency is too significant an innovation to abandon outright. Keep some small amount of whatever makes you feel most comfortable, or better yet, do as you're doing and continue to learn through reading and asking questions, anyone can become more confident in what to invest in with enough study.


One thing I know for sure; I will continue to run my own full node (which variant I need to think about).  If SW does indeed soft fork then I will need to remain vigilant and either move my non-SW-UXTO to SW-UXTO (it's too early for that, right?) or move it to the -BU coin (how is that done or am I confused?).  I don't want to lose my investment.  All this debating/fighting is undermining my confidence.

You don't need to do anything, that's the safest option. As Angry Dwarf says, you can hedge with very simple set of steps, bear in mind you'll need double the hard disk space to run that configuration (for both the BTC chain and the BTU chain)


A recent announcement by 12 or so major exchanges has taken alot of the uncertainty out of a potential BU hard fork.

They have agreed between them to refuse to list BTU if the BU development team don't change their code to prevent replay attacks. This is highly disruptive attack, enabled by unwillingness to alter BU sufficiently from Bitcoin that the attack is impossible. The attack allows the malicious party to -

  • monitor the 2 blockchains
  • copy transactions from one of either forked chain (which are of course free for all to see)
  • send the same transaction on the chain the original was not sent on

All the attacker gains is annoying those who get attacked, they can't steal for themselves. They're just moving the coins against your will, simply because they have everything they need (a signed transaction) to playback the same transaction on the other blockchain. But if you were sending the money to an address not in your node's wallet (an exchange address being the obvious example), there is a risk that you wouldn't be able to get your coins either. So it's pretty damn serious overall.


Because of this statement from the (major) exchanges, BU now basically have no choice but to fix the attack vector, as the exchanges couldn't list BTU in good conscience knowing the serious losses or uncertainty this could otherwise have caused. So they've done us all a favour, and the ball is in BU's court. I expect they'll fix it.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: d5000 on March 17, 2017, 09:24:11 PM
That's pretty close to my stance, although I'd probably phrase it more that developers guide the protocol rather than control it.  [...] Any developer can make any changes they want, but it's ultimately down to the users if they elect to run that code or not.  And obviously most devs would have a pretty sound idea of which changes the users would likely accept and which ideas would never get off the ground, so things won't get too anarchic.

I agree, but the word "control" was referring to the specific specs/implementations a group of developers are working on. Code maintainers can have complete control over a code repository, but the users decide which protocol parameters and which implementation to use, as you say. The model outlined above is obviously very simplified.

@David Rabahy: I agree in some ways. But how do you know which is the "official" implementation then? It's all OK if a developer group achieves universal acceptance for their work. But a developer group focused too much on one particular parameter set or solution can lead to fragmentation if there isn't wide acceptance for this solution.

It would be interesting to see a working BTU network "live" and "without interference to Core" as an altcoin. But as the Bitcoin protocol gives the option to do a hard fork from the existing blockchain, then this way to fork can be more attractive for the disagreeing developer groups, for obvious reasons (value attached to the chain).

Now you can say: Let 'em fork and end that theater. But I think such a fork would do harm to Bitcoin, whatever the outcome may be. Very probably it wouldn't be "over" that fast: For example, the "BU shilling" miners could continue to block Segwit with a small part of their hashrate until October when the possible UASF Segwit is scheduled. Until October is a long time, where both sides would probably continue with their mutual accusations, flamewars, short sellings of the "enemy token", etc. I wouldn't be surprised with a sub-500 USD BTC in this case.

A way better way would be to achieve more acceptance for a slightly modified "official" implementation. And that's where solutions like BIP 100/102/106 could help.

Or "could have helped".  Perhaps it's too late. Or not? ;)


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: David Rabahy on March 17, 2017, 09:34:28 PM
1) Bitcoin as it is running right now with no significant development team to love it at first
Will you explain why you think 1 will happen? I am non-plussed
Love that word "nonplussed".

I can't remember exactly where (somewhere in this forum for sure; getting too old) but I saw something about neither SW nor BU gaining enough "votes" and so Bitcoin would just plod along as it is (I could easily have misunderstood).  From there I speculated that neither camp would be content and so they would both hard fork into new altcoins.

It probably isn't safe/reasonable for me to speculated thusly; it's kinda like letting kids play with matches.

Why does Core automatically get to keep the legacy?  Why does BU have to fork off?


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 17, 2017, 10:02:05 PM
1) Bitcoin as it is running right now with no significant development team to love it at first
Will you explain why you think 1 will happen? I am non-plussed
Love that word "nonplussed".

I can't remember exactly where (somewhere in this forum for sure; getting too old) but I saw something about neither SW nor BU gaining enough "votes" and so Bitcoin would just plod along as it is (I could easily have misunderstood).  From there I speculated that neither camp would be content and so they would both hard fork into new altcoins.

It probably isn't safe/reasonable for me to speculated thusly; it's kinda like letting kids play with matches.

Why does Core automatically get to keep the legacy?  Why does BU have to fork off?

Ok, I think I see what's leading you to say this.


To begin with, remember that BU is explictly defined as a hard fork. Naming no names, but there are some excessively over-complicated descriptions of the difference between the two. But there are nuanced sub-categories of each type, so there is some grounding in reality to presenting every subcategory at once (but it's more confusing presented that way).

It's clearer like this:


The 2 overall categories: hard and soft

Hard fork: the blockchain splits in 2

1 Rule or more are either changed, or removed. The implications are that those running the previous versions of the Bitcoin software detect the new and different version, but refuse to accept the new version of the blockchain, because the new blocks allow actions that were not in the previously rules. That's why it's described as "hard", it's an all or nothing change, as a user, you're forced to choose one or the other, because you cannot choose both.

Soft fork: the blockchain remains as 1

All the previous rules are maintained and respected by the newer Bitcoin software. The difference is that extra rules (that don't contradict the old in any way) are added to the new software. Bitcoin was designed specifically to let this happen smoothly, so that when previous versions encounter blocks that observe new rules they do not have the code with which to understand or apply, there is a predefined way for those older version of Bitcoin to safely ignore the new rules (how could the old software interpret newer code that was written in the future?). So, the implications here are the opposite to hard forks: people running the old version don't have to choose between 2 blockchains, they can stay on the same chain as the newer Bitcoin software, ignoring the new rules while still observing the old rules.


With that out of the way, it should be clearer why it's not that likely that the 3 chain forks you suggested would happen, or, at least the way things are now. For your scenario to happen, either Bitcoin "As is" must do a hard fork from Bitcoin "Segwit", or the other way round. Because there is no proposal like that right now (or at least not with any meaningful support), it's far more likely that only one out of 1) and 2) would take place, not both.

And your final question, I hope, should be inherently easy to answer for yourself now: because BU makes changes to pre-existing rules, it is a hard fork by definition. BU must fork into a separate change to allow BU's changes to be expressed in blocks, because older nodes will reject BU blocks as they break the previous rules in Bitcoin.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: notthematrix on March 18, 2017, 04:50:23 AM
This is a good solution IMO , to make bitcoin one again...
Its simple , core coukd build it in , and if segwit would never activate I could live with that.
Other small changes in future could be adopted by everyone.
f.e fixing Malleability only , without all changes of signing in a outside block.



Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 18, 2017, 06:08:01 AM
f.e fixing Malleability only , without all changes of signing in a outside block.

Oh, you've solved the problems of malleability and quadratic sighash scaling a different way? What is your proposal?


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: kano on March 18, 2017, 10:21:33 AM
...
PS: It's funny - in other threads I'm attacked by Core maximalists, and here by a BU maximalist ;) Intermediate positions seem to be the most difficult to sustain in a polarized ecosystem.
Lulz "attacked" - I guess if anyone disagrees with core (and you) they're attacking you?
Narcissism much?

P.S. I'm not BU - my pool is mining "No Vote" - which is the current "running 2nd option" (BU is running 1st, SegWit is running last)
P.P.S. with no miners you have NO bitcoin. With no exchanges, you still have bitcoin.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: franky1 on March 18, 2017, 10:51:15 AM

Ok, I think I see what's leading you to say this.


To begin with, remember that BU is explictly defined as a hard fork. Naming no names, but there are some excessively over-complicated descriptions of the difference between the two. But there are nuanced sub-categories of each type, so there is some grounding in reality to presenting every subcategory at once (but it's more confusing presented that way).

It's clearer like this:

The 2 overall categories: hard and soft

Hard fork: the blockchain splits in 2

Soft fork: the blockchain remains as 1


no the emboldened parts are exaggerated propaganda of taking softs best case scenario and hards worse case scenario.
hiding the fact that even going soft can split the network(core actually admit that it exists in their bip9, to orphan and ban the opposer once active).
hiding the fact that even going hard can keep the network together(thats how true consensus works node and pool agreement).

for reference:
clarity

soft and hard is simply:
soft: pool only vote
hard: nodes and pools vote

below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split
softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains



Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Carlton Banks on March 18, 2017, 01:07:23 PM
P.P.S. with no miners you have NO bitcoin. With no exchanges, you still have bitcoin.

Kicking out miners who don't understand their role just creates a gap in the market where the uncooperative miners used to be.


New miners would be more than happy to take on the risk of securing Bitcoin if people like you carry on like this. Can you wave like The Queen, kano? Can you say "bye-bye"? ;D


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: kano on March 18, 2017, 11:37:53 PM
Bitcoin price is crashing coz core is centralised and people are losing trust in Bitcoin.

Core is promoting a minority agenda (segwit) since August last year (core 0.13.0)
It hasn't done a run on acceptance, it's basically a failure and it has been that way for a while now.

If core was decentralised it would include independent options for each of the block options and probably also a version of BIP100 ...


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: HannRa on May 16, 2017, 01:15:11 AM
Bitcoin price is crashing coz core is centralised and people are losing trust in Bitcoin.

Core is promoting a minority agenda (segwit) since August last year (core 0.13.0)
It hasn't done a run on acceptance, it's basically a failure and it has been that way for a while now.

If core was decentralised it would include independent options for each of the block options and probably also a version of BIP100 ...

Add in a 'BIP100' flag to your coinbase string, and I will join with my 625Th/s! I'm aware the Kano pool is not a large percentage of total and this will likely not change much, but I'm highly motivated to initiate any traction for BIP100.


Title: Re: BIP100 updated - By Jeff Garzik and Tom Harding
Post by: Paashaas on May 16, 2017, 02:29:01 AM
Bitcoin price is crashing coz core is centralised and people are losing trust in Bitcoin.

Core is promoting a minority agenda (segwit) since August last year (core 0.13.0)
It hasn't done a run on acceptance, it's basically a failure and it has been that way for a while now.

If core was decentralised it would include independent options for each of the block options and probably also a version of BIP100 ...

Do You like spreading FUD?