* Re: [bitcoin-dev] Bitcoin covenants are inevitable [not found] <mailman.9.1654344003.14400.bitcoin-dev@lists.linuxfoundation.org> @ 2022-06-04 12:27 ` John Carvalho 2022-06-04 13:48 ` Keagan McClelland ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: John Carvalho @ 2022-06-04 12:27 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3759 bytes --] Core development is not a hackathon project. None of the quoted following items are features or responsibilities of the Bitcoin software, nor Core developers. Quoted: "- Developers can build interesting projects with real demand in market. - Students learn Sapio and not just solidity. - Better tooling could be available for application developers. - Maybe we see bitcoin developer hackathons in different countries. - Demand for block space might increase, it wont be just exchanges and coinjoin. - Funding of bitcoin developers and projects might improve. Wont need to convince a few people for grants." Whether you are a child or an attacker, none of us should care, but CTV, nor any change to Bitcoin software, will never be justifiable simply because you and some of your friends think it is totally cool and might make more people like you or give your friends funding. Please stop making noise about CTV, this is not a place for spamming. -- John Carvalho On Sat, Jun 4, 2022 at 1:00 PM < bitcoin-dev-request@lists•linuxfoundation.org> wrote: > > Date: Fri, 03 Jun 2022 18:39:34 +0000 > From: alicexbt <alicexbt@protonmail•com> > To: Bitcoin Protocol Discussion > <bitcoin-dev@lists•linuxfoundation.org> > Subject: [bitcoin-dev] Bitcoin covenants are inevitable > Message-ID: > > <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@ > protonmail.com> > > Content-Type: text/plain; charset=utf-8 > > Note: This email is an opinion and not an attack on bitcoin > > Covenants on bitcoin will eventually be implemented with a soft fork. CTV > is the easiest and best possible way OP_TX looks good as well. Apart from > the technical merits, covenants will improve a few other things: > > - Developers can build interesting projects with real demand in market. > - Students learn Sapio and not just solidity. > - Better tooling could be available for application developers. > - Maybe we see bitcoin developer hackathons in different countries. > - Demand for block space might increase, it wont be just exchanges and > coinjoin. > - Funding of bitcoin developers and projects might improve. Wont need to > convince a few people for grants. > > **Why covenants are not contentious?** > > Some people may write paragraphs about CTV being contentious, spread > misinformation and do all types of drama, politics etc. on social media but > there are zero technical NACKs for CTV. We have discussed other covenant > proposals in detail on mailing list and IRC meetings with an open minded > approach. > > All the developers that participated in the discussion are either okay > with CTV or OP_TX or covenants in general. > > **How and when should covenants be implemented in Bitcoin?** > > I don't think we should wait for years anticipating a proposal that > everyone will agree on or argue for years to pretend changes are hard in > Bitcoin. We should improve the review process for soft fork BIPs and share > honest opinions with agreement, disagreement on technical merits. > > I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything > else being used if that improves Bitcoin. Covenants implemented in Bitcoin > before the next cycle would provide opportunity for developers to build > interesting things during the bear market. Ossification supporters also > believe there is some window that will close soon, maybe doing changes > considering each case individually will be a better approach. CTV is not a > rushed soft fork, less people followed the research and it was not > mentioned on social media repeatedly by the respected developers like other > soft forks. > > /dev/fd0 > > > Sent with Proton Mail secure email. > > > ------------------------------ > [-- Attachment #2: Type: text/html, Size: 4891 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-04 12:27 ` [bitcoin-dev] Bitcoin covenants are inevitable John Carvalho @ 2022-06-04 13:48 ` Keagan McClelland 2022-06-04 16:12 ` alicexbt 2022-06-06 13:02 ` Erik Aronesty 2 siblings, 0 replies; 55+ messages in thread From: Keagan McClelland @ 2022-06-04 13:48 UTC (permalink / raw) To: Bitcoin Protocol Discussion, John Carvalho [-- Attachment #1: Type: text/plain, Size: 5640 bytes --] > will never be justifiable simply because you and some of your friends think it is totally cool and might make more people like you or give your friends funding. 100% But while the OP may have given less than ideal reasons for things like covenants, it does not broadly characterize the reasons for adding them to the Bitcoin protocol. The reasons to do so are: - better self custody solutions that don’t rely on the trust of named third parties - significantly more tractable solutions for things like coin pools - significantly more efficient DLCs These are not “hackathon project” reasons and are the main reasons people advocate for covenants. > None of the quoted following items are features or responsibilities of the Bitcoin software, nor Core developers. Since you seem to have the stone tablets onto which our responsibilities are etched, would you care to enumerate them? > Whether you are a child or an attacker, none of us should care, Are you incapable of actually treating people with respect or do you think that bullying people on this mailing list is the most effective way to get what you want? If it’s the latter I may suggest you go back to Twitter where that works and maybe just leave those comments out of the mailing list if you actually want to convince people of your point of view. Keagan On Sat, Jun 4, 2022 at 7:37 AM John Carvalho via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Core development is not a hackathon project. > > None of the quoted following items are features or responsibilities of the > Bitcoin software, nor Core developers. > > Quoted: > "- Developers can build interesting projects with real demand in market. > - Students learn Sapio and not just solidity. > - Better tooling could be available for application developers. > - Maybe we see bitcoin developer hackathons in different countries. > - Demand for block space might increase, it wont be just exchanges and > coinjoin. > - Funding of bitcoin developers and projects might improve. Wont need to > convince a few people for grants." > > Whether you are a child or an attacker, none of us should care, but CTV, > nor any change to Bitcoin software, will never be justifiable simply > because you and some of your friends think it is totally cool and might > make more people like you or give your friends funding. > > Please stop making noise about CTV, this is not a place for spamming. > > -- > John Carvalho > > > > On Sat, Jun 4, 2022 at 1:00 PM < > bitcoin-dev-request@lists•linuxfoundation.org> wrote: > >> >> Date: Fri, 03 Jun 2022 18:39:34 +0000 >> From: alicexbt <alicexbt@protonmail•com> >> To: Bitcoin Protocol Discussion >> <bitcoin-dev@lists•linuxfoundation.org> >> Subject: [bitcoin-dev] Bitcoin covenants are inevitable >> Message-ID: >> >> <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@ >> protonmail.com> >> >> Content-Type: text/plain; charset=utf-8 >> >> Note: This email is an opinion and not an attack on bitcoin >> >> Covenants on bitcoin will eventually be implemented with a soft fork. CTV >> is the easiest and best possible way OP_TX looks good as well. Apart from >> the technical merits, covenants will improve a few other things: >> >> - Developers can build interesting projects with real demand in market. >> - Students learn Sapio and not just solidity. >> - Better tooling could be available for application developers. >> - Maybe we see bitcoin developer hackathons in different countries. >> - Demand for block space might increase, it wont be just exchanges and >> coinjoin. >> - Funding of bitcoin developers and projects might improve. Wont need to >> convince a few people for grants. >> >> **Why covenants are not contentious?** >> >> Some people may write paragraphs about CTV being contentious, spread >> misinformation and do all types of drama, politics etc. on social media but >> there are zero technical NACKs for CTV. We have discussed other covenant >> proposals in detail on mailing list and IRC meetings with an open minded >> approach. >> >> All the developers that participated in the discussion are either okay >> with CTV or OP_TX or covenants in general. >> >> **How and when should covenants be implemented in Bitcoin?** >> >> I don't think we should wait for years anticipating a proposal that >> everyone will agree on or argue for years to pretend changes are hard in >> Bitcoin. We should improve the review process for soft fork BIPs and share >> honest opinions with agreement, disagreement on technical merits. >> >> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything >> else being used if that improves Bitcoin. Covenants implemented in Bitcoin >> before the next cycle would provide opportunity for developers to build >> interesting things during the bear market. Ossification supporters also >> believe there is some window that will close soon, maybe doing changes >> considering each case individually will be a better approach. CTV is not a >> rushed soft fork, less people followed the research and it was not >> mentioned on social media repeatedly by the respected developers like other >> soft forks. >> >> /dev/fd0 >> >> >> Sent with Proton Mail secure email. >> >> >> ------------------------------ >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 9547 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-04 12:27 ` [bitcoin-dev] Bitcoin covenants are inevitable John Carvalho 2022-06-04 13:48 ` Keagan McClelland @ 2022-06-04 16:12 ` alicexbt 2022-06-06 13:02 ` Erik Aronesty 2 siblings, 0 replies; 55+ messages in thread From: alicexbt @ 2022-06-04 16:12 UTC (permalink / raw) To: John Carvalho; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 5564 bytes --] Hi John, > Core development is not a hackathon project. > > None of the quoted following items are features or responsibilities of the Bitcoin software, nor Core developers Core development was never listed as a hackathon project. Although I did not share responsibilities, they will improve bitcoin development. Bitcoin isn't only about "core developers" and I contribute to that repository. > Whether you are a child or an attacker, none of us should care, but CTV, nor any change to Bitcoin software, will never be justifiable simply because you and some of your friends think it is totally cool and might make more people like you or give your friends funding. These are not my friends and I don't know any of them in real life: https://utxos.org/signals/ Also the developers who are competent enough to understand code and soft forks that participated in CTV meetings are not my friends. Funding is a real issue for bitcoin developers, you would know if were a developer and these opportunities won't be available for me and my friends but everyone. > Please stop making noise about CTV, this is not a place for spamming. Let me share one example of spamming and noise: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020409.html I am aware of the things that you post on twitter and your thoughts about developers, author of BIP 119 and the way you would propose changes although not interested to debate anything related to bitcoin development with you as its a waste of time: https://nitter.net/BitcoinErrorLog/status/1407312037408038919 /dev/fd0 Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Saturday, June 4th, 2022 at 5:57 PM, John Carvalho via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Core development is not a hackathon project. > > None of the quoted following items are features or responsibilities of the Bitcoin software, nor Core developers. > > Quoted: > "- Developers can build interesting projects with real demand in market. > - Students learn Sapio and not just solidity. > - Better tooling could be available for application developers. > - Maybe we see bitcoin developer hackathons in different countries. > - Demand for block space might increase, it wont be just exchanges and coinjoin. > - Funding of bitcoin developers and projects might improve. Wont need to convince a few people for grants." > > Whether you are a child or an attacker, none of us should care, but CTV, nor any change to Bitcoin software, will never be justifiable simply because you and some of your friends think it is totally cool and might make more people like you or give your friends funding. > > Please stop making noise about CTV, this is not a place for spamming. > > -- > > John Carvalho > > On Sat, Jun 4, 2022 at 1:00 PM <bitcoin-dev-request@lists•linuxfoundation.org> wrote: > >> Date: Fri, 03 Jun 2022 18:39:34 +0000 >> From: alicexbt <alicexbt@protonmail•com> >> To: Bitcoin Protocol Discussion >> <bitcoin-dev@lists•linuxfoundation.org> >> Subject: [bitcoin-dev] Bitcoin covenants are inevitable >> Message-ID: >> <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@protonmail•com> >> >> Content-Type: text/plain; charset=utf-8 >> >> Note: This email is an opinion and not an attack on bitcoin >> >> Covenants on bitcoin will eventually be implemented with a soft fork. CTV is the easiest and best possible way OP_TX looks good as well. Apart from the technical merits, covenants will improve a few other things: >> >> - Developers can build interesting projects with real demand in market. >> - Students learn Sapio and not just solidity. >> - Better tooling could be available for application developers. >> - Maybe we see bitcoin developer hackathons in different countries. >> - Demand for block space might increase, it wont be just exchanges and coinjoin. >> - Funding of bitcoin developers and projects might improve. Wont need to convince a few people for grants. >> >> **Why covenants are not contentious?** >> >> Some people may write paragraphs about CTV being contentious, spread misinformation and do all types of drama, politics etc. on social media but there are zero technical NACKs for CTV. We have discussed other covenant proposals in detail on mailing list and IRC meetings with an open minded approach. >> >> All the developers that participated in the discussion are either okay with CTV or OP_TX or covenants in general. >> >> **How and when should covenants be implemented in Bitcoin?** >> >> I don't think we should wait for years anticipating a proposal that everyone will agree on or argue for years to pretend changes are hard in Bitcoin. We should improve the review process for soft fork BIPs and share honest opinions with agreement, disagreement on technical merits. >> >> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything else being used if that improves Bitcoin. Covenants implemented in Bitcoin before the next cycle would provide opportunity for developers to build interesting things during the bear market. Ossification supporters also believe there is some window that will close soon, maybe doing changes considering each case individually will be a better approach. CTV is not a rushed soft fork, less people followed the research and it was not mentioned on social media repeatedly by the respected developers like other soft forks. >> >> /dev/fd0 >> >> Sent with Proton Mail secure email. >> >> ------------------------------ [-- Attachment #2: Type: text/html, Size: 10858 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-04 12:27 ` [bitcoin-dev] Bitcoin covenants are inevitable John Carvalho 2022-06-04 13:48 ` Keagan McClelland 2022-06-04 16:12 ` alicexbt @ 2022-06-06 13:02 ` Erik Aronesty 2022-06-12 3:36 ` Peter Todd 2 siblings, 1 reply; 55+ messages in thread From: Erik Aronesty @ 2022-06-06 13:02 UTC (permalink / raw) To: John Carvalho, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4878 bytes --] Maintaining the security of the protocol is squarely the responsibility of the Bitcoin software and the core developers Continued demand for block space is critical for Bitcoin's security. Therefore it *is* the responsibility of Bitcoin software and core developers to maintain a continued demand for block space - which underpins the game-theoretical security of the protocol. While I'm personally confident that demand is still high, enough to reasonably secure the protocol, I do think that this is a matter not best left up to stern opinions. Whether covenant tech is essential for that security or not is a matter for simulations and proofs, not hype and speculation - on either side of the issue. On Sat, Jun 4, 2022 at 8:36 AM John Carvalho via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Core development is not a hackathon project. > > None of the quoted following items are features or responsibilities of the > Bitcoin software, nor Core developers. > > Quoted: > "- Developers can build interesting projects with real demand in market. > - Students learn Sapio and not just solidity. > - Better tooling could be available for application developers. > - Maybe we see bitcoin developer hackathons in different countries. > - Demand for block space might increase, it wont be just exchanges and > coinjoin. > - Funding of bitcoin developers and projects might improve. Wont need to > convince a few people for grants." > > Whether you are a child or an attacker, none of us should care, but CTV, > nor any change to Bitcoin software, will never be justifiable simply > because you and some of your friends think it is totally cool and might > make more people like you or give your friends funding. > > Please stop making noise about CTV, this is not a place for spamming. > > -- > John Carvalho > > > > On Sat, Jun 4, 2022 at 1:00 PM < > bitcoin-dev-request@lists•linuxfoundation.org> wrote: > >> >> Date: Fri, 03 Jun 2022 18:39:34 +0000 >> From: alicexbt <alicexbt@protonmail•com> >> To: Bitcoin Protocol Discussion >> <bitcoin-dev@lists•linuxfoundation.org> >> Subject: [bitcoin-dev] Bitcoin covenants are inevitable >> Message-ID: >> >> <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@ >> protonmail.com> >> >> Content-Type: text/plain; charset=utf-8 >> >> Note: This email is an opinion and not an attack on bitcoin >> >> Covenants on bitcoin will eventually be implemented with a soft fork. CTV >> is the easiest and best possible way OP_TX looks good as well. Apart from >> the technical merits, covenants will improve a few other things: >> >> - Developers can build interesting projects with real demand in market. >> - Students learn Sapio and not just solidity. >> - Better tooling could be available for application developers. >> - Maybe we see bitcoin developer hackathons in different countries. >> - Demand for block space might increase, it wont be just exchanges and >> coinjoin. >> - Funding of bitcoin developers and projects might improve. Wont need to >> convince a few people for grants. >> >> **Why covenants are not contentious?** >> >> Some people may write paragraphs about CTV being contentious, spread >> misinformation and do all types of drama, politics etc. on social media but >> there are zero technical NACKs for CTV. We have discussed other covenant >> proposals in detail on mailing list and IRC meetings with an open minded >> approach. >> >> All the developers that participated in the discussion are either okay >> with CTV or OP_TX or covenants in general. >> >> **How and when should covenants be implemented in Bitcoin?** >> >> I don't think we should wait for years anticipating a proposal that >> everyone will agree on or argue for years to pretend changes are hard in >> Bitcoin. We should improve the review process for soft fork BIPs and share >> honest opinions with agreement, disagreement on technical merits. >> >> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything >> else being used if that improves Bitcoin. Covenants implemented in Bitcoin >> before the next cycle would provide opportunity for developers to build >> interesting things during the bear market. Ossification supporters also >> believe there is some window that will close soon, maybe doing changes >> considering each case individually will be a better approach. CTV is not a >> rushed soft fork, less people followed the research and it was not >> mentioned on social media repeatedly by the respected developers like other >> soft forks. >> >> /dev/fd0 >> >> >> Sent with Proton Mail secure email. >> >> >> ------------------------------ >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 6450 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-06 13:02 ` Erik Aronesty @ 2022-06-12 3:36 ` Peter Todd 2022-06-12 13:02 ` Erik Aronesty 2022-06-12 19:16 ` alicexbt 0 siblings, 2 replies; 55+ messages in thread From: Peter Todd @ 2022-06-12 3:36 UTC (permalink / raw) To: Erik Aronesty, Bitcoin Protocol Discussion; +Cc: John Carvalho [-- Attachment #1: Type: text/plain, Size: 537 bytes --] On Mon, Jun 06, 2022 at 09:02:18AM -0400, Erik Aronesty via bitcoin-dev wrote: > Maintaining the security of the protocol is squarely the responsibility of > the Bitcoin software and the core developers > > Continued demand for block space is critical for Bitcoin's security. Only because the block reward goes away. If it was made to continue indefinitely - most likely with an inflation hard fork - demand for block space would not be critical to Bitcoin's security. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-12 3:36 ` Peter Todd @ 2022-06-12 13:02 ` Erik Aronesty 2022-06-12 16:35 ` Corey Haddad 2022-06-12 19:16 ` alicexbt 1 sibling, 1 reply; 55+ messages in thread From: Erik Aronesty @ 2022-06-12 13:02 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion, John Carvalho [-- Attachment #1: Type: text/plain, Size: 803 bytes --] Yes Although I'm guessing most would agree that would be worse. I certainly would choose to add fee generating features over inflation Probably most other people would too On Sat, Jun 11, 2022, 11:36 PM Peter Todd <pete@petertodd•org> wrote: > On Mon, Jun 06, 2022 at 09:02:18AM -0400, Erik Aronesty via bitcoin-dev > wrote: > > Maintaining the security of the protocol is squarely the responsibility > of > > the Bitcoin software and the core developers > > > > Continued demand for block space is critical for Bitcoin's security. > > Only because the block reward goes away. If it was made to continue > indefinitely - most likely with an inflation hard fork - demand for block > space > would not be critical to Bitcoin's security. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > [-- Attachment #2: Type: text/html, Size: 1499 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-12 13:02 ` Erik Aronesty @ 2022-06-12 16:35 ` Corey Haddad 0 siblings, 0 replies; 55+ messages in thread From: Corey Haddad @ 2022-06-12 16:35 UTC (permalink / raw) To: Erik Aronesty, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 456 bytes --] Even if demand for block space is currently not needed to pay for security due to the block rewards, demand for BTC itself is needed for those rewards to be worth anything. Bitcoin, as a proof of work system, is only secure at scale. Therefore continued growth and user adoption are both critical for Bitcoin's security. Perhaps the question then becomes who feels that Bitcoin is inevitable, and who feels it is possible that it can damaged or destroyed? [-- Attachment #2: Type: text/html, Size: 504 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-12 3:36 ` Peter Todd 2022-06-12 13:02 ` Erik Aronesty @ 2022-06-12 19:16 ` alicexbt 2022-06-19 10:31 ` Peter Todd 1 sibling, 1 reply; 55+ messages in thread From: alicexbt @ 2022-06-12 19:16 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion Hi Peter, > Only because the block reward goes away. If it was made to continue > indefinitely - most likely with an inflation hard fork - demand for block space > would not be critical to Bitcoin's security. I am not completely against your proposal although 100% sure this will not have "consensus" to be implemented. I think if bitcoin doesn't have enough demand for block space, it should die. I will be sad if bitcoin doesn't exist but it should be a lesson for all the people opposing soft forks based on drama and politics instead of technical review. I don't see anything wrong with users paying 100x fees for opening and closing LN channels. /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Sunday, June 12th, 2022 at 9:06 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > On Mon, Jun 06, 2022 at 09:02:18AM -0400, Erik Aronesty via bitcoin-dev wrote: > > > Maintaining the security of the protocol is squarely the responsibility of > > the Bitcoin software and the core developers > > > > Continued demand for block space is critical for Bitcoin's security. > > > Only because the block reward goes away. If it was made to continue > indefinitely - most likely with an inflation hard fork - demand for block space > would not be critical to Bitcoin's security. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-12 19:16 ` alicexbt @ 2022-06-19 10:31 ` Peter Todd 2022-06-19 15:54 ` Manuel Costa 0 siblings, 1 reply; 55+ messages in thread From: Peter Todd @ 2022-06-19 10:31 UTC (permalink / raw) To: alicexbt; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1352 bytes --] On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote: > Hi Peter, > > > Only because the block reward goes away. If it was made to continue > > indefinitely - most likely with an inflation hard fork - demand for block space > > would not be critical to Bitcoin's security. > > > I am not completely against your proposal although 100% sure this will not have "consensus" to be implemented. I think if bitcoin doesn't have enough demand for block space, it should die. I will be sad if bitcoin doesn't exist but it should be a lesson for all the people opposing soft forks based on drama and politics instead of technical review. > > I don't see anything wrong with users paying 100x fees for opening and closing LN channels. The PoW security of Bitcoin benefits all Bitcoin users, proportional to the value of BTC they hold; if Bitcoin blocks aren't reliably created the value of *all* BTC goes down. It doesn't make sense for the entire cost of that security to be paid for on a per-tx basis. And there's a high chance paying for it on a per-tx basis won't work anyway due to lack of consistent demand. It would be extremely unfortunate if one of the very few decentralized ways to store value died simply because we couldn't find a way to pay to keep it secure. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-19 10:31 ` Peter Todd @ 2022-06-19 15:54 ` Manuel Costa 2022-06-19 18:26 ` Kate Salazar 2022-06-19 22:35 ` Erik Aronesty 0 siblings, 2 replies; 55+ messages in thread From: Manuel Costa @ 2022-06-19 15:54 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3446 bytes --] "Long time listener, first time caller". Just sharing my 2 sats: While I find it stimulating, I think this discussion (and other similar doom-like scenarios) is somewhat irrelevant in practice. When the time comes and if we start seeing issues with block rewards being too low to maintain acceptable security, we're going to have multiple solutions being implemented for it, and definitely a hard fork to indefinitely maintain some degree of block subsidy is going to be within them. If it is indeed confirmed that the original chain is now insecure, consensus should eventually coalesce in one of the hard forks that can actually keep moving forward with some degree of security assurance. I feel like people sometimes think of these systems as when they fail there's a full loss, but that's not the case as the history is not lost, and so we can move forward from that history with multiple alternatives and allow the social/economic consensus to dictate which one becomes the new accepted chain. The genie is out of the box, and some chain whose history is prefixed by Bitcoin's current chain history will always exist. The only type of problems we should truly be worrying about are ones that might invalidate the security of the history itself, like a cryptographic breakthrough (quantum computing for example) that would turn some or all utxos into "anyone can spend". Transitions might be disorderly and filled with drama and discussion as the "block size wars" in 2017, but anyone who doesn't want to "vote", can always just keep their utxos frozen in place while the drama sorts itself out, and maintain whatever holdings they previously had on the new accepted chain. Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> escreveu no dia domingo, 19/06/2022 à(s) 11:32: > On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote: > > Hi Peter, > > > > > Only because the block reward goes away. If it was made to continue > > > indefinitely - most likely with an inflation hard fork - demand for > block space > > > would not be critical to Bitcoin's security. > > > > > > I am not completely against your proposal although 100% sure this will > not have "consensus" to be implemented. I think if bitcoin doesn't have > enough demand for block space, it should die. I will be sad if bitcoin > doesn't exist but it should be a lesson for all the people opposing soft > forks based on drama and politics instead of technical review. > > > > I don't see anything wrong with users paying 100x fees for opening and > closing LN channels. > > The PoW security of Bitcoin benefits all Bitcoin users, proportional to the > value of BTC they hold; if Bitcoin blocks aren't reliably created the > value of > *all* BTC goes down. It doesn't make sense for the entire cost of that > security > to be paid for on a per-tx basis. And there's a high chance paying for it > on a > per-tx basis won't work anyway due to lack of consistent demand. > > It would be extremely unfortunate if one of the very few decentralized > ways to > store value died simply because we couldn't find a way to pay to keep it > secure. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 4284 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-19 15:54 ` Manuel Costa @ 2022-06-19 18:26 ` Kate Salazar 2022-06-19 22:35 ` Erik Aronesty 1 sibling, 0 replies; 55+ messages in thread From: Kate Salazar @ 2022-06-19 18:26 UTC (permalink / raw) To: Manuel Costa, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4405 bytes --] Hey On Sun, Jun 19, 2022 at 8:04 PM Manuel Costa via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > "Long time listener, first time caller". Just sharing my 2 sats: > > While I find it stimulating, I think this discussion (and other similar > doom-like scenarios) is somewhat irrelevant in practice. > > When the time comes and if we start seeing issues with block rewards being > too low to maintain acceptable security, we're going to have multiple > solutions being implemented for it, and definitely a hard fork to > indefinitely maintain some degree of block subsidy is going to be within > them. > If it is indeed confirmed that the original chain is now insecure, > consensus should eventually coalesce in one of the hard forks that can > actually keep moving forward with some degree of security assurance. > > I feel like people sometimes think of these systems as when they fail > there's a full loss, but that's not the case as the history is not lost, > and so we can move forward from that history with multiple alternatives and > allow the social/economic consensus to dictate which one becomes the new > accepted chain. > The genie is out of the box, and some chain whose history is prefixed by > Bitcoin's current chain history will always exist. > I think you are right, the keywords maybe being consensus eventually coalesces in the most viable chain. > The only type of problems we should truly be worrying about are ones that > might invalidate the security of the history itself, like a cryptographic > breakthrough (quantum computing for example) that would turn some or all > utxos into "anyone can spend". > I think this is wrong. An entity investing in quantum power and letting their chop onto some particular utxos is a reasonable outcome. It parallels a tangible scenario: gang somehow getting a bulldozer and driving it into some particular safe. Being able to rewind such events is the only security issue here. More generally, circulating supply is circulating supply, to all effect, outcome is desirable or not. > Transitions might be disorderly and filled with drama and discussion as > the "block size wars" in 2017, but anyone who doesn't want to "vote", can > always just keep their utxos frozen in place while the drama sorts itself > out, and maintain whatever holdings they previously had on the new accepted > chain. > > Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> > escreveu no dia domingo, 19/06/2022 à(s) 11:32: > >> On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote: >> > Hi Peter, >> > >> > > Only because the block reward goes away. If it was made to continue >> > > indefinitely - most likely with an inflation hard fork - demand for >> block space >> > > would not be critical to Bitcoin's security. >> > >> > >> > I am not completely against your proposal although 100% sure this will >> not have "consensus" to be implemented. I think if bitcoin doesn't have >> enough demand for block space, it should die. I will be sad if bitcoin >> doesn't exist but it should be a lesson for all the people opposing soft >> forks based on drama and politics instead of technical review. >> > >> > I don't see anything wrong with users paying 100x fees for opening and >> closing LN channels. >> >> The PoW security of Bitcoin benefits all Bitcoin users, proportional to >> the >> value of BTC they hold; if Bitcoin blocks aren't reliably created the >> value of >> *all* BTC goes down. It doesn't make sense for the entire cost of that >> security >> to be paid for on a per-tx basis. And there's a high chance paying for it >> on a >> per-tx basis won't work anyway due to lack of consistent demand. >> >> It would be extremely unfortunate if one of the very few decentralized >> ways to >> store value died simply because we couldn't find a way to pay to keep it >> secure. >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> _______________________________________________ >> 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 > [-- Attachment #2: Type: text/html, Size: 6047 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-19 15:54 ` Manuel Costa 2022-06-19 18:26 ` Kate Salazar @ 2022-06-19 22:35 ` Erik Aronesty 2022-06-21 19:00 ` Keagan McClelland 1 sibling, 1 reply; 55+ messages in thread From: Erik Aronesty @ 2022-06-19 22:35 UTC (permalink / raw) To: Manuel Costa, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 802 bytes --] On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > if we start seeing issues with block rewards being too low to maintain > acceptable security, we're going to have multiple solutions being > implemented for it, and definitely a hard fork to indefinitely maintain > some degree of block subsidy > if we failed to first try increasing block demand with advanced transaction support, it would seem like we were just throwing money and growth away to support one narrative (simplicty of function), while destroying another (finite supply) if stuff like covenant support and mweb gets us higher fees, with stuff like on-chain mixing protocols, vaults, and higher utility, it might be more than enough to sustain bitcoin on fees alone forever [-- Attachment #2: Type: text/html, Size: 1216 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-19 22:35 ` Erik Aronesty @ 2022-06-21 19:00 ` Keagan McClelland 2022-06-21 20:10 ` Eric Voskuil 2022-06-23 19:17 ` Peter Todd 0 siblings, 2 replies; 55+ messages in thread From: Keagan McClelland @ 2022-06-21 19:00 UTC (permalink / raw) To: Erik Aronesty, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2299 bytes --] > The PoW security of Bitcoin benefits all Bitcoin users, proportional to the value of BTC they hold; if Bitcoin blocks aren't reliably created the value of *all* BTC goes down. It doesn't make sense for the entire cost of that security to be paid for on a per-tx basis. And there's a high chance paying for it on a per-tx basis won't work anyway due to lack of consistent demand. FWIW I prefer the demurrage route. Having something with finite supply as a means of measuring economic activity is unprecedented and I believe deeply important. I'm sympathetic to the argument that the security of the chain should not be solely the responsibility of transactors. We realize the value of money on receipt, hold *and* spend and it would be appropriate for there to be a balance of fees to that effect. While inflation may be simpler to implement (just chop off the last few halvings), I think it would be superior (on the assumption that such a hodl tax was necessary) to keep the supply fixed and have people's utxo balances decay, at least at the level of the UX. But also none of this should be reasons we don't improve Bitcoin's value (and therefore demand) Keagan On Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > > On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> if we start seeing issues with block rewards being too low to maintain >> acceptable security, we're going to have multiple solutions being >> implemented for it, and definitely a hard fork to indefinitely maintain >> some degree of block subsidy >> > > if we failed to first try increasing block demand with advanced > transaction support, it would seem like we were just throwing money and > growth away to support one narrative (simplicty of function), while > destroying another (finite supply) > > if stuff like covenant support and mweb gets us higher fees, with stuff > like on-chain mixing protocols, vaults, and higher utility, it might be > more than enough to sustain bitcoin on fees alone forever > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3307 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-21 19:00 ` Keagan McClelland @ 2022-06-21 20:10 ` Eric Voskuil 2022-06-23 19:17 ` Peter Todd 1 sibling, 0 replies; 55+ messages in thread From: Eric Voskuil @ 2022-06-21 20:10 UTC (permalink / raw) To: Keagan McClelland, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3373 bytes --] > On Jun 21, 2022, at 12:28, Keagan McClelland via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > The PoW security of Bitcoin benefits all Bitcoin users, proportional to the > value of BTC they hold; if Bitcoin blocks aren't reliably created the value of > *all* BTC goes down. It doesn't make sense for the entire cost of that security > to be paid for on a per-tx basis. Actually it does. People who transact are realizing the benefit of money - the avoidance of barter costs. Those who never transact, never realize any benefit. > And there's a high chance paying for it on a > per-tx basis won't work anyway due to lack of consistent demand. > > FWIW I prefer the demurrage route. Having something with finite supply as a means of measuring economic activity is unprecedented and I believe deeply important. I'm sympathetic to the argument that the security of the chain should not be solely the responsibility of transactors. Chain security - censorship resistance (as opposed to individual double-spend security), is entirely dependent upon tx fees. > We realize the value of money on receipt, hold *and* spend and it would be appropriate for there to be a balance of fees to that effect. There is zero point in saving if you never spend. You can instead just burn your coin. > While inflation may be simpler to implement (just chop off the last few halvings), I think it would be superior (on the assumption that such a hodl tax was necessary) to keep the supply fixed and have people's utxo balances decay, at least at the level of the UX. A hoard decays naturally due to opportunity cost. Investing it requires transaction to invest, and transaction to earn (profit), and transaction to return it (interest). > But also none of this should be reasons we don't improve Bitcoin's value (and therefore demand) Demand is the only reason we save, and eventually transacting is the only motivation for saving. No transacting implies no demand - and no security. e > Keagan > >> On Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> >>> On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >>> if we start seeing issues with block rewards being too low to maintain acceptable security, we're going to have multiple solutions being implemented for it, and definitely a hard fork to indefinitely maintain some degree of block subsidy >> >> if we failed to first try increasing block demand with advanced transaction support, it would seem like we were just throwing money and growth away to support one narrative (simplicty of function), while destroying another (finite supply) >> >> if stuff like covenant support and mweb gets us higher fees, with stuff like on-chain mixing protocols, vaults, and higher utility, it might be more than enough to sustain bitcoin on fees alone forever >> >> _______________________________________________ >> 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 [-- Attachment #2: Type: text/html, Size: 5181 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-21 19:00 ` Keagan McClelland 2022-06-21 20:10 ` Eric Voskuil @ 2022-06-23 19:17 ` Peter Todd 2022-06-28 3:55 ` Billy Tetrud 1 sibling, 1 reply; 55+ messages in thread From: Peter Todd @ 2022-06-23 19:17 UTC (permalink / raw) To: Keagan McClelland, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1773 bytes --] On Tue, Jun 21, 2022 at 01:00:07PM -0600, Keagan McClelland via bitcoin-dev wrote: > > The PoW security of Bitcoin benefits all Bitcoin users, proportional to > the > value of BTC they hold; if Bitcoin blocks aren't reliably created the value > of > *all* BTC goes down. It doesn't make sense for the entire cost of that > security > to be paid for on a per-tx basis. And there's a high chance paying for it > on a > per-tx basis won't work anyway due to lack of consistent demand. > > FWIW I prefer the demurrage route. Having something with finite supply as a > means of measuring economic activity is unprecedented and I believe deeply > important. I'm sympathetic to the argument that the security of the chain > should not be solely the responsibility of transactors. We realize the > value of money on receipt, hold *and* spend and it would be appropriate for > there to be a balance of fees to that effect. While inflation may be > simpler to implement (just chop off the last few halvings), I think it > would be superior (on the assumption that such a hodl tax was necessary) to > keep the supply fixed and have people's utxo balances decay, at least at > the level of the UX. Demurrage makes protocols like Lightning much more complex, and isn't compatible with existing implementations. While demurrage could in theory be implemented in a soft-fork by forcing txs to contain an output with the demurrage-taxed amount, spending to a pool of future mining fees, I really don't think it's practical to actually do that. Anyway, demurrage and inflation have identical economic properties. They're both a tax on savings. The only difference is the way that tax is implemented. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-23 19:17 ` Peter Todd @ 2022-06-28 3:55 ` Billy Tetrud 2022-06-28 16:23 ` Alex Lee ` (3 more replies) 0 siblings, 4 replies; 55+ messages in thread From: Billy Tetrud @ 2022-06-28 3:55 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5057 bytes --] @Eric > People who transact are realizing the benefit of money - the avoidance of barter costs. I'm very confident you're incorrect that holders don't receive any benefit and you're certainly not correct that every spend is receiving the same benefit. As I'm sure you're aware, one of the primary components of a currency's value and purpose is as a store of value. Storing value happens while you're holding it, not while you're spending it. Consider the following two scenarios: one person holds onto 10 bitcoin for 10 years and then spends those 10 bitcoins in some way in 2 transactions. Another person spends 4 bitcoins to buy something, then sells it for 6 bitcoins, and then buys something else for that 6 bitcoins and then never acquires any bitcoin for 10 years. Both people spent 10 bitcoins over 2 transactions. Over that 10 year period, only one of those people utilized bitcoin's utility as a store of value. Who benefited more from their use of bitcoin? > Those who never transact, never realize any benefit. While that's true, its not relevant and basically a red herring. You need to compare those who transact often and rarely hold, to those who hold a lot but rarely transact. Its not helpful to consider those who throw their bitcoin into a bottomless pit and never retrieve them. On an idealistic level, I agree with Keagan that it would make sense to have "a balance of fees to that effect". I think doing that would be technically/economically optimal. However, I think there is an enormous benefit to having a cultural aversion to monetary inflation and the consequences of convincing the bitcoin community that inflation is ok could have unintended negative consequences (not to mention how difficult convincing the community would be in the first place). There's also the economic distortion that inflation causes that has a negative effect which should also be considered. The idea of decaying utxo value is interesting to consider, but it would not solve the economic distortion that monetary inflation causes, because that distortion is a result of monetary devaluation (which decaying utxos would be a form of). Then again, maybe in this case the distortion of inflation would actually be a correction - correcting for the externality of benefit received by holders. I'm stream-of-consciousnessing a bit, but anyways, I suspect its not worth the trouble to perfect the distribution of bitcoin blockchain security costs to include holders. Tho, if I were to go back in time and influence how bitcoin was designed, I might advocate for it. @Peter > demurrage and inflation have identical economic properties. The distortion of incentives is identical, however there is also the effect it has on a currency's property as a useful unit of account. Decaying utxos would mean that it would contribute substantially less to market prices needing to change. I suspect this effect would be bordering on negligible tho. On Thu, Jun 23, 2022 at 2:17 PM Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Tue, Jun 21, 2022 at 01:00:07PM -0600, Keagan McClelland via > bitcoin-dev wrote: > > > The PoW security of Bitcoin benefits all Bitcoin users, proportional to > > the > > value of BTC they hold; if Bitcoin blocks aren't reliably created the > value > > of > > *all* BTC goes down. It doesn't make sense for the entire cost of that > > security > > to be paid for on a per-tx basis. And there's a high chance paying for it > > on a > > per-tx basis won't work anyway due to lack of consistent demand. > > > > FWIW I prefer the demurrage route. Having something with finite supply > as a > > means of measuring economic activity is unprecedented and I believe > deeply > > important. I'm sympathetic to the argument that the security of the chain > > should not be solely the responsibility of transactors. We realize the > > value of money on receipt, hold *and* spend and it would be appropriate > for > > there to be a balance of fees to that effect. While inflation may be > > simpler to implement (just chop off the last few halvings), I think it > > would be superior (on the assumption that such a hodl tax was necessary) > to > > keep the supply fixed and have people's utxo balances decay, at least at > > the level of the UX. > > Demurrage makes protocols like Lightning much more complex, and isn't > compatible with existing implementations. While demurrage could in theory > be > implemented in a soft-fork by forcing txs to contain an output with the > demurrage-taxed amount, spending to a pool of future mining fees, I really > don't think it's practical to actually do that. > > Anyway, demurrage and inflation have identical economic properties. They're > both a tax on savings. The only difference is the way that tax is > implemented. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 6181 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-28 3:55 ` Billy Tetrud @ 2022-06-28 16:23 ` Alex Lee 2022-06-28 23:22 ` Peter Todd 2022-06-28 23:20 ` Peter Todd ` (2 subsequent siblings) 3 siblings, 1 reply; 55+ messages in thread From: Alex Lee @ 2022-06-28 16:23 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5764 bytes --] On Tue, Jun 28, 2022 at 4:43 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > @Eric > > People who transact are realizing the benefit of money - the avoidance > of barter costs. > > I'm very confident you're incorrect that holders don't receive any benefit > and you're certainly not correct that every spend is receiving the same > benefit. As I'm sure you're aware, one of the primary components of a > currency's value and purpose is as a store of value. Storing value happens > while you're holding it, not while you're spending it. Consider the > following two scenarios: one person holds onto 10 bitcoin for 10 years and > then spends those 10 bitcoins in some way in 2 transactions. Another person > spends 4 bitcoins to buy something, then sells it for 6 bitcoins, and then > buys something else for that 6 bitcoins and then never acquires any bitcoin > for 10 years. > > Both people spent 10 bitcoins over 2 transactions. Over that 10 year > period, only one of those people utilized bitcoin's utility as a store of > value. Who benefited more from their use of bitcoin? > > The person who obtained greater economic utility from their two transactions. > > Those who never transact, never realize any benefit. > > While that's true, its not relevant and basically a red herring. You need > to compare those who transact often and rarely hold, to those who hold a > lot but rarely transact. Its not helpful to consider those who throw their > bitcoin into a bottomless pit and never retrieve them. > There are legitimate uses for burning bitcoin, speaking of bottomless pits. I would avoid confusing velocity metrics with utility, as these aren't the same thing. > > On an idealistic level, I agree with Keagan that it would make sense to > have "a balance of fees to that effect". I think doing that would be > technically/economically optimal. However, I think there is an enormous > benefit to having a cultural aversion to monetary inflation and the > consequences of convincing the bitcoin community that inflation is ok could > have unintended negative consequences (not to mention how difficult > convincing the community would be in the first place). There's also the > economic distortion that inflation causes that has a negative effect which > should also be considered. The idea of decaying utxo value is interesting > to consider, but it would not solve the economic distortion that > monetary inflation causes, because that distortion is a result of monetary > devaluation (which decaying utxos would be a form of). Then again, maybe in > this case the distortion of inflation would actually be a correction - > correcting for the externality of benefit received by holders. I'm > stream-of-consciousnessing a bit, but anyways, I suspect its not worth the > trouble to perfect the distribution of bitcoin blockchain security costs to > include holders. Tho, if I were to go back in time and influence how > bitcoin was designed, I might advocate for it. > > @Peter > > demurrage and inflation have identical economic properties. > > The distortion of incentives is identical, however there is also the > effect it has on a currency's property as a useful unit of account. > Decaying utxos would mean that it would contribute substantially less to > market prices needing to change. I suspect this effect would be bordering > on negligible tho. > > On Thu, Jun 23, 2022 at 2:17 PM Peter Todd via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> On Tue, Jun 21, 2022 at 01:00:07PM -0600, Keagan McClelland via >> bitcoin-dev wrote: >> > > The PoW security of Bitcoin benefits all Bitcoin users, proportional >> to >> > the >> > value of BTC they hold; if Bitcoin blocks aren't reliably created the >> value >> > of >> > *all* BTC goes down. It doesn't make sense for the entire cost of that >> > security >> > to be paid for on a per-tx basis. And there's a high chance paying for >> it >> > on a >> > per-tx basis won't work anyway due to lack of consistent demand. >> > >> > FWIW I prefer the demurrage route. Having something with finite supply >> as a >> > means of measuring economic activity is unprecedented and I believe >> deeply >> > important. I'm sympathetic to the argument that the security of the >> chain >> > should not be solely the responsibility of transactors. We realize the >> > value of money on receipt, hold *and* spend and it would be appropriate >> for >> > there to be a balance of fees to that effect. While inflation may be >> > simpler to implement (just chop off the last few halvings), I think it >> > would be superior (on the assumption that such a hodl tax was >> necessary) to >> > keep the supply fixed and have people's utxo balances decay, at least at >> > the level of the UX. >> >> Demurrage makes protocols like Lightning much more complex, and isn't >> compatible with existing implementations. While demurrage could in theory >> be >> implemented in a soft-fork by forcing txs to contain an output with the >> demurrage-taxed amount, spending to a pool of future mining fees, I really >> don't think it's practical to actually do that. >> >> Anyway, demurrage and inflation have identical economic properties. >> They're >> both a tax on savings. The only difference is the way that tax is >> implemented. >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> _______________________________________________ >> 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 > [-- Attachment #2: Type: text/html, Size: 7659 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-28 16:23 ` Alex Lee @ 2022-06-28 23:22 ` Peter Todd 2022-06-29 5:02 ` Alex Lee 0 siblings, 1 reply; 55+ messages in thread From: Peter Todd @ 2022-06-28 23:22 UTC (permalink / raw) To: Alex Lee, Bitcoin Protocol Discussion; +Cc: Billy Tetrud [-- Attachment #1: Type: text/plain, Size: 970 bytes --] On Tue, Jun 28, 2022 at 12:23:40PM -0400, Alex Lee via bitcoin-dev wrote: > > > Those who never transact, never realize any benefit. > > > > While that's true, its not relevant and basically a red herring. You need > > to compare those who transact often and rarely hold, to those who hold a > > lot but rarely transact. Its not helpful to consider those who throw their > > bitcoin into a bottomless pit and never retrieve them. > > > > There are legitimate uses for burning bitcoin, speaking of bottomless pits. > I would avoid confusing velocity metrics with utility, as these aren't the > same thing. All the legitimate uses for burning bitcoin are _not_ done via a "bottomless pit": they're done with transactions proving that the bitcoin has actually been burnt. And the value obtained by burning BTC in those scenarios is affected by tx fees and inflation just as much as any other tx. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-28 23:22 ` Peter Todd @ 2022-06-29 5:02 ` Alex Lee 0 siblings, 0 replies; 55+ messages in thread From: Alex Lee @ 2022-06-29 5:02 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion, Billy Tetrud [-- Attachment #1: Type: text/plain, Size: 1459 bytes --] On Tue, Jun 28, 2022 at 7:22 PM Peter Todd <pete@petertodd•org> wrote: > On Tue, Jun 28, 2022 at 12:23:40PM -0400, Alex Lee via bitcoin-dev wrote: > > > > Those who never transact, never realize any benefit. > > > > > > While that's true, its not relevant and basically a red herring. You > need > > > to compare those who transact often and rarely hold, to those who hold > a > > > lot but rarely transact. Its not helpful to consider those who throw > their > > > bitcoin into a bottomless pit and never retrieve them. > > > > > > > There are legitimate uses for burning bitcoin, speaking of bottomless > pits. > > I would avoid confusing velocity metrics with utility, as these aren't > the > > same thing. > > All the legitimate uses for burning bitcoin are _not_ done via a > "bottomless > pit": they're done with transactions proving that the bitcoin has actually > been > burnt. And the value obtained by burning BTC in those scenarios is > affected by > tx fees and inflation just as much as any other tx. > > The "bottomless pit" is a metaphor for the inability to spend the coins again in the future once burned, as Billy appeared to be indicating that the frequent movement of coins in itself somehow produced utility. Naturally you are correct that the utility of the burn comes from the proof; I am not sure what the meaning of "burned coins" would be without the proof to be honest. > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > [-- Attachment #2: Type: text/html, Size: 2227 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-28 3:55 ` Billy Tetrud 2022-06-28 16:23 ` Alex Lee @ 2022-06-28 23:20 ` Peter Todd 2022-06-29 10:44 ` Kate Salazar 2022-06-30 17:04 ` Erik Aronesty 3 siblings, 0 replies; 55+ messages in thread From: Peter Todd @ 2022-06-28 23:20 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1581 bytes --] On Mon, Jun 27, 2022 at 10:55:56PM -0500, Billy Tetrud wrote: > @Eric > > People who transact are realizing the benefit of money - the avoidance > of barter costs. > > I'm very confident you're incorrect that holders don't receive any benefit > and you're certainly not correct that every spend is receiving the same > benefit. As I'm sure you're aware, one of the primary components of a > currency's value and purpose is as a store of value. Storing value happens > while you're holding it, not while you're spending it. Consider the > following two scenarios: one person holds onto 10 bitcoin for 10 years and > then spends those 10 bitcoins in some way in 2 transactions. Another person > spends 4 bitcoins to buy something, then sells it for 6 bitcoins, and then > buys something else for that 6 bitcoins and then never acquires any bitcoin > for 10 years. > > Both people spent 10 bitcoins over 2 transactions. Over that 10 year > period, only one of those people utilized bitcoin's utility as a store of > value. Who benefited more from their use of bitcoin? Notice how people frequenty bring up the fact that if you divide the total block reward by the number of transactions, the cost per transaction is fairly high - on the order of tens of dollars. This makes much more sense when you realize that the average value moved per transaction is also very high - thousands of dollars - making the cost due to inflation of those tens of dollars transactions low enough to be affordable. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-28 3:55 ` Billy Tetrud 2022-06-28 16:23 ` Alex Lee 2022-06-28 23:20 ` Peter Todd @ 2022-06-29 10:44 ` Kate Salazar 2022-06-30 15:25 ` Billy Tetrud 2022-07-03 9:43 ` Peter Todd 2022-06-30 17:04 ` Erik Aronesty 3 siblings, 2 replies; 55+ messages in thread From: Kate Salazar @ 2022-06-29 10:44 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5968 bytes --] Hey On Tue, Jun 28, 2022 at 10:43 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > @Eric > > People who transact are realizing the benefit of money - the avoidance > of barter costs. > > I'm very confident you're incorrect that holders don't receive any benefit > and you're certainly not correct that every spend is receiving the same > benefit. As I'm sure you're aware, one of the primary components of a > currency's value and purpose is as a store of value. Storing value happens > while you're holding it, not while you're spending it. Consider the > following two scenarios: one person holds onto 10 bitcoin for 10 years and > then spends those 10 bitcoins in some way in 2 transactions. Another person > spends 4 bitcoins to buy something, then sells it for 6 bitcoins, and then > buys something else for that 6 bitcoins and then never acquires any bitcoin > for 10 years. > > Both people spent 10 bitcoins over 2 transactions. Over that 10 year > period, only one of those people utilized bitcoin's utility as a store of > value. Who benefited more from their use of bitcoin? > > > Those who never transact, never realize any benefit. > > While that's true, its not relevant and basically a red herring. You need > to compare those who transact often and rarely hold, to those who hold a > lot but rarely transact. Its not helpful to consider those who throw their > bitcoin into a bottomless pit and never retrieve them. > > On an idealistic level, I agree with Keagan that it would make sense to > have "a balance of fees to that effect". I think doing that would be > technically/economically optimal. However, I think there is an enormous > benefit to having a cultural aversion to monetary inflation and the > consequences of convincing the bitcoin community that inflation is ok could > have unintended negative consequences (not to mention how difficult > convincing the community would be in the first place). There's also the > economic distortion that inflation causes that has a negative effect which > should also be considered. The idea of decaying utxo value is interesting > to consider, but it would not solve the economic distortion that > monetary inflation causes, because that distortion is a result of monetary > devaluation (which decaying utxos would be a form of). Then again, maybe in > this case the distortion of inflation would actually be a correction - > correcting for the externality of benefit received by holders. I'm > stream-of-consciousnessing a bit, but anyways, I suspect its not worth the > trouble to perfect the distribution of bitcoin blockchain security costs to > include holders. Tho, if I were to go back in time and influence how > bitcoin was designed, I might advocate for it. > Pool operators are free to request larger fees from older utxos, or from all utxos, or from newer utxos, at their judgement, looking at the blockspace demand census and at what the other pool operators are doing. This is not consensus, it's policy. It's not a technology problem, it's solved above in the social layer. If this kind of problem torments anyone, maybe miner decentralization hard forks are worth looking at, some already exist. > > @Peter > > demurrage and inflation have identical economic properties. > > The distortion of incentives is identical, however there is also the > effect it has on a currency's property as a useful unit of account. > Decaying utxos would mean that it would contribute substantially less to > market prices needing to change. I suspect this effect would be bordering > on negligible tho. > > On Thu, Jun 23, 2022 at 2:17 PM Peter Todd via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> On Tue, Jun 21, 2022 at 01:00:07PM -0600, Keagan McClelland via >> bitcoin-dev wrote: >> > > The PoW security of Bitcoin benefits all Bitcoin users, proportional >> to >> > the >> > value of BTC they hold; if Bitcoin blocks aren't reliably created the >> value >> > of >> > *all* BTC goes down. It doesn't make sense for the entire cost of that >> > security >> > to be paid for on a per-tx basis. And there's a high chance paying for >> it >> > on a >> > per-tx basis won't work anyway due to lack of consistent demand. >> > >> > FWIW I prefer the demurrage route. Having something with finite supply >> as a >> > means of measuring economic activity is unprecedented and I believe >> deeply >> > important. I'm sympathetic to the argument that the security of the >> chain >> > should not be solely the responsibility of transactors. We realize the >> > value of money on receipt, hold *and* spend and it would be appropriate >> for >> > there to be a balance of fees to that effect. While inflation may be >> > simpler to implement (just chop off the last few halvings), I think it >> > would be superior (on the assumption that such a hodl tax was >> necessary) to >> > keep the supply fixed and have people's utxo balances decay, at least at >> > the level of the UX. >> >> Demurrage makes protocols like Lightning much more complex, and isn't >> compatible with existing implementations. While demurrage could in theory >> be >> implemented in a soft-fork by forcing txs to contain an output with the >> demurrage-taxed amount, spending to a pool of future mining fees, I really >> don't think it's practical to actually do that. >> >> Anyway, demurrage and inflation have identical economic properties. >> They're >> both a tax on savings. The only difference is the way that tax is >> implemented. >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> _______________________________________________ >> 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 > [-- Attachment #2: Type: text/html, Size: 7682 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-29 10:44 ` Kate Salazar @ 2022-06-30 15:25 ` Billy Tetrud 2022-07-03 9:43 ` Peter Todd 1 sibling, 0 replies; 55+ messages in thread From: Billy Tetrud @ 2022-06-30 15:25 UTC (permalink / raw) To: Kate Salazar; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8321 bytes --] @Alex > The person who obtained greater economic utility from their two transactions. That is not the case. The economic utility gained by their two transactions is probably almost entirely related to something other than bitcoin - the nature of the specific transactions themselves. The value they got from using bitcoin is the value they get from the properties of bitcoin when compared against other competing things in the market (other currencies or payment systems). Bitcoin's ability to finalize quickly, have no counterparty risk, reduced 3rd party middleman fees, and the willingness of that person to transact using bitcoin vs something else, to name a few. My example was intended to make it very clear that the person who held bitcoin over 10 years got more value from bitcoin itself, regardless of who received more economic utility from their chosen transactions. > Billy appeared to be indicating that the frequent movement of coins in itself somehow produced utility I was actually saying the opposite of that. My point, and the point of my example I explained above, was that holders gain quite a bit of value from bitcoin, and so bitcoin's value to its users is not derived solely from transacting. @Kate > Pool operators are free to request larger fees from older utxos You're absolutely right that whoever creates their block template can decide how to include transactions. However, by doing such non-standard things, they would lose money, so they are not incentivized to do that. Keagan's point was about who pays for bitcoin's security. Right now it is only transactors. And yet transactors are not the only actors who gain value from the use of bitcoin. As such, the payment for bitcoin's security is not spread proportionally to those who get value from the use of bitcoin. It would certainly be ideal if bitcoin's security was paid for by each actor proportionally to how much value they get from using bitcoin. Worth it? Questionable. But ideal, certainly. You aren't going to get to that ideal by expecting individual miners to altruistically lose money to enact that ideal. On Wed, Jun 29, 2022 at 3:44 AM Kate Salazar < mercedes.catherine.salazar@gmail•com> wrote: > Hey > > On Tue, Jun 28, 2022 at 10:43 AM Billy Tetrud via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> @Eric >> > People who transact are realizing the benefit of money - the avoidance >> of barter costs. >> >> I'm very confident you're incorrect that holders don't receive any >> benefit and you're certainly not correct that every spend is receiving the >> same benefit. As I'm sure you're aware, one of the primary components of a >> currency's value and purpose is as a store of value. Storing value happens >> while you're holding it, not while you're spending it. Consider the >> following two scenarios: one person holds onto 10 bitcoin for 10 years and >> then spends those 10 bitcoins in some way in 2 transactions. Another person >> spends 4 bitcoins to buy something, then sells it for 6 bitcoins, and then >> buys something else for that 6 bitcoins and then never acquires any bitcoin >> for 10 years. >> >> Both people spent 10 bitcoins over 2 transactions. Over that 10 year >> period, only one of those people utilized bitcoin's utility as a store of >> value. Who benefited more from their use of bitcoin? >> >> > Those who never transact, never realize any benefit. >> >> While that's true, its not relevant and basically a red herring. You need >> to compare those who transact often and rarely hold, to those who hold a >> lot but rarely transact. Its not helpful to consider those who throw their >> bitcoin into a bottomless pit and never retrieve them. >> >> On an idealistic level, I agree with Keagan that it would make sense to >> have "a balance of fees to that effect". I think doing that would be >> technically/economically optimal. However, I think there is an enormous >> benefit to having a cultural aversion to monetary inflation and the >> consequences of convincing the bitcoin community that inflation is ok could >> have unintended negative consequences (not to mention how difficult >> convincing the community would be in the first place). There's also the >> economic distortion that inflation causes that has a negative effect which >> should also be considered. The idea of decaying utxo value is interesting >> to consider, but it would not solve the economic distortion that >> monetary inflation causes, because that distortion is a result of monetary >> devaluation (which decaying utxos would be a form of). Then again, maybe in >> this case the distortion of inflation would actually be a correction - >> correcting for the externality of benefit received by holders. I'm >> stream-of-consciousnessing a bit, but anyways, I suspect its not worth the >> trouble to perfect the distribution of bitcoin blockchain security costs to >> include holders. Tho, if I were to go back in time and influence how >> bitcoin was designed, I might advocate for it. >> > > Pool operators are free to request larger fees from older utxos, or from > all utxos, or from newer utxos, at their judgement, looking at the > blockspace demand census and at what the other pool operators are doing. > This is not consensus, it's policy. It's not a technology problem, it's > solved above in the social layer. > > If this kind of problem torments anyone, maybe miner decentralization hard > forks are worth looking at, some already exist. > > >> >> @Peter >> > demurrage and inflation have identical economic properties. >> >> The distortion of incentives is identical, however there is also the >> effect it has on a currency's property as a useful unit of account. >> Decaying utxos would mean that it would contribute substantially less to >> market prices needing to change. I suspect this effect would be bordering >> on negligible tho. >> >> On Thu, Jun 23, 2022 at 2:17 PM Peter Todd via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> On Tue, Jun 21, 2022 at 01:00:07PM -0600, Keagan McClelland via >>> bitcoin-dev wrote: >>> > > The PoW security of Bitcoin benefits all Bitcoin users, proportional >>> to >>> > the >>> > value of BTC they hold; if Bitcoin blocks aren't reliably created the >>> value >>> > of >>> > *all* BTC goes down. It doesn't make sense for the entire cost of that >>> > security >>> > to be paid for on a per-tx basis. And there's a high chance paying for >>> it >>> > on a >>> > per-tx basis won't work anyway due to lack of consistent demand. >>> > >>> > FWIW I prefer the demurrage route. Having something with finite supply >>> as a >>> > means of measuring economic activity is unprecedented and I believe >>> deeply >>> > important. I'm sympathetic to the argument that the security of the >>> chain >>> > should not be solely the responsibility of transactors. We realize the >>> > value of money on receipt, hold *and* spend and it would be >>> appropriate for >>> > there to be a balance of fees to that effect. While inflation may be >>> > simpler to implement (just chop off the last few halvings), I think it >>> > would be superior (on the assumption that such a hodl tax was >>> necessary) to >>> > keep the supply fixed and have people's utxo balances decay, at least >>> at >>> > the level of the UX. >>> >>> Demurrage makes protocols like Lightning much more complex, and isn't >>> compatible with existing implementations. While demurrage could in >>> theory be >>> implemented in a soft-fork by forcing txs to contain an output with the >>> demurrage-taxed amount, spending to a pool of future mining fees, I >>> really >>> don't think it's practical to actually do that. >>> >>> Anyway, demurrage and inflation have identical economic properties. >>> They're >>> both a tax on savings. The only difference is the way that tax is >>> implemented. >>> >>> -- >>> https://petertodd.org 'peter'[:-1]@petertodd.org >>> _______________________________________________ >>> 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 >> > [-- Attachment #2: Type: text/html, Size: 10431 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-29 10:44 ` Kate Salazar 2022-06-30 15:25 ` Billy Tetrud @ 2022-07-03 9:43 ` Peter Todd 2022-07-03 10:30 ` Giuseppe B 1 sibling, 1 reply; 55+ messages in thread From: Peter Todd @ 2022-07-03 9:43 UTC (permalink / raw) To: Kate Salazar, Bitcoin Protocol Discussion; +Cc: Billy Tetrud [-- Attachment #1: Type: text/plain, Size: 2228 bytes --] On Wed, Jun 29, 2022 at 12:44:11PM +0200, Kate Salazar via bitcoin-dev wrote: > > On an idealistic level, I agree with Keagan that it would make sense to > > have "a balance of fees to that effect". I think doing that would be > > technically/economically optimal. However, I think there is an enormous > > benefit to having a cultural aversion to monetary inflation and the > > consequences of convincing the bitcoin community that inflation is ok could > > have unintended negative consequences (not to mention how difficult > > convincing the community would be in the first place). There's also the > > economic distortion that inflation causes that has a negative effect which > > should also be considered. The idea of decaying utxo value is interesting > > to consider, but it would not solve the economic distortion that > > monetary inflation causes, because that distortion is a result of monetary > > devaluation (which decaying utxos would be a form of). Then again, maybe in > > this case the distortion of inflation would actually be a correction - > > correcting for the externality of benefit received by holders. I'm > > stream-of-consciousnessing a bit, but anyways, I suspect its not worth the > > trouble to perfect the distribution of bitcoin blockchain security costs to > > include holders. Tho, if I were to go back in time and influence how > > bitcoin was designed, I might advocate for it. > > > > Pool operators are free to request larger fees from older utxos, or from > all utxos, or from newer utxos, at their judgement, looking at the > blockspace demand census and at what the other pool operators are doing. > This is not consensus, it's policy. It's not a technology problem, it's > solved above in the social layer. If pool operators can easily collude like you are proposing, we have a serious problem with pool centralization. What you would actually expect in a healthy Bitcoin ecosystem is for some pool operators to defect, and them winding up mining those transactions for market-based fees, eventually forcing the pool operators who are trying to charge a discriminatory premium to give up. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-03 9:43 ` Peter Todd @ 2022-07-03 10:30 ` Giuseppe B 2022-07-06 4:28 ` Corey Haddad 0 siblings, 1 reply; 55+ messages in thread From: Giuseppe B @ 2022-07-03 10:30 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion; +Cc: Billy Tetrud [-- Attachment #1: Type: text/plain, Size: 2908 bytes --] Bitcoin's finite supply is the main argument for people investing in it, the whole narrative around bitcoin is based on its finite supply. While it has its flaws and basically condemns bitcoin to be only used as a store of value (and not as a currency), I don't think it's worth questioning it at this point. Just my 2 sats. Giuseppe. On Sun, Jul 3, 2022, 11:44 AM Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Wed, Jun 29, 2022 at 12:44:11PM +0200, Kate Salazar via bitcoin-dev > wrote: > > > On an idealistic level, I agree with Keagan that it would make sense to > > > have "a balance of fees to that effect". I think doing that would be > > > technically/economically optimal. However, I think there is an enormous > > > benefit to having a cultural aversion to monetary inflation and the > > > consequences of convincing the bitcoin community that inflation is ok > could > > > have unintended negative consequences (not to mention how difficult > > > convincing the community would be in the first place). There's also the > > > economic distortion that inflation causes that has a negative effect > which > > > should also be considered. The idea of decaying utxo value is > interesting > > > to consider, but it would not solve the economic distortion that > > > monetary inflation causes, because that distortion is a result of > monetary > > > devaluation (which decaying utxos would be a form of). Then again, > maybe in > > > this case the distortion of inflation would actually be a correction - > > > correcting for the externality of benefit received by holders. I'm > > > stream-of-consciousnessing a bit, but anyways, I suspect its not worth > the > > > trouble to perfect the distribution of bitcoin blockchain security > costs to > > > include holders. Tho, if I were to go back in time and influence how > > > bitcoin was designed, I might advocate for it. > > > > > > > Pool operators are free to request larger fees from older utxos, or from > > all utxos, or from newer utxos, at their judgement, looking at the > > blockspace demand census and at what the other pool operators are doing. > > This is not consensus, it's policy. It's not a technology problem, it's > > solved above in the social layer. > > If pool operators can easily collude like you are proposing, we have a > serious > problem with pool centralization. > > What you would actually expect in a healthy Bitcoin ecosystem is for some > pool > operators to defect, and them winding up mining those transactions for > market-based fees, eventually forcing the pool operators who are trying to > charge a discriminatory premium to give up. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3944 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-03 10:30 ` Giuseppe B @ 2022-07-06 4:28 ` Corey Haddad 2022-07-06 11:10 ` vjudeu 0 siblings, 1 reply; 55+ messages in thread From: Corey Haddad @ 2022-07-06 4:28 UTC (permalink / raw) To: Giuseppe B, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2185 bytes --] >Bitcoin's finite supply is the main argument for people investing in it, the whole narrative around bitcoin is based on its finite supply. While it has its flaws and basically condemns bitcoin to be only used as a store >of value (and not as a currency), I don't think it's worth questioning it at this point. > >Just my 2 sats. > >Giuseppe. A finite supply alone is not enough to give something value, as it must also be useful in some way. In the case of Bitcoin, various forms of cryptographic security must all work - and work together - to make Bitcoin useful. If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders. There will always be competitive pressures with respect to efficiency, and both being over-secured and under-secured would be economically inefficient for a crypto currency, and thereby laving room for a more optimally-secured competitor to gain ground. Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists. There is also zero agreement on how much security would constitute such an optimum. Figuring out how much security is needed, or even better, figuring out a way to have a market mechanism to answer that question, will be an important project. Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient. Anthony Towns presented a form of this concept in greater detail at a Scaling Bitcoin conference some years ago. While this solution, if employed, would only work for some finite amount of time, it is possible that could give additional decades before the accumulated security budget was exhausted. Corey [-- Attachment #2: Type: text/html, Size: 2512 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-06 4:28 ` Corey Haddad @ 2022-07-06 11:10 ` vjudeu 2022-07-07 0:46 ` Billy Tetrud 2022-07-07 14:10 ` Giuseppe B 0 siblings, 2 replies; 55+ messages in thread From: vjudeu @ 2022-07-06 11:10 UTC (permalink / raw) To: Corey Haddad <corey3@gmail•com>, Bitcoin Protocol Discussion, Giuseppe B, Bitcoin Protocol Discussion > If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders. So, Paul Sztorc was right again, there are three options: Enormous Block Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. And I think using Merged Mining is the best option. More about that: https://www.truthcoin.info/blog/security-budget-ii-mm/ > Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient. Yes, that's also possible, RSK uses that. And making some kind of soft-fork for that is also possible, but I don't know if miners will agree to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_TRUE". On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >Bitcoin's finite supply is the main argument for people investing in it, the whole narrative around bitcoin is based on its finite supply. While it has its flaws and basically condemns bitcoin to be only used as a store >of value (and not as a currency), I don't think it's worth questioning it at this point. > >Just my 2 sats. > >Giuseppe. A finite supply alone is not enough to give something value, as it must also be useful in some way. In the case of Bitcoin, various forms of cryptographic security must all work - and work together - to make Bitcoin useful. If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders. There will always be competitive pressures with respect to efficiency, and both being over-secured and under-secured would be economically inefficient for a crypto currency, and thereby laving room for a more optimally-secured competitor to gain ground. Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists. There is also zero agreement on how much security would constitute such an optimum. Figuring out how much security is needed, or even better, figuring out a way to have a market mechanism to answer that question, will be an important project. Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient. Anthony Towns presented a form of this concept in greater detail at a Scaling Bitcoin conference some years ago. While this solution, if employed, would only work for some finite amount of time, it is possible that could give additional decades before the accumulated security budget was exhausted. Corey ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-06 11:10 ` vjudeu @ 2022-07-07 0:46 ` Billy Tetrud 2022-07-07 12:15 ` vjudeu 2022-07-07 14:05 ` Erik Aronesty 2022-07-07 14:10 ` Giuseppe B 1 sibling, 2 replies; 55+ messages in thread From: Billy Tetrud @ 2022-07-07 0:46 UTC (permalink / raw) To: vjudeu, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8595 bytes --] @Corey > Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists. I basically agree with this. The pedantic part of my mind does want to point out that the link between block subsidy and bitcoin's price does actually give somewhat of a feedback loop, in that the higher the price, the more valuable bitcoin is as a whole (at least as viewed by the active market), and therefore the more investment in security is appropriate. However, in the long run when the subsidy reduces to insignificance, we basically lose this link. And even with this link, it's not very direct. Fees retain only a little bit of this behavior, because presumably a more valuable bitcoin is more valuable to spend, but the link to security is very tenuous there. > There is also zero agreement on how much security would constitute such an optimum. This is really step 1. We need to generate consensus on this long before the block subsidy becomes too small. Probably in the next 10-15 years. I wrote a paper <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity> that uses a framework for thinking about how much security bitcoin might need. The concept is that we should figure out what bitcoin's bottlenecks are, and figure out the minimum requirements we want to place on running a node based on how many (public) nodes we think we need and what percentage of machines out there are likely to run a node. The goals I chose to explore in that paper are totally up for debate, and I think its an important debate to have. But they are basically a first stab at setting up what we would need to determine optimum security. I would very much appreciate your review of that part of the paper, Corey. > Figuring out how much security is needed, or even better, figuring out a way to have a market mechanism to answer that question, will be an important project. My thoughts on this are that we will need to periodically make some software change to adjust a *target amount of investment in security*, because the components of bitcoin's blockchain security are not all predictable. Many unpredictable things factor into bitcoin's security (eg miner behavior, pools, how many people generally run public nodes on their own, what features require running public nodes, value of bitcoin, etc. The primary mechanism we have to change how much security we have is to change the block size, which changes how much fees miners can collect each block. This isn't a linear thing. Its probably a parabola with a peak, where at that peak, making the block either smaller and larger would both reduce total fees paid. This is because when blocksize is higher, more transactions (and thus more fees) can be collected, but at the same time average fees will be lower. The pull of those two forces should define that parabola. So my suggestion here would be that we should target a certain amount of security and have programmatic adjustments to the block size in order to stay near enough to the parabolic maximum so that we pay miners enough to give us sufficient blockchain security. Conversely, it should also attempt to minimize how much "extra" security we pay for. It would be wasteful to pay 3 times as much for 3 times the security we actually need. Such a thing is a very real form of devaluation that basically represents a tax on bitcoin and users of bitcoin. And its very possible for the position of this parabola to change over time. We could never say with certainty whether we're on one side of the parabola's maximum or the other. This would make it rather complex to track well. Additionally, there's no clear trustless way to determine the market value of bitcoin at any given time, which makes it difficult to maintain this target over time. As the market value of bitcoin changes, that target could become quite inaccurate. This implies that we would need to do periodic adjustments to the target, either through periodic forks or through some other mechanism for changing the target. If there were a good trustless way to determine the market value of bitcoin, we would have to "manually" change this target potentially much less often. Transaction fees kind of have an association with market value. Perhaps some kind of analysis can be done on that to make a reasonable prediction of what market value is based on fees. Or maybe blocks can commit to a market price similarly to how they commit to a timestamp (which is also only verifiable to an approximation and can only be verified close to when it was mined but not eg years later). On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > If the only realistic (fair, efficient & proportionate) way to pay for > Bitcoin's security was by having some inflation scheme that violated the 21 > million cap, then agreeing to break the limit would probably be what makes > sense, and in the economic interest of its users and holders. > > So, Paul Sztorc was right again, there are three options: Enormous Block > Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come > From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. > And I think using Merged Mining is the best option. More about that: > https://www.truthcoin.info/blog/security-budget-ii-mm/ > > > Another option, if we were to decide we are over-secured in the short > term, would be to soft-fork in a reduction in the current and near-future > mining rewards, by somehow locking the coins in a contract that deprived > the miner of the full reward, and then using that contract to pay the > rewards out far in the future, should at some point we feel the security > budget was insufficient. > > Yes, that's also possible, RSK uses that. And making some kind of > soft-fork for that is also possible, but I don't know if miners will agree > to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY > OP_DROP OP_TRUE". > > On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >Bitcoin's finite supply is the main argument for people investing in it, > the whole narrative around bitcoin is based on its finite supply. While it > has its flaws and basically condemns bitcoin to be only used as a store >of > value (and not as a currency), I don't think it's worth questioning it at > this point. > > > >Just my 2 sats. > > > >Giuseppe. > > > A finite supply alone is not enough to give something value, as it must > also be useful in some way. In the case of Bitcoin, various forms of > cryptographic security must all work - and work together - to make Bitcoin > useful. If the only realistic (fair, efficient & proportionate) way to pay > for Bitcoin's security was by having some inflation scheme that violated > the 21 million cap, then agreeing to break the limit would probably be what > makes sense, and in the economic interest of its users and holders. > > There will always be competitive pressures with respect to efficiency, and > both being over-secured and under-secured would be economically inefficient > for a crypto currency, and thereby laving room for a more optimally-secured > competitor to gain ground. Currently there is zero feedback in the Bitcoin > system between what we might think is the optimum amount of security and > what actually exists. There is also zero agreement on how much security > would constitute such an optimum. Figuring out how much security is needed, > or even better, figuring out a way to have a market mechanism to answer > that question, will be an important project. > > Another option, if we were to decide we are over-secured in the short > term, would be to soft-fork in a reduction in the current and near-future > mining rewards, by somehow locking the coins in a contract that deprived > the miner of the full reward, and then using that contract to pay the > rewards out far in the future, should at some point we feel the security > budget was insufficient. Anthony Towns presented a form of this concept in > greater detail at a Scaling Bitcoin conference some years ago. While this > solution, if employed, would only work for some finite amount of time, it > is possible that could give additional decades before the accumulated > security budget was exhausted. > > > Corey > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 10002 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 0:46 ` Billy Tetrud @ 2022-07-07 12:15 ` vjudeu 2022-07-07 14:05 ` Erik Aronesty 1 sibling, 0 replies; 55+ messages in thread From: vjudeu @ 2022-07-07 12:15 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion > The primary mechanism we have to change how much security we have is to change the block size, which changes how much fees miners can collect each block. This isn't a linear thing. Its probably a parabola with a peak, where at that peak, making the block either smaller and larger would both reduce total fees paid. This is because when blocksize is higher, more transactions (and thus more fees) can be collected, but at the same time average fees will be lower. The pull of those two forces should define that parabola. I think it would be better to allow transaction joining, and lock some coins to the future block numbers in case of peaks, to make fees more smoothly, like it is in RSK. So, if there is 0.01 BTC fee for some transaction, it does not matter if that is paid by some single user, or by a million users, one satoshi each, that comes on-chain as a single transaction to serve all of them. > Transaction fees kind of have an association with market value. They will be more important in the future, because when all coins will be mined, then miners will earn nothing, if there will be no on-chain transactions. On the other hand, people will switch to other networks, if on-chain fees will be too high. So, I think the market should adjust fees, and finding the right balance between on-chain and off-chain should be left to the users, just by providing them options like transaction joining. I think such features will be created anyway, if not supported directly, then they will come as no-forks, and if that won't succeed, then I expect some centralized websites will start doing that anyway. On 2022-07-07 02:46:29 user Billy Tetrud <billy.tetrud@gmail•com> wrote: @Corey > Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists. I basically agree with this. The pedantic part of my mind does want to point out that the link between block subsidy and bitcoin's price does actually give somewhat of a feedback loop, in that the higher the price, the more valuable bitcoin is as a whole (at least as viewed by the active market), and therefore the more investment in security is appropriate. However, in the long run when the subsidy reduces to insignificance, we basically lose this link. And even with this link, it's not very direct. Fees retain only a little bit of this behavior, because presumably a more valuable bitcoin is more valuable to spend, but the link to security is very tenuous there. > There is also zero agreement on how much security would constitute such an optimum. This is really step 1. We need to generate consensus on this long before the block subsidy becomes too small. Probably in the next 10-15 years. I wrote a paper that uses a framework for thinking about how much security bitcoin might need. The concept is that we should figure out what bitcoin's bottlenecks are, and figure out the minimum requirements we want to place on running a node based on how many (public) nodes we think we need and what percentage of machines out there are likely to run a node. The goals I chose to explore in that paper are totally up for debate, and I think its an important debate to have. But they are basically a first stab at setting up what we would need to determine optimum security. I would very much appreciate your review of that part of the paper, Corey. > Figuring out how much security is needed, or even better, figuring out a way to have a market mechanism to answer that question, will be an important project. My thoughts on this are that we will need to periodically make some software change to adjust a *target amount of investment in security*, because the components of bitcoin's blockchain security are not all predictable. Many unpredictable things factor into bitcoin's security (eg miner behavior, pools, how many people generally run public nodes on their own, what features require running public nodes, value of bitcoin, etc. The primary mechanism we have to change how much security we have is to change the block size, which changes how much fees miners can collect each block. This isn't a linear thing. Its probably a parabola with a peak, where at that peak, making the block either smaller and larger would both reduce total fees paid. This is because when blocksize is higher, more transactions (and thus more fees) can be collected, but at the same time average fees will be lower. The pull of those two forces should define that parabola. So my suggestion here would be that we should target a certain amount of security and have programmatic adjustments to the block size in order to stay near enough to the parabolic maximum so that we pay miners enough to give us sufficient blockchain security. Conversely, it should also attempt to minimize how much "extra" security we pay for. It would be wasteful to pay 3 times as much for 3 times the security we actually need. Such a thing is a very real form of devaluation that basically represents a tax on bitcoin and users of bitcoin. And its very possible for the position of this parabola to change over time. We could never say with certainty whether we're on one side of the parabola's maximum or the other. This would make it rather complex to track well. Additionally, there's no clear trustless way to determine the market value of bitcoin at any given time, which makes it difficult to maintain this target over time. As the market value of bitcoin changes, that target could become quite inaccurate. This implies that we would need to do periodic adjustments to the target, either through periodic forks or through some other mechanism for changing the target. If there were a good trustless way to determine the market value of bitcoin, we would have to "manually" change this target potentially much less often. Transaction fees kind of have an association with market value. Perhaps some kind of analysis can be done on that to make a reasonable prediction of what market value is based on fees. Or maybe blocks can commit to a market price similarly to how they commit to a timestamp (which is also only verifiable to an approximation and can only be verified close to when it was mined but not eg years later). On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders. So, Paul Sztorc was right again, there are three options: Enormous Block Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. And I think using Merged Mining is the best option. More about that: https://www.truthcoin.info/blog/security-budget-ii-mm/ > Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient. Yes, that's also possible, RSK uses that. And making some kind of soft-fork for that is also possible, but I don't know if miners will agree to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_TRUE". On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >Bitcoin's finite supply is the main argument for people investing in it, the whole narrative around bitcoin is based on its finite supply. While it has its flaws and basically condemns bitcoin to be only used as a store >of value (and not as a currency), I don't think it's worth questioning it at this point. > >Just my 2 sats. > >Giuseppe. A finite supply alone is not enough to give something value, as it must also be useful in some way. In the case of Bitcoin, various forms of cryptographic security must all work - and work together - to make Bitcoin useful. If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders. There will always be competitive pressures with respect to efficiency, and both being over-secured and under-secured would be economically inefficient for a crypto currency, and thereby laving room for a more optimally-secured competitor to gain ground. Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists. There is also zero agreement on how much security would constitute such an optimum. Figuring out how much security is needed, or even better, figuring out a way to have a market mechanism to answer that question, will be an important project. Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient. Anthony Towns presented a form of this concept in greater detail at a Scaling Bitcoin conference some years ago. While this solution, if employed, would only work for some finite amount of time, it is possible that could give additional decades before the accumulated security budget was exhausted. Corey _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 0:46 ` Billy Tetrud 2022-07-07 12:15 ` vjudeu @ 2022-07-07 14:05 ` Erik Aronesty 1 sibling, 0 replies; 55+ messages in thread From: Erik Aronesty @ 2022-07-07 14:05 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 967 bytes --] . > > My thoughts on this are that we will need to periodically make some > software change to adjust a *target amount of investment in security*, > because the > I think perhaps you're underestimating the degree to which utility can be added to the main chain to encourage fees. For example, lightning channel open and close transactions are more valuable, via aggregation, than simple money transfers. The value of higher utility transactions goes up fairly quickly. There is no end of the possibility of fee levels in response to increased utility Other networks have clearly proven the extremes of this, with rampant fees appearing rapidly in response to higher utility levels Because this has already been proven on other networks, we can plan to gradually increase the utility of on-chain transactions in response to reward reductions This should be more than sufficient to offset and maintain sufficient security ... Hence the title of this thread. [-- Attachment #2: Type: text/html, Size: 1646 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-06 11:10 ` vjudeu 2022-07-07 0:46 ` Billy Tetrud @ 2022-07-07 14:10 ` Giuseppe B 2022-07-08 5:03 ` Billy Tetrud 1 sibling, 1 reply; 55+ messages in thread From: Giuseppe B @ 2022-07-07 14:10 UTC (permalink / raw) To: vjudeu; +Cc: Corey Haddad <corey3@gmail•com>, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4206 bytes --] It's the first time I read about the security budget and it definitely sounds scary to me. If it only takes a few million dollars to attack BTC and make it completely unusable for one day, I suppose it's only a matter of time before some hedge fund actually does it, using a short position to profit from the huge panic sell wave and global loss of confidence that would result from it. It seems even cheaper to do than the recent attack to Terra, unless I'm missing something. On Wed, Jul 6, 2022, 1:10 PM <vjudeu@gazeta•pl> wrote: > > If the only realistic (fair, efficient & proportionate) way to pay for > Bitcoin's security was by having some inflation scheme that violated the 21 > million cap, then agreeing to break the limit would probably be what makes > sense, and in the economic interest of its users and holders. > > So, Paul Sztorc was right again, there are three options: Enormous Block > Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come > From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. > And I think using Merged Mining is the best option. More about that: > https://www.truthcoin.info/blog/security-budget-ii-mm/ > > > Another option, if we were to decide we are over-secured in the short > term, would be to soft-fork in a reduction in the current and near-future > mining rewards, by somehow locking the coins in a contract that deprived > the miner of the full reward, and then using that contract to pay the > rewards out far in the future, should at some point we feel the security > budget was insufficient. > > Yes, that's also possible, RSK uses that. And making some kind of > soft-fork for that is also possible, but I don't know if miners will agree > to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY > OP_DROP OP_TRUE". > > On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >Bitcoin's finite supply is the main argument for people investing in it, > the whole narrative around bitcoin is based on its finite supply. While it > has its flaws and basically condemns bitcoin to be only used as a store >of > value (and not as a currency), I don't think it's worth questioning it at > this point. > > > >Just my 2 sats. > > > >Giuseppe. > > > A finite supply alone is not enough to give something value, as it must > also be useful in some way. In the case of Bitcoin, various forms of > cryptographic security must all work - and work together - to make Bitcoin > useful. If the only realistic (fair, efficient & proportionate) way to pay > for Bitcoin's security was by having some inflation scheme that violated > the 21 million cap, then agreeing to break the limit would probably be what > makes sense, and in the economic interest of its users and holders. > > There will always be competitive pressures with respect to efficiency, and > both being over-secured and under-secured would be economically inefficient > for a crypto currency, and thereby laving room for a more optimally-secured > competitor to gain ground. Currently there is zero feedback in the Bitcoin > system between what we might think is the optimum amount of security and > what actually exists. There is also zero agreement on how much security > would constitute such an optimum. Figuring out how much security is needed, > or even better, figuring out a way to have a market mechanism to answer > that question, will be an important project. > > Another option, if we were to decide we are over-secured in the short > term, would be to soft-fork in a reduction in the current and near-future > mining rewards, by somehow locking the coins in a contract that deprived > the miner of the full reward, and then using that contract to pay the > rewards out far in the future, should at some point we feel the security > budget was insufficient. Anthony Towns presented a form of this concept in > greater detail at a Scaling Bitcoin conference some years ago. While this > solution, if employed, would only work for some finite amount of time, it > is possible that could give additional decades before the accumulated > security budget was exhausted. > > > Corey > [-- Attachment #2: Type: text/html, Size: 4965 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 14:10 ` Giuseppe B @ 2022-07-08 5:03 ` Billy Tetrud 0 siblings, 0 replies; 55+ messages in thread From: Billy Tetrud @ 2022-07-08 5:03 UTC (permalink / raw) To: Giuseppe B, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6803 bytes --] @vjudeu > better to allow transaction joining.. to make fees more smoothly I'm not familiar with RSK transaction joining. However, I don't think this addresses the issues Corey brought up - which is that the appropriate amount of security (ie miner revenue) isn't linked with any bitcoin market behavior. It sounds like you're suggesting something that could smooth out the fee market and potentially lower fees, however it doesn't sound like a mechanism that could be used to target a particular security level. > I think the market should adjust fees, and finding the right balance between on-chain and off-chain should be left to the users, just by providing them options like transaction joining The market has an incentive to minimize fees. So I don't see how this would be sufficient if it ends up that miner revenue from fees is too low. @Erik > I think perhaps you're underestimating the degree to which utility can be added to the main chain to encourage fees. It seems you've misinterpreted me to be saying that fees will be too low. I have no idea if fees will be too low or not. And you might be right that fees are likely to remain high enough. However, fees might also remain *too high* which itself could be a problem. As I noted above, since market forces all incentivize driving fees down, what do we do if that force drives it below a sufficient level? How will we know when that happens until we know what the sufficient level of security is (eg in terms of total miner revenue). @Guiseppe > If it only takes a few million dollars to attack BTC and make it completely unusable for one day It would take much more than a few million to 51% attack bitcoin. Bitcoin's blockchain security is primarily based on the capital cost of buying up a massive amount of hashpower. The ongoing maintenance and electricity costs of mining are actually not very relevant to security because all those ongoing costs are directly offset by mining revenues. Its the upfront costs that serve as the primary barrier an attacker must surpass. Acquiring the mining hardware, finding places where energy costs are low enough, setting up the equipment, etc. To do that costs billions of dollars, not millions. On Thu, Jul 7, 2022 at 9:44 AM Giuseppe B via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > It's the first time I read about the security budget and it definitely > sounds scary to me. > If it only takes a few million dollars to attack BTC and make it > completely unusable for one day, I suppose it's only a matter of time > before some hedge fund actually does it, using a short position to profit > from the huge panic sell wave and global loss of confidence that would > result from it. > It seems even cheaper to do than the recent attack to Terra, unless I'm > missing something. > > > On Wed, Jul 6, 2022, 1:10 PM <vjudeu@gazeta•pl> wrote: > >> > If the only realistic (fair, efficient & proportionate) way to pay for >> Bitcoin's security was by having some inflation scheme that violated the 21 >> million cap, then agreeing to break the limit would probably be what makes >> sense, and in the economic interest of its users and holders. >> >> So, Paul Sztorc was right again, there are three options: Enormous Block >> Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come >> From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. >> And I think using Merged Mining is the best option. More about that: >> https://www.truthcoin.info/blog/security-budget-ii-mm/ >> >> > Another option, if we were to decide we are over-secured in the short >> term, would be to soft-fork in a reduction in the current and near-future >> mining rewards, by somehow locking the coins in a contract that deprived >> the miner of the full reward, and then using that contract to pay the >> rewards out far in the future, should at some point we feel the security >> budget was insufficient. >> >> Yes, that's also possible, RSK uses that. And making some kind of >> soft-fork for that is also possible, but I don't know if miners will agree >> to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY >> OP_DROP OP_TRUE". >> >> On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >Bitcoin's finite supply is the main argument for people investing in it, >> the whole narrative around bitcoin is based on its finite supply. While it >> has its flaws and basically condemns bitcoin to be only used as a store >of >> value (and not as a currency), I don't think it's worth questioning it at >> this point. >> > >> >Just my 2 sats. >> > >> >Giuseppe. >> >> >> A finite supply alone is not enough to give something value, as it must >> also be useful in some way. In the case of Bitcoin, various forms of >> cryptographic security must all work - and work together - to make Bitcoin >> useful. If the only realistic (fair, efficient & proportionate) way to pay >> for Bitcoin's security was by having some inflation scheme that violated >> the 21 million cap, then agreeing to break the limit would probably be what >> makes sense, and in the economic interest of its users and holders. >> >> There will always be competitive pressures with respect to efficiency, >> and both being over-secured and under-secured would be economically >> inefficient for a crypto currency, and thereby laving room for a more >> optimally-secured competitor to gain ground. Currently there is zero >> feedback in the Bitcoin system between what we might think is the optimum >> amount of security and what actually exists. There is also zero agreement >> on how much security would constitute such an optimum. Figuring out how >> much security is needed, or even better, figuring out a way to have a >> market mechanism to answer that question, will be an important project. >> >> Another option, if we were to decide we are over-secured in the short >> term, would be to soft-fork in a reduction in the current and near-future >> mining rewards, by somehow locking the coins in a contract that deprived >> the miner of the full reward, and then using that contract to pay the >> rewards out far in the future, should at some point we feel the security >> budget was insufficient. Anthony Towns presented a form of this concept in >> greater detail at a Scaling Bitcoin conference some years ago. While this >> solution, if employed, would only work for some finite amount of time, it >> is possible that could give additional decades before the accumulated >> security budget was exhausted. >> >> >> Corey >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 8447 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-28 3:55 ` Billy Tetrud ` (2 preceding siblings ...) 2022-06-29 10:44 ` Kate Salazar @ 2022-06-30 17:04 ` Erik Aronesty 3 siblings, 0 replies; 55+ messages in thread From: Erik Aronesty @ 2022-06-30 17:04 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 731 bytes --] > > Anyway, demurrage and inflation have identical economic properties. They're >> both a tax on savings. The only difference is the way that tax is >> implemented. > > the fact that a conversation on inflation is continuing without being ignored is probably an indicator that the utility of on-chain services as an incentive to drive fees is a worthwhile consideration. i especially like the proposed and very simple on-chain "payment codes" idea, for example. if a light-touch is used, bitcoin operators can thread the needle allowing utility to grow a bit in response to halvings. i suspect lightning ate a lot of the on-chain fees. future "compression and privacy" protocols, like mweb, should keep this concern in mind. [-- Attachment #2: Type: text/html, Size: 1150 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
[parent not found: <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org>]
* Re: [bitcoin-dev] Bitcoin covenants are inevitable [not found] <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org> @ 2022-07-07 13:24 ` John Carvalho 2022-07-07 14:12 ` Peter Todd 2022-07-07 22:02 ` Corey Haddad 0 siblings, 2 replies; 55+ messages in thread From: John Carvalho @ 2022-07-07 13:24 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 11187 bytes --] Billy, Proof of work and the difficulty adjustment function solve literally everything you are talking about already. Bitcoin does not need active economic governanance by devs or meddlers. Please stop spamming this list with this nonsensical thread. Love, John On Thu, Jul 7, 2022 at 1:00 PM < bitcoin-dev-request@lists•linuxfoundation.org> wrote: > Send bitcoin-dev mailing list submissions to > bitcoin-dev@lists•linuxfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > or, via email, send a message with subject or body 'help' to > bitcoin-dev-request@lists•linuxfoundation.org > > You can reach the person managing the list at > bitcoin-dev-owner@lists•linuxfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bitcoin-dev digest..." > > > Today's Topics: > > 1. Re: Bitcoin covenants are inevitable (Billy Tetrud) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 6 Jul 2022 17:46:15 -0700 > From: Billy Tetrud <billy.tetrud@gmail•com> > To: vjudeu@gazeta•pl, Bitcoin Protocol Discussion > <bitcoin-dev@lists•linuxfoundation.org> > Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable > Message-ID: > <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeCG2= > 3GgLQ@mail•gmail.com> > Content-Type: text/plain; charset="utf-8" > > @Corey > > > Currently there is zero feedback in the Bitcoin system between what we > might think is the optimum amount of security and what actually exists. > > I basically agree with this. The pedantic part of my mind does want to > point out that the link between block subsidy and bitcoin's price does > actually give somewhat of a feedback loop, in that the higher the price, > the more valuable bitcoin is as a whole (at least as viewed by the active > market), and therefore the more investment in security is appropriate. > However, in the long run when the subsidy reduces to insignificance, we > basically lose this link. And even with this link, it's not very direct. > Fees retain only a little bit of this behavior, because presumably a more > valuable bitcoin is more valuable to spend, but the link to security is > very tenuous there. > > > There is also zero agreement on how much security would constitute such > an optimum. > > This is really step 1. We need to generate consensus on this long before > the block subsidy becomes too small. Probably in the next 10-15 years. I > wrote a paper > <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity> > that uses a framework for thinking about how much security bitcoin might > need. The concept is that we should figure out what bitcoin's bottlenecks > are, and figure out the minimum requirements we want to place on running a > node based on how many (public) nodes we think we need and what percentage > of machines out there are likely to run a node. The goals I chose to > explore in that paper are totally up for debate, and I think its an > important debate to have. But they are basically a first stab at setting up > what we would need to determine optimum security. I would very much > appreciate your review of that part of the paper, Corey. > > > Figuring out how much security is needed, or even better, figuring out a > way to have a market mechanism to answer that question, will be an > important project. > > My thoughts on this are that we will need to periodically make some > software change to adjust a *target amount of investment in security*, > because the components of bitcoin's blockchain security are not all > predictable. Many unpredictable things factor into bitcoin's security (eg > miner behavior, pools, how many people generally run public nodes on their > own, what features require running public nodes, value of bitcoin, etc. > > The primary mechanism we have to change how much security we have is to > change the block size, which changes how much fees miners can collect each > block. This isn't a linear thing. Its probably a parabola with a peak, > where at that peak, making the block either smaller and larger would both > reduce total fees paid. This is because when blocksize is higher, more > transactions (and thus more fees) can be collected, but at the same time > average fees will be lower. The pull of those two forces should define that > parabola. > > So my suggestion here would be that we should target a certain amount of > security and have programmatic adjustments to the block size in order to > stay near enough to the parabolic maximum so that we pay miners enough to > give us sufficient blockchain security. Conversely, it should also attempt > to minimize how much "extra" security we pay for. It would be wasteful to > pay 3 times as much for 3 times the security we actually need. Such a thing > is a very real form of devaluation that basically represents a tax on > bitcoin and users of bitcoin. And its very possible for the position of > this parabola to change over time. We could never say with certainty > whether we're on one side of the parabola's maximum or the other. This > would make it rather complex to track well. > > Additionally, there's no clear trustless way to determine the market value > of bitcoin at any given time, which makes it difficult to maintain this > target over time. As the market value of bitcoin changes, that target could > become quite inaccurate. This implies that we would need to do periodic > adjustments to the target, either through periodic forks or through some > other mechanism for changing the target. > > If there were a good trustless way to determine the market value of > bitcoin, we would have to "manually" change this target potentially much > less often. Transaction fees kind of have an association with market value. > Perhaps some kind of analysis can be done on that to make a reasonable > prediction of what market value is based on fees. Or maybe blocks can > commit to a market price similarly to how they commit to a timestamp (which > is also only verifiable to an approximation and can only be verified close > to when it was mined but not eg years later). > > > > > On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > If the only realistic (fair, efficient & proportionate) way to pay for > > Bitcoin's security was by having some inflation scheme that violated the > 21 > > million cap, then agreeing to break the limit would probably be what > makes > > sense, and in the economic interest of its users and holders. > > > > So, Paul Sztorc was right again, there are three options: Enormous Block > > Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come > > From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. > > And I think using Merged Mining is the best option. More about that: > > https://www.truthcoin.info/blog/security-budget-ii-mm/ > > > > > Another option, if we were to decide we are over-secured in the short > > term, would be to soft-fork in a reduction in the current and near-future > > mining rewards, by somehow locking the coins in a contract that deprived > > the miner of the full reward, and then using that contract to pay the > > rewards out far in the future, should at some point we feel the security > > budget was insufficient. > > > > Yes, that's also possible, RSK uses that. And making some kind of > > soft-fork for that is also possible, but I don't know if miners will > agree > > to send some coinbase reward to "<futureBlockNumber> > OP_CHECKLOCKTIMEVERIFY > > OP_DROP OP_TRUE". > > > > On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev < > > bitcoin-dev@lists•linuxfoundation.org> wrote: > > >Bitcoin's finite supply is the main argument for people investing in it, > > the whole narrative around bitcoin is based on its finite supply. While > it > > has its flaws and basically condemns bitcoin to be only used as a store > >of > > value (and not as a currency), I don't think it's worth questioning it at > > this point. > > > > > >Just my 2 sats. > > > > > >Giuseppe. > > > > > > A finite supply alone is not enough to give something value, as it must > > also be useful in some way. In the case of Bitcoin, various forms of > > cryptographic security must all work - and work together - to make > Bitcoin > > useful. If the only realistic (fair, efficient & proportionate) way to > pay > > for Bitcoin's security was by having some inflation scheme that violated > > the 21 million cap, then agreeing to break the limit would probably be > what > > makes sense, and in the economic interest of its users and holders. > > > > There will always be competitive pressures with respect to efficiency, > and > > both being over-secured and under-secured would be economically > inefficient > > for a crypto currency, and thereby laving room for a more > optimally-secured > > competitor to gain ground. Currently there is zero feedback in the > Bitcoin > > system between what we might think is the optimum amount of security and > > what actually exists. There is also zero agreement on how much security > > would constitute such an optimum. Figuring out how much security is > needed, > > or even better, figuring out a way to have a market mechanism to answer > > that question, will be an important project. > > > > Another option, if we were to decide we are over-secured in the short > > term, would be to soft-fork in a reduction in the current and near-future > > mining rewards, by somehow locking the coins in a contract that deprived > > the miner of the full reward, and then using that contract to pay the > > rewards out far in the future, should at some point we feel the security > > budget was insufficient. Anthony Towns presented a form of this concept > in > > greater detail at a Scaling Bitcoin conference some years ago. While this > > solution, if employed, would only work for some finite amount of time, it > > is possible that could give additional decades before the accumulated > > security budget was exhausted. > > > > > > Corey > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220706/d5a48a69/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ------------------------------ > > End of bitcoin-dev Digest, Vol 86, Issue 7 > ****************************************** > -- -- John Carvalho CEO, Synonym.to <http://synonym.to/> Schedule: https://calendly.com/bitcoinerrorlog Chat: https://t.me/bitcoinerrorlog Social: https://twitter.com/bitcoinerrorlog [-- Attachment #2: Type: text/html, Size: 15179 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 13:24 ` John Carvalho @ 2022-07-07 14:12 ` Peter Todd 2022-07-07 16:24 ` Eric Voskuil 2022-07-07 22:06 ` Anthony Towns 2022-07-07 22:02 ` Corey Haddad 1 sibling, 2 replies; 55+ messages in thread From: Peter Todd @ 2022-07-07 14:12 UTC (permalink / raw) To: John Carvalho, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1933 bytes --] On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote: > Billy, > > Proof of work and the difficulty adjustment function solve literally > everything you are talking about already. Unfortunately you are quite wrong: the difficulty adjustment function merely adjusts for changes in the amount of observable, non-51%-attacking, hashing power. In the event of a chain split, the difficulty adjustment function does nothing; against a 51% attacker, the difficulty adjustment does nothing; against a censor, the difficulty adjustment does nothing. We should not imbue real technology with magical qualities. > Bitcoin does not need active economic governanance by devs or meddlers. Yes, active governance would definitely be an exploitable mechanism. On the other hand, the status quo of the block reward eventually going away entirely is obviously a risky state change too. > > > There is also zero agreement on how much security would constitute such > > an optimum. > > > > This is really step 1. We need to generate consensus on this long before > > the block subsidy becomes too small. Probably in the next 10-15 years. I > > wrote a paper The fact of the matter is that the present amount of security is about 1.7% of the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also already an amount low enough that it's much smaller than economic volatility. Obviously 0% is too small. There's zero reason to stress about finding an "optimal" amount. An amount low enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5% would probably be fine; 0.1% would probably be fine. Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on savings; 0.1% works out to be 7.2% These are all amounts that are likely to be dwarfed by economic shifts. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 14:12 ` Peter Todd @ 2022-07-07 16:24 ` Eric Voskuil 2022-07-07 17:37 ` Erik Aronesty 2022-07-07 22:06 ` Anthony Towns 1 sibling, 1 reply; 55+ messages in thread From: Eric Voskuil @ 2022-07-07 16:24 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion; +Cc: John Carvalho [-- Attachment #1: Type: text/plain, Size: 4267 bytes --] > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote: >> Billy, >> >> Proof of work and the difficulty adjustment function solve literally >> everything you are talking about already. > > Unfortunately you are quite wrong: the difficulty adjustment function merely > adjusts for changes in the amount of observable, non-51%-attacking, hashing > power. In the event of a chain split, the difficulty adjustment function does > nothing; against a 51% attacker, the difficulty adjustment does nothing; > against a censor, the difficulty adjustment does nothing. Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, possibly to min difficulty if all non-censors stop mining and with all censors collaborating (one miner). Yet as difficulty falls, so does the cost of countering the censor. At min difficulty everyone can CPU mine again. Given the presumption that fees rise on unconfirmed transactions, there is inherent economic incentive to countering at any level of difficulty. Consequently the censor is compelled to subsidize the loss resulting from forgoing higher fee transactions that are incentivizing its competition. With falling difficulty this incentive is compounded. Comparisons of security in different scenarios presume a consistent level of demand. If that demand is insufficient to offset the censor’s subsidy, there is no security in any scenario. Given that the block subsidy (inflation) is paid equally to censoring and non-censoring miners, it offers no security against censorship whatsoever. Trading fee-based block reward for inflation-based is simply trading censorship resistance for the presumption of double-spend security. But of course, a censor can double spend profitably in any scenario where the double spend value (to the censor) exceeds that of blocks orphaned (as the censor earns 100% of all block rewards). Banks and state monies offer reasonable double spend security. Not sure that’s a trade worth making. It’s not clear to me that Satoshi understood this relation. I’ve seen no indication of it. However the decision to phase out subsidy, once a sufficient number of units (to assure divisibility) had been issued, is what transitions Bitcoin from a censorable to a censorship resistant money. If one does not believe there is sufficient demand for such a money, there is no way to reconcile that belief with a model of censorship resistance. > We should not imbue real technology with magical qualities. Precisely. It is economic forces (people), not technology, that provide security. e >> Bitcoin does not need active economic governanance by devs or meddlers. > > Yes, active governance would definitely be an exploitable mechanism. On the > other hand, the status quo of the block reward eventually going away entirely > is obviously a risky state change too. > >>>> There is also zero agreement on how much security would constitute such >>> an optimum. >>> >>> This is really step 1. We need to generate consensus on this long before >>> the block subsidy becomes too small. Probably in the next 10-15 years. I >>> wrote a paper > > The fact of the matter is that the present amount of security is about 1.7% of > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also > already an amount low enough that it's much smaller than economic volatility. > > Obviously 0% is too small. > > There's zero reason to stress about finding an "optimal" amount. An amount low > enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5% > would probably be fine; 0.1% would probably be fine. > > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on > savings; 0.1% works out to be 7.2% > > These are all amounts that are likely to be dwarfed by economic shifts. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: signature.asc --] [-- Type: application/octet-stream, Size: 833 bytes --] -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmLG6dcACgkQLly11TVR LzfHRQ//dCSdHeUKwvpEN4kUI5n8riCjOzFbzf7DtGjZ8mr5JKk99Y5dvNSt43E0 x5B+fp0jt6NPoQkQ9d/gMChdloyeCpIzI0q5t6upVWWIejE/lE109OhaZJxW2/Fm 8iDZjPbx0agvzxktmsEYoOQ7UHzEz1J78GrhlE3uuR80QY/8YwNvL6348Ycxgzi9 0XdZX5yf9grl1gAJldx5icTHIo0hNEpWQZye2SnLda9NrLPSKgE5UcDSIEIBJBfv F5HELWV5Gf0F/ruxC70kXUMx+qlIk/Nao6bvEy31YkYStA3GlWo5ZmnuyvdnQ4yr JuZwQJw/R2RiiOYsK8TMbB7kXwYD3Gzt6QW+bhXpty3K0sKT/70FT2VE+NdMXFNT EqxJK9AYuUK3WTLZSOda9Ny/eBK3RDMkWbXdxMXAPOsW86BC3j5+KzzSSmIVpU0j URaqcE0XfXWBvCz+LFH8Mvkxi7xS9kro/XXXzLVO6ZSrpw8z5MmMPy6HdruWZbp2 VpLcaANBFxGUrFbh/zvMJB03vAU8peRtfwWodn9ynWymb38DlZsBZyg2uejnKjYv ghPGxPdAEXbm/zSWmnVU9jhN/0+7DA7+r0pk8+l6t4iOdqu46l/K8CRxkwKlIOSA bcTYYeZthY7iTEABS+RNAx/vzP54bxywpPg9HGy/zKmKCT/sDpE= =I1Dy -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 16:24 ` Eric Voskuil @ 2022-07-07 17:37 ` Erik Aronesty 2022-07-07 19:57 ` Eric Voskuil 0 siblings, 1 reply; 55+ messages in thread From: Erik Aronesty @ 2022-07-07 17:37 UTC (permalink / raw) To: Eric Voskuil, Bitcoin Protocol Discussion; +Cc: John Carvalho [-- Attachment #1: Type: text/plain, Size: 5329 bytes --] > > We should not imbue real technology with magical qualities. > Precisely. It is economic forces (people), not technology, that provide security. Yes, and these forces don't prevent double-spend / 51% attacks if the amounts involved are greater than the incentives. In addition to "utility", lowering the block size could help prevent this issue as well... increasing fee pressure and double-spend security while reducing the burden on node operators. Changes to inflation are, very likely, off the table. On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev > wrote: > >> Billy, > >> > >> Proof of work and the difficulty adjustment function solve literally > >> everything you are talking about already. > > > > Unfortunately you are quite wrong: the difficulty adjustment function > merely > > adjusts for changes in the amount of observable, non-51%-attacking, > hashing > > power. In the event of a chain split, the difficulty adjustment function > does > > nothing; against a 51% attacker, the difficulty adjustment does nothing; > > against a censor, the difficulty adjustment does nothing. > > Consider falling hash rate due to a perpetual 51% attack. Difficulty > falls, possibly to min difficulty if all non-censors stop mining and with > all censors collaborating (one miner). Yet as difficulty falls, so does the > cost of countering the censor. At min difficulty everyone can CPU mine > again. > > Given the presumption that fees rise on unconfirmed transactions, there is > inherent economic incentive to countering at any level of difficulty. > Consequently the censor is compelled to subsidize the loss resulting from > forgoing higher fee transactions that are incentivizing its competition. > > With falling difficulty this incentive is compounded. > > Comparisons of security in different scenarios presume a consistent level > of demand. If that demand is insufficient to offset the censor’s subsidy, > there is no security in any scenario. > > Given that the block subsidy (inflation) is paid equally to censoring and > non-censoring miners, it offers no security against censorship whatsoever. > Trading fee-based block reward for inflation-based is simply trading > censorship resistance for the presumption of double-spend security. But of > course, a censor can double spend profitably in any scenario where the > double spend value (to the censor) exceeds that of blocks orphaned (as the > censor earns 100% of all block rewards). > > Banks and state monies offer reasonable double spend security. Not sure > that’s a trade worth making. > > It’s not clear to me that Satoshi understood this relation. I’ve seen no > indication of it. However the decision to phase out subsidy, once a > sufficient number of units (to assure divisibility) had been issued, is > what transitions Bitcoin from a censorable to a censorship resistant money. > If one does not believe there is sufficient demand for such a money, there > is no way to reconcile that belief with a model of censorship resistance. > > > We should not imbue real technology with magical qualities. > > Precisely. It is economic forces (people), not technology, that provide > security. > > e > > >> Bitcoin does not need active economic governanance by devs or meddlers. > > > > Yes, active governance would definitely be an exploitable mechanism. On > the > > other hand, the status quo of the block reward eventually going away > entirely > > is obviously a risky state change too. > > > >>>> There is also zero agreement on how much security would constitute > such > >>> an optimum. > >>> > >>> This is really step 1. We need to generate consensus on this long > before > >>> the block subsidy becomes too small. Probably in the next 10-15 years. > I > >>> wrote a paper > > > > The fact of the matter is that the present amount of security is about > 1.7% of > > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% > is also > > already an amount low enough that it's much smaller than economic > volatility. > > > > Obviously 0% is too small. > > > > There's zero reason to stress about finding an "optimal" amount. An > amount low > > enough to be easily affordable, but non-zero, is fine. 1% would be fine; > 0.5% > > would probably be fine; 0.1% would probably be fine. > > > > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% > tax on > > savings; 0.1% works out to be 7.2% > > > > These are all amounts that are likely to be dwarfed by economic shifts. > > > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > _______________________________________________ > > 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 > [-- Attachment #2: Type: text/html, Size: 6753 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 17:37 ` Erik Aronesty @ 2022-07-07 19:57 ` Eric Voskuil 2022-07-07 21:11 ` Erik Aronesty 0 siblings, 1 reply; 55+ messages in thread From: Eric Voskuil @ 2022-07-07 19:57 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion, John Carvalho [-- Attachment #1: Type: text/plain, Size: 7282 bytes --] It’s not clear how reducing block size changes the fee aspect of the block reward. Assuming half the space implies twice the fee per avg tx the reward remains constant. Any additional cost of processing more or less bytes would not matter, because of course this is just a cost that gets nulled out by difficulty — average profit (net income) is the cost of capital. The reason for smaller vs. larger blocks is to ensure that individuals can afford to validate. That’s a threshold criteria. Given unlimited size blocks, miners would still have to fix a point in time to mine, gathering as much fee as they can optimize in some time period presumably less than 10 minutes. The produces a limit to transaction volume, yet neither reward nor profit would be affected given the above assumptions. The difference would be in a tradeoff of per tx fee against the threshold. Given Moore’s Law, that threshold is constantly decreasing, which will make it cheaper over time for more individuals to validate. But the difference for miners for smaller blocks is largely inconsequential relative to their other costs. Increasing demand is the only thing that increases double spend security (and censorship resistance assuming fee-based reward). With rising demand there is rising overall hash rate, despite block reward and profit remaining constant. This makes the cost of attempting to orphan a block higher, therefore lowering the depth/time requirement implied to secure a given tx amount. These are the two factors, demand and time. Less demand implies more time to secure a given amount against double spend, and also implies a lower cost to subsidize a censorship regime. But the latter requires a differential in reward between the censor and non-censoring miners. While this could be paid in side fees, that is a significant anonymity issue. e > On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32•com> wrote: > > > > > We should not imbue real technology with magical qualities. > > > Precisely. It is economic forces (people), not technology, that provide security. > > Yes, and these forces don't prevent double-spend / 51% attacks if the amounts involved are greater than the incentives. > > In addition to "utility", lowering the block size could help prevent this issue as well... increasing fee pressure and double-spend security while reducing the burden on node operators. > > Changes to inflation are, very likely, off the table. > > > >> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> >> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> > >> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote: >> >> Billy, >> >> >> >> Proof of work and the difficulty adjustment function solve literally >> >> everything you are talking about already. >> > >> > Unfortunately you are quite wrong: the difficulty adjustment function merely >> > adjusts for changes in the amount of observable, non-51%-attacking, hashing >> > power. In the event of a chain split, the difficulty adjustment function does >> > nothing; against a 51% attacker, the difficulty adjustment does nothing; >> > against a censor, the difficulty adjustment does nothing. >> >> Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, possibly to min difficulty if all non-censors stop mining and with all censors collaborating (one miner). Yet as difficulty falls, so does the cost of countering the censor. At min difficulty everyone can CPU mine again. >> >> Given the presumption that fees rise on unconfirmed transactions, there is inherent economic incentive to countering at any level of difficulty. Consequently the censor is compelled to subsidize the loss resulting from forgoing higher fee transactions that are incentivizing its competition. >> >> With falling difficulty this incentive is compounded. >> >> Comparisons of security in different scenarios presume a consistent level of demand. If that demand is insufficient to offset the censor’s subsidy, there is no security in any scenario. >> >> Given that the block subsidy (inflation) is paid equally to censoring and non-censoring miners, it offers no security against censorship whatsoever. Trading fee-based block reward for inflation-based is simply trading censorship resistance for the presumption of double-spend security. But of course, a censor can double spend profitably in any scenario where the double spend value (to the censor) exceeds that of blocks orphaned (as the censor earns 100% of all block rewards). >> >> Banks and state monies offer reasonable double spend security. Not sure that’s a trade worth making. >> >> It’s not clear to me that Satoshi understood this relation. I’ve seen no indication of it. However the decision to phase out subsidy, once a sufficient number of units (to assure divisibility) had been issued, is what transitions Bitcoin from a censorable to a censorship resistant money. If one does not believe there is sufficient demand for such a money, there is no way to reconcile that belief with a model of censorship resistance. >> >> > We should not imbue real technology with magical qualities. >> >> Precisely. It is economic forces (people), not technology, that provide security. >> >> e >> >> >> Bitcoin does not need active economic governanance by devs or meddlers. >> > >> > Yes, active governance would definitely be an exploitable mechanism. On the >> > other hand, the status quo of the block reward eventually going away entirely >> > is obviously a risky state change too. >> > >> >>>> There is also zero agreement on how much security would constitute such >> >>> an optimum. >> >>> >> >>> This is really step 1. We need to generate consensus on this long before >> >>> the block subsidy becomes too small. Probably in the next 10-15 years. I >> >>> wrote a paper >> > >> > The fact of the matter is that the present amount of security is about 1.7% of >> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also >> > already an amount low enough that it's much smaller than economic volatility. >> > >> > Obviously 0% is too small. >> > >> > There's zero reason to stress about finding an "optimal" amount. An amount low >> > enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5% >> > would probably be fine; 0.1% would probably be fine. >> > >> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on >> > savings; 0.1% works out to be 7.2% >> > >> > These are all amounts that are likely to be dwarfed by economic shifts. >> > >> > -- >> > https://petertodd.org 'peter'[:-1]@petertodd.org >> > _______________________________________________ >> > 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 [-- Attachment #2: Type: text/html, Size: 9318 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 19:57 ` Eric Voskuil @ 2022-07-07 21:11 ` Erik Aronesty 2022-07-08 0:28 ` Eric Voskuil 0 siblings, 1 reply; 55+ messages in thread From: Erik Aronesty @ 2022-07-07 21:11 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion, John Carvalho [-- Attachment #1: Type: text/plain, Size: 8166 bytes --] The relationship between block size and fees is not remotely linear. In a restricted environment, the fee rewards are much higher. **the ones moving more sats will win the top spots and will pay as much as is reasonable** Smaller blocks produce better security for the network both in validation, and in fees. Without a bidding war for space, everyone can post 1 SAT/byte With a bidding war for space, larger transactions will pay much higher rates. There have been a number of papers written on this but you can concoct a trivial example to prove it. On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric@voskuil•org> wrote: > It’s not clear how reducing block size changes the fee aspect of the block > reward. Assuming half the space implies twice the fee per avg tx the > reward remains constant. > > Any additional cost of processing more or less bytes would not matter, > because of course this is just a cost that gets nulled out by difficulty — > average profit (net income) is the cost of capital. > > The reason for smaller vs. larger blocks is to ensure that individuals can > afford to validate. That’s a threshold criteria. > > Given unlimited size blocks, miners would still have to fix a point in > time to mine, gathering as much fee as they can optimize in some time > period presumably less than 10 minutes. The produces a limit to transaction > volume, yet neither reward nor profit would be affected given the above > assumptions. The difference would be in a tradeoff of per tx fee against > the threshold. > > Given Moore’s Law, that threshold is constantly decreasing, which will > make it cheaper over time for more individuals to validate. But the > difference for miners for smaller blocks is largely inconsequential > relative to their other costs. > > Increasing demand is the only thing that increases double spend security > (and censorship resistance assuming fee-based reward). With rising demand > there is rising overall hash rate, despite block reward and profit > remaining constant. This makes the cost of attempting to orphan a block > higher, therefore lowering the depth/time requirement implied to secure a > given tx amount. > > These are the two factors, demand and time. Less demand implies more time > to secure a given amount against double spend, and also implies a lower > cost to subsidize a censorship regime. But the latter requires a > differential in reward between the censor and non-censoring miners. While > this could be paid in side fees, that is a significant anonymity issue. > > e > > On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32•com> wrote: > > > > > We should not imbue real technology with magical qualities. > > > Precisely. It is economic forces (people), not technology, that provide > security. > > Yes, and these forces don't prevent double-spend / 51% attacks if the > amounts involved are greater than the incentives. > > In addition to "utility", lowering the block size could help prevent this > issue as well... increasing fee pressure and double-spend security while > reducing the burden on node operators. > > Changes to inflation are, very likely, off the table. > > > > On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> >> >> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> > >> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via >> bitcoin-dev wrote: >> >> Billy, >> >> >> >> Proof of work and the difficulty adjustment function solve literally >> >> everything you are talking about already. >> > >> > Unfortunately you are quite wrong: the difficulty adjustment function >> merely >> > adjusts for changes in the amount of observable, non-51%-attacking, >> hashing >> > power. In the event of a chain split, the difficulty adjustment >> function does >> > nothing; against a 51% attacker, the difficulty adjustment does nothing; >> > against a censor, the difficulty adjustment does nothing. >> >> Consider falling hash rate due to a perpetual 51% attack. Difficulty >> falls, possibly to min difficulty if all non-censors stop mining and with >> all censors collaborating (one miner). Yet as difficulty falls, so does the >> cost of countering the censor. At min difficulty everyone can CPU mine >> again. >> >> Given the presumption that fees rise on unconfirmed transactions, there >> is inherent economic incentive to countering at any level of difficulty. >> Consequently the censor is compelled to subsidize the loss resulting from >> forgoing higher fee transactions that are incentivizing its competition. >> >> With falling difficulty this incentive is compounded. >> >> Comparisons of security in different scenarios presume a consistent level >> of demand. If that demand is insufficient to offset the censor’s subsidy, >> there is no security in any scenario. >> >> Given that the block subsidy (inflation) is paid equally to censoring and >> non-censoring miners, it offers no security against censorship whatsoever. >> Trading fee-based block reward for inflation-based is simply trading >> censorship resistance for the presumption of double-spend security. But of >> course, a censor can double spend profitably in any scenario where the >> double spend value (to the censor) exceeds that of blocks orphaned (as the >> censor earns 100% of all block rewards). >> >> Banks and state monies offer reasonable double spend security. Not sure >> that’s a trade worth making. >> >> It’s not clear to me that Satoshi understood this relation. I’ve seen no >> indication of it. However the decision to phase out subsidy, once a >> sufficient number of units (to assure divisibility) had been issued, is >> what transitions Bitcoin from a censorable to a censorship resistant money. >> If one does not believe there is sufficient demand for such a money, there >> is no way to reconcile that belief with a model of censorship resistance. >> >> > We should not imbue real technology with magical qualities. >> >> Precisely. It is economic forces (people), not technology, that provide >> security. >> >> e >> >> >> Bitcoin does not need active economic governanance by devs or meddlers. >> > >> > Yes, active governance would definitely be an exploitable mechanism. On >> the >> > other hand, the status quo of the block reward eventually going away >> entirely >> > is obviously a risky state change too. >> > >> >>>> There is also zero agreement on how much security would constitute >> such >> >>> an optimum. >> >>> >> >>> This is really step 1. We need to generate consensus on this long >> before >> >>> the block subsidy becomes too small. Probably in the next 10-15 >> years. I >> >>> wrote a paper >> > >> > The fact of the matter is that the present amount of security is about >> 1.7% of >> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% >> is also >> > already an amount low enough that it's much smaller than economic >> volatility. >> > >> > Obviously 0% is too small. >> > >> > There's zero reason to stress about finding an "optimal" amount. An >> amount low >> > enough to be easily affordable, but non-zero, is fine. 1% would be >> fine; 0.5% >> > would probably be fine; 0.1% would probably be fine. >> > >> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a >> 31% tax on >> > savings; 0.1% works out to be 7.2% >> > >> > These are all amounts that are likely to be dwarfed by economic shifts. >> > >> > -- >> > https://petertodd.org 'peter'[:-1]@petertodd.org >> > _______________________________________________ >> > 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 >> > [-- Attachment #2: Type: text/html, Size: 10327 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 21:11 ` Erik Aronesty @ 2022-07-08 0:28 ` Eric Voskuil 2022-07-08 4:59 ` vjudeu 2022-07-08 15:14 ` Erik Aronesty 0 siblings, 2 replies; 55+ messages in thread From: Eric Voskuil @ 2022-07-08 0:28 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion, John Carvalho [-- Attachment #1: Type: text/plain, Size: 10729 bytes --] Value is subjective, though a constraint of 1tx per 10 minutes seems unlikey to create a fee of 5000x that of 5000tx. This is of course why I stated my assumption. Yet this simple example should make clear that at some point a reduction in confirmation rate reduces reward. Otherwise a rate of zero implies infinite reward. You cannot support the blanket statement (and absent any assumption) that lower confirmation rates produce “much higher fees” or “better security”. What you call a “bidding war” is merely market pricing, as it occurs with any good. People *always* will pay as much as they will pay. This is tautological. What you cannot say is how much more someone will pay at any given time for any given good, until they have done it. And I’m pretty sure Bitcoin hasn’t done it. You cannot prove what the price of anything will be, nor can any “papers”. The absurdity of S2F should have clearly demonstrated that by now. Value is an individual human preference. If everyone pays 1 sat, then either miners are profitable at 1 sat, or these people are not getting confirmed (economic rationality always assumed). The assumption of 1 sat txs filling blocks is based on a disproportionately high subsidy. A subsidy of 50btc would imply somewhere in the neighborhood of $200 per tx in fees today, and as $680. As that falls, fees will continue to keep miners at the same profit level. If demand does not rise to compensate (as it always has) then hash rate will fall. Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin is a market money. Like gold it is produced at market cost. Yet it will prevent Bitcoin from achieving any meaningful level of censorship resistance. This of course should make people look closely at such arguments. Of course, once you have a censor, block space gets really small for those who want to resist the censor. Then of course only fees can offset the censorship. Without fee-based tx confirmation (for anonymity), and/or with a disproportionate subsidy going to the censor, a censor can operate profitably and indefinitely (under the assumption of constant demand). There is no reason to assume demand for censored txs wouldn’t even increase, given the white market blessing which so many seem to want. But there is of course no real issue here. Simply fork off an inflation coin and test your theory. I mean, that’s the only way it can happen anyway. e > On Jul 7, 2022, at 14:11, Erik Aronesty <erik@q32•com> wrote: > > > The relationship between block size and fees is not remotely linear. In a restricted environment, the fee rewards are much higher. > > **the ones moving more sats will win the top spots and will pay as much as is reasonable** > > Smaller blocks produce better security for the network both in validation, and in fees. > > Without a bidding war for space, everyone can post 1 SAT/byte > > With a bidding war for space, larger transactions will pay much higher rates. There have been a number of papers written on this but you can concoct a trivial example to prove it. > > >> On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric@voskuil•org> wrote: >> It’s not clear how reducing block size changes the fee aspect of the block reward. Assuming half the space implies twice the fee per avg tx the reward remains constant. >> >> Any additional cost of processing more or less bytes would not matter, because of course this is just a cost that gets nulled out by difficulty — average profit (net income) is the cost of capital. >> >> The reason for smaller vs. larger blocks is to ensure that individuals can afford to validate. That’s a threshold criteria. >> >> Given unlimited size blocks, miners would still have to fix a point in time to mine, gathering as much fee as they can optimize in some time period presumably less than 10 minutes. The produces a limit to transaction volume, yet neither reward nor profit would be affected given the above assumptions. The difference would be in a tradeoff of per tx fee against the threshold. >> >> Given Moore’s Law, that threshold is constantly decreasing, which will make it cheaper over time for more individuals to validate. But the difference for miners for smaller blocks is largely inconsequential relative to their other costs. >> >> Increasing demand is the only thing that increases double spend security (and censorship resistance assuming fee-based reward). With rising demand there is rising overall hash rate, despite block reward and profit remaining constant. This makes the cost of attempting to orphan a block higher, therefore lowering the depth/time requirement implied to secure a given tx amount. >> >> These are the two factors, demand and time. Less demand implies more time to secure a given amount against double spend, and also implies a lower cost to subsidize a censorship regime. But the latter requires a differential in reward between the censor and non-censoring miners. While this could be paid in side fees, that is a significant anonymity issue. >> >> e >> >>>> On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32•com> wrote: >>>> >>> >>> > > We should not imbue real technology with magical qualities. >>> >>> > Precisely. It is economic forces (people), not technology, that provide security. >>> >>> Yes, and these forces don't prevent double-spend / 51% attacks if the amounts involved are greater than the incentives. >>> >>> In addition to "utility", lowering the block size could help prevent this issue as well... increasing fee pressure and double-spend security while reducing the burden on node operators. >>> >>> Changes to inflation are, very likely, off the table. >>> >>> >>> >>>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >>>> >>>> >>>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >>>> > >>>> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote: >>>> >> Billy, >>>> >> >>>> >> Proof of work and the difficulty adjustment function solve literally >>>> >> everything you are talking about already. >>>> > >>>> > Unfortunately you are quite wrong: the difficulty adjustment function merely >>>> > adjusts for changes in the amount of observable, non-51%-attacking, hashing >>>> > power. In the event of a chain split, the difficulty adjustment function does >>>> > nothing; against a 51% attacker, the difficulty adjustment does nothing; >>>> > against a censor, the difficulty adjustment does nothing. >>>> >>>> Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, possibly to min difficulty if all non-censors stop mining and with all censors collaborating (one miner). Yet as difficulty falls, so does the cost of countering the censor. At min difficulty everyone can CPU mine again. >>>> >>>> Given the presumption that fees rise on unconfirmed transactions, there is inherent economic incentive to countering at any level of difficulty. Consequently the censor is compelled to subsidize the loss resulting from forgoing higher fee transactions that are incentivizing its competition. >>>> >>>> With falling difficulty this incentive is compounded. >>>> >>>> Comparisons of security in different scenarios presume a consistent level of demand. If that demand is insufficient to offset the censor’s subsidy, there is no security in any scenario. >>>> >>>> Given that the block subsidy (inflation) is paid equally to censoring and non-censoring miners, it offers no security against censorship whatsoever. Trading fee-based block reward for inflation-based is simply trading censorship resistance for the presumption of double-spend security. But of course, a censor can double spend profitably in any scenario where the double spend value (to the censor) exceeds that of blocks orphaned (as the censor earns 100% of all block rewards). >>>> >>>> Banks and state monies offer reasonable double spend security. Not sure that’s a trade worth making. >>>> >>>> It’s not clear to me that Satoshi understood this relation. I’ve seen no indication of it. However the decision to phase out subsidy, once a sufficient number of units (to assure divisibility) had been issued, is what transitions Bitcoin from a censorable to a censorship resistant money. If one does not believe there is sufficient demand for such a money, there is no way to reconcile that belief with a model of censorship resistance. >>>> >>>> > We should not imbue real technology with magical qualities. >>>> >>>> Precisely. It is economic forces (people), not technology, that provide security. >>>> >>>> e >>>> >>>> >> Bitcoin does not need active economic governanance by devs or meddlers. >>>> > >>>> > Yes, active governance would definitely be an exploitable mechanism. On the >>>> > other hand, the status quo of the block reward eventually going away entirely >>>> > is obviously a risky state change too. >>>> > >>>> >>>> There is also zero agreement on how much security would constitute such >>>> >>> an optimum. >>>> >>> >>>> >>> This is really step 1. We need to generate consensus on this long before >>>> >>> the block subsidy becomes too small. Probably in the next 10-15 years. I >>>> >>> wrote a paper >>>> > >>>> > The fact of the matter is that the present amount of security is about 1.7% of >>>> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also >>>> > already an amount low enough that it's much smaller than economic volatility. >>>> > >>>> > Obviously 0% is too small. >>>> > >>>> > There's zero reason to stress about finding an "optimal" amount. An amount low >>>> > enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5% >>>> > would probably be fine; 0.1% would probably be fine. >>>> > >>>> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on >>>> > savings; 0.1% works out to be 7.2% >>>> > >>>> > These are all amounts that are likely to be dwarfed by economic shifts. >>>> > >>>> > -- >>>> > https://petertodd.org 'peter'[:-1]@petertodd.org >>>> > _______________________________________________ >>>> > 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 [-- Attachment #2: Type: text/html, Size: 14493 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-08 0:28 ` Eric Voskuil @ 2022-07-08 4:59 ` vjudeu 2022-07-08 7:26 ` John Carvalho 2022-07-08 15:14 ` Erik Aronesty 1 sibling, 1 reply; 55+ messages in thread From: vjudeu @ 2022-07-08 4:59 UTC (permalink / raw) To: Eric Voskuil <eric@voskuil•org>, Bitcoin Protocol Discussion, Erik Aronesty Cc: Bitcoin Protocol Discussion, John Carvalho > Simply fork off an inflation coin and test your theory. I mean, that’s the only way it can happen anyway. That would be an altcoin. But it can be done in a simpler way: we have 21 million coins. It doesn't matter if it is 21 million, if it is 100 million, or if it is in some normalized range from 0 to 1, where you can always know, what fraction of the total supply you have. So, if the total supply is constant, then it is all about proportions. And that means, you can create some system on top of Bitcoin, that would move coins from users to miners. It is all about that: if all coins are mined, then they can move only if users will move them. So if you want to change that, it is all about encouraging them to put their coins in some evil Lightning channel, when they will lose their coins over time. That's how inflation works. So, imagine some evil channel, where you can put for example 0.01 BTC, and have a time-based fee, so you will pay 1000 satoshis per day. Guess what: 1000 days, and your coins are gone! That means, if anyone want to test inflation, it is possible right here and right now. Good luck to convince people to use your inflationary system in a non-obfuscated way, because that's how it truly looks like: if you double coin supply, you can reach the same by halving all amounts. On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: Value is subjective, though a constraint of 1tx per 10 minutes seems unlikey to create a fee of 5000x that of 5000tx. This is of course why I stated my assumption. Yet this simple example should make clear that at some point a reduction in confirmation rate reduces reward. Otherwise a rate of zero implies infinite reward. You cannot support the blanket statement (and absent any assumption) that lower confirmation rates produce “much higher fees” or “better security”. What you call a “bidding war” is merely market pricing, as it occurs with any good. People *always* will pay as much as they will pay. This is tautological. What you cannot say is how much more someone will pay at any given time for any given good, until they have done it. And I’m pretty sure Bitcoin hasn’t done it. You cannot prove what the price of anything will be, nor can any “papers”. The absurdity of S2F should have clearly demonstrated that by now. Value is an individual human preference. If everyone pays 1 sat, then either miners are profitable at 1 sat, or these people are not getting confirmed (economic rationality always assumed). The assumption of 1 sat txs filling blocks is based on a disproportionately high subsidy. A subsidy of 50btc would imply somewhere in the neighborhood of $200 per tx in fees today, and as $680. As that falls, fees will continue to keep miners at the same profit level. If demand does not rise to compensate (as it always has) then hash rate will fall. Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin is a market money. Like gold it is produced at market cost. Yet it will prevent Bitcoin from achieving any meaningful level of censorship resistance. This of course should make people look closely at such arguments. Of course, once you have a censor, block space gets really small for those who want to resist the censor. Then of course only fees can offset the censorship. Without fee-based tx confirmation (for anonymity), and/or with a disproportionate subsidy going to the censor, a censor can operate profitably and indefinitely (under the assumption of constant demand). There is no reason to assume demand for censored txs wouldn’t even increase, given the white market blessing which so many seem to want. But there is of course no real issue here. Simply fork off an inflation coin and test your theory. I mean, that’s the only way it can happen anyway. e On Jul 7, 2022, at 14:11, Erik Aronesty <erik@q32•com> wrote: The relationship between block size and fees is not remotely linear. In a restricted environment, the fee rewards are much higher. **the ones moving more sats will win the top spots and will pay as much as is reasonable** Smaller blocks produce better security for the network both in validation, and in fees. Without a bidding war for space, everyone can post 1 SAT/byte With a bidding war for space, larger transactions will pay much higher rates. There have been a number of papers written on this but you can concoct a trivial example to prove it. On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric@voskuil•org> wrote: It’s not clear how reducing block size changes the fee aspect of the block reward. Assuming half the space implies twice the fee per avg tx the reward remains constant. Any additional cost of processing more or less bytes would not matter, because of course this is just a cost that gets nulled out by difficulty — average profit (net income) is the cost of capital. The reason for smaller vs. larger blocks is to ensure that individuals can afford to validate. That’s a threshold criteria. Given unlimited size blocks, miners would still have to fix a point in time to mine, gathering as much fee as they can optimize in some time period presumably less than 10 minutes. The produces a limit to transaction volume, yet neither reward nor profit would be affected given the above assumptions. The difference would be in a tradeoff of per tx fee against the threshold. Given Moore’s Law, that threshold is constantly decreasing, which will make it cheaper over time for more individuals to validate. But the difference for miners for smaller blocks is largely inconsequential relative to their other costs. Increasing demand is the only thing that increases double spend security (and censorship resistance assuming fee-based reward). With rising demand there is rising overall hash rate, despite block reward and profit remaining constant. This makes the cost of attempting to orphan a block higher, therefore lowering the depth/time requirement implied to secure a given tx amount. These are the two factors, demand and time. Less demand implies more time to secure a given amount against double spend, and also implies a lower cost to subsidize a censorship regime. But the latter requires a differential in reward between the censor and non-censoring miners. While this could be paid in side fees, that is a significant anonymity issue. e On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32•com> wrote: > > We should not imbue real technology with magical qualities. > Precisely. It is economic forces (people), not technology, that provide security. Yes, and these forces don't prevent double-spend / 51% attacks if the amounts involved are greater than the incentives. In addition to "utility", lowering the block size could help prevent this issue as well... increasing fee pressure and double-spend security while reducing the burden on node operators. Changes to inflation are, very likely, off the table. On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote: >> Billy, >> >> Proof of work and the difficulty adjustment function solve literally >> everything you are talking about already. > > Unfortunately you are quite wrong: the difficulty adjustment function merely > adjusts for changes in the amount of observable, non-51%-attacking, hashing > power. In the event of a chain split, the difficulty adjustment function does > nothing; against a 51% attacker, the difficulty adjustment does nothing; > against a censor, the difficulty adjustment does nothing. Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, possibly to min difficulty if all non-censors stop mining and with all censors collaborating (one miner). Yet as difficulty falls, so does the cost of countering the censor. At min difficulty everyone can CPU mine again. Given the presumption that fees rise on unconfirmed transactions, there is inherent economic incentive to countering at any level of difficulty. Consequently the censor is compelled to subsidize the loss resulting from forgoing higher fee transactions that are incentivizing its competition. With falling difficulty this incentive is compounded. Comparisons of security in different scenarios presume a consistent level of demand. If that demand is insufficient to offset the censor’s subsidy, there is no security in any scenario. Given that the block subsidy (inflation) is paid equally to censoring and non-censoring miners, it offers no security against censorship whatsoever. Trading fee-based block reward for inflation-based is simply trading censorship resistance for the presumption of double-spend security. But of course, a censor can double spend profitably in any scenario where the double spend value (to the censor) exceeds that of blocks orphaned (as the censor earns 100% of all block rewards). Banks and state monies offer reasonable double spend security. Not sure that’s a trade worth making. It’s not clear to me that Satoshi understood this relation. I’ve seen no indication of it. However the decision to phase out subsidy, once a sufficient number of units (to assure divisibility) had been issued, is what transitions Bitcoin from a censorable to a censorship resistant money. If one does not believe there is sufficient demand for such a money, there is no way to reconcile that belief with a model of censorship resistance. > We should not imbue real technology with magical qualities. Precisely. It is economic forces (people), not technology, that provide security. e >> Bitcoin does not need active economic governanance by devs or meddlers. > > Yes, active governance would definitely be an exploitable mechanism. On the > other hand, the status quo of the block reward eventually going away entirely > is obviously a risky state change too. > >>>> There is also zero agreement on how much security would constitute such >>> an optimum. >>> >>> This is really step 1. We need to generate consensus on this long before >>> the block subsidy becomes too small. Probably in the next 10-15 years. I >>> wrote a paper > > The fact of the matter is that the present amount of security is about 1.7% of > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also > already an amount low enough that it's much smaller than economic volatility. > > Obviously 0% is too small. > > There's zero reason to stress about finding an "optimal" amount. An amount low > enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5% > would probably be fine; 0.1% would probably be fine. > > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on > savings; 0.1% works out to be 7.2% > > These are all amounts that are likely to be dwarfed by economic shifts. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-08 4:59 ` vjudeu @ 2022-07-08 7:26 ` John Carvalho 0 siblings, 0 replies; 55+ messages in thread From: John Carvalho @ 2022-07-08 7:26 UTC (permalink / raw) To: vjudeu; +Cc: Eric Voskuil <eric@voskuil•org>, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 13563 bytes --] vjudeu@gazeta•pl, what you describe is not possible without a hard fork, just like Eric said. There is no atomic way to move Bitcoin off of Bitcoin. You can use Bitcoin txns, or you can use trust/custody, or you can make a shitcoin. There is no way to actually divide or transfer sats to another network. This talk of inflation is absurd and forced and ignores all understanding of Bitcoin and economic primitives. You would all do better to listen to Eric and appreciate him taking the time to elaborate. In the end, I will reiterate. Proof of work and the difficulty adjustment scheme already solve all of these issues. When blockspace demand increases, fees increase, more miners mine, security goes up. Thus any theoretical supply increase would have the opposite effect. All of these arguments for inflation amount to "That restaurant is too popular, nobody goes there anymore." If people are using Bitcoin, miners will mine. If all Bitcoin users are hodling only, then demand is gone, and miners will leave. It is elegant. Stop trying to fix Bitcoin, it isn't broken. -- John Carvalho CEO, Synonym.to <http://synonym.to/> On Fri, Jul 8, 2022 at 5:59 AM <vjudeu@gazeta•pl> wrote: > > Simply fork off an inflation coin and test your theory. I mean, that’s > the only way it can happen anyway. > > That would be an altcoin. But it can be done in a simpler way: we have 21 > million coins. It doesn't matter if it is 21 million, if it is 100 million, > or if it is in some normalized range from 0 to 1, where you can always > know, what fraction of the total supply you have. So, if the total supply > is constant, then it is all about proportions. And that means, you can > create some system on top of Bitcoin, that would move coins from users to > miners. It is all about that: if all coins are mined, then they can move > only if users will move them. So if you want to change that, it is all > about encouraging them to put their coins in some evil Lightning channel, > when they will lose their coins over time. That's how inflation works. > > So, imagine some evil channel, where you can put for example 0.01 BTC, and > have a time-based fee, so you will pay 1000 satoshis per day. Guess what: > 1000 days, and your coins are gone! That means, if anyone want to test > inflation, it is possible right here and right now. Good luck to convince > people to use your inflationary system in a non-obfuscated way, because > that's how it truly looks like: if you double coin supply, you can reach > the same by halving all amounts. > > > On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > Value is subjective, though a constraint of 1tx per 10 minutes seems > unlikey to create a fee of 5000x that of 5000tx. This is of course why I > stated my assumption. Yet this simple example should make clear that at > some point a reduction in confirmation rate reduces reward. Otherwise a > rate of zero implies infinite reward. > > > You cannot support the blanket statement (and absent any assumption) that > lower confirmation rates produce “much higher fees” or “better security”. > > > What you call a “bidding war” is merely market pricing, as it occurs with > any good. People *always* will pay as much as they will pay. This is > tautological. What you cannot say is how much more someone will pay at any > given time for any given good, until they have done it. And I’m pretty sure > Bitcoin hasn’t done it. > > > You cannot prove what the price of anything will be, nor can any “papers”. > The absurdity of S2F should have clearly demonstrated that by now. Value is > an individual human preference. > > > If everyone pays 1 sat, then either miners are profitable at 1 sat, or > these people are not getting confirmed (economic rationality always > assumed). > > > The assumption of 1 sat txs filling blocks is based on a > disproportionately high subsidy. A subsidy of 50btc would imply somewhere > in the neighborhood of $200 per tx in fees today, and as $680. As that > falls, fees will continue to keep miners at the same profit level. If > demand does not rise to compensate (as it always has) then hash rate will > fall. > > > Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin > is a market money. Like gold it is produced at market cost. Yet it will > prevent Bitcoin from achieving any meaningful level of censorship > resistance. This of course should make people look closely at such > arguments. > > > Of course, once you have a censor, block space gets really small for those > who want to resist the censor. Then of course only fees can offset the > censorship. Without fee-based tx confirmation (for anonymity), and/or with > a disproportionate subsidy going to the censor, a censor can operate > profitably and indefinitely (under the assumption of constant demand). > There is no reason to assume demand for censored txs wouldn’t even > increase, given the white market blessing which so many seem to want. > > > But there is of course no real issue here. Simply fork off an inflation > coin and test your theory. I mean, that’s the only way it can happen anyway. > > > e > > > On Jul 7, 2022, at 14:11, Erik Aronesty <erik@q32•com> wrote: > > > > The relationship between block size and fees is not remotely linear. In > a restricted environment, the fee rewards are much higher. > > > **the ones moving more sats will win the top spots and will pay as much as > is reasonable** > > > Smaller blocks produce better security for the network both in validation, > and in fees. > > > Without a bidding war for space, everyone can post 1 SAT/byte > > > With a bidding war for space, larger transactions will pay much higher > rates. There have been a number of papers written on this but you can > concoct a trivial example to prove it. > > > > > On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric@voskuil•org> wrote: > > > > It’s not clear how reducing block size changes the fee aspect of the block > reward. Assuming half the space implies twice the fee per avg tx the reward > remains constant. > > > Any additional cost of processing more or less bytes would not matter, > because of course this is just a cost that gets nulled out by difficulty — > average profit (net income) is the cost of capital. > > > The reason for smaller vs. larger blocks is to ensure that individuals can > afford to validate. That’s a threshold criteria. > > > Given unlimited size blocks, miners would still have to fix a point in > time to mine, gathering as much fee as they can optimize in some time > period presumably less than 10 minutes. The produces a limit to transaction > volume, yet neither reward nor profit would be affected given the above > assumptions. The difference would be in a tradeoff of per tx fee against > the threshold. > > > Given Moore’s Law, that threshold is constantly decreasing, which will > make it cheaper over time for more individuals to validate. But the > difference for miners for smaller blocks is largely inconsequential > relative to their other costs. > > > Increasing demand is the only thing that increases double spend security > (and censorship resistance assuming fee-based reward). With rising demand > there is rising overall hash rate, despite block reward and profit > remaining constant. This makes the cost of attempting to orphan a block > higher, therefore lowering the depth/time requirement implied to secure a > given tx amount. > > > These are the two factors, demand and time. Less demand implies more time > to secure a given amount against double spend, and also implies a lower > cost to subsidize a censorship regime. But the latter requires a > differential in reward between the censor and non-censoring miners. While > this could be paid in side fees, that is a significant anonymity issue. > > > e > > > On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32•com> wrote: > > > > > > We should not imbue real technology with magical qualities. > > > > Precisely. It is economic forces (people), not technology, that provide > security. > > > > Yes, and these forces don't prevent double-spend / 51% attacks if the > amounts involved are greater than the incentives. > > > In addition to "utility", lowering the block size could help prevent this > issue as well... increasing fee pressure and double-spend security while > reducing the burden on node operators. > > > Changes to inflation are, very likely, off the table. > > > > > > > On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev > wrote: > >> Billy, > >> > >> Proof of work and the difficulty adjustment function solve literally > >> everything you are talking about already. > > > > Unfortunately you are quite wrong: the difficulty adjustment function > merely > > adjusts for changes in the amount of observable, non-51%-attacking, > hashing > > power. In the event of a chain split, the difficulty adjustment function > does > > nothing; against a 51% attacker, the difficulty adjustment does nothing; > > against a censor, the difficulty adjustment does nothing. > > Consider falling hash rate due to a perpetual 51% attack. Difficulty > falls, possibly to min difficulty if all non-censors stop mining and with > all censors collaborating (one miner). Yet as difficulty falls, so does the > cost of countering the censor. At min difficulty everyone can CPU mine > again. > > Given the presumption that fees rise on unconfirmed transactions, there is > inherent economic incentive to countering at any level of difficulty. > Consequently the censor is compelled to subsidize the loss resulting from > forgoing higher fee transactions that are incentivizing its competition. > > With falling difficulty this incentive is compounded. > > Comparisons of security in different scenarios presume a consistent level > of demand. If that demand is insufficient to offset the censor’s subsidy, > there is no security in any scenario. > > Given that the block subsidy (inflation) is paid equally to censoring and > non-censoring miners, it offers no security against censorship whatsoever. > Trading fee-based block reward for inflation-based is simply trading > censorship resistance for the presumption of double-spend security. But of > course, a censor can double spend profitably in any scenario where the > double spend value (to the censor) exceeds that of blocks orphaned (as the > censor earns 100% of all block rewards). > > Banks and state monies offer reasonable double spend security. Not sure > that’s a trade worth making. > > It’s not clear to me that Satoshi understood this relation. I’ve seen no > indication of it. However the decision to phase out subsidy, once a > sufficient number of units (to assure divisibility) had been issued, is > what transitions Bitcoin from a censorable to a censorship resistant money. > If one does not believe there is sufficient demand for such a money, there > is no way to reconcile that belief with a model of censorship resistance. > > > We should not imbue real technology with magical qualities. > > Precisely. It is economic forces (people), not technology, that provide > security. > > e > > >> Bitcoin does not need active economic governanance by devs or meddlers. > > > > Yes, active governance would definitely be an exploitable mechanism. On > the > > other hand, the status quo of the block reward eventually going away > entirely > > is obviously a risky state change too. > > > >>>> There is also zero agreement on how much security would constitute > such > >>> an optimum. > >>> > >>> This is really step 1. We need to generate consensus on this long > before > >>> the block subsidy becomes too small. Probably in the next 10-15 years. > I > >>> wrote a paper > > > > The fact of the matter is that the present amount of security is about > 1.7% of > > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% > is also > > already an amount low enough that it's much smaller than economic > volatility. > > > > Obviously 0% is too small. > > > > There's zero reason to stress about finding an "optimal" amount. An > amount low > > enough to be easily affordable, but non-zero, is fine. 1% would be fine; > 0.5% > > would probably be fine; 0.1% would probably be fine. > > > > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% > tax on > > savings; 0.1% works out to be 7.2% > > > > These are all amounts that are likely to be dwarfed by economic shifts. > > > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > _______________________________________________ > > 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 > > [-- Attachment #2: Type: text/html, Size: 16281 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-08 0:28 ` Eric Voskuil 2022-07-08 4:59 ` vjudeu @ 2022-07-08 15:14 ` Erik Aronesty 2022-07-14 4:55 ` Billy Tetrud 1 sibling, 1 reply; 55+ messages in thread From: Erik Aronesty @ 2022-07-08 15:14 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion, John Carvalho [-- Attachment #1: Type: text/plain, Size: 2978 bytes --] On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil <eric@voskuil•org> wrote: > Value is subjective, though a constraint of 1tx per 10 minutes seems > unlikey to create a fee of 5000x that of 5000tx. This is of course why I > stated my assumption. Yet this simple example should make clear that at > some point a reduction in confirmation rate reduces reward. Otherwise a > rate of zero implies infinite reward. > Like i said, it's not linear. So no, a rate of 0 does not imply an infinite reward. A number of papers on the Nash equilibrium of mining rewards and block size have been written. There are block sizes that are optimal for fees, and they obviously not zero, where the system collapses, and they are obviously not infinite... where all bidders pay 1 sat/byte. > > You cannot support the blanket statement (and absent any assumption) that > lower confirmation rates produce “much higher fees” or “better security”. > You can look at the research and the history of zero-size block impact on fees and see that this is true. > > What you call a “bidding war” is merely market pricing, as it occurs with > any good. People *always* will pay as much as they will pay. This is > tautological. What you cannot say is how much more someone will pay at any > given time for any given good, until they have done it. And I’m pretty sure > Bitcoin hasn’t done it. > If there is infinite supply, then there is zero value. Infinite blocks have lower fees. This is impossible to argue against. > You cannot prove what the price of anything will be, nor can any “papers”. > The absurdity of S2F should have clearly demonstrated that by now. Value is > an individual human preference. > A trivial example: block sizeof 10, and 10 people want to transact, all can bid 1 SAT/byte, 2 tx are moving 100 mil sats, the other 8 are moving 10 mil sats. Block size of 2. Now the two transactions moving 100 mil sats will bid, they can easily pay 400 sats/byte. You can show, from history, that when block sizes are more constrained, due to the mining of zero byte blocks, total fees were higher. People will always pay for "next confirm" if the cost of that is very reasonable (less than 0.1%). > > If everyone pays 1 sat, then either miners are profitable at 1 sat, or > these people are not getting confirmed (economic rationality always > assumed). > Yes, and if miners are not profitable at 1 sat, then they will not mine, and the hash rate will drop. And this reduces the security of the coin. Hashrate is an index of security. But there is of course no real issue here. Simply fork off an inflation > coin and test your theory. I mean, that’s the only way it can happen anyway. > I would argue inflation is not a good solution. Instead, being cautious about block-compressing tech, like mweb, and being more aggressive about fee-driving tech, makes more sense . [-- Attachment #2: Type: text/html, Size: 4745 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-08 15:14 ` Erik Aronesty @ 2022-07-14 4:55 ` Billy Tetrud 0 siblings, 0 replies; 55+ messages in thread From: Billy Tetrud @ 2022-07-14 4:55 UTC (permalink / raw) To: Erik Aronesty, Bitcoin Protocol Discussion; +Cc: John Carvalho [-- Attachment #1: Type: text/plain, Size: 6631 bytes --] @Peter Todd > The fact of the matter is that the present amount of security is about 1.7% of the total coin supply/year That's on the order of what I calculated <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#analysis-of-various-consensus-algorithms>: ~0.5%. I'm curious where the 1.7% number comes from. Perhaps much of the difference in our two numbers likely comes from me incorporating what I call the "Economic Mining Monopoly Attack" <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#economic-mining-monopoly-attack> which effectively cuts the security in half. > There's zero reason to stress about finding an "optimal" amount. An amount low enough to be easily affordable, but non-zero, is fine. That's fair. What I mean is that we should estimate an optimal value to some degree of accuracy. It doesn't have to be super accurate. But too low and we could have a bad time. Too high and its a deadweight cost forever (which increases fees, slows adoption, and causes an inflation-like devaluation force on bitcoin, which has all the familiar market distorting effects, albeit to a much smaller degree than we're used to). In any case, we need to come to an accurate enough estimate of how much is enough security so that we ensure we're above that amount. > These are all amounts that are likely to be dwarfed by economic shifts. Perhaps you're right. Regardless, its certainly an improvement to what we've had the last 100 years. @Erik Voskuil > You cannot support the blanket statement (and absent any assumption) that lower confirmation rates produce “much higher fees” or “better security”. I can in fact support it. The theory of supply and demand supports it. Well, depending on what you mean by "fees". Reducing the block size will certainly increase average fees/vbyte. Whether it increases total fees collected by miners (and thus lead to "better security") is another story - a story that depends on the demand dynamics in the market. It could very well be that reducing the blocksize reduces the number of transactions by a higher proportion than fees go up. As we have seen in past periods of high traffic tho, total fees go up *quite* a lot. So it seems pretty clear to me that constraining the block size would very likely increase total fees collected by miners, at least for the near future. @Carvalho > I will reiterate. Proof of work and the difficulty adjustment scheme already solve all of these issues You haven't addressed any of the comments that disagree with you above. You didn't address any of my comments originally. You are simply claiming things without any logical support. If you want to be a respectable part of this conversation, I'd recommend explaining yourself much more thoroughly. > That restaurant is too popular, nobody goes there anymore. If you could feed 100,000 people with 1 entire from a restaurant, your restaurant might not make enough money to survive despite feeding the entire country. That's what the lightning network does for/to bitcoin. We need to make sure the restaurant can afford to staff itself despite massive increases in food-use efficiency. On Fri, Jul 8, 2022 at 12:32 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil <eric@voskuil•org> wrote: > >> Value is subjective, though a constraint of 1tx per 10 minutes seems >> unlikey to create a fee of 5000x that of 5000tx. This is of course why I >> stated my assumption. Yet this simple example should make clear that at >> some point a reduction in confirmation rate reduces reward. Otherwise a >> rate of zero implies infinite reward. >> > > Like i said, it's not linear. So no, a rate of 0 does not imply an > infinite reward. A number of papers on the Nash equilibrium of mining > rewards and block size have been written. There are block sizes that > are optimal for fees, and they obviously not zero, where the system > collapses, and they are obviously not infinite... where all bidders pay 1 > sat/byte. > > >> >> You cannot support the blanket statement (and absent any assumption) that >> lower confirmation rates produce “much higher fees” or “better security”. >> > > You can look at the research and the history of zero-size block impact on > fees and see that this is true. > > > >> >> What you call a “bidding war” is merely market pricing, as it occurs with >> any good. People *always* will pay as much as they will pay. This is >> tautological. What you cannot say is how much more someone will pay at any >> given time for any given good, until they have done it. And I’m pretty sure >> Bitcoin hasn’t done it. >> > > If there is infinite supply, then there is zero value. Infinite blocks > have lower fees. This is impossible to argue against. > > >> You cannot prove what the price of anything will be, nor can any >> “papers”. The absurdity of S2F should have clearly demonstrated that by >> now. Value is an individual human preference. >> > > A trivial example: block sizeof 10, and 10 people want to transact, all > can bid 1 SAT/byte, 2 tx are moving 100 mil sats, the other 8 are moving 10 > mil sats. Block size of 2. Now the two transactions moving 100 mil sats > will bid, they can easily pay 400 sats/byte. > > You can show, from history, that when block sizes are more constrained, > due to the mining of zero byte blocks, total fees were higher. People > will always pay for "next confirm" if the cost of that is very reasonable > (less than 0.1%). > >> >> If everyone pays 1 sat, then either miners are profitable at 1 sat, or >> these people are not getting confirmed (economic rationality always >> assumed). >> > > Yes, and if miners are not profitable at 1 sat, then they will not mine, > and the hash rate will drop. And this reduces the security of the coin. > Hashrate is an index of security. > > But there is of course no real issue here. Simply fork off an inflation >> coin and test your theory. I mean, that’s the only way it can happen anyway. >> > > I would argue inflation is not a good solution. Instead, being cautious > about block-compressing tech, like mweb, and being more aggressive about > fee-driving tech, makes more sense . > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 9397 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 14:12 ` Peter Todd 2022-07-07 16:24 ` Eric Voskuil @ 2022-07-07 22:06 ` Anthony Towns 1 sibling, 0 replies; 55+ messages in thread From: Anthony Towns @ 2022-07-07 22:06 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion; +Cc: John Carvalho On Thu, Jul 07, 2022 at 10:12:41AM -0400, Peter Todd via bitcoin-dev wrote: > We should not imbue real technology with magical qualities. That's much more fun if you invert it, and take it as a mission statement. Advance technology sufficiently! > The fact of the matter is that the present amount of security is about 1.7% of > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also > already an amount low enough that it's much smaller than economic volatility. > > Obviously 0% is too small. > > There's zero reason to stress about finding an "optimal" amount. An amount low > enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5% > would probably be fine; 0.1% would probably be fine. For comparison, 0.1% of 21M BTC per annum is 0.4 BTC per block, which is about 50sat/vb if blocks are 800kvB on average. Doing that purely with fees seems within the ballpark of feasibility to me. 50sat/vb for a 200vb tx (roughly the size of a 2-in, 2-out p2wpkh/p2tr tx) is $2 at $20k/BTC, $10 at $100k/BTC, $100 at $1M/BTC etc. If the current block reward of ~1.7% pa of 19M at a price of $20k funds the current level of mining activity, then you'd expect a similar level of mining activity as today with reward at 0.1% pa of 21M at a price of ~$310k. Going by the halving schedule, the block subsidy alone will remain above 0.1% of supply until we hit the 0.39 BTC/block regime, in 2036, at which point it drops to ~0.0986% annualised. (I guess you could extend that by four years if you're willing to assume more than 1.5% of bitcoin supply has been permanently lost) Cheers, aj ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-07 13:24 ` John Carvalho 2022-07-07 14:12 ` Peter Todd @ 2022-07-07 22:02 ` Corey Haddad 1 sibling, 0 replies; 55+ messages in thread From: Corey Haddad @ 2022-07-07 22:02 UTC (permalink / raw) To: John Carvalho, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1941 bytes --] >Billy, > >Proof of work and the difficulty adjustment function solve literally everything you are talking about already. >Bitcoin does not need active economic governanance by devs or meddlers. >Please stop spamming this list with this nonsensical thread. > >Love, >John Sorry John, but this is a divisive comment. You are the spammer here. While it is unclear why you are trying to harm the Bitcoin development process, you are, and anyone reading this should know that. Proof of work and the difficulty adjustment have no capability to ensure that the amount of security is adequate or reasonable.The only proximate incentive-compatible feedback mechanisms would either make the security too low or too high, and not approach 'just right'. If the price falls, and the hashrate goes down, people might conclude that Bitcoin is looking vulnerable to attack and therefore sell, which would be a negative feedback loop. Conversely, if a price rise leads to a higher hashrate, people might think Bitcoin is now even more secure than before and buy, causing a positive feedback loop. These are not stable equilibria. PoW and the difficulty adjustments hold block times at 10 minutes, and by the same token, keep coin issuance roughly on schedule. They have also turned out to - thus far - have charted a reasonable (albeit predetermined) course through the various hash-based attacks that lurk out there in the world. Without any sort or restorative force that guides the security budget to an optimum, or even towards a reasonable range, we have to recognize that we are just lucky that Satoshi got it right. When navigating via dead reckoning, the uncertainty accumulates over time and distance. Eventually external corrections are needed. We absolutely need to keep apprised of the current and future threats, assess Bitcoin's resilience in the face of those threats, and when needed make changes to ensure Bitcoin remains secure. Corey [-- Attachment #2: Type: text/html, Size: 2327 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* [bitcoin-dev] Bitcoin covenants are inevitable
@ 2022-06-03 18:39 alicexbt
2022-06-04 0:29 ` micaroni
` (2 more replies)
0 siblings, 3 replies; 55+ messages in thread
From: alicexbt @ 2022-06-03 18:39 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Note: This email is an opinion and not an attack on bitcoin
Covenants on bitcoin will eventually be implemented with a soft fork. CTV is the easiest and best possible way OP_TX looks good as well. Apart from the technical merits, covenants will improve a few other things:
- Developers can build interesting projects with real demand in market.
- Students learn Sapio and not just solidity.
- Better tooling could be available for application developers.
- Maybe we see bitcoin developer hackathons in different countries.
- Demand for block space might increase, it wont be just exchanges and coinjoin.
- Funding of bitcoin developers and projects might improve. Wont need to convince a few people for grants.
**Why covenants are not contentious?**
Some people may write paragraphs about CTV being contentious, spread misinformation and do all types of drama, politics etc. on social media but there are zero technical NACKs for CTV. We have discussed other covenant proposals in detail on mailing list and IRC meetings with an open minded approach.
All the developers that participated in the discussion are either okay with CTV or OP_TX or covenants in general.
**How and when should covenants be implemented in Bitcoin?**
I don't think we should wait for years anticipating a proposal that everyone will agree on or argue for years to pretend changes are hard in Bitcoin. We should improve the review process for soft fork BIPs and share honest opinions with agreement, disagreement on technical merits.
I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything else being used if that improves Bitcoin. Covenants implemented in Bitcoin before the next cycle would provide opportunity for developers to build interesting things during the bear market. Ossification supporters also believe there is some window that will close soon, maybe doing changes considering each case individually will be a better approach. CTV is not a rushed soft fork, less people followed the research and it was not mentioned on social media repeatedly by the respected developers like other soft forks.
/dev/fd0
Sent with Proton Mail secure email.
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-03 18:39 alicexbt @ 2022-06-04 0:29 ` micaroni 2022-06-04 18:43 ` Jorge Timón 2022-07-19 4:44 ` Anthony Towns 2 siblings, 0 replies; 55+ messages in thread From: micaroni @ 2022-06-04 0:29 UTC (permalink / raw) To: alicexbt, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2568 bytes --] Totally agree. I couldn't agree more. On Fri, Jun 3, 2022 at 3:44 PM alicexbt via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Note: This email is an opinion and not an attack on bitcoin > > Covenants on bitcoin will eventually be implemented with a soft fork. CTV > is the easiest and best possible way OP_TX looks good as well. Apart from > the technical merits, covenants will improve a few other things: > > - Developers can build interesting projects with real demand in market. > - Students learn Sapio and not just solidity. > - Better tooling could be available for application developers. > - Maybe we see bitcoin developer hackathons in different countries. > - Demand for block space might increase, it wont be just exchanges and > coinjoin. > - Funding of bitcoin developers and projects might improve. Wont need to > convince a few people for grants. > > **Why covenants are not contentious?** > > Some people may write paragraphs about CTV being contentious, spread > misinformation and do all types of drama, politics etc. on social media but > there are zero technical NACKs for CTV. We have discussed other covenant > proposals in detail on mailing list and IRC meetings with an open minded > approach. > > All the developers that participated in the discussion are either okay > with CTV or OP_TX or covenants in general. > > **How and when should covenants be implemented in Bitcoin?** > > I don't think we should wait for years anticipating a proposal that > everyone will agree on or argue for years to pretend changes are hard in > Bitcoin. We should improve the review process for soft fork BIPs and share > honest opinions with agreement, disagreement on technical merits. > > I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything > else being used if that improves Bitcoin. Covenants implemented in Bitcoin > before the next cycle would provide opportunity for developers to build > interesting things during the bear market. Ossification supporters also > believe there is some window that will close soon, maybe doing changes > considering each case individually will be a better approach. CTV is not a > rushed soft fork, less people followed the research and it was not > mentioned on social media repeatedly by the respected developers like other > soft forks. > > /dev/fd0 > > > Sent with Proton Mail secure email. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3263 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-03 18:39 alicexbt 2022-06-04 0:29 ` micaroni @ 2022-06-04 18:43 ` Jorge Timón 2022-06-05 4:18 ` alicexbt 2022-07-19 4:44 ` Anthony Towns 2 siblings, 1 reply; 55+ messages in thread From: Jorge Timón @ 2022-06-04 18:43 UTC (permalink / raw) To: alicexbt, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2721 bytes --] "Some people say CTV is contentious, but they're spreading misinformation"? Really? Seriously? Come on, guys, we can do better than nina jankovich and the "fact checkers". Please, rise the bar. On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Note: This email is an opinion and not an attack on bitcoin > > Covenants on bitcoin will eventually be implemented with a soft fork. CTV > is the easiest and best possible way OP_TX looks good as well. Apart from > the technical merits, covenants will improve a few other things: > > - Developers can build interesting projects with real demand in market. > - Students learn Sapio and not just solidity. > - Better tooling could be available for application developers. > - Maybe we see bitcoin developer hackathons in different countries. > - Demand for block space might increase, it wont be just exchanges and > coinjoin. > - Funding of bitcoin developers and projects might improve. Wont need to > convince a few people for grants. > > **Why covenants are not contentious?** > > Some people may write paragraphs about CTV being contentious, spread > misinformation and do all types of drama, politics etc. on social media but > there are zero technical NACKs for CTV. We have discussed other covenant > proposals in detail on mailing list and IRC meetings with an open minded > approach. > > All the developers that participated in the discussion are either okay > with CTV or OP_TX or covenants in general. > > **How and when should covenants be implemented in Bitcoin?** > > I don't think we should wait for years anticipating a proposal that > everyone will agree on or argue for years to pretend changes are hard in > Bitcoin. We should improve the review process for soft fork BIPs and share > honest opinions with agreement, disagreement on technical merits. > > I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything > else being used if that improves Bitcoin. Covenants implemented in Bitcoin > before the next cycle would provide opportunity for developers to build > interesting things during the bear market. Ossification supporters also > believe there is some window that will close soon, maybe doing changes > considering each case individually will be a better approach. CTV is not a > rushed soft fork, less people followed the research and it was not > mentioned on social media repeatedly by the respected developers like other > soft forks. > > /dev/fd0 > > > Sent with Proton Mail secure email. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3417 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-04 18:43 ` Jorge Timón @ 2022-06-05 4:18 ` alicexbt 2022-06-08 3:51 ` Billy Tetrud 2022-06-09 0:03 ` Ryan Grant 0 siblings, 2 replies; 55+ messages in thread From: alicexbt @ 2022-06-05 4:18 UTC (permalink / raw) To: Bitcoin Protocol Discussion Hi Jorge, Misinformation is false or inaccurate information, especially that which is deliberately intended to deceive. A combination of 'misleading' and 'information'. Here are a few examples and I am sure I missed a lot of others but its difficult for me to keep a track of everything: 1) Sapio is open source and everything mentioned in tweet is false: https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602 2) Personal attacks on author of BIP 119 with false information: https://nitter.net/s3cp256k1/status/1521238634111770624 3) Andreas Antonopoulos shared false things about CTV and explained by Ryan in this email: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html 4) Misleading things shared in these emails by Michael Folkson: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html 5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin and L2. I replied in this email: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html 6) Social media influencers like Peter McCormack tweeted they don't understand BIP 119 but its an attack (this was even retweeted by developers like Peter Todd): https://nitter.net/PeterMcCormack/status/1521253840963653632 7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine: https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained 8) There were lies and misinformation about BIP 119 on social media according to this Bitcoin Magazine article: https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it 9) John Carvalho tweeting false things: https://nitter.net/BitcoinErrorLog/status/1468599535538745359 https://nitter.net/BitcoinErrorLog/status/1522652884218822658 https://nitter.net/BitcoinErrorLog/status/1442554615967354880 https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog) 10) Greg Maxwell responding to misinformation related to BIP 119 but adding false things in the comments: https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/ I am not surprised by your email but it would be better if the people who are interested in reviewing BIP 119 could raise the bar and not share misleading information. /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón <jtimon@jtimon•cc> wrote: > "Some people say CTV is contentious, but they're spreading misinformation"? Really? Seriously?Come on, guys, we can do better than nina jankovich and the "fact checkers". > Please, rise the bar. > On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > Note: This email is an opinion and not an attack on bitcoin > > > > Covenants on bitcoin will eventually be implemented with a soft fork. CTV is the easiest and best possible way OP_TX looks good as well. Apart from the technical merits, covenants will improve a few other things: > > > > - Developers can build interesting projects with real demand in market. > > - Students learn Sapio and not just solidity. > > - Better tooling could be available for application developers. > > - Maybe we see bitcoin developer hackathons in different countries. > > - Demand for block space might increase, it wont be just exchanges and coinjoin. > > - Funding of bitcoin developers and projects might improve. Wont need to convince a few people for grants. > > > > **Why covenants are not contentious?** > > > > Some people may write paragraphs about CTV being contentious, spread misinformation and do all types of drama, politics etc. on social media but there are zero technical NACKs for CTV. We have discussed other covenant proposals in detail on mailing list and IRC meetings with an open minded approach. > > > > All the developers that participated in the discussion are either okay with CTV or OP_TX or covenants in general. > > > > **How and when should covenants be implemented in Bitcoin?** > > > > I don't think we should wait for years anticipating a proposal that everyone will agree on or argue for years to pretend changes are hard in Bitcoin. We should improve the review process for soft fork BIPs and share honest opinions with agreement, disagreement on technical merits. > > > > I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything else being used if that improves Bitcoin. Covenants implemented in Bitcoin before the next cycle would provide opportunity for developers to build interesting things during the bear market. Ossification supporters also believe there is some window that will close soon, maybe doing changes considering each case individually will be a better approach. CTV is not a rushed soft fork, less people followed the research and it was not mentioned on social media repeatedly by the respected developers like other soft forks. > > > > /dev/fd0 > > > > > > Sent with Proton Mail secure email. > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-05 4:18 ` alicexbt @ 2022-06-08 3:51 ` Billy Tetrud 2022-06-08 9:22 ` Jorge Timón 2022-06-09 0:03 ` Ryan Grant 1 sibling, 1 reply; 55+ messages in thread From: Billy Tetrud @ 2022-06-08 3:51 UTC (permalink / raw) To: alicexbt, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6604 bytes --] Wholeheartedly agree with you alicexbt. There are no technical issues that have been shown that I'm aware of. Once the non-technical folks have time to discuss it and realize that, I'm hopeful things will move forward. Perhaps we can learn from this and figure out how to better catch the attention of the larger bitcoin community for important changes without alarming them. On Sun, Jun 5, 2022 at 2:48 AM alicexbt via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Hi Jorge, > > > Misinformation is false or inaccurate information, especially that which > is deliberately intended to deceive. A combination of 'misleading' and > 'information'. Here are a few examples and I am sure I missed a lot of > others but its difficult for me to keep a track of everything: > > > 1) Sapio is open source and everything mentioned in tweet is false: > https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602 > > 2) Personal attacks on author of BIP 119 with false information: > https://nitter.net/s3cp256k1/status/1521238634111770624 > > 3) Andreas Antonopoulos shared false things about CTV and explained by > Ryan in this email: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html > > 4) Misleading things shared in these emails by Michael Folkson: > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html > > 5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin and > L2. I replied in this email: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html > > 6) Social media influencers like Peter McCormack tweeted they don't > understand BIP 119 but its an attack (this was even retweeted by developers > like Peter Todd): > https://nitter.net/PeterMcCormack/status/1521253840963653632 > > 7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine: > https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained > > 8) There were lies and misinformation about BIP 119 on social media > according to this Bitcoin Magazine article: > https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it > > 9) John Carvalho tweeting false things: > > https://nitter.net/BitcoinErrorLog/status/1468599535538745359 > > https://nitter.net/BitcoinErrorLog/status/1522652884218822658 > > https://nitter.net/BitcoinErrorLog/status/1442554615967354880 > > https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog) > > 10) Greg Maxwell responding to misinformation related to BIP 119 but > adding false things in the comments: > https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/ > > > I am not surprised by your email but it would be better if the people who > are interested in reviewing BIP 119 could raise the bar and not share > misleading information. > > > /dev/fd0 > > > Sent with Proton Mail secure email. > ------- Original Message ------- > On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón <jtimon@jtimon•cc> > wrote: > > > > "Some people say CTV is contentious, but they're spreading > misinformation"? Really? Seriously?Come on, guys, we can do better than > nina jankovich and the "fact checkers". > > Please, rise the bar. > > On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > > Note: This email is an opinion and not an attack on bitcoin > > > > > > Covenants on bitcoin will eventually be implemented with a soft fork. > CTV is the easiest and best possible way OP_TX looks good as well. Apart > from the technical merits, covenants will improve a few other things: > > > > > > - Developers can build interesting projects with real demand in market. > > > - Students learn Sapio and not just solidity. > > > - Better tooling could be available for application developers. > > > - Maybe we see bitcoin developer hackathons in different countries. > > > - Demand for block space might increase, it wont be just exchanges and > coinjoin. > > > - Funding of bitcoin developers and projects might improve. Wont need > to convince a few people for grants. > > > > > > **Why covenants are not contentious?** > > > > > > Some people may write paragraphs about CTV being contentious, spread > misinformation and do all types of drama, politics etc. on social media but > there are zero technical NACKs for CTV. We have discussed other covenant > proposals in detail on mailing list and IRC meetings with an open minded > approach. > > > > > > All the developers that participated in the discussion are either okay > with CTV or OP_TX or covenants in general. > > > > > > **How and when should covenants be implemented in Bitcoin?** > > > > > > I don't think we should wait for years anticipating a proposal that > everyone will agree on or argue for years to pretend changes are hard in > Bitcoin. We should improve the review process for soft fork BIPs and share > honest opinions with agreement, disagreement on technical merits. > > > > > > I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind > anything else being used if that improves Bitcoin. Covenants implemented in > Bitcoin before the next cycle would provide opportunity for developers to > build interesting things during the bear market. Ossification supporters > also believe there is some window that will close soon, maybe doing changes > considering each case individually will be a better approach. CTV is not a > rushed soft fork, less people followed the research and it was not > mentioned on social media repeatedly by the respected developers like other > soft forks. > > > > > > /dev/fd0 > > > > > > > > > Sent with Proton Mail secure email. > > > _______________________________________________ > > > 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 > [-- Attachment #2: Type: text/html, Size: 9827 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-08 3:51 ` Billy Tetrud @ 2022-06-08 9:22 ` Jorge Timón 2022-06-09 4:30 ` Billy Tetrud 0 siblings, 1 reply; 55+ messages in thread From: Jorge Timón @ 2022-06-08 9:22 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7193 bytes --] Who do you mean by "the non technical folks"? You don't include alicexbt or yourself as a "technical folk", do you? On Wed, Jun 8, 2022 at 8:38 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Wholeheartedly agree with you alicexbt. There are no technical issues that > have been shown that I'm aware of. Once the non-technical folks have time > to discuss it and realize that, I'm hopeful things will move forward. > Perhaps we can learn from this and figure out how to better catch the > attention of the larger bitcoin community for important changes without > alarming them. > > On Sun, Jun 5, 2022 at 2:48 AM alicexbt via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Hi Jorge, >> >> >> Misinformation is false or inaccurate information, especially that which >> is deliberately intended to deceive. A combination of 'misleading' and >> 'information'. Here are a few examples and I am sure I missed a lot of >> others but its difficult for me to keep a track of everything: >> >> >> 1) Sapio is open source and everything mentioned in tweet is false: >> https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602 >> >> 2) Personal attacks on author of BIP 119 with false information: >> https://nitter.net/s3cp256k1/status/1521238634111770624 >> >> 3) Andreas Antonopoulos shared false things about CTV and explained by >> Ryan in this email: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html >> >> 4) Misleading things shared in these emails by Michael Folkson: >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html >> >> 5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin and >> L2. I replied in this email: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html >> >> 6) Social media influencers like Peter McCormack tweeted they don't >> understand BIP 119 but its an attack (this was even retweeted by developers >> like Peter Todd): >> https://nitter.net/PeterMcCormack/status/1521253840963653632 >> >> 7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine: >> https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained >> >> 8) There were lies and misinformation about BIP 119 on social media >> according to this Bitcoin Magazine article: >> https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it >> >> 9) John Carvalho tweeting false things: >> >> https://nitter.net/BitcoinErrorLog/status/1468599535538745359 >> >> https://nitter.net/BitcoinErrorLog/status/1522652884218822658 >> >> https://nitter.net/BitcoinErrorLog/status/1442554615967354880 >> >> https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog) >> >> 10) Greg Maxwell responding to misinformation related to BIP 119 but >> adding false things in the comments: >> https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/ >> >> >> I am not surprised by your email but it would be better if the people who >> are interested in reviewing BIP 119 could raise the bar and not share >> misleading information. >> >> >> /dev/fd0 >> >> >> Sent with Proton Mail secure email. >> ------- Original Message ------- >> On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón <jtimon@jtimon•cc> >> wrote: >> >> >> > "Some people say CTV is contentious, but they're spreading >> misinformation"? Really? Seriously?Come on, guys, we can do better than >> nina jankovich and the "fact checkers". >> > Please, rise the bar. >> > On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> > >> > > Note: This email is an opinion and not an attack on bitcoin >> > > >> > > Covenants on bitcoin will eventually be implemented with a soft fork. >> CTV is the easiest and best possible way OP_TX looks good as well. Apart >> from the technical merits, covenants will improve a few other things: >> > > >> > > - Developers can build interesting projects with real demand in >> market. >> > > - Students learn Sapio and not just solidity. >> > > - Better tooling could be available for application developers. >> > > - Maybe we see bitcoin developer hackathons in different countries. >> > > - Demand for block space might increase, it wont be just exchanges >> and coinjoin. >> > > - Funding of bitcoin developers and projects might improve. Wont need >> to convince a few people for grants. >> > > >> > > **Why covenants are not contentious?** >> > > >> > > Some people may write paragraphs about CTV being contentious, spread >> misinformation and do all types of drama, politics etc. on social media but >> there are zero technical NACKs for CTV. We have discussed other covenant >> proposals in detail on mailing list and IRC meetings with an open minded >> approach. >> > > >> > > All the developers that participated in the discussion are either >> okay with CTV or OP_TX or covenants in general. >> > > >> > > **How and when should covenants be implemented in Bitcoin?** >> > > >> > > I don't think we should wait for years anticipating a proposal that >> everyone will agree on or argue for years to pretend changes are hard in >> Bitcoin. We should improve the review process for soft fork BIPs and share >> honest opinions with agreement, disagreement on technical merits. >> > > >> > > I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind >> anything else being used if that improves Bitcoin. Covenants implemented in >> Bitcoin before the next cycle would provide opportunity for developers to >> build interesting things during the bear market. Ossification supporters >> also believe there is some window that will close soon, maybe doing changes >> considering each case individually will be a better approach. CTV is not a >> rushed soft fork, less people followed the research and it was not >> mentioned on social media repeatedly by the respected developers like other >> soft forks. >> > > >> > > /dev/fd0 >> > > >> > > >> > > Sent with Proton Mail secure email. >> > > _______________________________________________ >> > > 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 10808 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-08 9:22 ` Jorge Timón @ 2022-06-09 4:30 ` Billy Tetrud 0 siblings, 0 replies; 55+ messages in thread From: Billy Tetrud @ 2022-06-09 4:30 UTC (permalink / raw) To: Jorge Timón, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8364 bytes --] @jorge > Who do you mean by "the non technical folks"? I mean people that don't have software engineering skills. This is the twittersphere, reddit, most podcasters, etc etc. This is the vast majority of the bitcoin community, and the vast majority of.. everyone. > You don't include alicexbt or yourself as a "technical folk", do you? I have no idea what alicexbt's skillset is. I do include myself. I have a degree in software engineering. I work as a programmer in the bitcoin space. I have written papers on technical aspects of bitcoin. Why would you assume that I'm not technical as someone who participates in the bitcoin developers mailing list? Perhaps its projection? On Wed, Jun 8, 2022 at 3:31 PM Jorge Timón via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Who do you mean by "the non technical folks"? > You don't include alicexbt or yourself as a "technical folk", do you? > > > On Wed, Jun 8, 2022 at 8:38 AM Billy Tetrud via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Wholeheartedly agree with you alicexbt. There are no technical issues >> that have been shown that I'm aware of. Once the non-technical folks have >> time to discuss it and realize that, I'm hopeful things will move forward. >> Perhaps we can learn from this and figure out how to better catch the >> attention of the larger bitcoin community for important changes without >> alarming them. >> >> On Sun, Jun 5, 2022 at 2:48 AM alicexbt via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> Hi Jorge, >>> >>> >>> Misinformation is false or inaccurate information, especially that which >>> is deliberately intended to deceive. A combination of 'misleading' and >>> 'information'. Here are a few examples and I am sure I missed a lot of >>> others but its difficult for me to keep a track of everything: >>> >>> >>> 1) Sapio is open source and everything mentioned in tweet is false: >>> https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602 >>> >>> 2) Personal attacks on author of BIP 119 with false information: >>> https://nitter.net/s3cp256k1/status/1521238634111770624 >>> >>> 3) Andreas Antonopoulos shared false things about CTV and explained by >>> Ryan in this email: >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html >>> >>> 4) Misleading things shared in these emails by Michael Folkson: >>> >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html >>> >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html >>> >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html >>> >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html >>> >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html >>> >>> 5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin >>> and L2. I replied in this email: >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html >>> >>> 6) Social media influencers like Peter McCormack tweeted they don't >>> understand BIP 119 but its an attack (this was even retweeted by developers >>> like Peter Todd): >>> https://nitter.net/PeterMcCormack/status/1521253840963653632 >>> >>> 7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine: >>> https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained >>> >>> 8) There were lies and misinformation about BIP 119 on social media >>> according to this Bitcoin Magazine article: >>> https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it >>> >>> 9) John Carvalho tweeting false things: >>> >>> https://nitter.net/BitcoinErrorLog/status/1468599535538745359 >>> >>> https://nitter.net/BitcoinErrorLog/status/1522652884218822658 >>> >>> https://nitter.net/BitcoinErrorLog/status/1442554615967354880 >>> >>> https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog) >>> >>> 10) Greg Maxwell responding to misinformation related to BIP 119 but >>> adding false things in the comments: >>> https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/ >>> >>> >>> I am not surprised by your email but it would be better if the people >>> who are interested in reviewing BIP 119 could raise the bar and not share >>> misleading information. >>> >>> >>> /dev/fd0 >>> >>> >>> Sent with Proton Mail secure email. >>> ------- Original Message ------- >>> On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón <jtimon@jtimon•cc> >>> wrote: >>> >>> >>> > "Some people say CTV is contentious, but they're spreading >>> misinformation"? Really? Seriously?Come on, guys, we can do better than >>> nina jankovich and the "fact checkers". >>> > Please, rise the bar. >>> > On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev < >>> bitcoin-dev@lists•linuxfoundation.org> wrote: >>> > >>> > > Note: This email is an opinion and not an attack on bitcoin >>> > > >>> > > Covenants on bitcoin will eventually be implemented with a soft >>> fork. CTV is the easiest and best possible way OP_TX looks good as well. >>> Apart from the technical merits, covenants will improve a few other things: >>> > > >>> > > - Developers can build interesting projects with real demand in >>> market. >>> > > - Students learn Sapio and not just solidity. >>> > > - Better tooling could be available for application developers. >>> > > - Maybe we see bitcoin developer hackathons in different countries. >>> > > - Demand for block space might increase, it wont be just exchanges >>> and coinjoin. >>> > > - Funding of bitcoin developers and projects might improve. Wont >>> need to convince a few people for grants. >>> > > >>> > > **Why covenants are not contentious?** >>> > > >>> > > Some people may write paragraphs about CTV being contentious, spread >>> misinformation and do all types of drama, politics etc. on social media but >>> there are zero technical NACKs for CTV. We have discussed other covenant >>> proposals in detail on mailing list and IRC meetings with an open minded >>> approach. >>> > > >>> > > All the developers that participated in the discussion are either >>> okay with CTV or OP_TX or covenants in general. >>> > > >>> > > **How and when should covenants be implemented in Bitcoin?** >>> > > >>> > > I don't think we should wait for years anticipating a proposal that >>> everyone will agree on or argue for years to pretend changes are hard in >>> Bitcoin. We should improve the review process for soft fork BIPs and share >>> honest opinions with agreement, disagreement on technical merits. >>> > > >>> > > I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind >>> anything else being used if that improves Bitcoin. Covenants implemented in >>> Bitcoin before the next cycle would provide opportunity for developers to >>> build interesting things during the bear market. Ossification supporters >>> also believe there is some window that will close soon, maybe doing changes >>> considering each case individually will be a better approach. CTV is not a >>> rushed soft fork, less people followed the research and it was not >>> mentioned on social media repeatedly by the respected developers like other >>> soft forks. >>> > > >>> > > /dev/fd0 >>> > > >>> > > >>> > > Sent with Proton Mail secure email. >>> > > _______________________________________________ >>> > > 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 >>> >> _______________________________________________ >> 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 > [-- Attachment #2: Type: text/html, Size: 12481 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-05 4:18 ` alicexbt 2022-06-08 3:51 ` Billy Tetrud @ 2022-06-09 0:03 ` Ryan Grant 1 sibling, 0 replies; 55+ messages in thread From: Ryan Grant @ 2022-06-09 0:03 UTC (permalink / raw) To: alicexbt, Bitcoin Protocol Discussion I think Jorge's request for specifics is reasonable. I agree that we can raise the level of discussion. Each claim about how good or bad a specific BIP is should say why on the technical merits. Comments on prior claims may expose misinformation, expose "trust me" authority, or point out other fallacies. They should include a citation of the original source, a fair restatement of the problematic claim for current readers, and a short explanation of why it doesn't advance understanding technical consensus. There have been lots of mean comments. Some "Truth and Reconciliation" will come due, and it will be a huge amount of work. Another history book? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-06-03 18:39 alicexbt 2022-06-04 0:29 ` micaroni 2022-06-04 18:43 ` Jorge Timón @ 2022-07-19 4:44 ` Anthony Towns 2022-07-19 14:46 ` alicexbt 2 siblings, 1 reply; 55+ messages in thread From: Anthony Towns @ 2022-07-19 4:44 UTC (permalink / raw) To: Bitcoin Protocol Discussion On Fri, Jun 03, 2022 at 06:39:34PM +0000, alicexbt via bitcoin-dev wrote: > Covenants on bitcoin will eventually be implemented with a soft fork. That's begging the question. The issue is whether we should allow such soft forks, or if the danger of losing coins to covenants and thus losing fungibility and the freedom to transact is too much of a risk, compared to whatever benefits the soft fork would bring. > **Why covenants are not contentious?** I think this actually misses the point: covenants are "contentious" because that term is usually used to describe a concept that's utterly counter to the point of bitcoin as a monetary instrument. We've taken the term and applied it for something that's different in key ways, which just ends up confusing and misleading. Using a traditional meaning, a "covenant" is an "agreement" but with an implication of permanency: whether that's because you're making a covenant with God that will bind your children and their children, or you're putting a covenant on your property that "runs with the land", eg: """A covenant is said to run with the land in the event that the covenant is annexed to the estate and cannot be separated from the land or the land transferred without it. Such a covenant exists if the original owner as well as each successive owner of the property is either subject to its burden or entitled to its benefit.""" [0] [0] https://legal-dictionary.thefreedictionary.com/covenant Sometimes people talk about "recursive covenants" in bitcoin, which I think is intended to imply something similar to the "runs with the land" concept above. But recursion in programming generally terminates (calculating "Fib(n) := if (n <= 1) then 1 else Fib(n-1) + Fib(n-2)" eg), while covenants that run with the land are often unable to be removed. I think a better programming analogy would be "non-terminating"; so for example, CTV is "recursive" in the sense that you can nest one CTV commitment inside another, but it does terminate, because you can only nest a finite number of CTV commitments inside another, due to computational limits. Covenants even have a racist history in the US (because of course they do), apparently, with covenants along the lines of "None of said land may be conveyed to, used, owned, or occupied by negroes as owners or tenants" [1] having been in use. Such covenants have apparently been ruled uneforcable by the Supreme Court, but apparently are nevertheless often difficult or impossible to remove from the property despite that. Presumably we at least don't need to worry about somehow introducing racist opcodes in bitcoin, but if you're wondering why covenants are controversial, their historical use is relevant. [1] https://www.npr.org/2021/11/17/1049052531/racial-covenants-housing-discrimination Covenants are specifically undesirable if applied to bitcoin because they break fungibility -- if you have some covenant that "runs with the coin", then it's no longer true to say "1 BTC = 1 BTC" if such a covenant means the one of the left can't be used for a lightning channel or the one on the right can't be used to back an asset on eth or liquid. But that isn't what anyone's *trying* to do here. What we're trying to do is add temporary conditions that allow us to do smarter things than we currently can while the coin remains in our ownership -- for example protecting our own money by putting it in a "vault", or pooling funds with people we don't entirely trust. That often requires recursion in the first place (so that the vault or the pool doesn't disappear after the first transaction). And from there, it can be easy to prevent the recursion from terminating and turn what would otherwise be a temporary condition into a permanent one. That was theoretically interesting in 2013 [2], and remains so today [3], but it isn't something that's *desirable* to apply to bitcoin. [2] https://bitcointalk.org/index.php?topic=278122.0 [3] https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html That is: even if it becomes possible to create permanent non-terminating covenants that run with a coin on bitcoin, that isn't something you should do, and if you do, people should not (and almost certainly will not) accept those coins from you, unless you first find a way to remove that covenant. One significant difference between real estate covenants and anything we might have on bitcoin is the ability to be sure that once you receive ownership of bitcoin, that that ownership does not come with encumbrances you're unaware of. In particular, when purchasing real estate, you may have to do numerous legal searches to be sure that there isn't a covenant, easement or other encumbrance on your property; in bitcoin, you decide the exact set of encumbrances that will be placed on your coins when you create the receiving address that you use, and once the address is chosen, those conditions are fixed. (Though to be fair, they could reference external things, such as an oracle, which could change) So, all in all, I think we should stop describing these features we're thinking about adding with the word that's mainly used for the single most inappropriate and undesirable use case for them. I think I'm going to go with talking about these features as enabling "transaction introspection" [4] [5] [6] (or "output introspection") instead -- that is, the ability for a script or witness from the input of a transaction to specify that the validator needs to examine components of the transaction itself (particularly its own outputs -- the value or the scriptPubKey or both), and ensure that some set of requirements imposed by the script/witness is fulfilled. [4] eg https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020735.html [5] compare with https://en.wikipedia.org/wiki/Type_introspection [6] see also https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md Note that signatures already involve transaction/output introspection: SIGHASH_ALL and SIGHASH_SINGLE impose the requirement that one or all outputs hash to some particular value, and validators obviously must check that requirement when validating signatures. That we already have this feature is why seemingly unrealted opcodes like CAT (or SUBSTR or SHA256STREAM) could also enable covenants in bitcoin. The CLTV and CSV opcodes also do transaction introspection, though not output introspection as they only examine the tx header (nlocktime) and the current input (nsequence). Cheers, aj ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [bitcoin-dev] Bitcoin covenants are inevitable 2022-07-19 4:44 ` Anthony Towns @ 2022-07-19 14:46 ` alicexbt 0 siblings, 0 replies; 55+ messages in thread From: alicexbt @ 2022-07-19 14:46 UTC (permalink / raw) To: Anthony Towns; +Cc: Bitcoin Protocol Discussion Hi Anthony, > The issue is whether we should allow such > soft forks, or if the danger of losing coins to covenants and thus > losing fungibility and the freedom to transact is too much of a risk, > compared to whatever benefits the soft fork would bring. There are so many ways to lose coins and [fungibility][1] of bitcoin is debatable. Most UTXOs are already distinguishable from another. > that. Presumably we at least don't need to worry about somehow introducing > racist opcodes in bitcoin, but if you're wondering why covenants are > controversial, their historical use is relevant. Could rebranding the term 'covenants' help in sharing the benefits of related proposals for bitcoin? According to Greg Maxwell's [comment][2] on reddit, he came up with the term as applied in bitcoin. > But that isn't what anyone's trying to do here. What we're trying to > do is add temporary conditions that allow us to do smarter things than > we currently can while the coin remains in our ownership -- for example > protecting our own money by putting it in a "vault", or pooling funds > with people we don't entirely trust. Agree. > In particular, when purchasing real estate, you > may have to do numerous legal searches to be sure that there isn't a > covenant, easement or other encumbrance on your property; in bitcoin, > you decide the exact set of encumbrances that will be placed on your > coins when you create the receiving address that you use, and once the > address is chosen, those conditions are fixed. Agree and users should be free to add conditions to the coins they own. > I think I'm going to go with talking about these features as enabling > "transaction introspection" [4] [5] [6] (or "output introspection") > instead -- that is, the ability for a script or witness from the input of > a transaction to specify that the validator needs to examine components > of the transaction itself (particularly its own outputs -- the value > or the scriptPubKey or both), and ensure that some set of requirements > imposed by the script/witness is fulfilled. Interesting perspective and maybe this is the rebranding I was thinking about. [1]: https://en.wikipedia.org/wiki/Fungibility [2]: https://www.reddit.com/r/Bitcoin/comments/uim560/comment/i7dhfpb/ /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Tuesday, July 19th, 2022 at 10:14 AM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > On Fri, Jun 03, 2022 at 06:39:34PM +0000, alicexbt via bitcoin-dev wrote: > > > Covenants on bitcoin will eventually be implemented with a soft fork. > > > That's begging the question. The issue is whether we should allow such > soft forks, or if the danger of losing coins to covenants and thus > losing fungibility and the freedom to transact is too much of a risk, > compared to whatever benefits the soft fork would bring. > > > Why covenants are not contentious? > > > I think this actually misses the point: covenants are "contentious" > because that term is usually used to describe a concept that's utterly > counter to the point of bitcoin as a monetary instrument. We've taken > the term and applied it for something that's different in key ways, > which just ends up confusing and misleading. > > Using a traditional meaning, a "covenant" is an "agreement" but with > an implication of permanency: whether that's because you're making a > covenant with God that will bind your children and their children, or > you're putting a covenant on your property that "runs with the land", eg: > > """A covenant is said to run with the land in the event that the covenant > is annexed to the estate and cannot be separated from the land or the land > transferred without it. Such a covenant exists if the original owner as > well as each successive owner of the property is either subject to its > burden or entitled to its benefit.""" [0] > > [0] https://legal-dictionary.thefreedictionary.com/covenant > > Sometimes people talk about "recursive covenants" in bitcoin, which > I think is intended to imply something similar to the "runs with the > land" concept above. But recursion in programming generally terminates > (calculating "Fib(n) := if (n <= 1) then 1 else Fib(n-1) + Fib(n-2)" > eg), while covenants that run with the land are often unable to be > removed. I think a better programming analogy would be "non-terminating"; > so for example, CTV is "recursive" in the sense that you can nest one > CTV commitment inside another, but it does terminate, because you can > only nest a finite number of CTV commitments inside another, due to > computational limits. > > Covenants even have a racist history in the US (because of course they > do), apparently, with covenants along the lines of "None of said land > may be conveyed to, used, owned, or occupied by negroes as owners or > tenants" [1] having been in use. Such covenants have apparently been > ruled uneforcable by the Supreme Court, but apparently are nevertheless > often difficult or impossible to remove from the property despite > that. Presumably we at least don't need to worry about somehow introducing > racist opcodes in bitcoin, but if you're wondering why covenants are > controversial, their historical use is relevant. > > [1] https://www.npr.org/2021/11/17/1049052531/racial-covenants-housing-discrimination > > Covenants are specifically undesirable if applied to bitcoin because they > break fungibility -- if you have some covenant that "runs with the coin", > then it's no longer true to say "1 BTC = 1 BTC" if such a covenant means > the one of the left can't be used for a lightning channel or the one on > the right can't be used to back an asset on eth or liquid. > > But that isn't what anyone's trying to do here. What we're trying to > do is add temporary conditions that allow us to do smarter things than > we currently can while the coin remains in our ownership -- for example > protecting our own money by putting it in a "vault", or pooling funds > with people we don't entirely trust. > > That often requires recursion in the first place (so that the vault or > the pool doesn't disappear after the first transaction). And from there, > it can be easy to prevent the recursion from terminating and turn what > would otherwise be a temporary condition into a permanent one. That > was theoretically interesting in 2013 [2], and remains so today [3], > but it isn't something that's desirable to apply to bitcoin. > > [2] https://bitcointalk.org/index.php?topic=278122.0 > [3] https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html > > That is: even if it becomes possible to create permanent non-terminating > covenants that run with a coin on bitcoin, that isn't something you > should do, and if you do, people should not (and almost certainly will > not) accept those coins from you, unless you first find a way to remove > that covenant. > > One significant difference between real estate covenants and anything > we might have on bitcoin is the ability to be sure that once you receive > ownership of bitcoin, that that ownership does not come with encumbrances > you're unaware of. In particular, when purchasing real estate, you > may have to do numerous legal searches to be sure that there isn't a > covenant, easement or other encumbrance on your property; in bitcoin, > you decide the exact set of encumbrances that will be placed on your > coins when you create the receiving address that you use, and once the > address is chosen, those conditions are fixed. (Though to be fair, they > could reference external things, such as an oracle, which could change) > > So, all in all, I think we should stop describing these features we're > thinking about adding with the word that's mainly used for the single > most inappropriate and undesirable use case for them. > > I think I'm going to go with talking about these features as enabling > "transaction introspection" [4] [5] [6] (or "output introspection") > instead -- that is, the ability for a script or witness from the input of > a transaction to specify that the validator needs to examine components > of the transaction itself (particularly its own outputs -- the value > or the scriptPubKey or both), and ensure that some set of requirements > imposed by the script/witness is fulfilled. > > [4] eg https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020735.html > [5] compare with https://en.wikipedia.org/wiki/Type_introspection > [6] see also https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md > > Note that signatures already involve transaction/output introspection: > SIGHASH_ALL and SIGHASH_SINGLE impose the requirement that one or all > outputs hash to some particular value, and validators obviously must > check that requirement when validating signatures. That we already have > this feature is why seemingly unrealted opcodes like CAT (or SUBSTR or > SHA256STREAM) could also enable covenants in bitcoin. > > The CLTV and CSV opcodes also do transaction introspection, though not > output introspection as they only examine the tx header (nlocktime) > and the current input (nsequence). > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2022-07-19 14:46 UTC | newest]
Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.9.1654344003.14400.bitcoin-dev@lists.linuxfoundation.org>
2022-06-04 12:27 ` [bitcoin-dev] Bitcoin covenants are inevitable John Carvalho
2022-06-04 13:48 ` Keagan McClelland
2022-06-04 16:12 ` alicexbt
2022-06-06 13:02 ` Erik Aronesty
2022-06-12 3:36 ` Peter Todd
2022-06-12 13:02 ` Erik Aronesty
2022-06-12 16:35 ` Corey Haddad
2022-06-12 19:16 ` alicexbt
2022-06-19 10:31 ` Peter Todd
2022-06-19 15:54 ` Manuel Costa
2022-06-19 18:26 ` Kate Salazar
2022-06-19 22:35 ` Erik Aronesty
2022-06-21 19:00 ` Keagan McClelland
2022-06-21 20:10 ` Eric Voskuil
2022-06-23 19:17 ` Peter Todd
2022-06-28 3:55 ` Billy Tetrud
2022-06-28 16:23 ` Alex Lee
2022-06-28 23:22 ` Peter Todd
2022-06-29 5:02 ` Alex Lee
2022-06-28 23:20 ` Peter Todd
2022-06-29 10:44 ` Kate Salazar
2022-06-30 15:25 ` Billy Tetrud
2022-07-03 9:43 ` Peter Todd
2022-07-03 10:30 ` Giuseppe B
2022-07-06 4:28 ` Corey Haddad
2022-07-06 11:10 ` vjudeu
2022-07-07 0:46 ` Billy Tetrud
2022-07-07 12:15 ` vjudeu
2022-07-07 14:05 ` Erik Aronesty
2022-07-07 14:10 ` Giuseppe B
2022-07-08 5:03 ` Billy Tetrud
2022-06-30 17:04 ` Erik Aronesty
[not found] <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org>
2022-07-07 13:24 ` John Carvalho
2022-07-07 14:12 ` Peter Todd
2022-07-07 16:24 ` Eric Voskuil
2022-07-07 17:37 ` Erik Aronesty
2022-07-07 19:57 ` Eric Voskuil
2022-07-07 21:11 ` Erik Aronesty
2022-07-08 0:28 ` Eric Voskuil
2022-07-08 4:59 ` vjudeu
2022-07-08 7:26 ` John Carvalho
2022-07-08 15:14 ` Erik Aronesty
2022-07-14 4:55 ` Billy Tetrud
2022-07-07 22:06 ` Anthony Towns
2022-07-07 22:02 ` Corey Haddad
2022-06-03 18:39 alicexbt
2022-06-04 0:29 ` micaroni
2022-06-04 18:43 ` Jorge Timón
2022-06-05 4:18 ` alicexbt
2022-06-08 3:51 ` Billy Tetrud
2022-06-08 9:22 ` Jorge Timón
2022-06-09 4:30 ` Billy Tetrud
2022-06-09 0:03 ` Ryan Grant
2022-07-19 4:44 ` Anthony Towns
2022-07-19 14:46 ` alicexbt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox