* [bitcoin-dev] Block solving slowdown question/poll @ 2020-03-21 18:40 Dave Scotese 2020-03-22 7:54 ` David A. Harding 0 siblings, 1 reply; 15+ messages in thread From: Dave Scotese @ 2020-03-21 18:40 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 441 bytes --] It seems that many on this list think deeply enough to imagine the scenario where we have few days left before a difficulty adjustment comes up but we also see mining power dropping off at a rate that suggests the few days might become a few weeks, and then, possibly, a few months or even the unthinkable, a few eons. I'm curious to know if anyone has ideas on how this might be handled because I'm sure we're not going to let it happen. [-- Attachment #2: Type: text/html, Size: 477 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-21 18:40 [bitcoin-dev] Block solving slowdown question/poll Dave Scotese @ 2020-03-22 7:54 ` David A. Harding 2020-03-22 11:58 ` LORD HIS EXCELLENCY JAMES HRMH 0 siblings, 1 reply; 15+ messages in thread From: David A. Harding @ 2020-03-22 7:54 UTC (permalink / raw) To: Dave Scotese, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1169 bytes --] On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote: > [Imagine] we also see mining power dropping off at a rate that > suggests the few days [until retarget] might become a few weeks, and > then, possibly, a few months or even the unthinkable, a few eons. I'm > curious to know if anyone has ideas on how this might be handled There are only two practical solutions I'm aware of: 1. Do nothing 2. Hard fork a difficulty reduction If bitcoins retain even a small fraction of their value compared to the previous retarget period and if most mining equipment is still available for operation, then doing nothing is probably the best choice---as block space becomes scarcer, transaction feerates will increase and miners will be incentivized to increase their block production rate. If the bitcoin price has plummeted more than, say, 99% in two weeks with no hope of short-term recovery or if a large fraction of mining equipment has become unusable (again, say, 99% in two weeks with no hope of short-term recovery), then it's probably worth Bitcoin users discussing a hard fork to reduce difficulty to a currently sustainable level. -Dave [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-22 7:54 ` David A. Harding @ 2020-03-22 11:58 ` LORD HIS EXCELLENCY JAMES HRMH 2020-03-22 16:54 ` Eric Voskuil 0 siblings, 1 reply; 15+ messages in thread From: LORD HIS EXCELLENCY JAMES HRMH @ 2020-03-22 11:58 UTC (permalink / raw) To: Dave Scotese, Bitcoin Protocol Discussion, David A. Harding [-- Attachment #1: Type: text/plain, Size: 2105 bytes --] There seems to be the real possibility that miners are simply trying to optimise mining profit by limiting the average hash rate during the retargeting, saving some electricity but poorly considering the overall situation where they give opportunity to other miners probably raising the hashrate for the next period. It is far more profitable for the ecosystem considering the whole to hold a lottery for minig as has been discussed elsewhere some time ago. Regards, LORD HIS EXCELLENCY JAMES HRMH ________________________________ From: bitcoin-dev <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of David A. Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> Sent: Sunday, 22 March 2020 6:54 PM To: Dave Scotese <dscotese@litmocracy•com>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org> Subject: Re: [bitcoin-dev] Block solving slowdown question/poll On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote: > [Imagine] we also see mining power dropping off at a rate that > suggests the few days [until retarget] might become a few weeks, and > then, possibly, a few months or even the unthinkable, a few eons. I'm > curious to know if anyone has ideas on how this might be handled There are only two practical solutions I'm aware of: 1. Do nothing 2. Hard fork a difficulty reduction If bitcoins retain even a small fraction of their value compared to the previous retarget period and if most mining equipment is still available for operation, then doing nothing is probably the best choice---as block space becomes scarcer, transaction feerates will increase and miners will be incentivized to increase their block production rate. If the bitcoin price has plummeted more than, say, 99% in two weeks with no hope of short-term recovery or if a large fraction of mining equipment has become unusable (again, say, 99% in two weeks with no hope of short-term recovery), then it's probably worth Bitcoin users discussing a hard fork to reduce difficulty to a currently sustainable level. -Dave [-- Attachment #2: Type: text/html, Size: 3507 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-22 11:58 ` LORD HIS EXCELLENCY JAMES HRMH @ 2020-03-22 16:54 ` Eric Voskuil 2020-03-22 18:17 ` Dave Scotese 0 siblings, 1 reply; 15+ messages in thread From: Eric Voskuil @ 2020-03-22 16:54 UTC (permalink / raw) To: LORD HIS EXCELLENCY JAMES HRMH, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2494 bytes --] Mining is a lottery. e > On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > There seems to be the real possibility that miners are simply trying to optimise mining profit by limiting the average hash rate during the retargeting, saving some electricity but poorly considering the overall situation where they give opportunity to other miners probably raising the hashrate for the next period. It is far more profitable for the ecosystem considering the whole to hold a lottery for minig as has been discussed elsewhere some time ago. > > Regards, > LORD HIS EXCELLENCY JAMES HRMH > > > From: bitcoin-dev <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of David A. Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> > Sent: Sunday, 22 March 2020 6:54 PM > To: Dave Scotese <dscotese@litmocracy•com>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org> > Subject: Re: [bitcoin-dev] Block solving slowdown question/poll > > On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote: > > [Imagine] we also see mining power dropping off at a rate that > > suggests the few days [until retarget] might become a few weeks, and > > then, possibly, a few months or even the unthinkable, a few eons. I'm > > curious to know if anyone has ideas on how this might be handled > > There are only two practical solutions I'm aware of: > > 1. Do nothing > 2. Hard fork a difficulty reduction > > If bitcoins retain even a small fraction of their value compared to the > previous retarget period and if most mining equipment is still available > for operation, then doing nothing is probably the best choice---as block > space becomes scarcer, transaction feerates will increase and miners > will be incentivized to increase their block production rate. > > If the bitcoin price has plummeted more than, say, 99% in two weeks > with no hope of short-term recovery or if a large fraction of mining > equipment has become unusable (again, say, 99% in two weeks with no > hope of short-term recovery), then it's probably worth Bitcoin users > discussing a hard fork to reduce difficulty to a currently sustainable > level. > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 4070 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-22 16:54 ` Eric Voskuil @ 2020-03-22 18:17 ` Dave Scotese 2020-03-23 12:59 ` Andrew Cann 0 siblings, 1 reply; 15+ messages in thread From: Dave Scotese @ 2020-03-22 18:17 UTC (permalink / raw) To: Eric Voskuil, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4985 bytes --] The software currently allows up to a two hour difference between the system clock and the time implied by a fresh block's timestamp (if I remember correctly). This reliance on realtime system clocks can be used in a much weaker form to justify a plan for a difficulty adjustment to be built into the software for when the expected block production rate is far enough behind its expected value. We would have to agree on how far behind mining should be to justify expediting the adjustment. The sooner we decide on and implement this second difficulty adjustment trigger, the better. It cuts off a nightmare scenario made possible by collusion between states through regulation and fiat, as well as any other external factors. I propose that miners detecting that the expected 2016 blocks have not been mined after twice the expected wait time (4032 * 10 minutes = 28 days) ought to signal their recognition in any block they produce, to be rejected by any miner whose clock disagrees (after taking into account the 2-hour leeway), and that any block produced on top of one with such a signal should reflect an expedited difficulty adjustment (and also include the signal), which is then in effect for the rest of the 2016 blocks and the entire following difficulty period. Every block from there until the modulo 2016 block should have the same signal, which not only indicates that a difficulty adjustment was expedited, but also that the next modulo 2016 block should not make one, but rather turn off the signal. If anyone thinks it's a good enough idea for a BIP, I will consider writing one unless someone else wants to. Dave. On Sun, Mar 22, 2020 at 9:54 AM Eric Voskuil via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Mining is a lottery. > > e > > On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > There seems to be the real possibility that miners are simply trying to > optimise mining profit by limiting the average hash rate during the > retargeting, saving some electricity but poorly considering the overall > situation where they give opportunity to other miners probably raising the > hashrate for the next period. It is far more profitable for the ecosystem > considering the whole to hold a lottery for minig as has been discussed > elsewhere some time ago. > > Regards, > LORD HIS EXCELLENCY JAMES HRMH > > > ------------------------------ > *From:* bitcoin-dev <bitcoin-dev-bounces@lists•linuxfoundation.org> on > behalf of David A. Harding via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> > *Sent:* Sunday, 22 March 2020 6:54 PM > *To:* Dave Scotese <dscotese@litmocracy•com>; Bitcoin Protocol Discussion > <bitcoin-dev@lists•linuxfoundation.org> > *Subject:* Re: [bitcoin-dev] Block solving slowdown question/poll > > On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev > wrote: > > [Imagine] we also see mining power dropping off at a rate that > > suggests the few days [until retarget] might become a few weeks, and > > then, possibly, a few months or even the unthinkable, a few eons. I'm > > curious to know if anyone has ideas on how this might be handled > > There are only two practical solutions I'm aware of: > > 1. Do nothing > 2. Hard fork a difficulty reduction > > If bitcoins retain even a small fraction of their value compared to the > previous retarget period and if most mining equipment is still available > for operation, then doing nothing is probably the best choice---as block > space becomes scarcer, transaction feerates will increase and miners > will be incentivized to increase their block production rate. > > If the bitcoin price has plummeted more than, say, 99% in two weeks > with no hope of short-term recovery or if a large fraction of mining > equipment has become unusable (again, say, 99% in two weeks with no > hope of short-term recovery), then it's probably worth Bitcoin users > discussing a hard fork to reduce difficulty to a currently sustainable > level. > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy <http://www.litmocracy.com> and Meme Racing <http://www.memeracing.net> (in alpha). I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which now accepts Bitcoin. I also code for The Dollar Vigilante <http://dollarvigilante.com/>. "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto [-- Attachment #2: Type: text/html, Size: 7644 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-22 18:17 ` Dave Scotese @ 2020-03-23 12:59 ` Andrew Cann 2020-03-23 18:39 ` Dave Scotese 0 siblings, 1 reply; 15+ messages in thread From: Andrew Cann @ 2020-03-23 12:59 UTC (permalink / raw) To: Dave Scotese, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1621 bytes --] Hi, noob question here: Is there a long-term plan for if the block reward drops too low to ensure the security of the network? IIUC miners only make profit from block rewards and transaction fees, and once the block reward drop to zero we're merely hoping that transaction fees will keep mining expensive enough to stop a state actor or someone from buying enough hash power to attack the network. If that's the case, should we start making plans now to change the protocol to allow an adjustable block reward? Here's a half-baked idea I had of how that could work: Since the block reward dilutes the value of the currency bitcoin holders have an incentive to keep the reward low. However, since the block reward is also (partly) what incentivizes mining, bitcoin holders also have an incentive to keep the reward high enough to keep the network secure. So if bitcoin holders were able to vote to decide the block reward they "should", hypothetically, reliably choose a value that balances these two concerns. You could implement this voting by adding an optional extra field to every txout that signals what the holder thinks the inflation rate should be. If the field is missing you just assume the default value based on the current protocol. Then, whenever a new block is mined, you take the median inflation rate of all the pre-existing utxos, weighted by the utxo value, to calculate the block's reward. Is this idea fundamentally broken somehow? Or are there already better ideas for how to tackle this problem (I don't follow this list very closely)? Or is this actually a non-issue to start with? - Andrew [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-23 12:59 ` Andrew Cann @ 2020-03-23 18:39 ` Dave Scotese 2020-03-24 7:42 ` ZmnSCPxj 0 siblings, 1 reply; 15+ messages in thread From: Dave Scotese @ 2020-03-23 18:39 UTC (permalink / raw) To: Andrew Cann; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3012 bytes --] I believe this isn't something we need to address. The fact is that every byte stored in the blockchain is already valuable to everyone who downloads the blockchain because of what it allows them to prove - by adding more bytes to it. Over time, the value per byte will increase. Perhaps there will be holding companies with specialized scripts that cost $500 - $1000 to add to the blockchain and allow those companies to handle transactions for thousands of customers, kind of like a community lightning channel. Anyway, yes, your idea is fundamentally broken because a zero block reward happens because creating even one more satoshi will push the amount of bitcoin over 21,000,0000, breaking the meaning of "bitcoin," or, if you like, creating a fundamental contradiction in our use of the term. On Mon, Mar 23, 2020 at 5:59 AM Andrew Cann <shum@canndrew•org> wrote: > Hi, noob question here: Is there a long-term plan for if the block reward > drops > too low to ensure the security of the network? > > IIUC miners only make profit from block rewards and transaction fees, and > once > the block reward drop to zero we're merely hoping that transaction fees > will > keep mining expensive enough to stop a state actor or someone from buying > enough hash power to attack the network. If that's the case, should we > start > making plans now to change the protocol to allow an adjustable block > reward? > > Here's a half-baked idea I had of how that could work: Since the block > reward > dilutes the value of the currency bitcoin holders have an incentive to > keep the > reward low. However, since the block reward is also (partly) what > incentivizes > mining, bitcoin holders also have an incentive to keep the reward high > enough > to keep the network secure. So if bitcoin holders were able to vote to > decide > the block reward they "should", hypothetically, reliably choose a value > that > balances these two concerns. You could implement this voting by adding an > optional extra field to every txout that signals what the holder thinks the > inflation rate should be. If the field is missing you just assume the > default > value based on the current protocol. Then, whenever a new block is mined, > you > take the median inflation rate of all the pre-existing utxos, weighted by > the > utxo value, to calculate the block's reward. > > Is this idea fundamentally broken somehow? Or are there already better > ideas > for how to tackle this problem (I don't follow this list very closely)? Or > is > this actually a non-issue to start with? > > - Andrew > > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy <http://www.litmocracy.com> and Meme Racing <http://www.memeracing.net> (in alpha). I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which now accepts Bitcoin. I also code for The Dollar Vigilante <http://dollarvigilante.com/>. "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto [-- Attachment #2: Type: text/html, Size: 3656 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-23 18:39 ` Dave Scotese @ 2020-03-24 7:42 ` ZmnSCPxj 2020-03-25 15:23 ` Andrew Cann 0 siblings, 1 reply; 15+ messages in thread From: ZmnSCPxj @ 2020-03-24 7:42 UTC (permalink / raw) To: Dave Scotese, Bitcoin Protocol Discussion Good morning Andrew, > > Hi, noob question here: Is there a long-term plan for if the block reward drops > > too low to ensure the security of the network? > > > > IIUC miners only make profit from block rewards and transaction fees, and once > > the block reward drop to zero we're merely hoping that transaction fees will > > keep mining expensive enough to stop a state actor or someone from buying > > enough hash power to attack the network. If that's the case, should we start > > making plans now to change the protocol to allow an adjustable block reward? > > > > Here's a half-baked idea I had of how that could work: Since the block reward > > dilutes the value of the currency bitcoin holders have an incentive to keep the > > reward low. However, since the block reward is also (partly) what incentivizes > > mining, bitcoin holders also have an incentive to keep the reward high enough > > to keep the network secure. So if bitcoin holders were able to vote to decide > > the block reward they "should", hypothetically, reliably choose a value that > > balances these two concerns. They already do so, via an implicit "field", known as the transaction fee. This is "implicit" since it is only the difference of the sum of all inputs with the sum of all outputs, but any Bitcoin HODLer spending their coins always need to make this decision. This makes the vote for how much security is needed to be costly to the voter, which is appropriate: you pay for your security. This mechanism is the same mechanism as well that is the long-term plan for the lowered block rewards in the future, and is already the best known idea to tackle this problem as well. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-24 7:42 ` ZmnSCPxj @ 2020-03-25 15:23 ` Andrew Cann 2020-03-26 1:42 ` ZmnSCPxj 0 siblings, 1 reply; 15+ messages in thread From: Andrew Cann @ 2020-03-25 15:23 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2179 bytes --] Hi, thanks for the replies. > Anyway, yes, your idea is fundamentally broken because a zero block reward > happens because creating even one more satoshi will push the amount of > bitcoin over 21,000,0000, breaking the meaning of "bitcoin," or, if you > like, creating a fundamental contradiction in our use of the term. I wouldn't really consider that fundamentally broken. It changes the meaning of "bitcoin", but so does every upgrade to the protocol. The worst problem I can see with this is that there's probably a lot of software out there which assumes a cap of 21M. But we'd have years to find and fix those bugs. > They already do so, via an implicit "field", known as the transaction fee. > This makes the vote for how much security is needed to be costly to the > voter, which is appropriate: you pay for your security. This isn't the same thing though, economically / game-theoretically speaking. Transaction fees are only paid when bitcoins get moved. There's no on-going cost for people holding bitcoins (assuming they're doing their day-to-day transactions almost entirely off-chain, which is something that's only going to become more common). More to the point, the transaction fee is only set by the current demand for block space. If transaction fees drop too low to maintain a secure hash rate then people *could* willingly pay more than they need to to get their transactions mined, but it's unlikely they will since it'd be cheaper to just pay the minimum and hope that everyone else covers the costs of keeping the network secure for them. With the voting idea everyone decides what everyone pays (via dilution) to keep the network secure. Choosing to signal a high inflation rate doesn't mean you pay more than everyone else, just that you might shift the median, so there's no tragedy-of-the-commons problem. Also, votes are weighted by the value of the utxo, so people both vote and pay in proportion to the amount of bitcoin they're holding. Does this make sense? Or is there some game-theoretic reason I'm not seeing for why transaction fees can never drop dangerously low in the first place? - Andrew [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-25 15:23 ` Andrew Cann @ 2020-03-26 1:42 ` ZmnSCPxj 2020-03-27 9:17 ` Andrew Cann 0 siblings, 1 reply; 15+ messages in thread From: ZmnSCPxj @ 2020-03-26 1:42 UTC (permalink / raw) To: Andrew Cann; +Cc: Bitcoin Protocol Discussion Good morning Andrew, > > > Anyway, yes, your idea is fundamentally broken because a zero block reward > > happens because creating even one more satoshi will push the amount of > > bitcoin over 21,000,0000, breaking the meaning of "bitcoin," or, if you > > like, creating a fundamental contradiction in our use of the term. > > I wouldn't really consider that fundamentally broken. It changes the meaning of > "bitcoin", but so does every upgrade to the protocol. The worst problem I can > see with this is that there's probably a lot of software out there which > assumes a cap of 21M. But we'd have years to find and fix those bugs. There are changes of meaning, and then there are changes of meaning. Smaller changes that puny humans can understand are better than larger changes beyond the ken of mortal man. To change the supply is far too big a change. > > They already do so, via an implicit "field", known as the transaction fee. > > This makes the vote for how much security is needed to be costly to the > > voter, which is appropriate: you pay for your security. > > This isn't the same thing though, economically / game-theoretically speaking. > Transaction fees are only paid when bitcoins get moved. There's no on-going > cost for people holding bitcoins (assuming they're doing their day-to-day > transactions almost entirely off-chain, which is something that's only going to > become more common). More to the point, the transaction fee is only set by the > current demand for block space. If transaction fees drop too low to maintain a > secure hash rate then people could willingly pay more than they need to to > get their transactions mined, but it's unlikely they will since it'd be cheaper > to just pay the minimum and hope that everyone else covers the costs of keeping > the network secure for them. > > With the voting idea everyone decides what everyone pays (via dilution) to keep > the network secure. Choosing to signal a high inflation rate doesn't mean you > pay more than everyone else, just that you might shift the median, so there's > no tragedy-of-the-commons problem. Also, votes are weighted by the value of > the utxo, so people both vote and pay in proportion to the amount of bitcoin > they're holding. > > Does this make sense? Or is there some game-theoretic reason I'm not seeing for > why transaction fees can never drop dangerously low in the first place? What happens if I own a few million Bitcoin and then accidentally lose my private keys in a tragic ear-cleaning accident? Then the vote of that UTXO containing a few million Bitcoins will remain forever fixed and unable to change according to whatever you believe would make us as a community decide to change the inflation rate. If you enforce that only "recently-created" UTXOs get to vote, then in order for me to affect the vote (in the happy case where I do **not** lose all my privkeys in a tragic ear-cleaning accident), I would have to make a synthetic self-paying transaction. How is it so different from me having to make up a synthetic transaction in order to pay fees and thus affect the current security of the blockchain? -- It is helpful to remember that as a UTXO gets buried deeper, its security is inevitably better, and once I have a sufficient level of security in my ownership of the coin, I will not particularly care about any improved security and will not be interested in paying for more, hence why should I support any fork which makes me pay for my security continuously when I can simply support a fork that retains the current supply and does *not* make me pay for continued security? -- If I want to *spend* my Bitcoins on something --- and nothing has value until I actually utilize it --- then I *will* pay transaction fees. The receiver of the coin would want to ensure that the received UTXO is deeply buried to the point that it has sufficient security for the receiver, before releasing or providing me with whatever I am exchanging the coin for. Thus, if I find that there are no miners at all, I could offer a high fee to get my transaction mined. Of course, you might say that this only pays for one block. But in most cases I will have more value remaining beyond what I spend to the receiver, i.e. I have a change output from that transaction. In such a case, I can pay for more blocks by re-spending the change output to myself, paying a transaction fee each time, until the original transaction that spends to the receiver is deeply buried and the receiver credits it and then releases the product or service I am exchanging *for*. Alternately the receiver can do the same for its *own* UTXO, and will increase the payment it demands from me in order to perform this itself; thus I still end up paying for the security of the *transaction* and not the security of the *holding*. So there is really no need for any mechanism beyond transaction fees. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-26 1:42 ` ZmnSCPxj @ 2020-03-27 9:17 ` Andrew Cann 2020-03-28 2:12 ` ZmnSCPxj 0 siblings, 1 reply; 15+ messages in thread From: Andrew Cann @ 2020-03-27 9:17 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6569 bytes --] > To change the supply is far too big a change. It would also be a big change if bitcoin became unusable due to mining profits dropping low enough for a state actor with a warehouse full of asics to mount a 51% attack and mine empty blocks all day. > What happens if I own a few million Bitcoin and then accidentally lose my > private keys in a tragic ear-cleaning accident? > Then the vote of that UTXO containing a few million Bitcoins will remain > forever fixed and unable to change according to whatever you believe would > make us as a community decide to change the inflation rate. All that matters is whether the long-term rate of deflation due to lost coins is less or greater than the rate of inflation. This determines whether the proportion of coins whose signaled inflation rate is fixed in time would tend towards zero or one. I think it's /fairly/ safe to assume that it would remain less. People obviously have a pretty strong incentive to not lose their coins - particularly people who are holding massive amounts of bitcoin - and as bitcoin becomes more mainstream, regular users will necessarily be using forms of protection against losing their coins (whatever they might be). Contrast this against the inflation rate which should remain high enough to prevent very wealthy entities from being able to mount a 51% attack. What proportion of the total market cap of bitcoin do you think your least favorite government could plausibly be willing to spend to take down bitcoin for a month? And do you think it's less or greater than the proportion of all bitcoins that get lost in a month? > It is helpful to remember that as a UTXO gets buried deeper, its security is > inevitably better, and once I have a sufficient level of security in my > ownership of the coin, I will not particularly care about any improved > security and will not be interested in paying for more. If we're talking about the possibility of your coin becoming worthless because someone out there can unwind transactions at will and prevent you from spending it then you should definitely be interested. > If I want to *spend* my Bitcoins on something --- and nothing has value until > I actually utilize it --- then I *will* pay transaction fees. The receiver of > the coin would want to ensure that the received UTXO is deeply buried to the > point that it has sufficient security for the receiver, before releasing or > providing me with whatever I am exchanging the coin for. > > Thus, if I find that there are no miners at all, I could offer a high fee to > get my transaction mined. Of course, you might say that this only pays for > one block. > > But in most cases I will have more value remaining beyond what I spend to the > receiver, i.e. I have a change output from that transaction. > > In such a case, I can pay for more blocks by re-spending the change output > to myself, paying a transaction fee each time, until the original transaction > that spends to the receiver is deeply buried and the receiver credits it and > then releases the product or service I am exchanging *for*. Alternately the > receiver can do the same for its *own* UTXO, and will increase the payment it > demands from me in order to perform this itself; thus I still end up paying > for the security of the *transaction* and not the security of the *holding*. In your example though it's just you or the receiver paying for blocks. In that case you're only paying for your own security and so there's no tragedy of the commons and the system works. But once you have a thousand people putting transactions in every block and everyone is collectively paying for everyone's collective security then, without some mechanism to force everyone to pay their fair share, you're inviting Moloch to the party. Here's a better explanation than I could write of the phenomenon I'm talking about: > As a thought experiment, let’s consider aquaculture (fish farming) in a lake. > Imagine a lake with a thousand identical fish farms owned by a thousand > competing companies. Each fish farm earns a profit of $1000/month. For a > while, all is well. > > But each fish farm produces waste, which fouls the water in the lake. Let’s > say each fish farm produces enough pollution to lower productivity in the > lake by $1/month. > > A thousand fish farms produce enough waste to lower productivity by > $1000/month, meaning none of the fish farms are making any money. Capitalism > to the rescue: someone invents a complex filtering system that removes waste > products. It costs $300/month to operate. All fish farms voluntarily install > it, the pollution ends, and the fish farms are now making a profit of > $700/month – still a respectable sum. > > But one farmer (let’s call him Steve) gets tired of spending the money to > operate his filter. Now one fish farm worth of waste is polluting the lake, > lowering productivity by $1. Steve earns $999 profit, and everyone else earns > $699 profit. > > Everyone else sees Steve is much more profitable than they are, because he’s > not spending the maintenance costs on his filter. They disconnect their > filters too. > > Once four hundred people disconnect their filters, Steve is earning > $600/month – less than he would be if he and everyone else had kept their > filters on! And the poor virtuous filter users are only making $300. Steve > goes around to everyone, saying “Wait! We all need to make a voluntary pact > to use filters! Otherwise, everyone’s productivity goes down.” > > Everyone agrees with him, and they all sign the Filter Pact, except one > person who is sort of a jerk. Let’s call him Mike. Now everyone is back using > filters again, except Mike. Mike earns $999/month, and everyone else earns > $699/month. Slowly, people start thinking they too should be getting big > bucks like Mike, and disconnect their filter for $300 extra profit… > > A self-interested person never has any incentive to use a filter. A > self-interested person has some incentive to sign a pact to make everyone use > a filter, but in many cases has a stronger incentive to wait for everyone > else to sign such a pact but opt out himself. This can lead to an undesirable > equilibrium in which no one will sign such a pact. Won't a thousand bitcoin-spenders, individually paying for their transactions but collectively paying for their security, end up falling into the same dynamic? - Andrew [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown question/poll 2020-03-27 9:17 ` Andrew Cann @ 2020-03-28 2:12 ` ZmnSCPxj 2020-03-29 8:11 ` [bitcoin-dev] Block solving slowdown Andrew Cann 0 siblings, 1 reply; 15+ messages in thread From: ZmnSCPxj @ 2020-03-28 2:12 UTC (permalink / raw) To: Andrew Cann; +Cc: Bitcoin Protocol Discussion Good morning Andrew, > Here's a better explanation than I could write of the phenomenon I'm talking > about: > > > As a thought experiment, let’s consider aquaculture (fish farming) in a lake. > > Imagine a lake with a thousand identical fish farms owned by a thousand > > competing companies. Each fish farm earns a profit of $1000/month. For a > > while, all is well. > > But each fish farm produces waste, which fouls the water in the lake. Let’s > > say each fish farm produces enough pollution to lower productivity in the > > lake by $1/month. > > A thousand fish farms produce enough waste to lower productivity by > > $1000/month, meaning none of the fish farms are making any money. Capitalism > > to the rescue: someone invents a complex filtering system that removes waste > > products. It costs $300/month to operate. All fish farms voluntarily install > > it, the pollution ends, and the fish farms are now making a profit of > > $700/month – still a respectable sum. > > But one farmer (let’s call him Steve) gets tired of spending the money to > > operate his filter. Now one fish farm worth of waste is polluting the lake, > > lowering productivity by $1. Steve earns $999 profit, and everyone else earns > > $699 profit. > > Everyone else sees Steve is much more profitable than they are, because he’s > > not spending the maintenance costs on his filter. They disconnect their > > filters too. > > Once four hundred people disconnect their filters, Steve is earning > > $600/month – less than he would be if he and everyone else had kept their > > filters on! And the poor virtuous filter users are only making $300. Steve > > goes around to everyone, saying “Wait! We all need to make a voluntary pact > > to use filters! Otherwise, everyone’s productivity goes down.” > > Everyone agrees with him, and they all sign the Filter Pact, except one > > person who is sort of a jerk. Let’s call him Mike. Now everyone is back using > > filters again, except Mike. Mike earns $999/month, and everyone else earns > > $699/month. Slowly, people start thinking they too should be getting big > > bucks like Mike, and disconnect their filter for $300 extra profit… > > A self-interested person never has any incentive to use a filter. A > > self-interested person has some incentive to sign a pact to make everyone use > > a filter, but in many cases has a stronger incentive to wait for everyone > > else to sign such a pact but opt out himself. This can lead to an undesirable > > equilibrium in which no one will sign such a pact. > > Won't a thousand bitcoin-spenders, individually paying for their transactions > but collectively paying for their security, end up falling into the same > dynamic? Fortunately in our case, only the top 4,000,000 weight worth of transactions gets in a block. Every bitcoin spender has an incentive to spend as little as possible to get into this top 4,000,000 weight and no more, but they still have to outbid every other user who wants the same security. Some bitcoin spender will then decide that overpaying slightly to ensure that they do not drop out of the top 4,000,000 weight even in case of a "slow" block. Thus, there will always be a need for *some* block weight limit, and that is what ensures that miners can get paid. Now it was brought up earlier that people are moving transactions offchain, but that is perfectly fine, because every offchain mechanism first needs an onchain setup, and will at some point need an onchain teardown. This allows increasing the effective capacity, while still ensuring that onchain fees remain at a level that will still ensure continued healthy operation of the blockchain layer. Basically, the offchain mechanism does not remove onchain fees, it only amortizes the onchain fees to multiple logical transactions. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown 2020-03-28 2:12 ` ZmnSCPxj @ 2020-03-29 8:11 ` Andrew Cann 2020-03-30 2:59 ` ZmnSCPxj 0 siblings, 1 reply; 15+ messages in thread From: Andrew Cann @ 2020-03-29 8:11 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2335 bytes --] > Fortunately in our case, only the top 4,000,000 weight worth of transactions > gets in a block. Every bitcoin spender has an incentive to spend as little > as possible to get into this top 4,000,000 weight and no more, but they still > have to outbid every other user who wants the same security. Some bitcoin > spender will then decide that overpaying slightly to ensure that they do not > drop out of the top 4,000,000 weight even in case of a "slow" block. > > Thus, there will always be a need for *some* block weight limit, and that is > what ensures that miners can get paid. Yes, but how does this ensure that miners get paid *enough*? Every individual making a transaction needs the miners to get paid enough for the transaction to be meaningful, but they each individually only have the incentive to pay the market rate for block space which is set purely by supply and demand. It's the same as the fish farming analogy. Everyone making a transaction could collectively decide how much miners need to get paid and agree to split the costs. But then each individual has the incentive to renege on the agreement and only pay the minimum they need to get their transaction included in the block while everyone else pays for the transaction's security. My voting idea is one potential way they could break the Nash equilibrium. > Now it was brought up earlier that people are moving transactions offchain, > but that is perfectly fine, because every offchain mechanism first needs an > onchain setup, and will at some point need an onchain teardown. This > allows increasing the effective capacity, while still ensuring that onchain > fees remain at a level that will still ensure continued healthy operation of > the blockchain layer. Basically, the offchain mechanism does not remove > onchain fees, it only amortizes the onchain fees to multiple logical > transactions. I concede that every bitcoin user pays transaction fees, if not directly then indirectly, so whether miners get paid through transaction fees or a block reward is irrelevant. My concern is that moving things off-chain reduces the transaction fees by reducing demand for block-space and that this could cause miner revenue to drop lower than what's required to keep the network secure. Is there any good reason to think this won't happen? - Andrew [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown 2020-03-29 8:11 ` [bitcoin-dev] Block solving slowdown Andrew Cann @ 2020-03-30 2:59 ` ZmnSCPxj 2020-03-31 2:06 ` ZmnSCPxj 0 siblings, 1 reply; 15+ messages in thread From: ZmnSCPxj @ 2020-03-30 2:59 UTC (permalink / raw) To: Andrew Cann, Bitcoin Protocol Discussion Good morning Andrew, > > Fortunately in our case, only the top 4,000,000 weight worth of transactions > > gets in a block. Every bitcoin spender has an incentive to spend as little > > as possible to get into this top 4,000,000 weight and no more, but they still > > have to outbid every other user who wants the same security. Some bitcoin > > spender will then decide that overpaying slightly to ensure that they do not > > drop out of the top 4,000,000 weight even in case of a "slow" block. > > Thus, there will always be a need for some block weight limit, and that is > > what ensures that miners can get paid. > > Yes, but how does this ensure that miners get paidenough? Every individual > making a transaction needs the miners to get paid enough for the transaction to > be meaningful, but they each individually only have the incentive to pay the > market rate for block space which is set purely by supply and demand. If your coins have no security, you cannot use them safely. If you assign value to something, you will want to ensure some amount of protection to that something, proportional to the value you assign the something By forcing a competition for limited block space, Bitcoin forces users to honestly assess how much security they are willing to pay for. > It's the same as the fish farming analogy. Everyone making a transaction could > collectively decide how much miners need to get paid and agree to split the > costs. But then each individual has the incentive to renege on the agreement > and only pay the minimum they need to get their transaction included in the > block while everyone else pays for the transaction's security. My voting idea > is one potential way they could break the Nash equilibrium. Suppose everybody "agrees" to a reasonable fee level. They divide up the block space among themselves and assign a fee. Then suddenly one of the participants realizes they actually have to have a transaction added, but the block space they already agreed to use is not sufficient to fit. Since their agreement is just ink on a page, this participant spins up a new Bitcoin non-full node, connects to the Bitcoin network over TOR, then broadcasts the extra transaction with a higher feerate. This evicts one of the transactions in the next block (which could also be one that this cheating participant wants, but let us say that this sudden new transaction is even more important than the others it currently has allocated for the next block). The other participants now have a risk that their transaction does not get included in the block. Each one then re-assesses their security and timeliness requirements, and can then decide to bump their fee using RBF, if that is necessary. This competition will then stabilize when each participant decides that the added fee to ensure their inclusion in the next block is too high for their security and timeliness requirements, and the risk they do not get their transaction confirmed is acceptable to them given the cost of getting their transaction confirmed. All of the above is already how Bitcoin works today. That is the only mechanism necessary, or even possible. Always remember that any voting scheme always implicitly has an extra option called "all the options suck so I will not vote". In this context, this implies that people can just sell their coins and forget the whole system, rather than deal with a mechanism which ensures that coins they own are always devalued continuously by others voting for devaluation. They can sell it for a coin where their held coins are not devalued by policy, i.e. your mechanism will never have widespread support necessary for reliably forking the chain. > > > Now it was brought up earlier that people are moving transactions offchain, > > but that is perfectly fine, because every offchain mechanism first needs an > > onchain setup, and will at some point need an onchain teardown. This > > allows increasing the effective capacity, while still ensuring that onchain > > fees remain at a level that will still ensure continued healthy operation of > > the blockchain layer. Basically, the offchain mechanism does not remove > > onchain fees, it only amortizes the onchain fees to multiple logical > > transactions. > > I concede that every bitcoin user pays transaction fees, if not directly then > indirectly, so whether miners get paid through transaction fees or a block > reward is irrelevant. My concern is that moving things off-chain reduces the > transaction fees by reducing demand for block-space and that this could cause > miner revenue to drop lower than what's required to keep the network secure. > > Is there any good reason to think this won't happen? Death. No Lightning node will last forever, and its channels will be eventually be closed. Than, any onchain funds will be in the slow expensive onchain domain, so the heirs of the dead Lightning node will want to put them back into Lightning as fast as possible. Given the number of economic nodes we expect to eventually exist (and thus possibly die) in the future, we can expect some level of such activity in the long run. It is helpful to remember as well that this is a long-run issue anyway. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Block solving slowdown 2020-03-30 2:59 ` ZmnSCPxj @ 2020-03-31 2:06 ` ZmnSCPxj 0 siblings, 0 replies; 15+ messages in thread From: ZmnSCPxj @ 2020-03-31 2:06 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion Good morning Andrew, Another thing I did not consider is how miners will actually behave under this ruleset. Miners are the direct beneficiaries of any increased inflation rate voted in. Miners are also ultimately the ones who decide which transactions get added into blocks, or put another way, which UTXOs are deleted and which UTXOs are created. Thus, miners are likely to accept attempts to delete UTXOs that vote for lower inflation rates and create UTXOs that vote for higher inflation rates, and reject attempts to delete UTXOs that vote for higher inflation rates and create UTXOs that vote for lower inflation rates. Thus, miners will end up strongly controlling the inflation rate of the coin. Even worse, since the inflation gives increased coins to miners, more and more of the value of the coin, with which you vote for, will be in the hands of miners, who can then vote directly instead of censoring votes they dislike. The entire point of Bitcoin having a fixed inflation rate schedule (that is ultimately disinflationary) is to avoid the moral hazard of having the beneficiaries of higher inflation rates also be the ones who decide what the inflation rate will be. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-03-31 2:06 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-21 18:40 [bitcoin-dev] Block solving slowdown question/poll Dave Scotese 2020-03-22 7:54 ` David A. Harding 2020-03-22 11:58 ` LORD HIS EXCELLENCY JAMES HRMH 2020-03-22 16:54 ` Eric Voskuil 2020-03-22 18:17 ` Dave Scotese 2020-03-23 12:59 ` Andrew Cann 2020-03-23 18:39 ` Dave Scotese 2020-03-24 7:42 ` ZmnSCPxj 2020-03-25 15:23 ` Andrew Cann 2020-03-26 1:42 ` ZmnSCPxj 2020-03-27 9:17 ` Andrew Cann 2020-03-28 2:12 ` ZmnSCPxj 2020-03-29 8:11 ` [bitcoin-dev] Block solving slowdown Andrew Cann 2020-03-30 2:59 ` ZmnSCPxj 2020-03-31 2:06 ` ZmnSCPxj
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox