- Aug 29, 2015
- 536
- 2,597
New article by John Blocke: Bitcoin Economics in One Lesson
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
@adamstgbit
I liked your post because I think the biggest pitfall for us BU supporters and creators is to get so obsessed with tools like AD that we forget they are just tools, only useful for one particular class of emergent consensus scenario.
For example, if miners and important nodes simply decide out of band that they will raise the blocksize cap starting at a certain block number, the other BU tools may go unused. Or maybe will be only used by nodes as a failsafe. Et cetera.
I've seen some offhand remarks recently that if BU tools like AD are not used we can't have emergent consensus, but that very much depends on whether blocksize is emergently coordinated and actually very solid and well-defined in any given period, or whether it is this dynamic thing that is always liable to move around. I think people are falling into thinking that emergent consensus has to look like the latter, when it could easily look like the former. In fact I think the former is more likely.
You buy a set of wrenches and probably never use most of them. That doesn't mean they weren't worth buying, because you have them if you need them. It would be a mistake, however, to assume that just because you bought them all you're going to use them all, and to reason about all your future plans from the premise that that 7/8-incher is definitely going to play a key role in them.
[doublepost=1481599752][/doublepost]And if I may reiterate, forcing the user to set such things (instead of having defaults) seems to remove the problem of miner uneasiness (the ol' jonny1000 catch-22?
).
I liked your post because I think the biggest pitfall for us BU supporters and creators is to get so obsessed with tools like AD that we forget they are just tools, only useful for one particular class of emergent consensus scenario.
For example, if miners and important nodes simply decide out of band that they will raise the blocksize cap starting at a certain block number, the other BU tools may go unused. Or maybe will be only used by nodes as a failsafe. Et cetera.
I've seen some offhand remarks recently that if BU tools like AD are not used we can't have emergent consensus, but that very much depends on whether blocksize is emergently coordinated and actually very solid and well-defined in any given period, or whether it is this dynamic thing that is always liable to move around. I think people are falling into thinking that emergent consensus has to look like the latter, when it could easily look like the former. In fact I think the former is more likely.
You buy a set of wrenches and probably never use most of them. That doesn't mean they weren't worth buying, because you have them if you need them. It would be a mistake, however, to assume that just because you bought them all you're going to use them all, and to reason about all your future plans from the premise that that 7/8-incher is definitely going to play a key role in them.
[doublepost=1481599752][/doublepost]And if I may reiterate, forcing the user to set such things (instead of having defaults) seems to remove the problem of miner uneasiness (the ol' jonny1000 catch-22?
).
Last edited:
- Aug 29, 2015
- 536
- 2,597
@adamstgbit @Zangelbert Bingledack The way I think about AD is a kind-of fail safe, or failure mode recovery. I don't think any node operator would set up their node expecting the Acceptance Depth behavior ever to be used. It is a fall-back in case other nodes on the network do something unexpected.
So I don't think we need to make AD behavior overly sophisticated or complicated. If AD is ever used, it means something unexpected happened, and the node operator will probably have to investigate and manually intervene to adjust the node configuration.
One AD behavior I would support is some kind of prominent user notification if AD is ever reached (maybe it already does this? I am not super familiar with the implementation details).
So I don't think we need to make AD behavior overly sophisticated or complicated. If AD is ever used, it means something unexpected happened, and the node operator will probably have to investigate and manually intervene to adjust the node configuration.
One AD behavior I would support is some kind of prominent user notification if AD is ever reached (maybe it already does this? I am not super familiar with the implementation details).
adamstgbit
Well-Known Member
- Mar 13, 2016
- 1,206
- 2,650
@Mengerian
i've very recently become more interested with the details of AD's functionality and purpose. and i've become convinced it very much tied to the heart of this "emergent consensus" idea BU is known for.
seems to me, the root idea of this "emergent consensus" is that nodes all act independently when it comes to enforcing blocksize limits. There is no universally accepted and known blocksize limit, only individualistic limits set by individual nodes. This means that AD is required, since a node will never be able to orphen a block and know for sure if the rest of the network will do the same.
AD allows all the nodes to act very independently and at the same time guarantee all nodes will "converge" onto the same chain in the end.
Problem is that if AD is reached all the individual attempts at enforcing individual limits have failed, and its possible that this is due to a minority hashing power acting like a shit head. a minority now has the possibility of imposing its will on the majority! scrazy thought!
to prevent this we can do many things
i am saying set an upper limit so the shit-head-miner can only do limited damage
https://bitco.in/forum/threads/implicit-blocksize-limit.1664/
thezerg is saying if AD is based on the weight of EB then the cost of this attack becomes very high very fast.
https://bitco.in/forum/threads/buip041-buip038-counter-prevent-minority-hash-power-from-injecting-very-large-blocks.1648/
someone else is saying F' AD all together.
in the end i think its a minor issue really, the cost of the attack even as it stands today is kinda high, without very significant hashing power cost is simply to high.
but its interesting thing to fallow, and also it provides incentive to really understand how BU is currently using all this MG EB AD stuff
i've very recently become more interested with the details of AD's functionality and purpose. and i've become convinced it very much tied to the heart of this "emergent consensus" idea BU is known for.
seems to me, the root idea of this "emergent consensus" is that nodes all act independently when it comes to enforcing blocksize limits. There is no universally accepted and known blocksize limit, only individualistic limits set by individual nodes. This means that AD is required, since a node will never be able to orphen a block and know for sure if the rest of the network will do the same.
AD allows all the nodes to act very independently and at the same time guarantee all nodes will "converge" onto the same chain in the end.
Problem is that if AD is reached all the individual attempts at enforcing individual limits have failed, and its possible that this is due to a minority hashing power acting like a shit head. a minority now has the possibility of imposing its will on the majority!
scrazy thought!to prevent this we can do many things
i am saying set an upper limit so the shit-head-miner can only do limited damage
https://bitco.in/forum/threads/implicit-blocksize-limit.1664/
thezerg is saying if AD is based on the weight of EB then the cost of this attack becomes very high very fast.
https://bitco.in/forum/threads/buip041-buip038-counter-prevent-minority-hash-power-from-injecting-very-large-blocks.1648/
someone else is saying F' AD all together.
in the end i think its a minor issue really, the cost of the attack even as it stands today is kinda high, without very significant hashing power cost is simply to high.
but its interesting thing to fallow, and also it provides incentive to really understand how BU is currently using all this MG EB AD stuff
Last edited:
Roger_Murdock
Active Member
- Dec 17, 2015
- 223
- 1,453
My views track @Mengerian 's above. Also, I don't see why removing functionality would make BU more attractive. If miners don't want to use the AD feature, they don't have to -- they can set it to effectively infinite by maxing out its value. (Or they can set it to something like 1,000 to at least cover the dreaded I-fell-into-a-coma-and-the-rest-of-the-network-decided-to-raise-the-limit-before-I-woke-up scenario.)
But you're wrong to think that if there were no AD setting, you could simply look at everyone's advertised EB settings to determine a block size which >51% will "for sure" reject. The rules that the network are actually enforcing at any given time are inherently indeterminate because (among other reasons) people can false signal their settings.
adamstgbit
Well-Known Member
- Mar 13, 2016
- 1,206
- 2,650
@Roger_Murdock
ya I'm starting to get a much clearer picture...
I think AD is a sort of fail safe, because in reality miners will be very careful when setting MG and EB and its unlikely they will start "fighting" and resorting to AD to impose their biggest-block-ever.
however, there is an slightly annoying attack vector exposed by this totally free for all emergent consensus.
ya I'm starting to get a much clearer picture...
I think AD is a sort of fail safe, because in reality miners will be very careful when setting MG and EB and its unlikely they will start "fighting" and resorting to AD to impose their biggest-block-ever.
however, there is an slightly annoying attack vector exposed by this totally free for all emergent consensus.
- Aug 22, 2015
- 1,558
- 4,693
To be honest, there is a slightly annoying attack vector exposed by Core's unfree ACK-ACK consensus.
Right now, a miner with significant hash-rate could keep mining empty blocks, reducing effective block capacity by a third or even a half strangling the Bitcoin economy, now that there is no "fat" in the transaction flow, anything cut down is real economic activity with meaningful urgency to the users.
Right now, a miner with significant hash-rate could keep mining empty blocks, reducing effective block capacity by a third or even a half strangling the Bitcoin economy, now that there is no "fat" in the transaction flow, anything cut down is real economic activity with meaningful urgency to the users.
Last edited:
@awemany, I like the idea of a higher level script, and if someone made an example, it might help miners actually implement one. You probably have all the RPC commands you need already, but if there's a strong argument for others, I'll add them.
Miners using the emergent consensus algorithm will benefit from coming to an agreement about when to change EB or max generate size settings. Due to the trust involved (these agreements/algorithms always assume that miners are voting honestly) I always imagined this as a manual process, but a script is also an option.
And a script that notifies the miner when EB or EB/AD is exceeded would be great! I don't think that it makes much sense to put all the modern notification channels in bitcoind -- a customizable script makes a lot of sense.
But I still think, even with scripts, notification, etc, that BUIP041 (basically wait proportionally longer before accepting proportionally bigger blocks) will be useful.
[doublepost=1481637209][/doublepost]
Yes but that is the reality of the situation. The problem with the block voting schemes (i.e. when 90% of blocks are marked like this, wait 30 days then activate the feature), is liars who vote but then don't activate. This could force a minority of nodes off onto a fork with a panic downgrade to fix the problem, resulting in a favorable difficulty adjustment for those miners who stay on the main chain.
Yes, liars will be rare (maybe non-existent), but EC works just peachy in the blue sky scenario as well... this huge block attack is extremely theoretical, requires a similarly large % of the hash power, and (unlike lie-about-voting schemes) spends a lot of money in the form of orphaned blocks.
I saw there is finally a writeup of what transpired this past sunday. Things are going to get bumpy.
http://news.8btc.com/exlusive-roger-ver-said-house-of-bitcoin-is-on-fire-and-said-house-of-bitcoin-is-on-fire-in-cores-meetup-on-sunday
http://news.8btc.com/exlusive-roger-ver-said-house-of-bitcoin-is-on-fire-and-said-house-of-bitcoin-is-on-fire-in-cores-meetup-on-sunday
To get a jump on the next Core/BS narrative, any ideas what they will say if we have a big price rally from now, like to $2000+?
- "The market loves full blocks"
- "The market loves Core stewardship"
- "The market loves gridlock because Extreme Consensus shows Bitcoin is immutable" <cringe>
- "It's because Segwit is about to be adopted"
- "It's because LN has is ready to be released"
- "It's because BU adoption is stalled"
???
- "The market loves full blocks"
- "The market loves Core stewardship"
- "The market loves gridlock because Extreme Consensus shows Bitcoin is immutable" <cringe>
- "It's because Segwit is about to be adopted"
- "It's because LN has is ready to be released"
- "It's because BU adoption is stalled"
???
@theZerg: Cool. Are there JSON-RPCs already for setting AD/EB? I looked but I couldn't find any. I thought there were some in the back of my mind.
I am wondering whether I should make my BUIP just 'provide tools to make it possible to write short scripts for EB/AD notification as well as implementing dynamic blocksize proposals' - and simply make it compatible with all the other BUIPs regarding the sticky flag out there - and not a counter proposal to them.
(And regarding the voting code: I was busy with other stuff. I'll write something up the next couple days and make a thread somewhere here on this. I'll try to get the google hangout working as well. From what I gathered from @Peter R., the voting part wasn't highly time critical yet.)
I am wondering whether I should make my BUIP just 'provide tools to make it possible to write short scripts for EB/AD notification as well as implementing dynamic blocksize proposals' - and simply make it compatible with all the other BUIPs regarding the sticky flag out there - and not a counter proposal to them.
(And regarding the voting code: I was busy with other stuff. I'll write something up the next couple days and make a thread somewhere here on this. I'll try to get the google hangout working as well. From what I gathered from @Peter R., the voting part wasn't highly time critical yet.)
molecular
Active Member
- Aug 31, 2015
- 372
- 1,391
https://www.reddit.com/r/Bitcoin/comments/5i46nu/bitcoin_core_irc_meeting_summary_december_8_2016/
in this reddit thread nullc is bragging about how he helps users double-spend funds and the linked core meeting notes show they want to increase mempool expiry time from 3 days to 2 weeks (!!!)
Looks like they're preparing an even more successful "fee cartel"? Maybe the miners have to be bribed?
in this reddit thread nullc is bragging about how he helps users double-spend funds and the linked core meeting notes show they want to increase mempool expiry time from 3 days to 2 weeks (!!!)
Looks like they're preparing an even more successful "fee cartel"? Maybe the miners have to be bribed?
adamstgbit
Well-Known Member
- Mar 13, 2016
- 1,206
- 2,650
" The needs of the few outweigh the needs of the many, or the whole "
So on Reddit, @jonny1000 just mentioned his friend having a nTimelock transaction to himself in the future.
What do you guys think is reasonable time frame for IOUs to be redeemable on Bitcoin?
2 years, 5 years, 10 years, infinite? I personally think <=10y is about the time frame, with my own opinion probably somewhere in the 2 .. 5 years range. It is a trade-off, IMO. What do others think?
Also: With all the talk about LN channels being open indefinitely, we and the miners should be especially careful with what kind of new Blockchain uses are agreed upon or are incentivized: Because lots of people having money locked into a Blockstream channel for a hundred years might well shift the incentives to them supporting Blockstream in certain ways!
What do you guys think is reasonable time frame for IOUs to be redeemable on Bitcoin?
2 years, 5 years, 10 years, infinite? I personally think <=10y is about the time frame, with my own opinion probably somewhere in the 2 .. 5 years range. It is a trade-off, IMO. What do others think?
Also: With all the talk about LN channels being open indefinitely, we and the miners should be especially careful with what kind of new Blockchain uses are agreed upon or are incentivized: Because lots of people having money locked into a Blockstream channel for a hundred years might well shift the incentives to them supporting Blockstream in certain ways!
Last edited:
Quite sane discussion I just had with luke-jr on reddit regarding VISA scale full nodes, but then ...
Part of the discussion: Luke-Jr (Blockstream employee or at least contractor!) saying that Lightning Network is basically just regular (existing) Bitcoin payment channels stringed together. I think this bit has interesting implications, given the fact that payment channel use didn't pick up yet and that Blockstream intends to somehow sell LN.
Part of the discussion: Luke-Jr (Blockstream employee or at least contractor!) saying that Lightning Network is basically just regular (existing) Bitcoin payment channels stringed together. I think this bit has interesting implications, given the fact that payment channel use didn't pick up yet and that Blockstream intends to somehow sell LN.
Yes this feature is valuable irrespective of what AD algorithm is chosen... I would suggest a separate BUIP.
bucktotal
Member
- Aug 28, 2015
- 28
- 54
i'd could see, for example, parents creating such transactions for trust-fund babies, or something similar. So a use case for 18+yrs is there.
lunar
Well-Known Member
- Aug 28, 2015
- 1,001
- 4,290
Another fantastic essay. These articles that deconstruct the economics, really shine a light on Cores fundamental ignorance of the incentives that make bitcoin function as sound money.
Treating miners as the enemy is foolish. It seems they either don't understand the 51% solution to the byzantine generals problem or that they want to somehow 'improve' on this dynamic, not realising that by doing so it is under mining the only thing that keeps the network secure.
Instead we should be attempting to give miners as much potential to profit from fees as possible. This increases the incentive to mine and hence increases bitcoins security.
Thank you Mr Blocke
I see it's been picked up by FEE too. Great job.