What gets me is that there's nothing stopping miners from increasing the blocksize by modding their code, other than that they know the ecosystem (nodes, investors, infastructure) may not accept it because a lot of the community trusts Core. Yet Core is saying that if everyone ran BU, miners would mine and relay abusively large blocks. It's so weird because the miners can very easily remove their blocksize cap by modding their code; the trick is always to get enough of everyone else to accept it, so what difference does it make if they run Core or BU??
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
In terms of the miners, I don't think a lot of them care about the block size stuff or the things more technical in nature. They just see it as a way to make 'easy money.' I.e, who cares about any of this stuff, all we care is that the spice keeps flowing. I think that's probably 50% of miners everywhere and then you have 25% firmly supporting either camp. I'm interested to see Sundays news one way or another. This war has been going on since 2012 it seems and will not stop anytime soon.
Last edited:
Miners are going to have to start caring, because it will no longer be easy money when they have to make informed choices about how big to make blocks so as to avoid losing a ton of money to orphaning (or on the other end, a ton of money to fees left on the table). The fact that they don't have to do this now a symptom of Bitcoin's immaturity, their lateness in waking up to this fact is a symptom of Core dev's paternalism.
Satoshi - in the whitepaper - intended miners to be investor-like stewards, and they are. It's just that they haven't had the incentives or reason to step into their role until now, because there hasn't been enough volume to hit arbitrary protocol limits or enough controversy or dev-team co-option for them to actually have money on the line that requires making the right decision. Soon enough the decision about what size blocks to mine will be crucial to their bottom line and they will pay dearly for getting it wrong.
That will be the mining business. It will entail a lot of market research and probably in-house devs and economic consultants. It's going to be a lot healthier that the current Core-dev-presided system, and it will make a lot more sense as these "miners dancing on heads of a pin" arguments will die as it will be obvious that miners, far from being great potential attackers, are in fact total slaves to market demand and will do anything to avoid stepping on the ecosystem's toes.
Satoshi - in the whitepaper - intended miners to be investor-like stewards, and they are. It's just that they haven't had the incentives or reason to step into their role until now, because there hasn't been enough volume to hit arbitrary protocol limits or enough controversy or dev-team co-option for them to actually have money on the line that requires making the right decision. Soon enough the decision about what size blocks to mine will be crucial to their bottom line and they will pay dearly for getting it wrong.
That will be the mining business. It will entail a lot of market research and probably in-house devs and economic consultants. It's going to be a lot healthier that the current Core-dev-presided system, and it will make a lot more sense as these "miners dancing on heads of a pin" arguments will die as it will be obvious that miners, far from being great potential attackers, are in fact total slaves to market demand and will do anything to avoid stepping on the ecosystem's toes.
Last edited:
- Aug 29, 2015
- 536
- 2,597
The mining market continues to evolve towards increasingly specialized division of labor. Over time, it could start to shift away from "pools", where hashers still bear risk from the luck of finding blocks or not, towards a market where pools simply purchase hash power directly for bitcoins, at a rate determined on the spot market. The pools would become specialized block builders.
The hashers would then simply specialize in producing hash rate in the most efficient manner possible. Block builders would deal with all the complications of the Bitcoin network such as transaction selection policies, block transmission and orphaning, and fostering utility for Bitcoin users. The block builders would also have to deal with market risks, and hashing variance "luck". They would grow into the role of "investor-like stewards".
The hashers would then simply specialize in producing hash rate in the most efficient manner possible. Block builders would deal with all the complications of the Bitcoin network such as transaction selection policies, block transmission and orphaning, and fostering utility for Bitcoin users. The block builders would also have to deal with market risks, and hashing variance "luck". They would grow into the role of "investor-like stewards".
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
Indeed. I have argued before that Satoshi had to have the foresight to see that development is the remaining somewhat-central-point-of-failure (when enough folks are sleepwalking / hypnotically follow the current team) in his scheme. He needed the insight into incentives and people dynamics and how money, bubbles, fear and greed work to implement this beast. A single, centralized development team is way too obvious to overlook as a potential problem if you think about the big picture.
By introducing the (rather low, one might add!) 1MB limit and clearly calling it temporary everywhere and having made sure that he is not misunderstood(*) on scaling, he put in something so that the inevitable psychopaths, always present and always attracted to power that appears up for grabs like flies to shit, show up soon enough and find something to attach to. Find something to try to exploit.
And so the 1MB limit is that flytrap, and surely it is working as intended.
The miners' gravest mistake (and a total dick move) in all this was to 'give Core the benefit of killing the competition'. They absolutely squandered the chance to nip this problem in the bud - they even made it a lot worse - but on the plus side, if Bitcoin survives this, it will have - as you have said - developed an even better immune system.
It appears that miners are slowly waking up, though. I think that's mostly what all our 'keyboard warriordom' does when we're writing on reddit and elsewhere. To raise enough of a stink and to show the miners that the early adopters and holders do care about not needlessly deviating and redefining Bitcoin's path, like Core - led by the Blockstream-bought developers - very clearly intends to do.
--
(*)- It should be noted that one of the lines of attack I have seen from Greg or his minions is that 'Satoshi was ambivalent about on-chain scaling, it is not clear whether he was a big blocker...' Thus trying to muddy the waters on this absolutely clear picture whether Bitcoin is meant as on-chain scalable or not. If applied often enough (repeat a lie ...), this is a powerful propaganda technique, and as an example on how this tactic can be successfully used to hollow out quite clear-cut agreements, one need to look no further than the sorry state of the 2nd and the 4th amendment in the U.S.
Thought experiment:
From a network-stewardship perspective, my profit maximization is exactly aligned with maximizing transaction throughput but only to the extent that it keeps everyone in the ecosystem happy. Same for the mining pools, as they gain and lose revenue (and users) in the same way.
From an attack perspective, mining an abusive block (such as an excessively large block) or contributing my hashpower to a pool that has abusive policies is going to lose me money due to orphaning. The incentives are so tightly interwoven that it doesn't even make sense to call such blocks "abusive" but rather just "throwing away money."
- BU-like user-configurable blocksize settings get universally adopted
- We are having another 2013-like adoption surge and blocksizes are averaging around 50MB
- Nodes are getting bumped off and there is a lot of controversy that maybe we are going too far
- Therefore some really big blocks are getting orphaned sometimes as other miners become reluctant to build on them for fear of pissing off more nodes, the infrastructure companies that run them, and the investors (importantly, assume there is Xthin and more so that the orphaning is NOT due to network transport constraints yet, but solely the Keynesian beauty contest)
- Yet all the juicy fees are looking quite attractive so miners aren't incredibly conservative either
- Some pools are more conservative than others
- I just bought a powerful ASIC
From a network-stewardship perspective, my profit maximization is exactly aligned with maximizing transaction throughput but only to the extent that it keeps everyone in the ecosystem happy. Same for the mining pools, as they gain and lose revenue (and users) in the same way.
From an attack perspective, mining an abusive block (such as an excessively large block) or contributing my hashpower to a pool that has abusive policies is going to lose me money due to orphaning. The incentives are so tightly interwoven that it doesn't even make sense to call such blocks "abusive" but rather just "throwing away money."
Gmax often brings up the following supposedly-clever attack scenario in the absence of a hardcoded blocksize cap:
1. Miners up the blocksize enough to bump a little less than half the nodes off the network (an economic minority, the logic being that if they bumped off an economic majority of nodes they would just ignore the overlarge blocks)
2. The remaining nodes are fine with it, because they didn't get bumped off, so "Bitcoin is fine"
3. A while later, the miners raise the blocksize even higher, bumping off a little less than half of the remaining nodes by economic import
4. The remaining nodes again don't mind and "Bitcoin is fine"
5. The miners keep doing this every so often until there are hardly any nodes left and the network is centralized and most of the nodes by economic importance have been disenfranchised even though at any given time there weren't enough of them to stop the next turn of the ratchet (the second time, about 75% of the economy is against it, but "they no longer run nodes so are irrelevant")
How does this attack look in the above thought experiment? What do I do with my ASIC at each stage to maximize my income? Probably at the very start I don't mine for a pool that would mine such big blocks as to knock off anywhere near half of the economically important nodes.
Note: I've actually steelmanned (made stronger) Gmax's argument here: his original argument was even more handwavy as it only spoke of "nodes" (or "full nodes") with no reference to their economic import.
Knocking off "half the nodes" may be fine if they are mostly just charity nodes and sybils spun up to make a point. This judgment is the key one: what kinds of nodes am I knocking off, and what are the investors thinking? This judgment is the one Core developers feel should be theirs to make, rather than the miners. Why should that be so? What incentive to do they have to get it right? What expertise do they have in market research, investing, economics, business, etc.?
Core devs have no more expertise to set the size of blocks than they have to set the price of Bitcoin itself. They are not investors, only advisors.
Clearly this is a job for the miners, who are a unique type of investor specialized in staying attuned to what everyone else in the ecosystem wants, or soon will be when they realize their ability to do this is the deciding factor in their profitability. (If they fail, yes, as I often say it goes to the general hodlers/investors to "fire" them by a PoW-changing fork, or to deliberately create a permanent split.)
Under controversy, then, is exactly when being a miner becomes interesting. There is money to be made by being a better steward of the network, knowing what kind of blocks to build and when, knowing when to orphan other miners' blocks, always researching the market, polling the ecosystem, looking at fork prediction markets, being conservative enough to avoid stepping on people's toes but not so conservative that fee money is left on the table (and that altcoins take over due to overconservatism).
The current crop of miners/pools may not be up to the task, and there will be a winnowing as the BS Dam breaks.
1. Miners up the blocksize enough to bump a little less than half the nodes off the network (an economic minority, the logic being that if they bumped off an economic majority of nodes they would just ignore the overlarge blocks)
2. The remaining nodes are fine with it, because they didn't get bumped off, so "Bitcoin is fine"
3. A while later, the miners raise the blocksize even higher, bumping off a little less than half of the remaining nodes by economic import
4. The remaining nodes again don't mind and "Bitcoin is fine"
5. The miners keep doing this every so often until there are hardly any nodes left and the network is centralized and most of the nodes by economic importance have been disenfranchised even though at any given time there weren't enough of them to stop the next turn of the ratchet (the second time, about 75% of the economy is against it, but "they no longer run nodes so are irrelevant")
How does this attack look in the above thought experiment? What do I do with my ASIC at each stage to maximize my income? Probably at the very start I don't mine for a pool that would mine such big blocks as to knock off anywhere near half of the economically important nodes.
Note: I've actually steelmanned (made stronger) Gmax's argument here: his original argument was even more handwavy as it only spoke of "nodes" (or "full nodes") with no reference to their economic import.
Knocking off "half the nodes" may be fine if they are mostly just charity nodes and sybils spun up to make a point. This judgment is the key one: what kinds of nodes am I knocking off, and what are the investors thinking? This judgment is the one Core developers feel should be theirs to make, rather than the miners. Why should that be so? What incentive to do they have to get it right? What expertise do they have in market research, investing, economics, business, etc.?
Core devs have no more expertise to set the size of blocks than they have to set the price of Bitcoin itself. They are not investors, only advisors.
Clearly this is a job for the miners, who are a unique type of investor specialized in staying attuned to what everyone else in the ecosystem wants, or soon will be when they realize their ability to do this is the deciding factor in their profitability. (If they fail, yes, as I often say it goes to the general hodlers/investors to "fire" them by a PoW-changing fork, or to deliberately create a permanent split.)
Under controversy, then, is exactly when being a miner becomes interesting. There is money to be made by being a better steward of the network, knowing what kind of blocks to build and when, knowing when to orphan other miners' blocks, always researching the market, polling the ecosystem, looking at fork prediction markets, being conservative enough to avoid stepping on people's toes but not so conservative that fee money is left on the table (and that altcoins take over due to overconservatism).
The current crop of miners/pools may not be up to the task, and there will be a winnowing as the BS Dam breaks.
Last edited:
Everyone: For those that didn't notice yet there's this discussion ongoing about the 'sticky gate flag'.
See BUIP038, BUIP040, BUIP041.
I am wondering whether I should propose formally as a BUIP what I just outlined here, namely the goal of keeping Unlimited configurable and staying out of the way regarding the user's decision on blocksize. I think it also presents the opportunity to shift the blocksize debate away from those dealing with the C++ code towards anyone who wants to throw an easy 10-line script onto github or similar.
Thoughts?
See BUIP038, BUIP040, BUIP041.
I am wondering whether I should propose formally as a BUIP what I just outlined here, namely the goal of keeping Unlimited configurable and staying out of the way regarding the user's decision on blocksize. I think it also presents the opportunity to shift the blocksize debate away from those dealing with the C++ code towards anyone who wants to throw an easy 10-line script onto github or similar.
Thoughts?
- Dec 16, 2015
- 2,806
- 6,088
@awemany : in BUIP038 I mused that a completely independent BUIP to improve alerting on EB "violations" might be useful, i.e. better notification that the user should take a decision.
I like the idea of an interface as you suggest, to allow the user to automate their parameter adjustment as they please. The ZMQ interface allows subscription which seems suitable for these kinds of event notifications.
I like the idea of an interface as you suggest, to allow the user to automate their parameter adjustment as they please. The ZMQ interface allows subscription which seems suitable for these kinds of event notifications.
- Aug 29, 2015
- 536
- 2,597
Seems to me this implies balancing two properties: 1) ease of entering transactions into the block chain, and 2) ease of verifying the transactions and protecting against fraud.
These technical capabilities both represent important monetary properties. If there is a tradeoff between them, then a decision on where to the balance somehow needs to be settled on. To make Bitcoin the best form of money possible, these properties should be balanced such that the total value of the system is maximized. In other words, such that the long term market value on bitcoin is greatest. Sounds like the perfect job for investor/speculator miners!
Last edited:
lunar
Well-Known Member
- Aug 28, 2015
- 1,001
- 4,290
This would be an interesting thread to pull on. Imagine a landmark case where bitcoin was declared a public good, and BSCore were found guilty conspiring to form a cartel. It's pretty simple economics to show Blockthestream has a conflict of interest here, so with s signed letter from their CEO (sorry individual) ....
Any lawyers here ?
https://www.reddit.com/r/btc/comments/5hkn8w/rico_racketeer_influenced_and_corrupt/
Any lawyers here ?
https://www.reddit.com/r/btc/comments/5hkn8w/rico_racketeer_influenced_and_corrupt/
@Mengerian
Yes, it's actually kind of bizarre that developers should be looked to to set these parameters at all. What do software developers have to do with anything, other than just giving miners and nodes (and investors, but that's another topic: fork-robust wallet software) the necessary tools to set these parameters conveniently? Even if they do have special input to contribute, they can give it verbally. Hardcoding their "advice" just distorts everything. BU clears away the fog on the matter.
As far as BU, there is mainly one question still remaining in my mind. In a BU world, will blocksize be set by out-of-band coordination, miner consortiums, business groups making recommendations, etc. for everyone to have the same settings for a period of time (convergence on a Schelling point)? Or will it actually be a more dynamic situation where people make a use of the BU tools quite actively and the chain tip becomes a little less certain, perhaps messing with first/second confirmation reliability? (Not BU's fault, but an inevitable result of controversy and changing conditions.)
In the first case, which seems more likely, many of BU's tools may go largely unused except maybe in emergencies or during planned fork events. That is fine, I think. They are there if needed.
Regarding the (at this blocksize very silly) "fee market" idea, whenever we do reach the true practical max blocksize, I think miners will agree to set a soft cap perhaps halfway below that size and only raise it temporarily to clear backlog that results from demand spikes and the random streak of slow blocks. That way there is very mild fee pressure but without the logjams we are experiencing now due to this:
Yes, it's actually kind of bizarre that developers should be looked to to set these parameters at all. What do software developers have to do with anything, other than just giving miners and nodes (and investors, but that's another topic: fork-robust wallet software) the necessary tools to set these parameters conveniently? Even if they do have special input to contribute, they can give it verbally. Hardcoding their "advice" just distorts everything. BU clears away the fog on the matter.
As far as BU, there is mainly one question still remaining in my mind. In a BU world, will blocksize be set by out-of-band coordination, miner consortiums, business groups making recommendations, etc. for everyone to have the same settings for a period of time (convergence on a Schelling point)? Or will it actually be a more dynamic situation where people make a use of the BU tools quite actively and the chain tip becomes a little less certain, perhaps messing with first/second confirmation reliability? (Not BU's fault, but an inevitable result of controversy and changing conditions.)
In the first case, which seems more likely, many of BU's tools may go largely unused except maybe in emergencies or during planned fork events. That is fine, I think. They are there if needed.
Regarding the (at this blocksize very silly) "fee market" idea, whenever we do reach the true practical max blocksize, I think miners will agree to set a soft cap perhaps halfway below that size and only raise it temporarily to clear backlog that results from demand spikes and the random streak of slow blocks. That way there is very mild fee pressure but without the logjams we are experiencing now due to this:
Last edited:
Roger_Murdock
Active Member
- Dec 17, 2015
- 223
- 1,453
"First they came for the node operators with 1990s-grade Internet -- and I did not speak out. Because I am not Luke-Jr..."
But seriously, nice write-up @Zangelbert Bingledack. The small-blockers' ignorance of (or willful disregard for) the basic incentive system underlying Bitcoin's security is kind of amazing.
Christoph Bergmann
Active Member
Me too. For sure Jonny should not be a membership.
Roger_Murdock
Active Member
- Dec 17, 2015
- 223
- 1,453
Call me crazy, but I'm not strongly opposed to Jonny's membership bid -- provided, obviously, that it achieves "strong consensus." If he can attract the support of 95% of the existing membership (and to be clear, I'm not referring here simply to 95% of the votes cast), I, for one, am prepared to say "welcome aboard."
adamstgbit
Well-Known Member
- Mar 13, 2016
- 1,206
- 2,650
i think everyone greatly overestimates the minners willingness to makes blocks bigger..
first piece of evidence that miners care less about minning fees then they do about keeping a sound network would be the Extreme caution they exercised when slowly lifting soft limits, they didnt go from 250KB to 1MB blocks over night, there was some TX backlog still minner respected their soft limits.
second piece of evidence, we are STILL at 1MB, if miners didnt care and would do whatever it takes to incress revenue by making there blocks bigger and just centralizing to eliminate orphen risk( nullc often says its a FACT that they will do this -_-) THEY WOULD HAVE DONE SO ALREADY, they had plenty of opportunity, bitcoinXT, bitcoinclassic, a open letter saying "we want bigger blocks" signed by many many top nodes....
the reality APPEARS to be that miners care more about the blockchains longevity and act more cautiously than anyone else! the idea that they would simply double block size over and over up to the point where nodes are being forced off, is simply not the reality.
The truth is that the fees they get from increasing their block size is not much of an incentive... (pulling data out of my ass here -_-) 80% of fees come from 20% of TX in most blocks, if you look at any one block you'll find that TX fee/ byte varies a lot! gorwing your block in order to fit a bunch more lowest fee/byte TX isn't much of an incentive...
miners will strive to make blocks fit just right, so that there is always fee pressure.
honest minners will simply not incress blocksize unless a very high % of the network is signaling there willingness to accept such a size. its not about profit its about survival... they will not take ANY action they believe would possibly harm the network, they've proven this before, and they are doing so again by refusing segwit, and they will refuse BU if its not perfect, period the end.
[doublepost=1481520001,1481519259][/doublepost]
your crazy!
[doublepost=1481520657][/doublepost]
this specific attack vector is kinda hard to fallow. i think i get the generally idea, but oboivly could benifit from a deep understanding of the code to come up with any kind of solution.
but thats not going to stop me from trying.
just Fing eliminate AD, have it set to 999999 for everyone by default and let that be the end of it. AD is kinda overkill, neat concept but might prove kinda useless and almost makes your EB setting less important. it was a nice idea worth exploring, but hardly a requirement for the end goal of market driven blocksize IMO.
- Aug 22, 2015
- 1,558
- 4,693
Well said. If he can attract a vote of 95% of the membership then we should make him an official gold-pated wall-plaque recognising his achievement of Extreme Consensus.
[doublepost=1481522253][/doublepost]@adamstgbit
I'm liking your post for your insight into the conservatism of miners.
Just regarding the AD. We do need this to ensure that the network recoverges quickly and that all forks (over block size limit and sigops limit disagreement) are temporary.
Roger_Murdock
Active Member
- Dec 17, 2015
- 223
- 1,453
I don't see AD as an essential feature (see related thoughts here), but I do think it's important one -- especially for non-mining nodes who don't necessarily want to monitor the network as closely as miners. And I also think the AD feature is one that at least some miners will find useful (and if they don't, they can always effectively disable it by setting their AD to an extremely large value). As I see it, the AD is basically an emergency fail-safe. Setting a particular EB reflects your prediction that the network as a whole will reject blocks any larger than that. Your AD setting is your acknowledgement that you could be wrong, i.e.,: "If a block larger than my current EB setting is mined, and at least AD blocks are mined on top of it, and that chain is currently the longest, and I haven't already manually intervened by either increasing my EB (indicating, 'yes, follow that chain') or increasing my AD (indicating, 'no, I'm still not quite ready to switch') ... then I'm probably asleep, passed out, or in a coma -- but it sounds like a situation where the network has moved on without me, which will get really expensive for me very quickly if I'm indisposed for too long so... go ahead and switch to the longer chain."
The "problem" here is that the "A.I." / "autopilot" logic is never going to be perfect. You're not going to come up with an algorithm that's going to make exactly the same decisions for all scenarios that you'd make if you were actually paying attention and had time to process all available information. But so what? It doesn't have to be perfect.
And I still don't really get this attack scenario we're worried about. So a majority of the hash power (let's say 80%) is using a particular EB setting with a relatively low AD setting. And the 20% hash power minority decides to "attack" the network by spending a lot of money attempting to build chains with really large blocks until they finally get lucky enough to outpace the mining majority for AD + 1 blocks, thereby forcing the mining majority into accepting a few super-sized blocks... and then what? Presumably the mining majority still thinks those blocks are generally too large, realizes pretty quickly that it was a minority of the hash power that forced them through, and then coordinates the reinstatement of the EB limit (but maybe this time using a higher AD setting).
As far as my thoughts on the specific options we should provide, I do think that "reverting the sticky gate" completely is probably unacceptable as there are too many scenarios where a miner would be continually lagging the chain tip (which would completely defeat the purpose of the AD feature). I do think the existing logic is fine, but I'd still be curious to know what actual miners think. And if they want something more "conservative" (i.e., the "gate" is only opened partially and incrementally rather than being "thrown immediately wide open") then let's at least give them that option. Having said all that, I'm also very sympathetic to the concern expressed here by @Zangelbert Bingledack:
adamstgbit
Well-Known Member
- Mar 13, 2016
- 1,206
- 2,650
idk if thats good or not, my feeling is that being able to say beyond a shadow of a doubt that X sized block will NOT be acceptable and therefore safe to orphen and forget it, is better.
when you ask a minner how many blocks are you willing to lose over blocksize disagreements the answer will always be "exactly 0"
i think we'll find that all honest miners dont ever create blocks that cause some >5% of the network to fork off, and when they do incress block size in a way which kicks off a few nodes it will not be a temporary or a all of a sudden type thing.
so i think AD is pretty useless in practice, and it only makes it more likely that a blocksize incress is performed with a smaller backing.
IMO blocksize should be market driven, but also should be hard to incress, like 95% of nodes should be ready and willing for XMB's. with AD it's more conceivable that 40% of hashing power is able to put extreme pressure on everyone else to accept there larger blocks. AD almost guarantees >51% hashing power's ability to manage blocksize... " its not a problem the others will be forced to accept our blocks"
removing AD altogether will make BU more active to miners... because at that point there will be no question about "temporary forks". a quick look at everyone EB setting will determine a block size which >51% will for sure automatically reject. with AD you can never truly be sure what block size will be rejected.
Last edited:
