Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
My thoughts of EC as a result of AD.
Bitcoin is a nuanced system and while no one understand the system in its entirety I just presume most understand the incentives. The technologies employed in bitcoin in most cases were over a decade old before they were applied to make a digital currency.
People had been trying to create digital curacies for years prior to bitcoin, they all failed because they lacked a general knowledge in economics, politics, psychology, philosophy, with a crippling overspecialization in cryptography and computer science, This is largely still the problem with developers today, and the centralised decision making process inherent in the OSS Core implementation.
The fundamental breakthrough that makes bitcoin possible is a solution to a cryptographic puzzle called the Byzantines general's problem. Summarized it's a solution to communicate in a verifiable, trustless and decentralized way.
Satoshi solved this problem in a very clever way, He used existing technologies and he applied economics, politics, psychology, philosophy, to create an incentive to solve what was thought of as an impossible computer science problem.
So the fundamental glue that makes bitcoin work, is not cryptography or computer science but rather arranging those technologies in an incentive design that creates an emergent network that solves the Byzantines general's problem.
If one attempted to write a large block it would be rejected by 100% of the network if it took longer than 10 minutes to validate. If you created a block that took longer than 30 seconds to validate you'd have less than a 5% change of building on that block, so a 95% chance of having no control at all and a 95% chance you'd lose almost $1 million a week. Not the type of attack anyone today can afford today.
AD has nothing to do with incentives for mining nodes, it’s a setting that allows relay nodes to follow the longest chain. Criticism of AD is dependent on miners not being incentivised to mine bitcoin blocks.
Block size is almost irrelevant in bitcoin, blocks are just time stamped transactions. The cost to store those transactions for decades is inconsequential. The fees we pay miners (almost 100% subsidised at this time) to write them to the blockchain is orders of magnitudes more that the cost for a node to store them. The real cost, is the cost to relay the transactions.
The mental trap that most intelligent people, who are ignorant of the incentive design fall victim to is the notion that if miners don't pay to store ore transactions, what stops them from including more that the network can handle if they don't pay for the cost?
The ignorant answer is bitcoin is broken or it needs a central authority a "we" who need to protect the network from the tragedy of the commons.
The actual answer reveals itself when you study the problem, BU have presented the solution.
Miners don't pay for storage, the storage cost is not a limiting factor, (an 8TB HD costs $300) there are other limiting factors to growth, storing transactions is not one of them. The limiting factor to transaction capacity (block size) is inherent to the network, it is the ability to distribute and relay transactions across the network and then time stamp them by doing computational work to find a the golden nonce. The first network participant to solve that PoW cryptographic puzzle is rewarded.
To the lay person they are rewarded tokens (a mining reward of 12.5 btc today), but in reality what is happening economically is more complicated, but none the less consistent with contemporary monetary theories.
Participating Bitcoin nodes compete for the reward, it is given to the node that writes the timestamp these nodes are known as miners. Miners are not incentivised to reject time stamped blocks based on the quantity or size of the transactions they describe. They check to see that the transactions included in the time stamped block are valid and that the golden nonce has a hash value lower than the target difficulty. If it does then the time stamped block is valid. The miner starts working to include transactions that give the reward they receive value and working on a cryptographic puzzle to find a nonce values that confirms to the rules.
The incentive to get this “mining” reward is not impeded or enhanced by including transactions, however all things being equal there is a risk that the greater the number of transactions that are included in the time stamped block the higher the probability that they have not fully propagated the network. There is a causal relationship that can be empirically measured that shows the higher the transactional demand the greater the chance that block reward will go to a competing network participant who has fewer transactions as measured by the time it competitors to validate. Miners are driven by economic incentives to optimise the limited recourses bandwidth – (HD space not being the limiting resource) .
This behavior is rational and explained by economics, politics, psychology, philosophy. This behavior is not guaranteed however the incentives are significant enough to trust it will continue.
On average a time stamped block is found every 10 minutes. Miners while they are not concerned with the number of transactions or the collective size of all transactions combined, are concerned with working on the next block as fast as they can. So the motive to orphan a block is 100% driven by statistics by their ability to validate the block as fast as possible – block orphaning is dependent on time to validate not the size.
A criticism with EC and AD is that a block size could be found where half the mining nodes would validate it quickly while the other half wouldn't even try.
They don’t understand the Bitcoin incentives and argue that BU somehow changes the incentives to validate blocks. The fact is teh incentives drives mining nodes to all validate mined blocks, and extend that chain unless they can’t validate it for some reason. AD is a relay nodes setting and if a mining node optimises to this variable they get an assurance from the relay nodes that they will validate and relay blocks that fall within their EB setting. Larger blocks don’t get this security as those blocks are not rejected, but not relayed leaving miners optimise.
Miners do not reject valid blocks unless there is a rule they all agree too like the 1MB limit. Without the 1MB limit miners will not reject blocks based on a transaction limit that is not universally agreed. Rather they will reject blocks based on the probability it will negatively impact their income.
So EC isn't a problem it does not introduce a new attack vector the most significant attack vector is miners who withdraw their participation or min they can do that today, and without a block limit it will have no negative impact.
So AD feature of BU should not be active for miners, it is a safety feature to ensure that relay nodes do not fork unnecessarily fork off the Bitcoin blockchain.
Bitcoin is a nuanced system and while no one understand the system in its entirety I just presume most understand the incentives. The technologies employed in bitcoin in most cases were over a decade old before they were applied to make a digital currency.
People had been trying to create digital curacies for years prior to bitcoin, they all failed because they lacked a general knowledge in economics, politics, psychology, philosophy, with a crippling overspecialization in cryptography and computer science, This is largely still the problem with developers today, and the centralised decision making process inherent in the OSS Core implementation.
The fundamental breakthrough that makes bitcoin possible is a solution to a cryptographic puzzle called the Byzantines general's problem. Summarized it's a solution to communicate in a verifiable, trustless and decentralized way.
Satoshi solved this problem in a very clever way, He used existing technologies and he applied economics, politics, psychology, philosophy, to create an incentive to solve what was thought of as an impossible computer science problem.
So the fundamental glue that makes bitcoin work, is not cryptography or computer science but rather arranging those technologies in an incentive design that creates an emergent network that solves the Byzantines general's problem.
If one attempted to write a large block it would be rejected by 100% of the network if it took longer than 10 minutes to validate. If you created a block that took longer than 30 seconds to validate you'd have less than a 5% change of building on that block, so a 95% chance of having no control at all and a 95% chance you'd lose almost $1 million a week. Not the type of attack anyone today can afford today.
AD has nothing to do with incentives for mining nodes, it’s a setting that allows relay nodes to follow the longest chain. Criticism of AD is dependent on miners not being incentivised to mine bitcoin blocks.
Block size is almost irrelevant in bitcoin, blocks are just time stamped transactions. The cost to store those transactions for decades is inconsequential. The fees we pay miners (almost 100% subsidised at this time) to write them to the blockchain is orders of magnitudes more that the cost for a node to store them. The real cost, is the cost to relay the transactions.
The mental trap that most intelligent people, who are ignorant of the incentive design fall victim to is the notion that if miners don't pay to store ore transactions, what stops them from including more that the network can handle if they don't pay for the cost?
The ignorant answer is bitcoin is broken or it needs a central authority a "we" who need to protect the network from the tragedy of the commons.
The actual answer reveals itself when you study the problem, BU have presented the solution.
Miners don't pay for storage, the storage cost is not a limiting factor, (an 8TB HD costs $300) there are other limiting factors to growth, storing transactions is not one of them. The limiting factor to transaction capacity (block size) is inherent to the network, it is the ability to distribute and relay transactions across the network and then time stamp them by doing computational work to find a the golden nonce. The first network participant to solve that PoW cryptographic puzzle is rewarded.
To the lay person they are rewarded tokens (a mining reward of 12.5 btc today), but in reality what is happening economically is more complicated, but none the less consistent with contemporary monetary theories.
Participating Bitcoin nodes compete for the reward, it is given to the node that writes the timestamp these nodes are known as miners. Miners are not incentivised to reject time stamped blocks based on the quantity or size of the transactions they describe. They check to see that the transactions included in the time stamped block are valid and that the golden nonce has a hash value lower than the target difficulty. If it does then the time stamped block is valid. The miner starts working to include transactions that give the reward they receive value and working on a cryptographic puzzle to find a nonce values that confirms to the rules.
The incentive to get this “mining” reward is not impeded or enhanced by including transactions, however all things being equal there is a risk that the greater the number of transactions that are included in the time stamped block the higher the probability that they have not fully propagated the network. There is a causal relationship that can be empirically measured that shows the higher the transactional demand the greater the chance that block reward will go to a competing network participant who has fewer transactions as measured by the time it competitors to validate. Miners are driven by economic incentives to optimise the limited recourses bandwidth – (HD space not being the limiting resource) .
This behavior is rational and explained by economics, politics, psychology, philosophy. This behavior is not guaranteed however the incentives are significant enough to trust it will continue.
On average a time stamped block is found every 10 minutes. Miners while they are not concerned with the number of transactions or the collective size of all transactions combined, are concerned with working on the next block as fast as they can. So the motive to orphan a block is 100% driven by statistics by their ability to validate the block as fast as possible – block orphaning is dependent on time to validate not the size.
A criticism with EC and AD is that a block size could be found where half the mining nodes would validate it quickly while the other half wouldn't even try.
They don’t understand the Bitcoin incentives and argue that BU somehow changes the incentives to validate blocks. The fact is teh incentives drives mining nodes to all validate mined blocks, and extend that chain unless they can’t validate it for some reason. AD is a relay nodes setting and if a mining node optimises to this variable they get an assurance from the relay nodes that they will validate and relay blocks that fall within their EB setting. Larger blocks don’t get this security as those blocks are not rejected, but not relayed leaving miners optimise.
Miners do not reject valid blocks unless there is a rule they all agree too like the 1MB limit. Without the 1MB limit miners will not reject blocks based on a transaction limit that is not universally agreed. Rather they will reject blocks based on the probability it will negatively impact their income.
So EC isn't a problem it does not introduce a new attack vector the most significant attack vector is miners who withdraw their participation or min they can do that today, and without a block limit it will have no negative impact.
So AD feature of BU should not be active for miners, it is a safety feature to ensure that relay nodes do not fork unnecessarily fork off the Bitcoin blockchain.
Last edited:
go1111111
Active Member
Good timing, I was planning to post some rough points for an essay I plan to write, tentatively titled "Why BU's EC algorithm sucks." Here's the gist:
The main reason for you to run a full node as a regular user is to know when you've been paid. The EC algorithm makes knowing when you've been paid more cumbersome than necessary, and leads to many potential bad scenarios.
Scenario #1: In our current situation, you're running BU with EB=4MB, AD=6. You see a payment to you appear in a 3 MB block. According to the software you're running, this block is valid, so it looks like the payment has 1 valid confirmation. This ignores that if someone really did mine a 3 MB block today, it would almost certainly be orphaned by the majority chain. Ideally you want your software to be able to distinguish between a block that is almost certainly going to be orphaned, and a block that is almost certainly going to be accepted. The EC algorithm with these settings doesn't do this.
Scenario #2: Let's say you want to avoid the situation above, so you decide to set EB=1MB temporarily and keep AD=6. This will protect you from being tricked by a rogue miner who isn't in consensus with the mining majority. However, if miners do agree to raise the block size, it'll be about an hour (6 blocks) before you realize this. If a block of 3 MB is mined which will eventually be accepted, then your node will reject it for an hour. If another miner sends you a 1 MB block containing a payment to you during this time, your software will lead you to mistakenly believe that this block will be confirmed.
Scenario #3: Same situation as in #2, except this time a large group of rogue miners start producing a long string of 100 MB blocks. Once this chain becomes 6 blocks longer than the original chain, your node will accept it. When you set AD, you actually meant "accept larger blocks after 6 confirmations, assuming the block size is reasonable." Yet EC gives you no way to accept reasonably larger blocks but reject unreasonably larger blocks, without leaving yourself vulnerable to situation #1.
As you can see, the fundamental problem is that you generally want your node to follow the rule "accept whatever blocks the economic majority will accept, and reject whatever blocks the economic majority will reject." Sadly, the tools that BU gives you are terrible for approximating this.
You might object "how could any software implement such complex/subjective logic?? EC is the best we can do!"
There are two better approaches:
(A) Adjust the block size using in-protocol communication as the default. An example is Jeff Garzik's BIP 100. The economic majority agrees on a protocol by which block size increases will be made. The rules are flexible but also hard coded, so that nodes can follow along. If the mining majority and economic majority wants to increase block size, there is no short term period where full nodes are out of step with the economic majority.
You still sometimes need out-of-protocol communication if you want to switch the overall algorithm the community is using, like if we wanted to switch from BIP 100 to something like the Bitcoin XT algorithm. However such switches will be more rare and likely have a lead time of at least a month, so active users will still never be out of sync with the rest of the network.
(B) Communicate entirely out-of-protocol, with a reasonable lead-time for making changes. For instance, the economic majority could rally behind a proposal to increase block size to 8 MB, starting at a certain block number. Ideally consensus settings are decoupled from implementations, so users can change their own settings to say "Stay at 1 MB until block 465877, after which go to 8 MB." Users who didn't care to change their own settings could just download the latest update from their wallet provider. Because there is some lead time and people are coordinating out of the protocol, you avoid the problems outlined above in the EC algorithm.
Thoughts? Objections?
The main reason for you to run a full node as a regular user is to know when you've been paid. The EC algorithm makes knowing when you've been paid more cumbersome than necessary, and leads to many potential bad scenarios.
Scenario #1: In our current situation, you're running BU with EB=4MB, AD=6. You see a payment to you appear in a 3 MB block. According to the software you're running, this block is valid, so it looks like the payment has 1 valid confirmation. This ignores that if someone really did mine a 3 MB block today, it would almost certainly be orphaned by the majority chain. Ideally you want your software to be able to distinguish between a block that is almost certainly going to be orphaned, and a block that is almost certainly going to be accepted. The EC algorithm with these settings doesn't do this.
Scenario #2: Let's say you want to avoid the situation above, so you decide to set EB=1MB temporarily and keep AD=6. This will protect you from being tricked by a rogue miner who isn't in consensus with the mining majority. However, if miners do agree to raise the block size, it'll be about an hour (6 blocks) before you realize this. If a block of 3 MB is mined which will eventually be accepted, then your node will reject it for an hour. If another miner sends you a 1 MB block containing a payment to you during this time, your software will lead you to mistakenly believe that this block will be confirmed.
Scenario #3: Same situation as in #2, except this time a large group of rogue miners start producing a long string of 100 MB blocks. Once this chain becomes 6 blocks longer than the original chain, your node will accept it. When you set AD, you actually meant "accept larger blocks after 6 confirmations, assuming the block size is reasonable." Yet EC gives you no way to accept reasonably larger blocks but reject unreasonably larger blocks, without leaving yourself vulnerable to situation #1.
As you can see, the fundamental problem is that you generally want your node to follow the rule "accept whatever blocks the economic majority will accept, and reject whatever blocks the economic majority will reject." Sadly, the tools that BU gives you are terrible for approximating this.
You might object "how could any software implement such complex/subjective logic?? EC is the best we can do!"
There are two better approaches:
(A) Adjust the block size using in-protocol communication as the default. An example is Jeff Garzik's BIP 100. The economic majority agrees on a protocol by which block size increases will be made. The rules are flexible but also hard coded, so that nodes can follow along. If the mining majority and economic majority wants to increase block size, there is no short term period where full nodes are out of step with the economic majority.
You still sometimes need out-of-protocol communication if you want to switch the overall algorithm the community is using, like if we wanted to switch from BIP 100 to something like the Bitcoin XT algorithm. However such switches will be more rare and likely have a lead time of at least a month, so active users will still never be out of sync with the rest of the network.
(B) Communicate entirely out-of-protocol, with a reasonable lead-time for making changes. For instance, the economic majority could rally behind a proposal to increase block size to 8 MB, starting at a certain block number. Ideally consensus settings are decoupled from implementations, so users can change their own settings to say "Stay at 1 MB until block 465877, after which go to 8 MB." Users who didn't care to change their own settings could just download the latest update from their wallet provider. Because there is some lead time and people are coordinating out of the protocol, you avoid the problems outlined above in the EC algorithm.
Thoughts? Objections?
Last edited:
Roger_Murdock
Active Member
- Dec 17, 2015
- 223
- 1,453
@go1111111 So my main objection to your post is that, at least from my perspective, BU doesn't have an "EC algorithm." BU simply provides a set of tools -- of which the optional AD feature is the least important! See this comment for a more complete explanation.
Right, it would almost certainly be orphaned immediately. Which is probably why we haven't seen a lot of 3-MB blocks mined. In fact, I'm pretty sure we've seen exactly one >1-MB block mined (and that was unintentional, the result of a software bug that was quickly fixed) -- and that block was in fact orphaned immediately. Mining a block that's orphaned because it's out of step with current consensus is a very expensive mistake to make. Miners who make too many of those mistakes won't stay in business long. But even in the rare scenario where it happens, are we really imagining that it's going to cause someone to lose money? I guess if that >1-MB block had included a payment for goods to a seller using BU with an EB=2 setting, and that seller had waited for exactly one confirmation before shipping the goods, and that seller had been relying solely on his own EB=2 node to determine such confirmation, and the buyer of goods had successfully double-spent that transaction so that it never made it into the main chain -- then yeah, I guess that guy lost money.
Well, that certainly sounds better than running a Core node (equivalent to EB=1, AD=infinity). That would permanently fork you off the network in the event of a block size limit increase of which you were unaware. But again, I think the scenario you're imagining is a little silly. You're a sophisticated enough Bitcoin user to be running your own full node (which you evidently rely on as your sole source for information about the state of the network), but you're so out of the loop that you're not aware that the network is coordinating a block size limit increase? Because I don't think there's any realistic scenario (certainly involving a non-malicious hash power majority) where a limit increase isn't going to be well-coordinated and publicized to the ecosystem well in advance.
Well, if a hash power majority is acting maliciously, Bitcoin's entire security model has broken down. So we're in trouble. And in that case, there are many easier and more destructive attacks for them to pull off than mining oversized blocks! Same goes for a malicious large hash power minority. And if we're talking about a large minority that's gone rogue, you can defend against the improbable attack you're describing by using an appropriate AD setting.
BU isn't fundamentally incompatible with the two Schelling points you propose. It sounds like you want the Schelling point defining the "current block size limit" to always be "solid" and well-defined. And I tend to think it WILL almost always be solid-feeling (simply because of the incentives), but the nature of Bitcoin is such that there's an inherent amount of indeterminacy surrounding the Schelling points defining the "current protocol." But, practically speaking, I don't see this as a problem. Miners have a very strong incentive to make sure that changes are well-coordinated and signaled in advance to avoid unnecessary disruption to the network.
Last edited:
I like how CSW backs up what he says with simple references to comments in the original version of the Bitcoin code. Especially the idea that full (non-mining) nodes are an oxymoron. The chat (until alp and crew join) is a great read and hard to summarize.
@bitsko I hope you see that an open participation Slack is impossible. I'm one of the most anti-censorship guys around, but the Slack/chat format simply requires limiting the participation to people who will stay on point and not talk out of turn, or it becomes completely unreadable and pointless. Even well-meaning people asking too many questions at once makes it unreadable; deliberate trolling (or even just sincere boneheadedness) even by one person can totally ruin it.
I trust this is all self-evident to anyone who has been on the BU Slack for long. As just one not-even-very-extreme example, the Bruce Fenton debates in #general were like a nuke dropped on the channel in terms of readability and accomplished nothing, whereas a few PMs sorted things out in minutes. It's no accident. The format is a very delicate one that only works under certain very specific conditions.
If CSW returns it should be in a locked channel, carefully monitored, and realistically with only people who don't have a history of talking too much, trolling, or being excessively combative. Once again, it's just the reality of the medium, a very flawed medium but as @awemany suggests it does get people talking in ways they often wouldn't in a forum.
Either that or we can get Craig here.
@bitsko I hope you see that an open participation Slack is impossible. I'm one of the most anti-censorship guys around, but the Slack/chat format simply requires limiting the participation to people who will stay on point and not talk out of turn, or it becomes completely unreadable and pointless. Even well-meaning people asking too many questions at once makes it unreadable; deliberate trolling (or even just sincere boneheadedness) even by one person can totally ruin it.
I trust this is all self-evident to anyone who has been on the BU Slack for long. As just one not-even-very-extreme example, the Bruce Fenton debates in #general were like a nuke dropped on the channel in terms of readability and accomplished nothing, whereas a few PMs sorted things out in minutes. It's no accident. The format is a very delicate one that only works under certain very specific conditions.
If CSW returns it should be in a locked channel, carefully monitored, and realistically with only people who don't have a history of talking too much, trolling, or being excessively combative. Once again, it's just the reality of the medium, a very flawed medium but as @awemany suggests it does get people talking in ways they often wouldn't in a forum.
Either that or we can get Craig here.
bitsko
Active Member
- Aug 31, 2015
- 730
- 1,532
What a day, had no idea Vlad2Vlad was going to pull a stunt like that 
Yeah, because I will not ban, and users were asking me to ban, I created a 'private' channel.
I still support the notion that people can go to a space knowing they are free to express their opinion, I did see the signal drop hard by the 2nd pastebin.
Now, if csw wishes to engage others again he has two venues there; an unmoderated general chat, a 'private' channel(ping me ill invite), or, if the unlimited team wants, he could present in their slack. That might be ideal depending on how it all sinks in to the participants like csw iang etc. I'm just happy to be along for the ride and offer an option- unmoderated has its cons, sure.
1st:
https://pastebin.com/6rCLZbai
2nd:
https://pastebin.com/dUmiV1E8
Hashcash excerpt:
https://pastebin.com/iFc15p0w
'private' channel:
https://pastebin.com/e6BFb2Hq
unabridged dump from some time before and through:
https://pastebin.com/6YnQrBdj
Yeah, because I will not ban, and users were asking me to ban, I created a 'private' channel.
I still support the notion that people can go to a space knowing they are free to express their opinion, I did see the signal drop hard by the 2nd pastebin.
Now, if csw wishes to engage others again he has two venues there; an unmoderated general chat, a 'private' channel(ping me ill invite), or, if the unlimited team wants, he could present in their slack. That might be ideal depending on how it all sinks in to the participants like csw iang etc. I'm just happy to be along for the ride and offer an option- unmoderated has its cons, sure.
- csw [7:10 PM]
- And Freetrader, no, free speech does not incorporate libel or slander.
1st:
https://pastebin.com/6rCLZbai
2nd:
https://pastebin.com/dUmiV1E8
Hashcash excerpt:
https://pastebin.com/iFc15p0w
'private' channel:
https://pastebin.com/e6BFb2Hq
unabridged dump from some time before and through:
https://pastebin.com/6YnQrBdj
Last edited:
@go1111111
EC isn't an algorithm. Quoting Anthony from BU Slack "EC is a term similar to 'the economic majority.' It's descriptive of how bitcoin works, not prescriptive of how it should work."
BU doesn't presently provide miners with tools to coordinate changes to the block size limit. I personally think it should, and I think most people here would agree.
My proposal would be for miners to signal (something like) "EB1/FE8@500000" which means "my current block size limit is 1 MB and I intend to change this to 8 MB starting at block 500,000." The BU code would be written such that it would in fact increase EB to 8 at 500,000. If enough miners end up signalling the same thing, then no one has to do anything and a coordinated upgrade to larger blocks occurs. If there isn't consensus, then the miners signalling "FE8@500000" might then abort that proposal and try something new.
I'd also be fine with BIP100, BIP101 or some other mechanism. But the first step--and we're getting really close--is for miners to commit to simply increasing MAX_BLOCK_SIZE now.
Signalling EB1 is a signal to the network that you're serious about increasing MAX_BLOCK_SIZE.
[doublepost=1493962284][/doublepost]Interesting, block #500,000 is currently estimated to be mined on Genesis Block Day 2018:
EC isn't an algorithm. Quoting Anthony from BU Slack "EC is a term similar to 'the economic majority.' It's descriptive of how bitcoin works, not prescriptive of how it should work."
BU doesn't presently provide miners with tools to coordinate changes to the block size limit. I personally think it should, and I think most people here would agree.
My proposal would be for miners to signal (something like) "EB1/FE8@500000" which means "my current block size limit is 1 MB and I intend to change this to 8 MB starting at block 500,000." The BU code would be written such that it would in fact increase EB to 8 at 500,000. If enough miners end up signalling the same thing, then no one has to do anything and a coordinated upgrade to larger blocks occurs. If there isn't consensus, then the miners signalling "FE8@500000" might then abort that proposal and try something new.
I'd also be fine with BIP100, BIP101 or some other mechanism. But the first step--and we're getting really close--is for miners to commit to simply increasing MAX_BLOCK_SIZE now.
Signalling EB1 is a signal to the network that you're serious about increasing MAX_BLOCK_SIZE.
[doublepost=1493962284][/doublepost]Interesting, block #500,000 is currently estimated to be mined on Genesis Block Day 2018:
Last edited:
go1111111
Active Member
There is a consensus algorithm implemented in the code. That's what I'm calling the EC algorithm. It uses EB and AD to decide whether/when to accept blocks.
EC is different than lower-case "emergent consensus." I'm a fan of emergent consensus but think the EC algorithm is not good.
You can say AD is optional, but that's not how BU has been marketed. (Also last I checked, not using it required a hack of setting its value super high, which shows that using AD is the intended use case). People only talk about how AD is optional when other people are pointing out its flaws.
@Roger_Murdock, I agree with you that the problematic scenarios I outlined are not super critical, but it's still easy to avoid them, so why not? It looks careless that EC has no way to deal with those issues, and gives the impression that the EC algorithm in general is not well thought through.
The miners need not be trying to harm Bitcoin. Maybe they're just trying to drive smaller miners out of business so they can more easily form a cartel and enjoy higher profits.
The larger the AD setting is, the more out of sync users will be during a real block size increase. As I discussed in my post, we don't need to make this kind of tradeoff if we use a better algorithm.
It'd be one thing if AD was just one of many potential settings that BU offered, but AD has been showcased as the centerpiece of BU's EC algorithm. It's the only thing distinguishing EC from a plain configurable block size.
In other words, practically speaking AD won't actually be useful. I agree with that.
I think that would be much better than the current EB/AD combo. The ability to use BU settings for long term coordination would be a big step forward.
"You can say AD is optional, but that's not how BU has been marketed. (Also last I checked, not using it required a hack of setting its value super high, which shows that using AD is the intended use case). People only talk about how AD is optional when other people are pointing out its flaws." -- @go1111111
I do agree that too much focus has been given to AD. AD is an optional safety mechanism -- that in normal operation would never be triggered -- to ensure that your node converges on the longest chain of valid transactions. It is not intended as a way for miners to coordinate changes to the block size limit.
BU has been working to correct this error in public perception. The new website doesn't mention AD anywhere outside of the FAQs and @freetrader has just written a BUIP to make it easier to disable AD. I'd also like to see AD signalling dropped from the user-agent and coinbase strings.
But I still don't understand how you can argue that AD is "flawed" or how that statement even makes sense. Many node operators like the AD feature, including myself. What's wrong with providing it?
I do agree that too much focus has been given to AD. AD is an optional safety mechanism -- that in normal operation would never be triggered -- to ensure that your node converges on the longest chain of valid transactions. It is not intended as a way for miners to coordinate changes to the block size limit.
BU has been working to correct this error in public perception. The new website doesn't mention AD anywhere outside of the FAQs and @freetrader has just written a BUIP to make it easier to disable AD. I'd also like to see AD signalling dropped from the user-agent and coinbase strings.
But I still don't understand how you can argue that AD is "flawed" or how that statement even makes sense. Many node operators like the AD feature, including myself. What's wrong with providing it?
lunar
Well-Known Member
- Aug 28, 2015
- 1,001
- 4,290
@Peter R
About a week ago on slack I found myself discussing something on BU signalling and just automatically started using EB1/FE8@75% instead of EB1/FE8@500000 just for ease of communication.
It might be worth putting the two options side by side and comparing their merits.
FE8@500000 tells the network the miner is wiling to accept <8MB blocks at a certain time, blk500000, in the future, with the assumption >51% of the network will go along with this. ( choice to hard fork or to increase blk depth)
FE8@75% tells the network the miner is wiling to accept <8MB blocks, at a certain majority; 75% in the future, but the timing is uncertain. However if it was clearly stated that the 75% value has a definition. (def: 750/1000 blocks and a delayed activation of 2016 blocks) Then the timing can be approximated. (option to reduce HF tolerance, or wait longer)
i'm not arguing for either option here, just stating they are different. The first option has a built in minimum viable fork of 51% and miners are horse trade on blk timing.The second option has less text in the coinbase and the miners are horse trading on minimum viable hard fork % with built in activation after 2 weeks.
Note both options could be made more flexible if FE8 was defined to mean (minimum majority integer increase <8MB.) or equivalent. eg 30% signalling 2MB, 35% signalling 4MB 20% @ 8MB and 15% not signalling for an increase, would mean the hard fork would activate after 2016 blocks or blk number but only to 2MB.
It could be advantageous to game these two scenarios further, to see which one provides the least friction to upgrade.
About a week ago on slack I found myself discussing something on BU signalling and just automatically started using EB1/FE8@75% instead of EB1/FE8@500000 just for ease of communication.
It might be worth putting the two options side by side and comparing their merits.
FE8@500000 tells the network the miner is wiling to accept <8MB blocks at a certain time, blk500000, in the future, with the assumption >51% of the network will go along with this. ( choice to hard fork or to increase blk depth)
FE8@75% tells the network the miner is wiling to accept <8MB blocks, at a certain majority; 75% in the future, but the timing is uncertain. However if it was clearly stated that the 75% value has a definition. (def: 750/1000 blocks and a delayed activation of 2016 blocks) Then the timing can be approximated. (option to reduce HF tolerance, or wait longer)
i'm not arguing for either option here, just stating they are different. The first option has a built in minimum viable fork of 51% and miners are horse trade on blk timing.The second option has less text in the coinbase and the miners are horse trading on minimum viable hard fork % with built in activation after 2 weeks.
Note both options could be made more flexible if FE8 was defined to mean (minimum majority integer increase <8MB.) or equivalent. eg 30% signalling 2MB, 35% signalling 4MB 20% @ 8MB and 15% not signalling for an increase, would mean the hard fork would activate after 2016 blocks or blk number but only to 2MB.
It could be advantageous to game these two scenarios further, to see which one provides the least friction to upgrade.
Last edited:
Roger_Murdock
Active Member
- Dec 17, 2015
- 223
- 1,453
@go1111111
And once again, it sounds like at least a lot of your issue is with BU's marketing (i.e.,"AD has been showcased as the centerpiece..."). And again, I agree with you that such marketing was misguided!
I've been saying for a while that I think a lot of BU's early marketing which emphasized the AD feature way too much was flawed. But that's just marketing. And I've also said that I think BU should have made AD explicitly optional (via on/off toggle) rather than relying on ability to set AD to an effectively infinite value. But again that really just comes down to making BU easier to market because practically speaking there's no difference. If a disgruntled minority is really convinced the hash power majority has gone over a cliff re: block size, they can certainly use plain-vanilla BU (with an effectively infinite AD setting) to allow themselves to be forked onto a minority chain, thereby allowing their chain to go to trading against the majority chain and forcing a "market referendum." If the minority is right and their chain becomes more highly valued by the market, it should quickly become the longest chain (because hash power ultimately follows price). Moreover, that will wipe out the previously-longer chain (assuming those following the big-block chain didn't add in a more restrictive / "soft fork" element to allow it to persist indefinitely as a minority chain). Having said that, I think that's a really, really unlikely scenario. If it ever really makes sense to not follow the hash power majority, Bitcoin is operating in a severe failure mode such that an emergency PoW-change is probably warranted. (And I personally don't think it will ever make sense to not follow the hash power majority over something as trivial as block size! Which is why it doesn't belong in the "consensus layer" as described here.)
But they're not really easy to avoid! (Or at least, they're not all easy to avoid in a deterministic sense. Again, practically speaking, I don't think they're an issue at all). The fundamental problem is inherent in the speculative nature of Bitcoin's "protocol." It's in your interests to only accept blocks that you anticipate that others will accept (and thus to reject blocks that you anticipate that others will reject). But it also makes sense to be prepared to revise your predictions about what others will accept based on new information about what they're actually doing. The AD feature is just an (optional and flexibly configurable) emergency fail-safe that allows you to make sure that you will ultimately, automatically, track the most-proof-of-work chain regardless of block size.
Ok, but Bitcoin's entire security model is premised on the notion that the hash power majority will be incentivized to act in an intelligently profit-seeking manner, and that this includes acting to protect the health and integrity of the network.
As I've written before, "emergent (i.e.,decentralized) consensus" is just a buzzword. It's not a new model; it's the way Bitcoin has always worked and the only way it could work. To me, EC doesn't imply AD! Rather, as I see it, people are simply using the term "EC" to highlight the fact that the network's actual stakeholders are free to converge on Schelling points other than those "hard-coded" into clients by volunteer "devs." EC is thus the idea that in cases of controversy, we should "get the devs out of the way" and attempt to reduce the friction associated with the stakeholders' negotiation of that controversy.
And once again, it sounds like at least a lot of your issue is with BU's marketing (i.e.,"AD has been showcased as the centerpiece..."). And again, I agree with you that such marketing was misguided!
I don't think it will be terribly useful in practice, but I think it's still potentially useful (especially for non-mining nodes). Having said that, I'm a bit on the fence as to whether including AD at all was a mistake. It's certainly been a major FUD vector and source of confusion. On the other hand, if we hadn't included it, I imagine the attack would have been: "BU doesn't guarantee convergence! The blockchain will splinter permanently into a thousand pieces as people set their EB settings all over the place in an arbitrary, uncoordinated manner." I don't think there's any winning when it comes to a lot of BU's most vocal detractors.
Sure, although I tend to think most real coordination will occur out-of-band. Having said that, I see BU's entire philosophy as one of empowering the users. So if there are additional tools that a significant number of users would actually find helpful vis-a-vis block size, then we should definitely give serious consideration to including them. Having said that, I also think "the block size issue" has been made infinitely more complicated than it needed to be. So I don't think the real problem is that the network's stakeholders don't have adequate tools; I think the real problem is that the process of routing around Core's entrenched status as "the reference client," moving toward a healthier multi-implementation governance environment, and countering all of the absurd propaganda and censorship is such a slow and painful one.
Last edited:
xhiggy
Active Member
- Mar 29, 2016
- 124
- 277
@go1111111
Many of the criticisms of the BU EC algorithm, as you put it, come from an assumption that the miners will follow it in lockstep, as if it is hardcoded into their hands when they type instructions for their computers. The setting parameters are just tools to communicate things the BU team thinks that the miners would want to share with each other. Once you realize this, the settings are a part of a larger decision making process, and there is flexibility to avoid these problems.
Scenario #1: Use software to consider orphan risk before determining how much security your confirmed transaction really has. If you are included in an excessive block for X% of the hashrate, do not consider this confirmation like you normally would.
Scenario #2: Set AD to 1.
Scenario #3:
Many of the criticisms of the BU EC algorithm, as you put it, come from an assumption that the miners will follow it in lockstep, as if it is hardcoded into their hands when they type instructions for their computers. The setting parameters are just tools to communicate things the BU team thinks that the miners would want to share with each other. Once you realize this, the settings are a part of a larger decision making process, and there is flexibility to avoid these problems.
Scenario #1: Use software to consider orphan risk before determining how much security your confirmed transaction really has. If you are included in an excessive block for X% of the hashrate, do not consider this confirmation like you normally would.
Scenario #2: Set AD to 1.
Scenario #3:
How on earth does this happen? You are describing 51% of miners taking control of the chain. One can easily set their client to change their settings dynamically if they see something ridiculous like this. The EC/AD settings are signals and not smart contracts that automatically activate if certain things happen.
EC, as you put it, is a signalling mechanism, not a set of laws everyone is agreeing to follow.
The less parameters have to be set, the easiest and more effective is the process. So far, for what I've understood, the parameters are the voting period, the quorum, and the voted size limit.
The voting period could be set by the required quorum, so it could be removed from the list. The quorum though, requires to define a default number of blocks, which may be a source of disagreement. Given this fact, I'd propose to think in terms of voting period. A good side-effect of this latter option, is that it compels miners to partecipate when in disagreement, in order to save their interest. A quorum would leave the option to disagree by ignoring the vote, and it's lost information (we don't know their preferences). The first problem of any voting system is to make it sure or likely that voters will partecipate and reveal their preferences in a truthful way, so that a truthfhul consensus is reached, and so incentive compatibility. Whoever would have chosen not to vote, would have signaled consent, while in the case of a quorum it would not be obvious, and more votations would be needed in future to ensure consensus.
An other bad consequence of quorums, is that they would need (statistically) more time compared to voting-period votings. This because not voting would be a vote for n-1 possible sizes, and cognitively less expensive than actually voting (as it happends in liberal democracies).
The voted size limit cannot be removed, obviously. Averaging would make it possible to aggregate different voting rounds, in order to not waste time and resources. This is cause it would make the voting implicitly multivalued.
So I would favor something like a FE8@500000 + averaging.
The voting period could be set by the required quorum, so it could be removed from the list. The quorum though, requires to define a default number of blocks, which may be a source of disagreement. Given this fact, I'd propose to think in terms of voting period. A good side-effect of this latter option, is that it compels miners to partecipate when in disagreement, in order to save their interest. A quorum would leave the option to disagree by ignoring the vote, and it's lost information (we don't know their preferences). The first problem of any voting system is to make it sure or likely that voters will partecipate and reveal their preferences in a truthful way, so that a truthfhul consensus is reached, and so incentive compatibility. Whoever would have chosen not to vote, would have signaled consent, while in the case of a quorum it would not be obvious, and more votations would be needed in future to ensure consensus.
An other bad consequence of quorums, is that they would need (statistically) more time compared to voting-period votings. This because not voting would be a vote for n-1 possible sizes, and cognitively less expensive than actually voting (as it happends in liberal democracies).
The voted size limit cannot be removed, obviously. Averaging would make it possible to aggregate different voting rounds, in order to not waste time and resources. This is cause it would make the voting implicitly multivalued.
So I would favor something like a FE8@500000 + averaging.
Roger_Murdock
Active Member
- Dec 17, 2015
- 223
- 1,453
I loved this comment from Greg. Obviously he was attempting to mock the "emergent consensus" herding animals / flocking birds analogy but, in fact, he provided a way to extend it.
As I said to him in my reply, I suppose in the Bitcoin context that would involve compromising people like the most influential developers for the "reference implementation" or the owner of several key Bitcoin communication channels.
I'd also observe that the group decision-making process of cattle (with respect to travel direction) may be "trivially exploitable" by a human who understands the dynamics involved in the process - but in that scenario you're talking about an entity that is radically more intelligent (and thanks to technology, radically more powerful) than a cow. I think it's safe to assume that the Bitcoin analog for "the herd" (i.e., a market made up of millions of individual human actors) isn't up against a comparatively more intelligent and powerful foe. (That's not an insult, Greg. I'm sure you're still very smart.)
(emphasis added)
As I said to him in my reply, I suppose in the Bitcoin context that would involve compromising people like the most influential developers for the "reference implementation" or the owner of several key Bitcoin communication channels.
I'd also observe that the group decision-making process of cattle (with respect to travel direction) may be "trivially exploitable" by a human who understands the dynamics involved in the process - but in that scenario you're talking about an entity that is radically more intelligent (and thanks to technology, radically more powerful) than a cow. I think it's safe to assume that the Bitcoin analog for "the herd" (i.e., a market made up of millions of individual human actors) isn't up against a comparatively more intelligent and powerful foe. (That's not an insult, Greg. I'm sure you're still very smart.)
I asked Greg if that was a confession, but he hasn't replied.
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
Sorry, I have to correct you on the BUIP link (what you linked was an initial call-for-interest post from last year):
https://bitco.in/forum/threads/buip054-make-ad-optional-set-default-to-infinity-i-e-disabled.2090/
Reading @Roger_Murdock above I realize that "infinity" for disabling something is a scary concept that does not engender trust.
Perhaps I should change the BUIPs title to remove "infinity" from it.
Users would in fact be able to use the more comforting alternatives
excessiveacceptdepth=off
excessiveacceptdepth=disabled
excessiveacceptdepth=false
... if they do not wish to to use 'infinity' or 'infinite' or 'inf' .
Last edited:
lunar
Well-Known Member
- Aug 28, 2015
- 1,001
- 4,290
I think the edge case dynamics would need to be sketched out to make sure they add up correctly, Iike I say, I haven't thought this through. Nevertheless in the above scenario you have 70% of the network signalling for an 8MB increase, with 30% whose activation threshold has been passed. (They are ready to mine on any block <8M - Yet the hardfork has not happened yet as they themselves are unlikely to mine a block that would risk forking.) note it is actively their choice to have set the 65% threshold opposing the 75%
My gut tells me that the normal incentives due to orphan risk will apply, and they will quickly come to consensus rather than risk orphaning or persistent chain split.
Method one has strong schelling points on safe block number (we already see everyone using blk500000) method 2 has strong schelling points on safe threshold for forking; convergence to say 66% or 75% might be the norm here. There are pros and cons for both. The difference is speed, of resolution. Method 2 has a continual 2016blk resolution period, whereas method 1 is more of an abstract point in the future.
note this is still signalling we are talking about, no miner is ever forced to do anything without majority. They may well change their coinbase at any moment in either scenario.
edit afterthought. we are examining this from a core perspective (large blocks, very dangerous, much centralisation wow) but after the 1MB is removed whats stopping all miners just lifting the limit to - 'any value well above demand' ? We might find miners set a minimum Tx fee then signal EB50 and have done with it for a while. At this point the resistive force comes from the other direction.
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
@Chritchens is working on an upgraded version of the Parity full node client, starting with a fixed bump to 2MB. He seems too humble to brag about it here, so I will point the spotlight
If there is anybody who knows Rust, I'm sure he would appreciate someone reviewing his modifications. Here's his announcement thread in this forum, so it does not get lost.
https://bitco.in/forum/threads/multi-implementation-client-development.2092/
And here's the repo: https://github.com/chritchens/parity-bitcoin-unlimited
Eventually this could turn into an ABC-capable version of Parity, or even a BU-compatible EC version.
Nice work, Christian!
To the rest of us, we could try helping him by testing or donating for his efforts, if he wishes.
If there is anybody who knows Rust, I'm sure he would appreciate someone reviewing his modifications. Here's his announcement thread in this forum, so it does not get lost.
https://bitco.in/forum/threads/multi-implementation-client-development.2092/
And here's the repo: https://github.com/chritchens/parity-bitcoin-unlimited
Eventually this could turn into an ABC-capable version of Parity, or even a BU-compatible EC version.
Nice work, Christian!
To the rest of us, we could try helping him by testing or donating for his efforts, if he wishes.
@freetrader, thank you for the advertisement XD. I'm not very into social networks, have to learn though
I will appreciate suggestions, tests, pushes and donations. I will move both the parity-bitcoin and the btcd forks into an organization, to avoid meddling stuff and because I don't like so much personalism, even if accidental. Btcd-unlimited is everything but ready, so far I've not pushed any commit, because tests are not ready, parity-bitcoin-unlimited could be used as it is. I have to admit though, that there are bugs in parity-bitcoin itself. So far I've found one in the buildig of op_return scripts. So, use it with moderation.
Donations would help me spend more time on this, cause so far I'm split among different projects. If I could merge the one I'm more into, a blockchain-based storage system, and Bitcoin, it would be cool, but without using federated sidechains or novel opcodes it's kinda impossible so far. An aside.
I would use part of the donations for testing in mainnet, cause no-one, for what I know, has publicly said how it feels to run parity-bitcoin. It would be cool also for testing purposes, cause there are other mods I would love to test, e.g. drivechain.
Btc address for donations: 1BDcLgVw777Qwjz8g5c21xUkPUvccDeyNi.
I will appreciate suggestions, tests, pushes and donations. I will move both the parity-bitcoin and the btcd forks into an organization, to avoid meddling stuff and because I don't like so much personalism, even if accidental. Btcd-unlimited is everything but ready, so far I've not pushed any commit, because tests are not ready, parity-bitcoin-unlimited could be used as it is. I have to admit though, that there are bugs in parity-bitcoin itself. So far I've found one in the buildig of op_return scripts. So, use it with moderation.
Donations would help me spend more time on this, cause so far I'm split among different projects. If I could merge the one I'm more into, a blockchain-based storage system, and Bitcoin, it would be cool, but without using federated sidechains or novel opcodes it's kinda impossible so far. An aside.
I would use part of the donations for testing in mainnet, cause no-one, for what I know, has publicly said how it feels to run parity-bitcoin. It would be cool also for testing purposes, cause there are other mods I would love to test, e.g. drivechain.
Btc address for donations: 1BDcLgVw777Qwjz8g5c21xUkPUvccDeyNi.
