Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Kate Salazar <mercedes.catherine.salazar@gmail.com>]

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