[bitcoin-dev] Bitcoin covenants are inevitable

[bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt]

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.

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[micaroni]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt]

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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Billy Tetrud]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Billy Tetrud]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Ryan Grant]

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?

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Anthony Towns]

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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt]

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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[John Carvalho]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Keagan McClelland]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Corey Haddad]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[alicexbt]

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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Manuel Costa]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Kate Salazar]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Keagan McClelland]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Eric Voskuil]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Billy Tetrud]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Alex Lee]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Alex Lee]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Kate Salazar]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Billy Tetrud]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Giuseppe B]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Corey Haddad]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[vjudeu]

> 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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Billy Tetrud]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[vjudeu]

> 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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Giuseppe B]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Billy Tetrud]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[John Carvalho]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Eric Voskuil]

[-- 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-----

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Eric Voskuil]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Eric Voskuil]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[vjudeu]

> 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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[John Carvalho]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Billy Tetrud]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Anthony Towns]

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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Corey Haddad]

[-- 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 --]