Nostr notes by

📅 Original date posted:2022-01-19 📝 Original message: Hmm, ...

2023-06-09T15:05:00+02:00

In reply to nevent1q…karw
_________________________

📅 Original date posted:2022-01-19
📝 Original message:
Hmm, I don't know anything about SIGHASH_BUNDLE. The only references
online I can find are just mentions (mostly from you). What is
SIGHASH_BUNDLE?

> unless you're binding a WTXID

That could work, but it would exclude cases where you have a transaction
that has already been partially signed and someone wants to, say, only sign
that transaction if some 3rd party signs a transaction paying part of the
fee for it. Kind of a niche use case, but it would be nice to support it if
possible. If the transaction hasn't been signed at all yet, a new
transaction can just be created that includes the prospective fee-payer,
and if the transaction is fully signed then it has a WTXID to use.

> then you can have fee bumping cycles

What kind of cycles do you mean? You're saying these cycles would make it
less robust to reorgs?

> OP_VER

I assume you mean something other than pushing the version onto the stack
<https://bitcoin.stackexchange.com/questions/97258/given-op-ver-was-never-used-is-disabled-and-not-considered-useful-can-its-meani>;?
Is that related to your fee account idea?

On Wed, Jan 19, 2022 at 1:32 AM Jeremy <jlrubin at mit.edu> wrote:

> Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE
> like proposals.
>
> For what you're discussing, I previously proposed
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> which is similar.
>
> The benefit of the OP_VER output is that SIGHASH_EXTERNAL has the issue
> that unless you're binding a WTXID (which is maybe too specific?) then you
> can have fee bumping cycles. Doing OP_VER output w/ TXID guarantees that
> you are acyclic.
>
> The difference between a fee account and this approach basically boils
> down to the impact on e.g. reorg stability, where the deposit/withdraw
> mechanism is a bit more "robust" for reorderings in reorgs than the in-band
> transaction approach, although they are very similar.
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> > because you make transactions third party malleable it becomes
>> possible to bundle and unbundle transactions.
>>
>> What I was suggesting doesn't make it possible to malleate someone else's
>> transaction. I guess maybe my proposal of using a sighash flag might
>> have been unclear. Imagine it as a script opcode that just says "this
>> transaction must be mined with this other transaction" - the only
>> difference being that you can use any output with any encumberance as an
>> input for fee bumping. It doesn't prevent the original transaction from
>> being mined on its own. So adding junk inputs would be no more of a problem
>> than dust attacks already are. It would be used exactly like cpfp, except
>> it doesn't spend the parent.
>>
>> I don't think what I was suggesting is as different from your proposal.
>> All the problems of fee revenue optimization and feerate rules that you
>> mentioned seem like they'd also exist for your proposal, or for cpfp. Let
>> me know if I should clarify further.
>>
>> On Tue, Jan 18, 2022 at 8:51 PM Jeremy <jlrubin at mit.edu> wrote:
>>
>>> The issue with sighash flags is that because you make transactions third
>>> party malleable it becomes possible to bundle and unbundle transactions.
>>>
>>> This means there are circumstances where an attacker could e.g. see your
>>> txn, and then add a lot of junk change/inputs + 25 descendants and strongly
>>> anchor your transaction to the bottom of the mempool.
>>>
>>> because of rbf rules requiring more fee and feerate, this means you have
>>> to bump across the whole package and that can get really messy.
>>>
>>> more generally speaking, you could imagine a future where mempools track
>>> many alternative things that might want to be in a transaction.
>>>
>>> suppose there are N inputs each with a weight and an amount of fee being
>>> added and the sighash flags let me pick any subset of them. However, for a
>>> txn to be standard it must be < 100k bytes and for it to be consensus <
>>> 1mb. Now it is possible you have to solve a knapsack problem in order to
>>> rationally bundle this transaction out of all possibilities.
>>>
>>> This problem can get even thornier, suppose that the inputs I'm adding
>>> themselves are the outputs of another txn in the mempool, now i have to
>>> track and propagate the feerates of that child back up to the parent txn
>>> and track all these dependencies.
>>>
>>> perhaps with very careful engineering these issues can be tamed. however
>>> it seems with sponsors or fee accounts, by separating the pays-for from the
>>> participates-in concerns we can greatly simplify it to something like:
>>> compute effective feerate for a txn, including all sponsors that pay more
>>> than the feerate of the base txn. Mine that txn and it's subsidies using
>>> the normal algo. If you run out of space, all subsidies are same-sized so
>>> just take the ones that pay the highest amount up until the added marginal
>>> feerate is less than the next eligible txn.
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>> <https://twitter.com/JeremyRubin>;
>>>
>>>
>>> On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud <billy.tetrud at gmail.com>
>>> wrote:
>>>
>>>> I see, its not primarily to make it cheaper to append fees, but also
>>>> allows appending fees in cases that aren't possible now. Is that right? I
>>>> can certainly see the benefit of a more general way to add a fee to any
>>>> transaction, regardless of whether you're related to that transaction or
>>>> not.
>>>>
>>>> How would you compare the pros and cons of your account-based approach
>>>> to something like a new sighash flag? Eg a sighash flag that says "I'm
>>>> signing this transaction, but the signature is only valid if mined in the
>>>> same block as transaction X (or maybe transactions LIST)". This could be
>>>> named SIGHASH_EXTERNAL. Doing this would be a lot more similar to other
>>>> bitcoin transactions, and no special account would need to be created. Any
>>>> transaction could specify this. At least that's the first thought I would
>>>> have in designing a way to arbitrarily bump fees. Have you compared your
>>>> solution to something more familiar like that?
>>>>
>>>> On Tue, Jan 18, 2022 at 11:43 AM Jeremy <jlrubin at mit.edu> wrote:
>>>>
>>>>> Can you clarify what you mean by "improve the situation"?
>>>>>
>>>>> There's a potential mild bytes savings, but the bigger deal is that
>>>>> the API should be much less vulnerable to pinning issues, fix dust leakage
>>>>> for eltoo like protocols, and just generally allow protocol designs to be
>>>>> fully abstracted from paying fees. You can't easily mathematically
>>>>> quantify API improvements like that.
>>>>> --
>>>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>>>> <https://twitter.com/JeremyRubin>;
>>>>>
>>>>>
>>>>> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud <billy.tetrud at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Do you have any back-of-the-napkin math on quantifying how much this
>>>>>> would improve the situation vs existing methods (eg cpfp)?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
>>>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>
>>>>>>> Happy new years devs,
>>>>>>>
>>>>>>> I figured I would share some thoughts for conceptual review that
>>>>>>> have been bouncing around my head as an opportunity to clean up the fee
>>>>>>> paying semantics in bitcoin "for good". The design space is very wide on
>>>>>>> the approach I'll share, so below is just a sketch of how it could work
>>>>>>> which I'm sure could be improved greatly.
>>>>>>>
>>>>>>> Transaction fees are an integral part of bitcoin.
>>>>>>>
>>>>>>> However, due to quirks of Bitcoin's transaction design, fees are a
>>>>>>> part of the transactions that they occur in.
>>>>>>>
>>>>>>> While this works in a "Bitcoin 1.0" world, where all transactions
>>>>>>> are simple on-chain transfers, real world use of Bitcoin requires support
>>>>>>> for things like Fee Bumping stuck transactions, DoS resistant Payment
>>>>>>> Channels, and other long lived Smart Contracts that can't predict future
>>>>>>> fee rates. Having the fees paid in band makes writing these contracts much
>>>>>>> more difficult as you can't merely express the logic you want for the
>>>>>>> transaction, but also the fees.
>>>>>>>
>>>>>>> Previously, I proposed a special type of transaction called a
>>>>>>> "Sponsor" which has some special consensus + mempool rules to allow
>>>>>>> arbitrarily appending fees to a transaction to bump it up in the mempool.
>>>>>>>
>>>>>>> As an alternative, we could establish an account system in Bitcoin
>>>>>>> as an "extension block".
>>>>>>>
>>>>>>> *Here's how it might work:*
>>>>>>>
>>>>>>> 1. Define a special anyone can spend output type that is a "fee
>>>>>>> account" (e.g. segwit V2). Such outputs have a redeeming key and an amount
>>>>>>> associated with them, but are overall anyone can spend.
>>>>>>> 2. All deposits to these outputs get stored in a separate UTXO
>>>>>>> database for fee accounts
>>>>>>> 3. Fee accounts can sign only two kinds of transaction: A: a fee
>>>>>>> amount and a TXID (or Outpoint?); B: a withdraw amount, a fee, and
>>>>>>> an address
>>>>>>> 4. These transactions are committed in an extension block merkle
>>>>>>> tree. While the actual signature must cover the TXID/Outpoint, the
>>>>>>> committed data need only cover the index in the block of the transaction.
>>>>>>> The public key for account lookup can be recovered from the message +
>>>>>>> signature.
>>>>>>> 5. In any block, any of the fee account deposits can be: released
>>>>>>> into fees if there is a corresponding tx; consolidated together to reduce
>>>>>>> the number of utxos (this can be just an OP_TRUE no metadata needed); or
>>>>>>> released into fees *and paid back* into the requested withdrawal key
>>>>>>> (encumbering a 100 block timeout). Signatures must be unique in a block.
>>>>>>> 6. Mempool logic is updated to allow attaching of account fee spends
>>>>>>> to transactions, the mempool can restrict that an account is not allowed
>>>>>>> more spend more than it's balance.
>>>>>>>
>>>>>>> *But aren't accounts "bad"?*
>>>>>>>
>>>>>>> Yes, accounts are bad. But these accounts are not bad, because any
>>>>>>> funds withdrawn from the fee extension are fundamentally locked for 100
>>>>>>> blocks as a coinbase output, so there should be no issues with any series
>>>>>>> of reorgs. Further, since there is no "rich state" for these accounts, the
>>>>>>> state updates can always be applied in a conflict-free way in any order.
>>>>>>>
>>>>>>>
>>>>>>> *Improving the privacy of this design:*
>>>>>>>
>>>>>>> This design could likely be modified to implement something like
>>>>>>> Tornado.cash or something else so that the fee account paying can be
>>>>>>> unlinked from the transaction being paid for, improving privacy at the
>>>>>>> expense of being a bit more expensive.
>>>>>>>
>>>>>>> Other operations could be added to allow a trustless mixing to be
>>>>>>> done by miners automatically where groups of accounts with similar values
>>>>>>> are trustlessly split into a common denominator and change, and keys are
>>>>>>> derived via a verifiable stealth address like protocol (so fee balances can
>>>>>>> be discovered by tracing the updates posted). These updates could also be
>>>>>>> produced by individuals rather than miners, and miners could simply honor
>>>>>>> them with better privacy. While a miner generating an update would be able
>>>>>>> to deanonymize their mixes, if you have your account mixed several times by
>>>>>>> independent miners that could potentially add sufficient privacy.
>>>>>>>
>>>>>>> The LN can also be used with PTLCs to, in theory, have another
>>>>>>> individual paid to sponsor a transaction on your behalf only if they reveal
>>>>>>> a valid sig from their fee paying account, although under this model it's
>>>>>>> hard to ensure that the owner doesn't pay a fee and then 'cancel' by
>>>>>>> withdrawing the rest. However, this could be partly solved by using
>>>>>>> reputable fee accounts (reputation could be measured somewhat
>>>>>>> decentralized-ly by longevity of the account and transactions paid for
>>>>>>> historically).
>>>>>>>
>>>>>>> *Scalability*
>>>>>>>
>>>>>>> This design is fundamentally 'decent' for scalability because adding
>>>>>>> fees to a transaction does not require adding inputs or outputs and does
>>>>>>> not require tracking substantial amounts of new state.
>>>>>>>
>>>>>>> Paying someone else to pay for you via the LN also helps make this
>>>>>>> more efficient if the withdrawal issues can be fixed.
>>>>>>>
>>>>>>> *Lightning:*
>>>>>>>
>>>>>>> This type of design works really well for channels because the
>>>>>>> addition of fees to e.g. a channel state does not require any sort of
>>>>>>> pre-planning (e.g. anchors) or transaction flexibility (SIGHASH flags).
>>>>>>> This sort of design is naturally immune to pinning issues since you could
>>>>>>> offer to pay a fee for any TXID and the number of fee adding offers does
>>>>>>> not need to be restricted in the same way the descendant transactions would
>>>>>>> need to be.
>>>>>>>
>>>>>>> *Without a fork?*
>>>>>>>
>>>>>>> This type of design could be done as a federated network that bribes
>>>>>>> miners -- potentially even retroactively after a block is formed. That
>>>>>>> might be sufficient to prove the concept works before a consensus upgrade
>>>>>>> is deployed, but such an approach does mean there is a centralizing layer
>>>>>>> interfering with normal mining.
>>>>>>>
>>>>>>>
>>>>>>> Happy new year!!
>>>>>>>
>>>>>>> Jeremy
>>>>>>>
>>>>>>> --
>>>>>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>>>>>> <https://twitter.com/JeremyRubin>;
>>>>>>> _______________________________________________
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220119/c587953e/attachment-0001.html>;

📅 Original date posted:2022-01-19 📝 Original message: > ...

2023-06-09T15:04:59+02:00

In reply to nevent1q…s5vu
_________________________

📅 Original date posted:2022-01-19
📝 Original message:
> because you make transactions third party malleable it becomes possible
to bundle and unbundle transactions.

What I was suggesting doesn't make it possible to malleate someone else's
transaction. I guess maybe my proposal of using a sighash flag might have
been unclear. Imagine it as a script opcode that just says "this
transaction must be mined with this other transaction" - the only
difference being that you can use any output with any encumberance as an
input for fee bumping. It doesn't prevent the original transaction from
being mined on its own. So adding junk inputs would be no more of a problem
than dust attacks already are. It would be used exactly like cpfp, except
it doesn't spend the parent.

I don't think what I was suggesting is as different from your proposal. All
the problems of fee revenue optimization and feerate rules that you
mentioned seem like they'd also exist for your proposal, or for cpfp. Let
me know if I should clarify further.

On Tue, Jan 18, 2022 at 8:51 PM Jeremy <jlrubin at mit.edu> wrote:

> The issue with sighash flags is that because you make transactions third
> party malleable it becomes possible to bundle and unbundle transactions.
>
> This means there are circumstances where an attacker could e.g. see your
> txn, and then add a lot of junk change/inputs + 25 descendants and strongly
> anchor your transaction to the bottom of the mempool.
>
> because of rbf rules requiring more fee and feerate, this means you have
> to bump across the whole package and that can get really messy.
>
> more generally speaking, you could imagine a future where mempools track
> many alternative things that might want to be in a transaction.
>
> suppose there are N inputs each with a weight and an amount of fee being
> added and the sighash flags let me pick any subset of them. However, for a
> txn to be standard it must be < 100k bytes and for it to be consensus <
> 1mb. Now it is possible you have to solve a knapsack problem in order to
> rationally bundle this transaction out of all possibilities.
>
> This problem can get even thornier, suppose that the inputs I'm adding
> themselves are the outputs of another txn in the mempool, now i have to
> track and propagate the feerates of that child back up to the parent txn
> and track all these dependencies.
>
> perhaps with very careful engineering these issues can be tamed. however
> it seems with sponsors or fee accounts, by separating the pays-for from the
> participates-in concerns we can greatly simplify it to something like:
> compute effective feerate for a txn, including all sponsors that pay more
> than the feerate of the base txn. Mine that txn and it's subsidies using
> the normal algo. If you run out of space, all subsidies are same-sized so
> just take the ones that pay the highest amount up until the added marginal
> feerate is less than the next eligible txn.
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> I see, its not primarily to make it cheaper to append fees, but also
>> allows appending fees in cases that aren't possible now. Is that right? I
>> can certainly see the benefit of a more general way to add a fee to any
>> transaction, regardless of whether you're related to that transaction or
>> not.
>>
>> How would you compare the pros and cons of your account-based approach to
>> something like a new sighash flag? Eg a sighash flag that says "I'm signing
>> this transaction, but the signature is only valid if mined in the same
>> block as transaction X (or maybe transactions LIST)". This could be named
>> SIGHASH_EXTERNAL. Doing this would be a lot more similar to other bitcoin
>> transactions, and no special account would need to be created. Any
>> transaction could specify this. At least that's the first thought I would
>> have in designing a way to arbitrarily bump fees. Have you compared your
>> solution to something more familiar like that?
>>
>> On Tue, Jan 18, 2022 at 11:43 AM Jeremy <jlrubin at mit.edu> wrote:
>>
>>> Can you clarify what you mean by "improve the situation"?
>>>
>>> There's a potential mild bytes savings, but the bigger deal is that the
>>> API should be much less vulnerable to pinning issues, fix dust leakage for
>>> eltoo like protocols, and just generally allow protocol designs to be fully
>>> abstracted from paying fees. You can't easily mathematically quantify API
>>> improvements like that.
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>> <https://twitter.com/JeremyRubin>;
>>>
>>>
>>> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud <billy.tetrud at gmail.com>
>>> wrote:
>>>
>>>> Do you have any back-of-the-napkin math on quantifying how much this
>>>> would improve the situation vs existing methods (eg cpfp)?
>>>>
>>>>
>>>>
>>>> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Happy new years devs,
>>>>>
>>>>> I figured I would share some thoughts for conceptual review that have
>>>>> been bouncing around my head as an opportunity to clean up the fee paying
>>>>> semantics in bitcoin "for good". The design space is very wide on the
>>>>> approach I'll share, so below is just a sketch of how it could work which
>>>>> I'm sure could be improved greatly.
>>>>>
>>>>> Transaction fees are an integral part of bitcoin.
>>>>>
>>>>> However, due to quirks of Bitcoin's transaction design, fees are a
>>>>> part of the transactions that they occur in.
>>>>>
>>>>> While this works in a "Bitcoin 1.0" world, where all transactions are
>>>>> simple on-chain transfers, real world use of Bitcoin requires support for
>>>>> things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
>>>>> and other long lived Smart Contracts that can't predict future fee rates.
>>>>> Having the fees paid in band makes writing these contracts much more
>>>>> difficult as you can't merely express the logic you want for the
>>>>> transaction, but also the fees.
>>>>>
>>>>> Previously, I proposed a special type of transaction called a
>>>>> "Sponsor" which has some special consensus + mempool rules to allow
>>>>> arbitrarily appending fees to a transaction to bump it up in the mempool.
>>>>>
>>>>> As an alternative, we could establish an account system in Bitcoin as
>>>>> an "extension block".
>>>>>
>>>>> *Here's how it might work:*
>>>>>
>>>>> 1. Define a special anyone can spend output type that is a "fee
>>>>> account" (e.g. segwit V2). Such outputs have a redeeming key and an amount
>>>>> associated with them, but are overall anyone can spend.
>>>>> 2. All deposits to these outputs get stored in a separate UTXO
>>>>> database for fee accounts
>>>>> 3. Fee accounts can sign only two kinds of transaction: A: a fee
>>>>> amount and a TXID (or Outpoint?); B: a withdraw amount, a fee, and
>>>>> an address
>>>>> 4. These transactions are committed in an extension block merkle tree.
>>>>> While the actual signature must cover the TXID/Outpoint, the committed data
>>>>> need only cover the index in the block of the transaction. The public key
>>>>> for account lookup can be recovered from the message + signature.
>>>>> 5. In any block, any of the fee account deposits can be: released into
>>>>> fees if there is a corresponding tx; consolidated together to reduce the
>>>>> number of utxos (this can be just an OP_TRUE no metadata needed); or
>>>>> released into fees *and paid back* into the requested withdrawal key
>>>>> (encumbering a 100 block timeout). Signatures must be unique in a block.
>>>>> 6. Mempool logic is updated to allow attaching of account fee spends
>>>>> to transactions, the mempool can restrict that an account is not allowed
>>>>> more spend more than it's balance.
>>>>>
>>>>> *But aren't accounts "bad"?*
>>>>>
>>>>> Yes, accounts are bad. But these accounts are not bad, because any
>>>>> funds withdrawn from the fee extension are fundamentally locked for 100
>>>>> blocks as a coinbase output, so there should be no issues with any series
>>>>> of reorgs. Further, since there is no "rich state" for these accounts, the
>>>>> state updates can always be applied in a conflict-free way in any order.
>>>>>
>>>>>
>>>>> *Improving the privacy of this design:*
>>>>>
>>>>> This design could likely be modified to implement something like
>>>>> Tornado.cash or something else so that the fee account paying can be
>>>>> unlinked from the transaction being paid for, improving privacy at the
>>>>> expense of being a bit more expensive.
>>>>>
>>>>> Other operations could be added to allow a trustless mixing to be done
>>>>> by miners automatically where groups of accounts with similar values are
>>>>> trustlessly split into a common denominator and change, and keys are
>>>>> derived via a verifiable stealth address like protocol (so fee balances can
>>>>> be discovered by tracing the updates posted). These updates could also be
>>>>> produced by individuals rather than miners, and miners could simply honor
>>>>> them with better privacy. While a miner generating an update would be able
>>>>> to deanonymize their mixes, if you have your account mixed several times by
>>>>> independent miners that could potentially add sufficient privacy.
>>>>>
>>>>> The LN can also be used with PTLCs to, in theory, have another
>>>>> individual paid to sponsor a transaction on your behalf only if they reveal
>>>>> a valid sig from their fee paying account, although under this model it's
>>>>> hard to ensure that the owner doesn't pay a fee and then 'cancel' by
>>>>> withdrawing the rest. However, this could be partly solved by using
>>>>> reputable fee accounts (reputation could be measured somewhat
>>>>> decentralized-ly by longevity of the account and transactions paid for
>>>>> historically).
>>>>>
>>>>> *Scalability*
>>>>>
>>>>> This design is fundamentally 'decent' for scalability because adding
>>>>> fees to a transaction does not require adding inputs or outputs and does
>>>>> not require tracking substantial amounts of new state.
>>>>>
>>>>> Paying someone else to pay for you via the LN also helps make this
>>>>> more efficient if the withdrawal issues can be fixed.
>>>>>
>>>>> *Lightning:*
>>>>>
>>>>> This type of design works really well for channels because the
>>>>> addition of fees to e.g. a channel state does not require any sort of
>>>>> pre-planning (e.g. anchors) or transaction flexibility (SIGHASH flags).
>>>>> This sort of design is naturally immune to pinning issues since you could
>>>>> offer to pay a fee for any TXID and the number of fee adding offers does
>>>>> not need to be restricted in the same way the descendant transactions would
>>>>> need to be.
>>>>>
>>>>> *Without a fork?*
>>>>>
>>>>> This type of design could be done as a federated network that bribes
>>>>> miners -- potentially even retroactively after a block is formed. That
>>>>> might be sufficient to prove the concept works before a consensus upgrade
>>>>> is deployed, but such an approach does mean there is a centralizing layer
>>>>> interfering with normal mining.
>>>>>
>>>>>
>>>>> Happy new year!!
>>>>>
>>>>> Jeremy
>>>>>
>>>>> --
>>>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>>>> <https://twitter.com/JeremyRubin>;
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220118/59a75bc9/attachment-0001.html>;

📅 Original date posted:2022-01-19 📝 Original message: I ...

2023-06-09T15:04:57+02:00

In reply to nevent1q…n3up
_________________________

📅 Original date posted:2022-01-19
📝 Original message:
I see, its not primarily to make it cheaper to append fees, but also allows
appending fees in cases that aren't possible now. Is that right? I can
certainly see the benefit of a more general way to add a fee to any
transaction, regardless of whether you're related to that transaction or
not.

How would you compare the pros and cons of your account-based approach to
something like a new sighash flag? Eg a sighash flag that says "I'm signing
this transaction, but the signature is only valid if mined in the same
block as transaction X (or maybe transactions LIST)". This could be named
SIGHASH_EXTERNAL. Doing this would be a lot more similar to other bitcoin
transactions, and no special account would need to be created. Any
transaction could specify this. At least that's the first thought I would
have in designing a way to arbitrarily bump fees. Have you compared your
solution to something more familiar like that?

On Tue, Jan 18, 2022 at 11:43 AM Jeremy <jlrubin at mit.edu> wrote:

> Can you clarify what you mean by "improve the situation"?
>
> There's a potential mild bytes savings, but the bigger deal is that the
> API should be much less vulnerable to pinning issues, fix dust leakage for
> eltoo like protocols, and just generally allow protocol designs to be fully
> abstracted from paying fees. You can't easily mathematically quantify API
> improvements like that.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> Do you have any back-of-the-napkin math on quantifying how much this
>> would improve the situation vs existing methods (eg cpfp)?
>>
>>
>>
>> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Happy new years devs,
>>>
>>> I figured I would share some thoughts for conceptual review that have
>>> been bouncing around my head as an opportunity to clean up the fee paying
>>> semantics in bitcoin "for good". The design space is very wide on the
>>> approach I'll share, so below is just a sketch of how it could work which
>>> I'm sure could be improved greatly.
>>>
>>> Transaction fees are an integral part of bitcoin.
>>>
>>> However, due to quirks of Bitcoin's transaction design, fees are a part
>>> of the transactions that they occur in.
>>>
>>> While this works in a "Bitcoin 1.0" world, where all transactions are
>>> simple on-chain transfers, real world use of Bitcoin requires support for
>>> things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
>>> and other long lived Smart Contracts that can't predict future fee rates.
>>> Having the fees paid in band makes writing these contracts much more
>>> difficult as you can't merely express the logic you want for the
>>> transaction, but also the fees.
>>>
>>> Previously, I proposed a special type of transaction called a "Sponsor"
>>> which has some special consensus + mempool rules to allow arbitrarily
>>> appending fees to a transaction to bump it up in the mempool.
>>>
>>> As an alternative, we could establish an account system in Bitcoin as an
>>> "extension block".
>>>
>>> *Here's how it might work:*
>>>
>>> 1. Define a special anyone can spend output type that is a "fee account"
>>> (e.g. segwit V2). Such outputs have a redeeming key and an amount
>>> associated with them, but are overall anyone can spend.
>>> 2. All deposits to these outputs get stored in a separate UTXO database
>>> for fee accounts
>>> 3. Fee accounts can sign only two kinds of transaction: A: a fee amount
>>> and a TXID (or Outpoint?); B: a withdraw amount, a fee, and an address
>>> 4. These transactions are committed in an extension block merkle tree.
>>> While the actual signature must cover the TXID/Outpoint, the committed data
>>> need only cover the index in the block of the transaction. The public key
>>> for account lookup can be recovered from the message + signature.
>>> 5. In any block, any of the fee account deposits can be: released into
>>> fees if there is a corresponding tx; consolidated together to reduce the
>>> number of utxos (this can be just an OP_TRUE no metadata needed); or
>>> released into fees *and paid back* into the requested withdrawal key
>>> (encumbering a 100 block timeout). Signatures must be unique in a block.
>>> 6. Mempool logic is updated to allow attaching of account fee spends to
>>> transactions, the mempool can restrict that an account is not allowed more
>>> spend more than it's balance.
>>>
>>> *But aren't accounts "bad"?*
>>>
>>> Yes, accounts are bad. But these accounts are not bad, because any funds
>>> withdrawn from the fee extension are fundamentally locked for 100 blocks as
>>> a coinbase output, so there should be no issues with any series of reorgs.
>>> Further, since there is no "rich state" for these accounts, the state
>>> updates can always be applied in a conflict-free way in any order.
>>>
>>>
>>> *Improving the privacy of this design:*
>>>
>>> This design could likely be modified to implement something like
>>> Tornado.cash or something else so that the fee account paying can be
>>> unlinked from the transaction being paid for, improving privacy at the
>>> expense of being a bit more expensive.
>>>
>>> Other operations could be added to allow a trustless mixing to be done
>>> by miners automatically where groups of accounts with similar values are
>>> trustlessly split into a common denominator and change, and keys are
>>> derived via a verifiable stealth address like protocol (so fee balances can
>>> be discovered by tracing the updates posted). These updates could also be
>>> produced by individuals rather than miners, and miners could simply honor
>>> them with better privacy. While a miner generating an update would be able
>>> to deanonymize their mixes, if you have your account mixed several times by
>>> independent miners that could potentially add sufficient privacy.
>>>
>>> The LN can also be used with PTLCs to, in theory, have another
>>> individual paid to sponsor a transaction on your behalf only if they reveal
>>> a valid sig from their fee paying account, although under this model it's
>>> hard to ensure that the owner doesn't pay a fee and then 'cancel' by
>>> withdrawing the rest. However, this could be partly solved by using
>>> reputable fee accounts (reputation could be measured somewhat
>>> decentralized-ly by longevity of the account and transactions paid for
>>> historically).
>>>
>>> *Scalability*
>>>
>>> This design is fundamentally 'decent' for scalability because adding
>>> fees to a transaction does not require adding inputs or outputs and does
>>> not require tracking substantial amounts of new state.
>>>
>>> Paying someone else to pay for you via the LN also helps make this more
>>> efficient if the withdrawal issues can be fixed.
>>>
>>> *Lightning:*
>>>
>>> This type of design works really well for channels because the addition
>>> of fees to e.g. a channel state does not require any sort of pre-planning
>>> (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
>>> design is naturally immune to pinning issues since you could offer to pay a
>>> fee for any TXID and the number of fee adding offers does not need to be
>>> restricted in the same way the descendant transactions would need to be.
>>>
>>> *Without a fork?*
>>>
>>> This type of design could be done as a federated network that bribes
>>> miners -- potentially even retroactively after a block is formed. That
>>> might be sufficient to prove the concept works before a consensus upgrade
>>> is deployed, but such an approach does mean there is a centralizing layer
>>> interfering with normal mining.
>>>
>>>
>>> Happy new year!!
>>>
>>> Jeremy
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>> <https://twitter.com/JeremyRubin>;
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220118/3c72c1c7/attachment.html>;

📅 Original date posted:2022-01-18 📝 Original message: Do ...

2023-06-09T15:04:56+02:00

In reply to nevent1q…aprh
_________________________

📅 Original date posted:2022-01-18
📝 Original message:
Do you have any back-of-the-napkin math on quantifying how much this would
improve the situation vs existing methods (eg cpfp)?

On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Happy new years devs,
>
> I figured I would share some thoughts for conceptual review that have been
> bouncing around my head as an opportunity to clean up the fee paying
> semantics in bitcoin "for good". The design space is very wide on the
> approach I'll share, so below is just a sketch of how it could work which
> I'm sure could be improved greatly.
>
> Transaction fees are an integral part of bitcoin.
>
> However, due to quirks of Bitcoin's transaction design, fees are a part of
> the transactions that they occur in.
>
> While this works in a "Bitcoin 1.0" world, where all transactions are
> simple on-chain transfers, real world use of Bitcoin requires support for
> things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
> and other long lived Smart Contracts that can't predict future fee rates.
> Having the fees paid in band makes writing these contracts much more
> difficult as you can't merely express the logic you want for the
> transaction, but also the fees.
>
> Previously, I proposed a special type of transaction called a "Sponsor"
> which has some special consensus + mempool rules to allow arbitrarily
> appending fees to a transaction to bump it up in the mempool.
>
> As an alternative, we could establish an account system in Bitcoin as an
> "extension block".
>
> *Here's how it might work:*
>
> 1. Define a special anyone can spend output type that is a "fee account"
> (e.g. segwit V2). Such outputs have a redeeming key and an amount
> associated with them, but are overall anyone can spend.
> 2. All deposits to these outputs get stored in a separate UTXO database
> for fee accounts
> 3. Fee accounts can sign only two kinds of transaction: A: a fee amount
> and a TXID (or Outpoint?); B: a withdraw amount, a fee, and an address
> 4. These transactions are committed in an extension block merkle tree.
> While the actual signature must cover the TXID/Outpoint, the committed data
> need only cover the index in the block of the transaction. The public key
> for account lookup can be recovered from the message + signature.
> 5. In any block, any of the fee account deposits can be: released into
> fees if there is a corresponding tx; consolidated together to reduce the
> number of utxos (this can be just an OP_TRUE no metadata needed); or
> released into fees *and paid back* into the requested withdrawal key
> (encumbering a 100 block timeout). Signatures must be unique in a block.
> 6. Mempool logic is updated to allow attaching of account fee spends to
> transactions, the mempool can restrict that an account is not allowed more
> spend more than it's balance.
>
> *But aren't accounts "bad"?*
>
> Yes, accounts are bad. But these accounts are not bad, because any funds
> withdrawn from the fee extension are fundamentally locked for 100 blocks as
> a coinbase output, so there should be no issues with any series of reorgs.
> Further, since there is no "rich state" for these accounts, the state
> updates can always be applied in a conflict-free way in any order.
>
>
> *Improving the privacy of this design:*
>
> This design could likely be modified to implement something like
> Tornado.cash or something else so that the fee account paying can be
> unlinked from the transaction being paid for, improving privacy at the
> expense of being a bit more expensive.
>
> Other operations could be added to allow a trustless mixing to be done by
> miners automatically where groups of accounts with similar values are
> trustlessly split into a common denominator and change, and keys are
> derived via a verifiable stealth address like protocol (so fee balances can
> be discovered by tracing the updates posted). These updates could also be
> produced by individuals rather than miners, and miners could simply honor
> them with better privacy. While a miner generating an update would be able
> to deanonymize their mixes, if you have your account mixed several times by
> independent miners that could potentially add sufficient privacy.
>
> The LN can also be used with PTLCs to, in theory, have another individual
> paid to sponsor a transaction on your behalf only if they reveal a valid
> sig from their fee paying account, although under this model it's hard to
> ensure that the owner doesn't pay a fee and then 'cancel' by withdrawing
> the rest. However, this could be partly solved by using reputable fee
> accounts (reputation could be measured somewhat decentralized-ly by
> longevity of the account and transactions paid for historically).
>
> *Scalability*
>
> This design is fundamentally 'decent' for scalability because adding fees
> to a transaction does not require adding inputs or outputs and does not
> require tracking substantial amounts of new state.
>
> Paying someone else to pay for you via the LN also helps make this more
> efficient if the withdrawal issues can be fixed.
>
> *Lightning:*
>
> This type of design works really well for channels because the addition of
> fees to e.g. a channel state does not require any sort of pre-planning
> (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
> design is naturally immune to pinning issues since you could offer to pay a
> fee for any TXID and the number of fee adding offers does not need to be
> restricted in the same way the descendant transactions would need to be.
>
> *Without a fork?*
>
> This type of design could be done as a federated network that bribes
> miners -- potentially even retroactively after a block is formed. That
> might be sufficient to prove the concept works before a consensus upgrade
> is deployed, but such an approach does mean there is a centralizing layer
> interfering with normal mining.
>
>
> Happy new year!!
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220118/655b3d36/attachment.html>;

📅 Original date posted:2021-08-10 📝 Original message: For ...

2023-06-09T14:40:49+02:00

In reply to nevent1q…deu3
_________________________

📅 Original date posted:2021-08-10
📝 Original message:
For sure, CT can be done with computational soundness. The advantage of
unhidden amounts (as with current bitcoin) is that you get unconditional
soundness. My understanding is that there is a fundamental tradeoff between
unconditional soundness and unconditional privacy. I believe Monero has
taken this alternate tradeoff path with unconditional privacy but only
computational soundness
<https://www.reddit.com/r/Monero/comments/8erg8e/what_should_monero_do_about_the_soundness_problem/dxy59ad?utm_source=share&utm_medium=web2x&context=3>;
.

> old things that never move more or less naturally "fall leftward"

Ah yes, something like that would definitely be interesting to basically
make dust a moot point. Sounds like the tradeoff mentioned is that proofs
would be twice as big? Except newer UTXOs would have substantially shorter
proofs. It sounds like the kind of thing where there's some point where
there would be so many old UTXOs that proofs would be smaller on average in
the swap tree version vs the dead-leaf version. Maybe someone smarter than
me could estimate where that point is.

On Mon, Aug 9, 2021 at 10:04 PM Jeremy <jlrubin at mit.edu> wrote:

> You might be interested in https://eprint.iacr.org/2017/1066.pdf which
> claims that you can make CT computationally hiding and binding, see section
> 4.6.
>
> with respect to utreexo, you might review
> https://github.com/mit-dci/utreexo/discussions/249?sort=new which
> discusses tradeoffs between different accumulator designs. With a swap
> tree, old things that never move more or less naturally "fall leftward",
> although there are reasons to prefer alternative designs.
>
>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210809/c4607f2b/attachment.html>;

📅 Original date posted:2023-01-04 🗒️ Summary of this ...

2023-06-08T01:18:04+02:00

In reply to nevent1q…57eq
_________________________

📅 Original date posted:2023-01-04
🗒️ Summary of this message: tionary Bitcoin relies heavily on coinbase rewards for security, with fees making up only a small portion. The cost of a 50% attack is currently less than $7 billion, but if Bitcoin's security needs increase to $2 trillion, a price of $4.3 million/bitcoin would be required. The fee market may grow superlinearly as Bitcoin adoption increases, making high levels of security more realistic.
📝 Original message:> In Bitcoin "the show must go on" and someone must pay for it. Active
[and/or] passive users

I certainly agree.

> or more precisely: tiny inflation

👍

> Right now security comes from almost fully from ~1.8% inflation.

Best I could find, fees make up about 13% of miner revenue
<https://decrypt.co/57740/bitcoin-miners-now-earn-1-btc-in-fees-per-block>;.
So yes, the vast majority of security comes from coinbase rewards. I assume
you're implying that ~13% of today's security is not enough? I would love
to see any quantitative thoughts you have on how one might determine that.

Have there been any thoughts put out in the community as to what size of
threat is unlikely enough to arise that we don't need to worry about it?
Maybe 1% of the yearly government budgets
<https://en.wikipedia.org/wiki/List_of_countries_by_government_budget>; of
the world would be an upper bound on how much anyone would expect could
realistically be brought to bear? Today that would be maybe around $350
billion.

Or perhaps a better way to estimate would be calculating the size of the
motivation of an attacker. For example, this paper
<https://files.stlouisfed.org/files/htdocs/publications/review/92/03/Seigniorage_Mar_Apr1992.pdf>;
seems
to conclude that the US government was extracting a maximum of ~$20
billion/year in 1982 dollars (so maybe $60 billion/year in 2022 dollars if
you go by CPI). If we scale this up to the entire world of governments,
this seems like it would place an upper bound of $180 billion/year of
seigniorage extraction that would be at risk if bitcoin might put the
currencies they gain seigniorage from out of business. Over 10 years (about
as far as we can expect any government to think), that's almost $2
trillion.

Whereas it would currently cost probably less than $7 billion to purchase a
50% share of bitcoin miners. To eventually reach a level of $350 billion,
bitcoin's price would need to reach about $800,000 / bitcoin. That seems
within the realm of possibility. To reach a level of $2 trillion, you'd
need a price of $4.3 million/bitcoin. That's still probably within the
realm of possibility, but certainly not as likely. If you then assume we
won't have significant coinbase rewards by that point, and only 13% of the
equivalent revenue (from fees) would be earned, then a price of ~$6 million
would be needed to support a $350 billion and $34 million to support a $2
trillion security. I think that second one is getting up towards the realm
of impossibility, so if we think that much security is necessary, we might
have to rethink things. Its also quite possible, as the network of people
who accept and use bitcoin as payment grows, that the fee market will grow
superlinearly in comparison to market cap, which would make these kind of
high levels of security more realistic.

Anyways if it turns out that fees alone don't look like they're supporting
enough security, we have a good amount of time to come to that conclusion
and do something about it.

> Deflation in Bitcoin is not 1:1 matter like in gold, for example...
Deflation in Bitcoin is more complex issue

It's helpful to keep our language precise here. Price inflation and
deflation act identically in bitcoin and gold and anything else. What you
seem to be talking about at this point is monetary inflation (specifically,
a reduction in it) which of course operates differently on the machinery of
bitcoin than it does in the machinery of gold or other things. Whereas my
comment about you mentioning Gresham's law was specifically talking about
price inflation, not the effects of the coin emission machinery in bitcoin.

On Mon, Jan 2, 2023 at 5:02 PM <jk_14 at op.pl> wrote:

>
>
> Right now security comes from almost fully from ~1.8% inflation.
> In November mempool was inflated to ~150MB and people were rather waiting
> for cheap transactions back.
> Instead of being happy that system is closer for a while to default
> working area.
>
> Deflation in Bitcoin is not 1:1 matter like in gold, for example.
> If all plain gold available to mine would be finished - gold mines as
> unprofitable enterprices are immediately closed.
> And it doesn't affect security of gold already in circulation.
> In Bitcoin "the show must go on" and someone must pay for it.
> Active and passive users together (balanced by market play) or: only
> active users (in current scenario, long-term).
>
> Deflation (or more precisely: tiny inflation) in Bitcoin is more complex
> issue with more repercussions than in gold.
> In case of drop of network security - the tax will be paid anyway, in
> Bitcoin price.
> So, there is an self-regulating mechanism here. The harsh one, but still.
>
>
>
> W dniu 2023-01-02 05:53:57 użytkownik Billy Tetrud <billy.tetrud at gmail.com>
> napisał:
> > is surely better than not delaying it.
>
> I might agree, but I don't think it really solves the problem well enough
> to be worth it. Any solution that would solve the problem better would make
> delaying halvings unnecessary.
>
> > there is non-zero risk that people will hoard it more and more,
> according to old Gresham's law
>
>
> Gresham's law doesn't apply here. Gresham's law is about the interaction
> between two currencies with a fixed, usually government-enforced exchange
> rate. You seem to be saying that Bitcoin will be hoarded because Bitcoin
> inflation reduces every halving. But even with 0 inflation, it certainly
> won't cause all Bitcoin to be hoarded. Also, "hoarding" is also known as
> "saving", and there's nothing wrong with saving. The spectre of deflation
> comes from a misunderstanding of deflation and why it happens during bad
> economic times. It is an effect, not a cause.
>
>
> On Sun, Jan 1, 2023, 15:23 <jk_14 at op.pl> wrote:
>
> Yes, the idea is:
> if mining activity is growing - let's execute consecutive halvings
> but if miner exodus has happened - let's delay next halving until mining
> activity is recovered to previous levels
>
> If it gets to the point where a sudden drop in mining difficulty happens -
> delaying the next halving may be not sufficient to correct, but is surely
> better than not delaying it.
>
> While Bitcoin is better and better money with every halving in comparision
> to other types of money - there is non-zero risk that people will hoard it
> more and more, according to old Gresham's law ("HODL"). And this way
> decreasing liquidity / transactions volume. The positive feedback loop - is
> my real concern here.
>
> Regarding the relationship between difficulty and security - I fully agree.
> But ASIC technology is already matured. And also any technology
> breakthrough is a short event within 4 years period.
> So growth of difficulty could be gained by technology breakthrough, but
> any sudden drop of difficulty would be always an issue, while there is no
> such thing as: ASIC technology regression.
>
> Obviously, not complicated solution would be better than complicated one.
>
>
>
>
> W dniu 2022-12-30 19:21:10 użytkownik Billy Tetrud <billy.tetrud at gmail.com>
> napisał:
> If the idea is to ensure that a catastrophic miner exodus doesn't happen,
> the "difference" you're calculating should only care about downward
> differences. Upward differences indicate more mining activity and so
> shouldn't cause a halving skip.
>
>
> But I don't think any scheme like this that only acts on the basis of
> difficulty will be sufficient. If it gets to the point where a sudden drop
> in mining difficulty happens, it is very likely that simply delaying the
> next halving or even ending halving all together will not be sufficient to
> correct for whatever is causing hashrate to tank. There is also the danger
> of simple difficulty stagnation, which this mechanism wouldn't detect.
>
>
> The relationship between difficulty and security becomes less and less
> predictable the longer you want to look ahead. There's no long term
> relation between difficulty and any reasonable security target. A security
> target might be something like "no colluding group with less than $1
> trillion dollars at their disposal could successfully 51% attack the
> network (with a probability of blah blah)". There is no way to today
> program in any code that detects based on difficult alone when that
> criteria is violated. You would have to program in assumptions about the
> cost of hashrate projected into the future.
>
>
> I can't think of any robust automatic way to do this. I think to a certain
> degree, it will have to be a change that happens in a fork of some kind
> (soft or hard) periodically (every 10 years? 30 years?). The basic
> relations needed is really the cost in Bitcoin of the security target (ie
> the minimum number of Bitcoin it should take to 51% attack the system) and
> the cost in Bitcoin of acquiring a unit of hashrate. This could be simply
> input into the code, or could use some complicated oracle system. But with
> that relation, the system could be programmed to calculate the difficulty
> necessary to keep the system secure.
>
>
> Once that is in place, the system could automatically adjust the subsidy
> up or down to attract more or less miners, or it could adjust the block
> size up or down to change the fee market such that more or less total fees
> are collected each block to attract more or less miners.
>
>
> On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> It seems like the more elegant solution could be by using a chainwork
> parameter instead.
> i.e. comparison just before halving - if the last 210,000 block interval
> has a higher chainwork difference between the begining and the end of
> interval
> than any other such inter-halving interval before.
>
> LIttle digression yet:
> A system in which all users participate in ensuring its security looks
> better than one in which only some (i.e. active) of them participate (and
> passive stakeholders are de facto free riders)
> In my opinion this concept above is only the complement of currently
> missing mechanism: achieving equilibrium regarding costs of security
> between two parties with opposing interests.
> It's easy to understand and - most important - it has no hardcoded value
> of tail emission - what is the clear proof it is based on a free market.
> And last but not least, if someone is 100% sure that income from
> transactions will takeover security support from block subsidy - accepting
> such proposal is like putting the money where the mouth is: this safety
> measure will never be triggered, then (no risk of fork)
>
>
> Best Regards
> Jaroslaw
>
>
>
> W dniu 2022-12-23 20:29:20 użytkownik Jaroslaw via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> napisał:
> >
> Necessary or not - it doesn't hurt to plan the robust model, just in case.
> The proposal is:
>
> Let every 210,000 the code calculate the average difficulty of 100 last
> retargets (100 fit well in 210,000 / 2016 = 104.166)
> and compare with the maximum of all such values calculated before, every
> 210,000 blocks:
>
>
> if average_diff_of_last_100_retargets >
> maximum_of_all_previous_average_diffs
> do halving
> else
> do nothing
>
>
> This way:
>
> 1. system cannot be played
> 2. only in case of destructive halving: system waits for the recovery of
> network security
>
>
> Best Regards
> Jaroslaw
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20230104/dfb173d9/attachment-0001.html>;

📅 Original date posted:2022-07-14 📝 Original message:@Peter ...

2023-06-08T01:11:08+02:00

In reply to nevent1q…nxle
_________________________

📅 Original date posted:2022-07-14
📝 Original message:@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 at lists.linuxfoundation.org> wrote:

> On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil <eric at 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 at 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/20220713/ee9b842f/attachment-0001.html>;

📅 Original date posted:2022-07-06 📝 Original message:@Corey ...

2023-06-08T01:10:55+02:00

In reply to nevent1q…wt59
_________________________

📅 Original date posted:2022-07-06
📝 Original message:@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 at 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: .
> 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 at 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 at 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.html>;

📅 Original date posted:2022-05-13 📝 Original ...

2023-06-08T01:09:33+02:00

In reply to nevent1q…8zz0
_________________________

📅 Original date posted:2022-05-13
📝 Original message:@alicexbt
> I think 'support' and 'opposition' can be replaced with readiness.
Miners should not consider signaling as voting.

I agree that it isn't voting, its signaling. But whether or not you call it
'readiness' or 'support', some miners will use it to signal 'support' and
will refuse to become ready if they do not support the change. Regardless,
I'm open to calling it "readiness" instead.

@Russell
> I'm sure there are lots of design choices available better than a
MUST_SIGNAL state that does not risk potentially taking a large fraction of
mining hardware offline for a protracted period of time.

I tend to agree. The case where the fork has not locked in, but some miners
are beginning to orphan other miners' blocks, seems like a rather chaotic
state to program into an activation mechanism. I do like the idea of using
orphaning to ensure that miners are alerted to the fact that a fork has
*already* locked in, but such a thing should be done at a low level (eg
orphan <10% of their blocks) - just high enough so the drop in revenue
makes them investigate, but as minimal as possible to avoid lots of orphans
and loss of hashpower.

On Wed, May 11, 2022 at 10:15 AM alicexbt <alicexbt at protonmail.com> wrote:

> Hi Billy,
>
> Thanks for the feedback. I agree with everything
> and bip-trinary-version-signaling looks interesting.
>
> > A primary difference from both BIP8 and BIP9 is that this proposal uses
> tri-state version signaling (rather than binary version bits) that can
> encode both active support as well as active opposition to an active soft
> fork.
>
>
> I think 'support' and 'opposition' can be replaced with readiness. Miners
> should not consider signaling as voting.
>
> > The meaning for each ternary value is as follows:
>
>
> 0 - No signal
> 1 - Ready for new consensus rules
> 2 - Not ready for new consensus rules
>
> The concept of a minimum and maximum threshold sounds intriguing, and I'm
> interested to read what other developers have to say about it.
>
> Concept ACK on removing LOT, using tri-state version signaling, min/max
> threshold and required threshold calculation.
>
>
> /dev/fd0
>
> Sent with ProtonMail secure email.
> ------- Original Message -------
> On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tetrud at gmail.com
> wrote:
>
>
>
> > I think this is a useful proposal. There are certainly things about BIP9
> that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but
> a BIP spec was never produced for it afaik. A possibly unhelpful comment:
> >
> > > minimum_activation_height
> > > I think a minor improvement would be to specify this as
> minimum_activation_blocks, ie a number of blocks passed the start_height.
> Slightly easier to reason about and change when necessary. I proposed
> semantics like that here.
> > > In any case, I'll give this a concept ACK. I would very much like
> future soft forks to use a previously specified activation mechanism rather
> than rolling out a rushed unspeced thing as part of the (very orthogonal)
> soft fork implementation.
> > > On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev
> bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> > > Hi Bitcoin Developers,
> > >
> > > There were some disagreements with speedy trial activation method
> recently and BIP 8 became controversial because of LOT earlier. I have
> tried to solve these two problems after reading some arguments for/against
> different activation methods by removing LOT from BIP 8 and calculating
> MUST_SIGNAL state based on threshold reached.
> > >
> > > BIP draft with no code and some changes in BIP 8:
> https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
> > >
> > > State transitions diagram:
> > >
> > > This proposal removes lockinontimeout flag, activation never fails
> although MUST_SIGNAL can be longer if miners signaling does not reach the
> threshold. Longer period for MUST_SIGNAL state is useful for coordination
> if LOCKED_IN was not reached.
> > >
> > > MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached
> and blocks that fail to signal in MUST_SIGNAL phase are invalid.
> > >
> > > Example:
> > >
> > > - This activation method is used for a soft fork
> > > - Only 60% miners signaled readiness and timeout height was reached
> > > - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> > > - LOCKED_IN and ACTIVE states remain same as BIP 8
> > > - Soft fork is activated with a delay of 2 months
> > >
> > > /dev/fd0
> > >
> > > Sent with ProtonMail secure
> email._______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at 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/20220513/6fbdf8b8/attachment.html>;

📅 Original date posted:2022-05-10 📝 Original message:I ...

2023-06-08T01:09:32+02:00

In reply to nevent1q…8agf
_________________________

📅 Original date posted:2022-05-10
📝 Original message:I think this is a useful proposal. There are certainly things about BIP9
that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but
a BIP spec was never produced for it afaik. A possibly unhelpful comment:

> minimum_activation_height

I think a minor improvement would be to specify this as
minimum_activation_blocks, ie a number of blocks passed the start_height.
Slightly easier to reason about and change when necessary. I proposed
semantics like that here
<https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/bip-trinary-version-bits.md>;
.

In any case, I'll give this a concept ACK. I would very much like future
soft forks to use a previously specified activation mechanism rather than
rolling out a rushed unspeced thing as part of the (very orthogonal) soft
fork implementation.

On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> There were some disagreements with speedy trial activation method recently
> and BIP 8 became controversial because of LOT earlier. I have tried to
> solve these two problems after reading some arguments for/against different
> activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL
> state based on threshold reached.
>
> BIP draft with no code and some changes in BIP 8:
> https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
>
> State transitions diagram:
>
> This proposal removes lockinontimeout flag, activation never fails
> although MUST_SIGNAL can be longer if miners signaling does not reach the
> threshold. Longer period for MUST_SIGNAL state is useful for coordination
> if LOCKED_IN was not reached.
>
> MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and
> blocks that fail to signal in MUST_SIGNAL phase are invalid.
>
> Example:
>
> - This activation method is used for a soft fork
> - Only 60% miners signaled readiness and timeout height was reached
> - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> - LOCKED_IN and ACTIVE states remain same as BIP 8
> - Soft fork is activated with a delay of 2 months
>
>
> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/>; secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220510/af6e90ce/attachment.html>;

📅 Original date posted:2022-05-01 📝 Original message:> ...

2023-06-08T01:08:53+02:00

In reply to nevent1q…sqar
_________________________

📅 Original date posted:2022-05-01
📝 Original message:> If a QC is able overnight to spend a large fraction of the supply, your
coins in your super non-QC vulnerable-bare-CTV-covenant (that would
eventually become vulnerable when trying to use it) are worthless.[1]

I know this has been debated to death, but I really don't think this
argument is very convincing. First of all, why are we assuming that if for
example, "satoshi's hoard" of 5+ million bitcoins was stolen, that it would
mean bitcoin becomes worthless? To me this is an absurd assumption to make.
The thief almost certainly wouldn't want to just destroy bitcoin. But even
if they did and put it all up for sale overnight, yes it would tank
bitcoin's price *temporarily*. But in the long run, this is less than 1/3
of the supply, and it at worst could be considered monetary inflation of <
30%, and so that's the amount that the price should take a hit of: less
than 30%. Plenty of fiat currencies have survived worse.

Second of all, its incredibly unlikely that someone is suddenly going to be
able to do QC so well that they jump straight to being able to find "a
large fraction" of the private keys out there, or enough private keys to
make up a large fraction of the supply. Its far more likely that the first
quantum computers that are able to derive *any* private keys will still
take a long time (weeks? months?) to do one. If you have your bitcoins in a
segwit address, you know that they can't be stolen by a quantum computer.
You can sit back calmly, and figure out what to do next. By contrast, if
your life savings is in a taproot address, you have to drop everything with
your underwear on fire and recklessly move that stuff ASAP. Chances for
hasty mistakes is high.

But lets say someone *does* jump to being able to derive 1 private key per
minute (pretty darn fast if you ask me). It would currently take such a
machine 152 years to crack all the 80 million UTXOs in existence. By the
time there are practical quantum machines, it'll probably be at least
double that many UTXOs. If it was trying to crack revealed private keys
from mempool transactions, it could only really hit 10 out of 2000
transactions. Hashing the public key is I think is quite an effective
protection to a quantum computing attack in the vast majority of likely QC
emergence scenarios. I honestly don't understand how someone could come to
a different conclusion.

It makes a lot of sense in a world where quantum computers are now a very
real thing, to store large amounts of bitcoin in a possibly slightly less
efficient way in order to ensure that those funds can't be snatched in a QC
disaster scenario. I would be very interested to see a proposal to add the
option of having a taproot address type that doesn't expose the bare public
key.

On Fri, Apr 29, 2022 at 6:53 AM Nadav Ivgi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Correction: thinking about this some more, you can't actually expect to
> have a stable txid if you allow additional inputs at all...
>
> So yes, amending BIP 118 to commit to sha_sequences (which indirectly also
> commits to the number of inputs) as proposed in the OP should be sufficient
> to get stable txids for single-input transactions.
>
> (I initially thought that APO has to cover some additional tx parts for
> this, but it seems that it's really just the scriptSig which is guarrnated
> to be empty if you have a single input that is known to be the taproot APO
> spend.)
>
> So in overall, my (1) and (5) points are only applicable to
> APO-as-currently-spec'd and not to the suggested APO revision.
>
> On Fri, Apr 29, 2022 at 1:21 PM Nadav Ivgi <nadav at shesek.info> wrote:
>
>> > This is *literally* what the post you are replying to is proposing to
>> solve.
>>
>> I thought the changes mentioned in the OP (+ committing to the spent
>> input index) only solves the half-spend problem, but not the stable txids
>> one?
>>
>> There can be other inputs with a scriptSig, which doesn't get committed
>> to in the APO hash. I guess this isn't too common, but there might be some
>> cases where you would want to spend some (pre-selected) non-segwit inputs
>> alongside your covenant, maybe for fees. With CTV you would pre-commit to
>> the scriptSig which makes it non-malleable even if the script itself is.
>>
>> > Hmm? You can't have channel factories without Eltoo. (Well, you can in
>> theory but good luck.)
>> > Maybe you are refering to non-interactive channel creation?
>>
>> I was referring to what BIP 119 calls 'Batched Channel Creation' [0],
>> which is a sort of a channel factory construction under a broader
>> definition (and in fact was previously called that in the BIP [1]).
>>
>> > The case for stable txids is less strong if we have APO (and therefore
>> Eltoo).
>>
>> There's merit in using these factory constructs for Poon-Dryja channels
>> even if Eltoo was available.
>> I don't foresee Eltoo taking over the penalty approach entirely, but
>> rather the two living side by side.
>>
>> (It could theoretically be possible to use APO to open Poon-Dryja
>> channels on top of unstable funding txids, but having stable txids makes
>> this much more easily integratable with existing lightning implementations,
>> without the invasive changes that unstable txids would bring.)
>>
>> > This has been addressed over and over and over again. If a QC is able
>> overnight to spend a large fraction of
>> > the supply, your coins in your super
>> non-QC-vulnerable-bare-CTV-covenant (that would eventually become
>> > vulnerable when trying to use it) are worthless.
>>
>> It might be the case that a sufficient fraction of supply does switch
>> over to QC-protected outputs in time, with only some small minority that
>> didn't actively switch over *and* with revealed bare pubkeys losing
>> their funds, which wouldn't make BTC entirely worthless. It makes sense not
>> to want to be in that minority, ideally without requiring further
>> time-sensitive active action (esp if considering long-term deep cold
>> storage for inheritance etc).
>>
>> (This of course assumes a safe post-QC mechanism to later spend these
>> funds; IIUC there are some viable approaches for that using a two-step
>> spending procedure, where you prove knowledge of the pubkey/script preimage
>> while commiting to a future tx.)
>>
>> > Sorry for being sarcastic, but at this point it's not fair to use
>> quantum-computer FUD to justify the
>> > activation of CTV over APO, or encourage the use of legacy transactions
>> over Taproot ones.
>>
>> Sorry if it came off as FUDing. I don't know enough to hold a strong
>> opinion on whether the fear of QCs is justified or not. I know that many
>> people on this list don't think so, but I also think that this fear is
>> prevalent enough to warrant taking it into consideration (at least for
>> features that target long-term SoV use cases; less so for features
>> targeted at L2 MoE applications like lightning spacechains paypools etc).
>>
>> > you can also use the internal key optimization .. you can't have
>> NUMS-ness then
>>
>> Right, which makes this unsuitable for the vaulting use case.
>>
>> > Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
>> witness units* (8.25 vbytes).
>>
>> Ugh yes sorry about that! I realized after hitting send and meant to
>> clarify that it should've been s/vbyte/WU/ in my next reply.
>>
>> > Are APO signatures more expensive to verify? .. the cost for the
>> network of validating signatures already exists today
>>
>> Not compared to existing signature verifications, but compared to a
>> CTV/TXHASH-like construction.
>>
>> Can anyone quantify how much of a difference this makes in practice?
>>
>> > i appreciate your reply and your efforts to explore the tradeoffs
>> between the two approaches.
>>
>> Thank you, I appreciate your efforts on this too :-)
>>
>> shesek
>>
>> [0]
>> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Batched_Channel_Creation
>> [1] https://github.com/bitcoin/bips/pull/1273
>>
>> On Fri, Apr 29, 2022 at 11:31 AM darosior <darosior at protonmail.com>
>> wrote:
>>
>>> Hi Shesek,
>>>
>>> 1. The resulting txids are not stable.
>>>
>>>
>>> This is *literally* what the post you are replying to is proposing to
>>> solve.
>>>
>>>
>>> This property could be important for some of the proposed CTV use-cases,
>>> like channel factories.
>>>
>>>
>>> Hmm? You can't have channel factories without Eltoo. (Well, you can in
>>> theory but good luck.)
>>> Maybe you are refering to non-interactive channel creation? The case for
>>> stable txids is less strong if we
>>> have APO (and therefore Eltoo). [0]
>>>
>>>
>>> 2. APO will only be available on Taproot, which some people might prefer
>>> to avoid for long-term multi-decade vault storage due to QC concerns. (also
>>> see my previous post on this thread [0])
>>>
>>>
>>> This has been addressed over and over and over again. If a QC is able
>>> overnight to spend a large fraction of
>>> the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
>>> (that would eventually become
>>> vulnerable when trying to use it) are worthless.[1]
>>>
>>> Sorry for being sarcastic, but at this point it's not fair to use
>>> quantum-computer FUD to justify the
>>> activation of CTV over APO, or encourage the use of legacy transactions
>>> over Taproot ones.
>>>
>>>
>>> 3. Higher witness satisfaction cost of roughly 3x vbytes vs
>>> CTV-in-Taproot (plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of
>>> a single CTV branch*, for the taproot control block. with more branches
>>> CTV-in-taproot eventually becomes preferable).
>>>
>>>
>>> Again, this is what my post discusses. Here are the arguments from my
>>> post about why i don't think it's a big deal:
>>>
>>> 1. You can in this case see CTV as an optimization of (tweaked)
>>> APOAS. A lot of us are doubtful about CTV
>>> usecases for real people. So much that it was even proposed to
>>> temporarily activate it to see if it would
>>> ever have any real traction! [2]
>>> My point with this post was: what if we do (a slightly tweaked)
>>> BIP118, that is otherwise useful. And
>>> if this use of covenants is really getting traction then we can
>>> roll out an optimization in the form of
>>> CTV (or better covenants, as we'd have had more research put into
>>> it by this time).
>>> 2. CTV is mainly sold for its usage inside vaults. While i'm not
>>> convinced, a few more vbytes should not
>>> matter for this usecase.
>>>
>>> Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
>>> witness units* (8.25 vbytes).
>>> Aside, you can also use the internal key optimization with APO. But i
>>> don't think it's desirable just to save
>>> 32 WU, as you can't have NUMS-ness then. [3]
>>>
>>>
>>> 4. Higher network-wide full-node validation costs (checking a signature
>>> is quite more expensive than hashing, and the hashing is done in both
>>> cases).
>>>
>>>
>>> Are APO signatures more expensive to verify? If not i don't think this
>>> should be a reason to constrain us to a
>>> much less useful construction, as the cost for the network of validating
>>> signatures already exists today. Even
>>> if it didn't, the tradeoff of cost/usefulness needs to be considered.
>>>
>>>
>>> 5. As APO is currently spec'd, it would suffer from the half-spend
>>> problem: if you have multiple outputs encumbered under an APO covenant that
>>> requires the same tx sigmsg hash, it becomes possible to spend all of them
>>> together as multiple inputs in a single transaction and burn the extra to
>>> mining fees.
>>>
>>> If I'm not mistaken, I believe this makes the simple-apo-vault
>>> implementation [1] vulnerable to spending multiple vaulted outputs of the
>>> same denomination together and burning all but the first one. I asked the
>>> author for a more definitive answer on twitter [2].
>>>
>>> Fixing this requires amending BIP 118 with some new sigmsg flags (making
>>> the ANYONECANPAY behaviour optional, as mentioned in the OP).
>>>
>>>
>>> Yes! And as i mentioned on Twitter also committing to the input index
>>> which i forgot to add in the OP here.
>>>
>>>
>>> While i don't think the specific points are valid, i appreciate your
>>> reply and your efforts to explore the
>>> tradeoffs between the two approaches.
>>>
>>> Thanks,
>>> Antoine
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
>>> [1] https://bitcoin.stackexchange.com/a/91050/101498
>>> [2]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
>>> [3]
>>> https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw
>>>
>>>
>>> This is definitely possible but also means that APO as-is isn't a
>>> CTV-replacement candidate, without first going through some more design and
>>> review iterations.
>>>
>>> shesek
>>>
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
>>> [1] https://github.com/darosior/simple-anyprevout-vault
>>> [2] https://twitter.com/shesek/status/1519874493434544128
>>>
>>>
>>>
>>> On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> I would like to know people's sentiment about doing (a very slightly
>>>> tweaked version of) BIP118 in place of
>>>> (or before doing) BIP119.
>>>>
>>>> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
>>>> over 6 years. It presents proven and
>>>> implemented usecases, that are demanded and (please someone correct me
>>>> if i'm wrong) more widely accepted than
>>>> CTV's.
>>>>
>>>> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
>>>> optional [0], can emulate CTV just fine.
>>>> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
>>>> expensive to use. But we can consider CTV
>>>> an optimization of APO-AS covenants.
>>>>
>>>> CTV advocates have been presenting vaults as the flagship usecase.
>>>> Although as someone who've been trying to
>>>> implement practical vaults for the past 2 years i doubt CTV is
>>>> necessary nor sufficient for this (but still
>>>> useful!), using APO-AS covers it. And it's not a couple dozen more
>>>> virtual bytes that are going to matter for
>>>> a potential vault user.
>>>>
>>>> If after some time all of us who are currently dubious about CTV's
>>>> stated usecases are proven wrong by onchain
>>>> usage of a less efficient construction to achieve the same goal, we
>>>> could roll-out CTV as an optimization. In
>>>> the meantime others will have been able to deploy new applications
>>>> leveraging ANYPREVOUT (Eltoo, blind
>>>> statechains, etc..[1]).
>>>>
>>>>
>>>> Given the interest in, and demand for, both simple covenants and better
>>>> offchain protocols it seems to me that
>>>> BIP118 is a soft fork candidate that could benefit more (if not most
>>>> of) Bitcoin users.
>>>> Actually i'd also be interested in knowing if people would oppose the
>>>> APO-AS part of BIP118, since it enables
>>>> CTV's features, for the same reason they'd oppose BIP119.
>>>>
>>>>
>>>> [0] That is, to not commit to the other inputs of the transaction (via
>>>> `sha_sequences` and maybe also
>>>> `sha_amounts`). Cf
>>>> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
>>>> .
>>>>
>>>> [1] https://anyprevout.xyz/ "Use Cases" section
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220501/8e6bc38d/attachment-0001.html>;

📅 Original date posted:2022-04-28 📝 Original ...

2023-06-08T01:08:27+02:00

In reply to nevent1q…zl9h
_________________________

📅 Original date posted:2022-04-28
📝 Original message:@Keagan
> we have to have a way (formalized or not) of deciding when the "lesser
experts" in aggregate have better judgement.

I agree. Its certainly convenient for development speed to limit the number
of cooks in the kitchen. But for the largest cryptocurrency in the world,
we're going to have to face the reality that the number of stakeholders has
grown vastly larger than the developer community and those who implicitly
trust the developer community, or any particular part of the dev community
working on any particular upgrade.

> Perhaps it warrants zooming out beyond even what my proposal aims to solve

I very much like the way you framed the question, and I think these are
important, potentially existential questions we should urge the bitcoin
community to think deeply about.

> 1. ... what would be the threshold for saying "this consensus change is
ready for activation"?

This is indeed the basic question.

> 1a. Does that threshold change based on the nature of the consensus change

I don't think the threshold of consensus changes should depend on the type
of consensus change. Any consensus change, no matter how small, introduces
risk, can cause bugs, can open a back door. Naturally, simpler changes
should be able to *reach* consensus faster, because presumably it would
take less analysis, and be easier to explain and convince people of. But
that doesn't mean the bar of consensus should be lower. I think it should
not. A change may look small and innocuous when it is in fact not, and it
would be less than ideal for people to try to pretend there's sufficient
consensus by insisting that a change is so "small" that no more is needed.

> 1b. Do different constituencies (end users, wallets, exchanges, coinjoin
coordinators, layer2 protocols, miners) have a desired minimum or maximum
representation in this "threshold"?

There is a lot to say about this simple question. I think it should be
recognized that the "say" anyone or any group has depends on their total
future (or perhaps only total near-term) economic influence on the network.
This is related to the concept of the "economic majority". What is the
"economic majority"? We could say this depends exactly on the proportion of
bitcoin you own, but I don't think that would be quite right. For example,
a miner that (hypothetically) keeps no bitcoin except for what is being
changed into fiat has an important role and significant economic influence
on bitcoin. Miners provide a service. Their livelihood depends on
bitcoiners, and the livelihood of bitcoin depends in part on miners.
Similarly, a vendor who accepts bitcoin directly but converts it all to
fiat provides a service as well. They expand the network of where bitcoin
is directly useful. People willing to pay for things in bitcoin also
similarly expand bitcoin's network.

I think it only makes sense to align incentives and attempt to match the
amount of representation a group gets to the amount of economic influence
they have on the network. To do otherwise would invite a schism.

Based on the above, I'm thinking that there are only really two components
of what should comprise the weight of any person or group's say: 1. the
stake they have in bitcoin, and 2. the value they provide to bitcoin. Let
me elaborate:

Bitcoin has a purpose. That purpose is as a currency. The directly valuable
aspects of that are as a store of value and as a means of exchange. The
properties of bitcoin lead to benefits to using it as both of those things.
Therefore, the stake people have in holding bitcoin should count heavily
because the value of holding is a major purpose of bitcoin. But at the same
time the ability to transact bitcoin should also count pretty heavily
because its also a major purpose of bitcoin and at the same time accepting
or spending bitcoin expands the network. If we were able to economically
equate those two things, we might get closer to a way to figure out how to
ideally distribute representation. Similarly, we could add miners and
developers into this mix, comparing them based on the value they provide to
the network.

So let:
holdAmount = the value of bitcoin they're holding over a given period of
time T
transactionVolume = the volume of transaction value over a given period of
time T
miningVolume = the value of bitcoin they mined over time period T
technologyValue = the value of new technological developments produced over
time period T

A group's representation should =
(holdAmount*A + transactionVolume*B + miningVolume*C + technologyValue*D)
/
(totalLiveBitcoin*A + totalTransactionVolume*B + totalMiningVolume*C +
totalTechnologyValue*D)

where A through D are constants that relate the value of holding vs the
value of transacting vs the value of mining vs the value of building
bitcoin technology. We could split this up so that eg the representation
that holders in total should have just by holding is: A/(A+B+C+D)

For example, an equivalence could be: how much value does holding bitcoin
give the average user per year? How much value does transacting give the
average user per year? These are fuzzy and subjective and potentially
dubious, but bare with me. Let's say that on average, a holder gets a
benefit of 2% of their holdings per year (on a risk adjusted basis). That
would be a benefit of $13.25 billion per year. And let's say that the ~$1.642
trillion of transactions per year
<https://data.nasdaq.com/data/BCHAIN/ETRVU-bitcoin-estimated-transaction-volume-usd>;
bitcoin
is doing has about 33% being actual exchanges of goods and services
<https://www.newsbtc.com/tech/only-33-of-bitcoin-payments-used-to-purchase-goods-economic-value-in-question/>;
and
for that 33% the transactors in sum also get a benefit of about 2% of the
transacted amount. That would be a benefit of $10.8 billion per year. If we
proxy the value of bitcoin mining to the network as the revenue they
received, perhaps this is as much as $15.3 billion
<https://www.prnewswire.com/news-releases/bitcoin-miners-revenue-rose-206-in-2021-301482452.html#:~:text=The%20report%20finds%20that%20on,in%20terms%20of%20Bitcoin%20mining.>;.
How do we calculate the value of developers? I don't know a good proxy for
that. But for kicks, why don't we say its as much as miners at $15.3
billion.

Using these numbers, the representation for each:

Holders: 13.25/(13.25+10.8+15.3+15.3) = 24%
Transactors: 10.8/(13.25+10.8+15.3+15.3) = 20%
Miners: 15.3/(13.25+10.8+15.3+15.3) = 27%
Developers: Also 27%

Maybe we could approximate that as each of the four categories has a 1/4th
share of representation. Values of A through D are certainly up for debate.

In any case, to get back to the question at hand (1b), I don't see any
reason to think there's a minimum or maximum representation for each
primary constituency. However, there would of course be minimum and maximum
bounds on our confidence for how much value/stake each constituency has,
and therefore a confidence range on how much representation they should
have.

But this 4 part group of holders, transactors, miners, and developers seems
to make a lot of sense to me. These are the main groups, and any other
subgroup can neatly fit into one or more of those.

With the assumption that the above numbers are somewhat accurate, it seems
reasonable to say that any majority of those four groups should be able to
prevent a change from happening. Maybe even any 40% of any of those groups.
Were we to roll this all into a single count, 40% of any group of 25% of
the whole is 10%, so it kind of supports the idea of a 90% threshold.
Although of course right now we have a 90% threshold on just miner
signaling. But since that's the only direct signaling we have, I think we
prudently erred on the safe side. But perhaps if we have something near
100% consensus in support of a change among the other 3 categories, perhaps
we could safely reduce the miner signaling quite a bit, perhaps not to 60%
(because of chain split concerns) but perhaps to 70% or 75%.

> what tests can we devise to measure those levels of support directly? If
we can't measure it directly, can we measure different indicators that
would help us infer or solve for the knowledge we want?

For 3 of the 4 groups, there seems to me clear mechanisms we can use:
* Holders: Something akin to my coin-weighted polling proposal here
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>;
.
* Transactors: Something akin to your transaction signaling proposal above.
Tho I would strongly suggest removing the tie between miner signaling and
transaction signaling to make it purely informational.
* Miner signaling as usual, or perhaps extended to provide a way for miners
to actively signal against a change
<https://github.com/fresheneesz/bip-trinary-version-signaling>;.

For developers, I would say we probably need to come to consensus with
discussion, but hopefully we could be a bit more structured about it. For
example, we could get rough measures of consensus by gathering explicit
reviews on a proposal. Opinions like "I don't like it" or "This is great,
let's do it!" would count for very little, reviews that look into a
particular section deeply or review the broad idea as a whole would count a
bit more, and reviews that discuss many good points and reasons about a
large fraction of the proposal would carry even more weight. This is of
course again subjective, but at least it would provide a framework to work
within, and a way to at least approximate a developer consensus weighted by
actual knowledge of and thought put into the subject. If we went further to
attempt to collect together these reviews in a structured way, it would
make it easier for someone to relatively quickly (ie by spending a few
hours reading through reviews) verify for themselves approximately what
consensus "is".

> 3. Can any of the answers to #2 be "gamed"?

As long as we understand the limitations of the measurements, I don't think
they can be gamed. However, they can leave a lot of room for doubt. Eg, a
coin-weighted poll might only have a response rate of 5% of the coin. If we
allow signals to both support or oppose a change, I think that would
substantially increase the meaningfulness of the data - at least we know
the consensus among those who care / are aware enough to signal (without
allowing opposition signaling, a low response rate means we have no idea
how many of the non signalers oppose a thing).

The transaction signaling can be gamed a bit, because someone can simply
spend more money to send more signals. This might favor bad actors a bit
(honest actors presumably wouldn't attempt to game the system).

Miner signaling doesn't really seem gameable.

TBH, developer consensus is probably the most gameable. All it is is talk.
Putting coin weight behind it would bias things, and often the
loudest/frequentest talkers get an advantage. Putting some major thought
into how to de-bias developer consensus seems like the most important thing
to figure out.

> Perhaps .. we are doomed to this painful process of arguing .. until
there's only one opinion left standing.. However, if this is the case, I
don't think we can honestly claim that devs don't control the protocol.

If we argue until the last left standing, is it even "the developers" in
control? Might it rather be the talkers, the yellers, the busy bodies? I
can't think of anyone worse being in control. I very much hope we're not
doomed to that fate. However, to avoid it, we need to come up with a
logical solution that is defendable and encodable into the social fabric of
bitcoin (just like sound money and nacho keys nacho cheese).

On Thu, Apr 28, 2022 at 12:18 AM Billy Tetrud <billy.tetrud at gmail.com>
wrote:

> @Felipe
> > the consensus should follow the current line: discussions and tests
> carried out by experts. We all know that the most important devs have the
> most weight in discussions. And that's how it should be
>
> We have up til this point been miraculously lucky that the vast majority
> of prominent bitcoin developers are in relative alignment on the big
> picture philosophy and have all seemed to be honest and open in general.
> However, we cannot rely on this era of philosopher kings to continue.
> Relying on experts in this way is an enormous attack vector. It should not
> be the "most important" devs who carry the most weight, but weight should
> be carried by the logic of what is being said. The speaker should ideally
> not matter in consensus building. So I agree with Keagan's implication that
> this is not how bitcoin should govern itself. We should move away from
> appeals to authority towards something more amorphous and difficult to
> control.
>
> @Jeremy
> > if there were a way to sign with a NUMS point for ring signature
> purposes
>
> Do you have any link you could point to about NUMS points? I assume this
> would be a way to aggregate coin-weighted signals in a way that helps hide
> who signaled in what direction?
>
> > if NUMS points are common these ring signatures protocols might not be
> too useful for collecting signals
>
> I'm curious: why is it better if its less common? I'm used to privacy
> properties increasing as the privacy technique used becomes more common.
>
> @Erik
> > it doesn't address the "what about people who don't know there's a vote
> going on"
> > how nonexperts can "have a say" when they simply don't understand the
> relevant issues.
>
> I think a useful way to think about this is in terms of preferences and
> representation, rather than in the terms of coming to the best technical
> solution. The fact of the matter is that value is subjective and therefore
> there is no "best" technical solution all the time. Sometimes the
> preferences of stakeholders must be weighed and a compromise come to.
> Hopefully most of these kinds of compromises can happen in the free market
> on upper layers. But certainly some of them happen on the consensus layer.
>
> An expert with deep knowledge can deeply understand a design or change
> well enough to come to a full opinion about it according to their
> preferences. But even other experts might not have read enough about a
> thing, or just don't have time to delve deeply into that particular aspect.
> They'll have to rely partly on their ability to make a determination from
> partial knowledge and their ability to evaluate the trustworthiness and
> skill of those who have deeper knowledge than them. Nonexperts and
> non-technical people have to rely on those kinds of things even more so.
> Many people only have social signals to rely on. What do the people they
> trust say?
>
> I believe that the truth gets out eventually. Those who have deep
> knowledge will eventually convince those who don't, tho that may take a
> long time to play out. As annoying as the twitterati is, I think we should
> get used to needing to give their opinions a bit of weight in terms of
> measuring consensus. Of course, we shouldn't be making technical decisions
> based on what nontechnical people want or think, however, what we should do
> is make sure that we are explaining the changes we propose to make clearly
> enough that a certainly level of comfort diffuses into the social circles
> of people who care about bitcoin but don't understand it at a technical
> enough level to participate in technical decision making. At a certain
> point, if not enough people are comfortable with a change, the change
> shouldn't be made yet until enough people are convinced its probably safe
> and probably good. Think of the large set of non-technical people to be a
> glue that connects together otherwise unconnected pockets of wisdom.
>
> Doing things this way would almost certainly lead to slower development.
> But development of the consensus layer slowing over time should be what we
> all expect, and I daresay what we should all want eventually.
>
> > it will just be a poll of "people who pay attention to the dev list and
> maybe some irc rooms"
>
> Maybe. But if there were mechanisms for broader consensus measuring,
> perhaps more would pay attention. Perhaps some way to affect change would
> lead more to have discussions and participate.
>
> Even if its a small group at first, I think it would be very useful
> information to see both who explicitly supports something, who explicitly
> is against something, and also who is paying attention but neutral (maybe
> even actively signaling as "neutral').
>
> > unless there's a great ux around the tooling my guess is that it won't
> garner a lot of meaningful data:
>
> I agree. Tooling would be very important here.
>
>
>
>
>
>
>
> On Wed, Apr 27, 2022 at 3:13 PM Erik Aronesty <erik at q32.com> wrote:
>
>>
>>>
>>> Have you taken a look at my proposal
>>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>;?
>>> The proposal is, to be clear, *not* "voting" but rather polling that isn't
>>> programmatically connected to activation. The intention is for people
>>> (developers) to look at the polling results and make an educated analysis
>>> of it as far as how it should contribute to consensus gathering.
>>>
>>
>> it's cool, and i agree it's somewhat censorship resistant
>>
>>
>>> Let's say everyone who participates in polling broadcasts it along the
>>> bitcoin network (a separate network would probably be better, so as to not
>>> interfere with normal bitcoin, but I digress),
>>>
>>
>> right, anyone can then publish a json file with polling aggregates at a
>> certain block height and anyone can quickly check to see if they are lying
>> or missing data
>>
>>
>>> Similar structures could be added to any script configuration to allow
>>> signing of polls without any significant exposure.
>>>
>>
>> rubin's suggestion around tapscript anon voting could help with anonymity
>>
>> .... all of this is cool ...
>>
>> but it doesn't address the "what about people who don't know there's a
>> vote going on" or other the other social issues with "weighted polling" in
>> general, like how nonexperts can "have a say" when they simply don't
>> understand the relevant issues. i personally feel like i'm "only a very
>> little bit up on the issues" and i have more tech knowledge than most
>> people i know
>>
>> also, it will just be a poll of "people who pay attention to the dev list
>> and maybe some irc rooms"
>>
>> might be worth experimenting with... but unless there's a great ux around
>> the tooling my guess is that it won't garner a lot of meaningful data:
>>
>> open source, simple cli, gitian build, installs easily on all platforms,
>> works well with bitcoind rpc, works with ledger, can import a seed, etc.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220428/4eac8acc/attachment-0001.html>;

📅 Original date posted:2022-04-27 📝 Original message:> A ...

2023-06-08T01:08:22+02:00

In reply to nevent1q…fgre
_________________________

📅 Original date posted:2022-04-27
📝 Original message:> A transaction signaling in the affirmative MUST NOT be included in a
block that does not signal in the affirmative

I feel like I've heard this idea somewhere before. Its an interesting idea.

It should be noted that there is a consequence of this: holders wouldn't
have much say. People that transact a lot (or happen to be transacting a
lot during the signaling time period) would have a very disproportionate
ability to pressure miners than people who aren't transacting much. This
would probably be a pretty good proxy for future mining revenue that
supports (or is against) a particular thing. However, the network does do
more than just transact, so I would be a bit worried that such a mechanism
would bias the system towards things that are good for transactors and bad
for holders. Things like more coin inflation, larger blocks, etc.

Another consideration is that miners are already incentivized to follow the
money here. Adding an *additional* incentive might be distorting the
market, so to speak.

An alternative I proposed was a way to do weighted polling of holders:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html

The polling wouldn't be directly connected to the activation mechanism in
any way, but would just be a mechanism to gauge some portion of consensus.
If enough people were involved, theoretically it could be hooked up to
activation, but I would be pretty wary of doing that directly as well.

> we should not let the wealthy make consensus decisions.

We shouldn't let the wealthy continue to control our governments. However,
bitcoin is not a government. Its a financial network. The fact of the
matter is that fundamentally, the economic majority controls where the
chain goes. Its very likely that the wealthy are disproportionately
represented in the economic majority. Attempting to subvert the economic
majority seems like a bad idea. The reality of control there will come out
one way or another, and being honest about it is probably the best way to
avoid major schisms in the future.

> Does a scheme like this afford us a better view into consensus than we
have today?

It does more than provide a view. It directly changes the game theory
around how activation works. If we wanted to simply get a better view into
consensus, we could allow the same thing, but allow any block to mine any
transaction regardless of transaction signaling. Then it would be more
purely informational.

> Can it be gamed to give us a *worse* view into consensus? How?
> Does it measure the right thing? If not, what do you think is the right
thing to measure?

Doesn't seem like it could be gamed, but as I mentioned above, the honest
mechanics of it might be themselves undesirably distorting.

On Tue, Apr 26, 2022 at 3:49 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> You may be interested in these posts on transaction signalling:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html
>
>
> On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Alongside the debate with CTV right now there's a second debate that was
>> not fully hashed out in the activation of Taproot. There is a lot of
>> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
>> etc. A significant reason for the breakdown in civility around this debate
>> is that because we don't have a means of measuring user support for
>> proposed sof-fork changes, it invariably devolves into people claiming that
>> their circles support/reject a proposal, AND that their circles are more
>> broadly representative of the set of Bitcoin users as a whole.
>>
>> It seems everyone in this forum has at one point or another said "I would
>> support activation of ____ if there was consensus on it, but there isn't".
>> This statement, in order to be true, requires that there exist a set of
>> conditions that would convince you that there is consensus. People have
>> tried to dodge this question by saying "it's obvious", but the reality is
>> that it fundamentally isn't. My bubble has a different "obvious" answer
>> than any of yours.
>>
>> Secondly, due to the trauma of the block size wars, no one wants to utter
>> a statement that could imply that miners have any influence over what
>> rulesets get activated or don't. As such "miner signaling" is consistently
>> devalued as a signal for market demand. I don't think this is reasonable
>> since following the events of '17 miners are aware that they have the
>> strong incentive that they understand market demand. Nevertheless, as it
>> stands right now the only signal we have to work with is miner signaling,
>> which I think is rightly frustrating to a lot of people.
>>
>> So how can we measure User Support for a proposed rule change?
>>
>> I've had this idea floating around in the back of my head for a while,
>> and I'd like to solicit some feedback here. Currently, all forms of
>> activation that are under consideration involve miner signaling in one form
>> or another. What if we could make it such that users could more directly
>> pressure miners to act on their behalf? After all, if miners are but the
>> humble servants of user demands, this should be in alignment with how
>> people want Bitcoin to behave.
>>
>> Currently, the only means users have of influencing miner decisions are
>> A. rejection of blocks that don't follow rules and B. paying fees for
>> transaction inclusion. I suggest we combine these in such a way that
>> transactions themselves can signal for upgrade. I believe (though am not
>> certain) that there are "free" bits in the version field of a transaction
>> that are presently ignored. If we could devise a mapping between some of
>> those free bits, and the signaling bits in the block header, it would be
>> possible to have rules as follows:
>>
>> - A transaction signaling in the affirmative MUST NOT be included in a
>> block that does not signal in the affirmative
>> - A transaction that is NOT signaling MAY be included in a block
>> regardless of that block's signaling vector
>> - (Optional) A transaction signaling in the negative MUST NOT be included
>> in a block that signals in the affirmative
>>
>> Under this set of conditions, a user has the means of sybil-resistant
>> influence over miner decisions. If a miner cannot collect the fees for a
>> transaction without signaling, the user's fee becomes active economic
>> pressure for the miner to signal (or not, if we include some variant of the
>> negative clause). In this environment, miners could have a better view into
>> what users do want, as would the Bitcoin network at large.
>>
>> Some may take issue with the idea that people can pay for the outcome
>> they want and may try to compare a method like this to Proof of Stake, but
>> there are only 3 sybil resistant mechanisms I am aware of, and any "real"
>> view into what social consensus looks like MUST be sybil resistant:
>>
>> - Hashpower
>> - Proof of personhood (KYC)
>> - Capital burn/risk
>>
>> Letting hashpower decide this is the thing that is currently contentious,
>> KYC is dead on arrival both on technical and social grounds, which really
>> just leaves some means of getting capital into the process of consensus
>> measurement. This mechanism I'm proposing is measurable completely
>> en-protocol and doesn't require trust in institutions that fork futures
>> would. Additionally it could be an auxiliary feature of the soft fork
>> deployment scheme chosen making it something you could neatly package all
>> together with the deployment itself.
>>
>> There are many potential tweaks to the design I propose above:
>> 1. Do we include a notion of negative signaling (allowing for the
>> possibility of rejection)
>> 2. Do we make it such that miner signaling must be congruent with >X% of
>> transactions, where congruence is that the signal must match any
>> non-neutral signal of transaction.
>>
>> Some anticipated objections:
>>
>> 1. signaling isn't voting, no deployment should be made without consensus
>> first.
>> - yeah well we can't currently measure consensus right now, so that's not
>> a super helpful thing to say and is breeding ground for abuse in the form
>> of certain people making the unsubstantiated claim that consensus does or
>> does not exist for a particular initiative
>>
>> 2. This is just a proposal for "pay to play", we should not let the
>> wealthy make consensus decisions.
>> - I agree that wealth should not be able to strong-arm decision making.
>> But the status quo seems even worse where we let publicly influential
>> people decide consensus in such a way where not only do they not "lose
>> ammunition" in the process of campaigning, but actually accrue it, creating
>> really bad long-term balances of power.
>>
>> 3. Enforcing this proposal requires its own soft fork.
>> - Yes. It does...and there's a certain cosmic irony to that, but before
>> we consider how to make this happen, I'd like to even discuss whether or
>> not it's a good idea.
>>
>> 4. This gives CoinJoin pool operators and L2 protocol implementations
>> power over deciding consensus.
>> - I see this as an improvement over the status quo
>>
>> 5. This encourages "spam"
>> - If you pay the fees, it's not spam.
>>
>> The biggest question I'd like to pose to the forum is:
>> - Does a scheme like this afford us a better view into consensus than we
>> have today?
>> - Can it be gamed to give us a *worse* view into consensus? How?
>> - Does it measure the right thing? If not, what do you think is the right
>> thing to measure? (assuming we could)
>> - Should I write a BIP spec'ing this out in detail?
>>
>> Cheers,
>> Keagan
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> - Bryan
> https://twitter.com/kanzure
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220426/6f7eba77/attachment-0001.html>;

📅 Original date posted:2022-04-23 📝 Original message:@Zac ...

2023-06-08T01:07:51+02:00

In reply to nevent1q…743u
_________________________

📅 Original date posted:2022-04-23
📝 Original message:@Zac
> More use cases means more blockchain usage which increases the price of
a transaction for *everyone*.

This is IMO a ridiculous opposition. Anything that increases the utility of
the bitcoin network will increase usage of the blockchain and increase the
price of a transaction on average. It is absurd to say such a thing is bad
for bitcoin. Its like the old saying: "nobody goes there any more - its too
crowded".

> I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
users.

This is a fair opinion to take on the face of it. However, I completely
disagree with it. Why must any change benefit *all* users? Did segwit
benefit all users? Did taproot? What if an upgrade benefits 90% of users
a LOT and at the same time doesn't negatively affect the other 10%? Is that
a bad change? I think you'd find it very difficult to argue it is.

Regardless of the above, I think CTV *does *in fact likely provide
substantial benefit to all users in the following ways:

1. CTV allows much easier/cheaper ways of improving their security via
wallet vaults, DLCs, channels, and many other use cases. This means both
societal benefit that grows the value of the bitcoin network and on-chain
benefit that reduces the fees people have to pay for certain utility, which
leads to lower fees for everyone.

2. Wallet vaults specifically, that CTV would unlock, would make it
substantially easier and cheaper to hold funds in a multi key vault (akin
to but better than a classic multisig wallet). This could substantially
increase the fraction of users that self-custody their bitcoin. This
increased self-custodiation would substantially improve the
decentralization of bitcoin in terms of holdership which is an important
part of bitcoin's resilience, which would be a huge benefit to anyone that
holds bitcoin or relies on the bitcoin network in any way.

Even if a minority (eg 20%) of bitcoin users use CTV, it would have a
substantial positive effect for everyone because of these things.

On Fri, Apr 22, 2022 at 10:40 AM Corey Haddad via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> >*A change that increases the number of use cases of Bitcoin affects all
> users and is *not* non-invasive. More use cases means more blockchain usage
> which increases the price of a transaction for *everyone*.*
>
> This manages to be both incorrect and philosophically opposed to what
> defines success of the project . Neither the number of ways that people
> figure out how to innovatively harness Bitcoin's existing capabilities, nor
> the number or complexity of any optional transaction types that the Bitcoin
> protocol supports have any bearing on transaction fees. Demand for
> blockspace from transactions, which is just plain *use* - and not *use
> cases* - is what could drive up transaction fees.
>
> On the philosophical level, as designers of the system, we all hope and
> work to make Bitcoin so useful, appealing, and secure that there is massive
> demand for blockspace, even in the face of high transaction fees. As an
> individual thinking only of their next on-chain transaction, it is
> understandable that one might hope for low fees and partially-filled
> blocks. Longer term, the health of the system can both be measured by and
> itself depends on high transaction demand and fee pressure.
>
> If you were trying to argue that CTV is invasive because it may increase
> transaction demand and therefore cost users more fees, that is 1) an
> endorsement of CTV's desirability and 2) reveals that you consider any
> increased free-market competition (i.e. more demand) to be "invasive".
>
>
> *>I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
> users. *
>
> As for Peter Todd's "any change of Bitcoin must benefit *all* users", that
> is absolutely a reasonable thing to consider. However, in order to make
> practical use of that maxim, we must adopt in our minds a *generic*, or
> "model user", and then replicate them so that we may meaningfully
> understand a least a proxy for "all users". In reality, there will always
> be someone (and at this point, probably a "user" too) who wouldn't benefit
> from a change, or at least think they won't. Some users of Bitcoin may even
> want Bitcoin to fail, so we cannot afford assume that people have alignment
> of goals or vision just by virtue of being a 'user'.
>
> Corey
>
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220423/1bd348d3/attachment.html>;

📅 Original date posted:2022-04-24 📝 Original message:@Matt ...

2023-06-08T01:07:45+02:00

In reply to nevent1q…xzdn
_________________________

📅 Original date posted:2022-04-24
📝 Original message:@Matt
> both of which are somewhat frustrating limitations, but not security
limitations, only practical ones.

So I think the first limitation you mentioned (that if your hot wallet's
key gets stolen you need) can be legitimately considered a security
limitation. Not because you need to rotate your keys, but because you might
*not know* your hot wallet key has been stolen. If you unvault an output to
your hot wallet, the thief could be lying in wait, ready to steal those
funds upon them landing. At that point, you would then know your hot wallet
key was compromised and could rotate your vault keys in order to prevent
further theft. However, the fact that there is a clear theft vulnerability
is something I would say should be considered a "security limitation".

As you mentioned, this is of course also a security limitation of a hot
wallet, so this setup definitely has a lot of advantages over a simple hot
wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
you can see that while theft of a single key would never result in any
theft in that setup, it could in a CTV vault. The other trade offs there
are ones of practicality and convenience.

This isn't to say a CTV vault wouldn't be useful. Just that it has
significant trade offs.

@Russel
> the original MES vault .. commits to the destination address during
unvaulting

I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
for me to understand that it does that. However, I can imagine how it
*might* do that.

One possibility is that the intended destination is predetermined and
hardcoded. This wouldn't be very useful, and also wouldn't be different
than how CTV could do it, so I assume that isn't what you envisioned this
doing.

I can imagine instead that the definition of the pattern could be specified
as a number indicating the number of stack items in the pattern, followed
by that number of stack items. If that's how it is done, I can see the user
inputting an intended destination script (corresponding to the intended
destination address) which would then be somehow rotated in to the right
spot within the pattern, allowing the pattern to specify the coins
eventually reaching an address with that script. However, this could be
quite cumbersome, and would require fully specifying the scripts along the
covenant pathways leading to a fair amount of information duplication
(since scripts must be specified both in the covenant and in spending the
subsequent output). Both of these things would seem to make OP_COV in
practice quite an expensive opcode to spend with. It also means that, since
the transactor must fully specify the script, its not possible to take
advantage of taproot's script hiding capabilities (were it to send to a
taproot address).

However, my assumptions might be incorrect. If you think OP_COV would be a
useful opcode, I would encourage you to write up a complete specification.

> What ways can we build a secured vault that commits to the destination
address?

Some kind of passed-through state allows doing this. With OP_COV (if my
assumptions above are correct), the intended destination can be passed
through the output script pattern(s). With my own proposed
op_pushoutputstack
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>;,
state is passed as an attachment on the output more directly. Curious what
you think about that proposal.

> Are there elegant ways of building secure vaults by using CTV plus
something else.

Since CTV predefines all the transactions that can happen under its
control, passed state like this can't help because any dynamic state would
change the template and render the CTV transaction invalid. I don't see any
way of solving this problem for CTV.

I'm curious how you think op_cat could enable this with CTV (other than the
cat+schnorr tricks that don't require CTV at all).

On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Okay, Matt explained to me the intended application of CTV vaults off
> list, so I have a better understanding now.
>
> The CTV vault scheme is designed as an improvement over the traditional
> management of hot-wallets and cold-wallets. The CTV vault is logically on
> the "cold-side" and lets funds be sent from the "cold" side to *one's own*
> the hot wallet after the unvaulting delay. In this case, the hot wallet
> funds are always at risk, so it isn't unexpected that those funds could be
> stolen. After all, that is how hot wallets are today. The advantage is
> that funds can be moved from the "cold" side without needing to dig out the
> cold keys.
>
> The MES vault scheme applies to a different scenario. In the MES case it
> is the hot funds are inside the vault, and it is the hot key that unvaults
> the funds and sends them to *customer's addresses* after a delay. If the
> hot-key is used in any unauthorised way, then funds can be sent to the
> address of the cold key (the MES vault actually does something fancy in
> case of recovery, but it could be adapted to simply send funds to a cold
> wallet).
>
> The MES vault lie somewhere between "better" and "different" when compared
> to the CTV vault. If one is unwilling to use the MES vault on the hot side
> and have every withdrawl vetted, then, while you could use the MES design
> on the cold side like the CTV vault, it wouldn't really offer you any
> advantages over a CTV vault. However, if you are interested in managing
> all your payments through a vault (as I've been imagining) then the CTV
> vault comes across as ineffective when compared to an MES style vault.
>
> On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> Still trying to make sure I understand this concern, let me know if I get
>> this all wrong.
>>
>> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
>> > It's not the attackers *only choice to succeed*. If an attacker steals
>> the hot key, then they have
>> > the option to simply wait for the user to unvault their funds of their
>> own accord and then race /
>> > outspend the users transaction with their own. Indeed, this is what we
>> expect would happen in the
>> > dark forest.
>>
>> Right, a key security assumption of the CTV-based vaults would be that
>> you MUST NOT EVER withdraw
>> more in one go than your hot wallet risk tolerance, but given that your
>> attack isn't any worse than
>> simply stealing the hot wallet key immediately after a withdraw.
>>
>> It does have the drawback that if you ever get a hot wallet key stole you
>> have to rotate all of your
>> CTV outputs and your CTV outputs must never be any larger than your hot
>> wallet risk tolerance
>> amount, both of which are somewhat frustrating limitations, but not
>> security limitations, only
>> practical ones.
>>
>> > And that's not even mentioning the issues already noted by the document
>> regarding fee management,
>> > which would likely also benefit from a less constrained design for
>> covenants.
>>
>> Of course I've always been in favor of a less constrained covenants
>> design from day one for ten
>> reasons, but that's a whole other rabbit hole :)
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220424/d2cb24bb/attachment-0001.html>;

📅 Original date posted:2022-04-23 📝 Original message:> ...

2023-06-08T01:07:43+02:00

In reply to nevent1q…y0jy
_________________________

📅 Original date posted:2022-04-23
📝 Original message:> If an attacker steals the hot key, then they have the option to simply
wait for the user to unvault their funds

This is definitely true. Its kind of a problem with most vault proposals.
Its one of the primary reasons I designed an alternative proposal
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults>;. The
OP_BEFOREBLOCKVERIFY opcode I proposed solves this security hole by
automatically swapping control of the UTXO over to the intended recipient
after a timeout. Alternatively, if OP_BBV weren't available, OP_POS in
conjunction with OP_CD could encode things such that the transaction
with the hot key could only spend to the intended recipient.

I'm curious if there are any other covenant proposals that have a solution
to that problem. I'm not aware of any that do other than my proposal.

On Fri, Apr 22, 2022 at 12:25 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This vault design (https://github.com/jamesob/simple-ctv-vault)
>> is a good benchmark for evaluating covenant proposals because it's (i)
>> simple and (ii) has high utility for many users of Bitcoin. I would
>> love to see it implemented in one or all of these alternatives, but I
>> am almost certain no one will do it in the next few months because the
>> implementations, tooling, and in some cases even complete
>> specifications do not exist.
>>
>
> Quoting from the link above:
> Detecting theft
>
> This unvault step is critical because it allows us to detect unexpected
> behavior. If an attacker had stolen our hot wallet keys, their only choice
> to succeed in the theft is to trigger an unvault.
>
>
> It's not the attackers *only choice to succeed*. If an attacker steals
> the hot key, then they have the option to simply wait for the user to
> unvault their funds of their own accord and then race / outspend the users
> transaction with their own. Indeed, this is what we expect would happen in
> the dark forest.
>
> A key feature of the MES vault design is that the destination address is
> included, and committed to, by the unvaulting step. However, this can only
> be achieved with a less constrained design for covenants.
>
> I suppose I can see that the damage from a hot key theft could be more
> contained under some circumstances using a CTV vault, but let us not
> overstate the value of the CTV vault.
>
> And that's not even mentioning the issues already noted by the document
> regarding fee management, which would likely also benefit from a less
> constrained design for covenants.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220422/cd3d2e54/attachment-0001.html>;

📅 Original date posted:2022-03-31 📝 Original message:> I ...

2023-06-08T01:06:23+02:00

In reply to nevent1q…mnvv
_________________________

📅 Original date posted:2022-03-31
📝 Original message:> I am not trying to convince you

If that's really true then you're wasting my and everyone's time here.

> Signaling period is a waste of time if mining pools that agreed on a soft
fork earlier do politics

They can and will do politics regardless of why misunderstandings about
signaling. This is not a relevant point.

> It is considered as voting not just by people outside Bitcoin but the
participants itself

This is not a concrete downside. You are simply restating the premise.

> It gives miners an edge over economic nodes that enforce consensus rules

This is completely false. I have to assume you don't include yourself in
the list of users who think a passing vote of miners is required to upgrade
Bitcoin. Am I wrong? If not, then you should know that this
misunderstanding gives no one an edge.

So I'm counting 0 concrete downsides of this misunderstanding of how
signaling works that are both relevant and true. I'm going to stick with my
conclusion that this is a pointless dead end argument to make about soft
fork deployment in particular, and literally any technical design in
general.

You will be able to find 3 people who misunderstand BIP8, or literally any
other thing you come up with. You could probably find thousands. Or
millions if you ask people who've never heard of it. The argument that
changing the design will somehow improve that situation is perplexing, but
the argument that changing the idea might be a good idea on that basis is
completely unconscionable.

On Thu, Mar 31, 2022, 09:19 pushd <pushd at protonmail.com> wrote:

> > Why do you care what they think? Why does it matter if they
> misunderstand?
>
> I care about improving soft fork activation mechanism and shared one of
> the advantages that helps avoid misleading things. It matters because they
> are participants in this process.
>
>
> > If the people aren't imaginary, then its their importance that's
> imaginary.
>
> Neither the people nor their importance is imaginary. They are a part of
> Bitcoin and as important as our opinion about soft forks on this mailing
> list.
>
>
> > This isn't even sufficient evidence that they don't understand.
>
> One example of an exchange:
>
> One example of a user:
> https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/
>
> 3 examples for each (user, mining pool and exchange) are enough to discuss
> a problem or list advantages of BIP 8/LOT=TRUE. I can create an archive
> with more if it helps during next soft fork.
>
>
> > You haven't convinced me this is a significant problem. What are the
> concrete downsides? Why do you think this can't be fixed by simple
> persistent explaining?
>
> I am not trying to convince you and we can have different opinions.
>
> Downsides:
>
> - Signaling period is a waste of time if mining pools that agreed on a
> soft fork earlier do politics or influenced by councils such as BMC or
> governments during signaling
>
> - It is considered as voting not just by people outside Bitcoin but the
> participants itself
>
> - It gives miners an edge over economic nodes that enforce consensus rules
>
> Simple persistent explaining has not helped in last few years. I don't see
> anything wrong in listing this as one of the advantages for BIP8/LOT=TRUE.
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
>
> ------- Original Message -------
> On Thursday, March 31st, 2022 at 10:01 AM, Billy Tetrud <
> billy.tetrud at gmail.com> wrote:
>
> > Many users, miners and exchanges still think its voting
>
> Why do you care what they think? Why does it matter if they misunderstand?
>
> > it is not an imaginary group of people
>
> If the people aren't imaginary, then its their importance that's imaginary.
>
> > One example of a mining pool
>
> This isn't even sufficient evidence that they don't understand. Its quite
> possible they're using the word "voting" loosely or that they don't
> understand english very well. And again, so what if they tweet things that
> are not correctly worded? This is not a reason to change how we design
> bitcoin soft forks.
>
> Its not even wrong to say that a particular signaling round is very much
> like voting. What's wrong is saying that bitcoin upgrades are made if and
> only if miners vote to approve those changes.
>
> > I see a problem that exists
>
> You haven't convinced me this is a significant problem. What are the
> concrete downsides? Why do you think this can't be fixed by simple
> persistent explaining? You can find groups of people who misunderstand
> basically any aspect of bitcoin. The solution to people misunderstanding
> the design is never to change how bitcoin is designed.
>
>
> On Wed, Mar 30, 2022 at 4:14 PM pushd <pushd at protonmail.com> wrote:
>
>> > No it does not. This narrative is the worst. A bad explanation of
>> speedy trial can mislead people into thinking miner signalling is how
>> Bitcoin upgrades are voted in. But a bad explanation can explain anything
>> badly.
>>
>> I agree it is worst but why do you think this narrative exists? People
>> have tried explaining it. Many users, miners and exchanges still think its
>> voting. I think the problem is with activation method so BIP 8/LOT=TRUE is
>> a solution.
>>
>>
>> > The solution is not to change how we engineer soft forks, it's to
>> explain speedy trial better to this imaginary group of important people
>> that think miner signaling is voting.
>>
>> We can suggest different solutions but the problem exists and it is not
>> an imaginary group of people.
>>
>> One example of a mining pool: https://archive.ph/oyH04
>>
>>
>> > We shouldn't change how we engineer Bitcoin because of optics. I
>> completely object to that point continuing to be used.
>>
>> Voting as described on wiki is quite similar to what happens during
>> miners signaling followed by activation if a certain threshold is reached.
>> If some participants in this process consider it voting instead of
>> signaling for readiness then listing advantages of a better activation
>> method should help everyone reading this thread/email.
>>
>> Sorry, I don't understand your objection. I see a problem that exists
>> since years and a better activation method fixes it. There are other
>> positives for using BIP 8/LOT=TRUE which I shared in
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html
>>
>> I will continue to discuss this problem with solutions until we use
>> better activation methods for future soft forks in any discussion about
>> activation methods.
>>
>>
>> pushd
>> ---
>>
>> parallel lines meet at infinity?
>>
>> ------- Original Message -------
>> On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud <
>> billy.tetrud at gmail.com> wrote:
>>
>> @Pushd
>>
>> > Speedy trial makes it worse by misleading lot of bitcoin users
>> including miners to consider signaling as voting and majority votes decide
>> if a soft fork gets activated
>>
>> No it does not. This narrative is the worst. A bad explanation of speedy
>> trial can mislead people into thinking miner signalling is how Bitcoin
>> upgrades are voted in. But a bad explanation can explain anything badly.
>> The solution is not to change how we engineer soft forks, it's to explain
>> speedy trial better to this imaginary group of important people that think
>> miner signaling is voting.
>>
>> We shouldn't change how we engineer Bitcoin because of optics. I
>> completely object to that point continuing to be used.
>>
>> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> > Any case where a flawed proposal makes it through getting activation
>>> parameters set and released, but doesn't achieve supermajority hashpower
>>> support is made worse by bip8/lot=true in comparison to speedy trial.
>>>
>>> - Flawed proposal making it through activation is a failure of review
>>> process
>>>
>>> - Supermajority hashpower percentage decided by bitcoin core developers
>>> can choose to not follow old or new consensus rules at any point
>>>
>>> - Speedy trial makes it worse by misleading lot of bitcoin users
>>> including miners to consider signaling as voting and majority votes decide
>>> if a soft fork gets activated
>>>
>>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus
>>> rules as they do right now if they wish to mine blocks for subsidy and fees.
>>>
>>>
>>> Note: Mining pools or individual miners can participate in soft fork
>>> discussions regardless of activation method and share their concern which
>>> can be evaluated based on technical merits.
>>>
>>>
>>> pushd
>>> ---
>>>
>>> parallel lines meet at infinity?
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at 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/20220331/772c73bb/attachment-0001.html>;

📅 Original date posted:2022-03-31 📝 Original message:> ...

2023-06-08T01:06:22+02:00

In reply to nevent1q…gcxq
_________________________

📅 Original date posted:2022-03-31
📝 Original message:> Many users, miners and exchanges still think its voting

Why do you care what they think? Why does it matter if they misunderstand?

> it is not an imaginary group of people

If the people aren't imaginary, then its their importance that's imaginary.

> One example of a mining pool

This isn't even sufficient evidence that they don't understand. Its quite
possible they're using the word "voting" loosely or that they don't
understand english very well. And again, so what if they tweet things that
are not correctly worded? This is not a reason to change how we design
bitcoin soft forks.

Its not even wrong to say that a particular signaling round is very much
like voting. What's wrong is saying that bitcoin upgrades are made if and
only if miners vote to approve those changes.

> I see a problem that exists

You haven't convinced me this is a significant problem. What are the
concrete downsides? Why do you think this can't be fixed by simple
persistent explaining? You can find groups of people who misunderstand
basically any aspect of bitcoin. The solution to people misunderstanding
the design is never to change how bitcoin is designed.

On Wed, Mar 30, 2022 at 4:14 PM pushd <pushd at protonmail.com> wrote:

> > No it does not. This narrative is the worst. A bad explanation of
> speedy trial can mislead people into thinking miner signalling is how
> Bitcoin upgrades are voted in. But a bad explanation can explain anything
> badly.
>
> I agree it is worst but why do you think this narrative exists? People
> have tried explaining it. Many users, miners and exchanges still think its
> voting. I think the problem is with activation method so BIP 8/LOT=TRUE is
> a solution.
>
>
> > The solution is not to change how we engineer soft forks, it's to
> explain speedy trial better to this imaginary group of important people
> that think miner signaling is voting.
>
> We can suggest different solutions but the problem exists and it is not an
> imaginary group of people.
>
> One example of a mining pool: https://archive.ph/oyH04
>
>
> > We shouldn't change how we engineer Bitcoin because of optics. I
> completely object to that point continuing to be used.
>
> Voting as described on wiki is quite similar to what happens during miners
> signaling followed by activation if a certain threshold is reached. If some
> participants in this process consider it voting instead of signaling for
> readiness then listing advantages of a better activation method should help
> everyone reading this thread/email.
>
> Sorry, I don't understand your objection. I see a problem that exists
> since years and a better activation method fixes it. There are other
> positives for using BIP 8/LOT=TRUE which I shared in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html
>
> I will continue to discuss this problem with solutions until we use better
> activation methods for future soft forks in any discussion about activation
> methods.
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
>
> ------- Original Message -------
> On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud <
> billy.tetrud at gmail.com> wrote:
>
> @Pushd
>
> > Speedy trial makes it worse by misleading lot of bitcoin users
> including miners to consider signaling as voting and majority votes decide
> if a soft fork gets activated
>
> No it does not. This narrative is the worst. A bad explanation of speedy
> trial can mislead people into thinking miner signalling is how Bitcoin
> upgrades are voted in. But a bad explanation can explain anything badly.
> The solution is not to change how we engineer soft forks, it's to explain
> speedy trial better to this imaginary group of important people that think
> miner signaling is voting.
>
> We shouldn't change how we engineer Bitcoin because of optics. I
> completely object to that point continuing to be used.
>
> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > Any case where a flawed proposal makes it through getting activation
>> parameters set and released, but doesn't achieve supermajority hashpower
>> support is made worse by bip8/lot=true in comparison to speedy trial.
>>
>> - Flawed proposal making it through activation is a failure of review
>> process
>>
>> - Supermajority hashpower percentage decided by bitcoin core developers
>> can choose to not follow old or new consensus rules at any point
>>
>> - Speedy trial makes it worse by misleading lot of bitcoin users
>> including miners to consider signaling as voting and majority votes decide
>> if a soft fork gets activated
>>
>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus
>> rules as they do right now if they wish to mine blocks for subsidy and fees.
>>
>>
>> Note: Mining pools or individual miners can participate in soft fork
>> discussions regardless of activation method and share their concern which
>> can be evaluated based on technical merits.
>>
>>
>> pushd
>> ---
>>
>> parallel lines meet at infinity?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at 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/20220330/88f65484/attachment.html>;

📅 Original date posted:2022-03-30 📝 Original message:@Pushd ...

2023-06-08T01:06:21+02:00

In reply to nevent1q…8s38
_________________________

📅 Original date posted:2022-03-30
📝 Original message:@Pushd

> Speedy trial makes it worse by misleading lot of bitcoin users including
miners to consider signaling as voting and majority votes decide if a soft
fork gets activated

No it does not. This narrative is the worst. A bad explanation of speedy
trial can mislead people into thinking miner signalling is how Bitcoin
upgrades are voted in. But a bad explanation can explain anything badly.
The solution is not to change how we engineer soft forks, it's to explain
speedy trial better to this imaginary group of important people that think
miner signaling is voting.

We shouldn't change how we engineer Bitcoin because of optics. I completely
object to that point continuing to be used.

On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> > Any case where a flawed proposal makes it through getting activation
> parameters set and released, but doesn't achieve supermajority hashpower
> support is made worse by bip8/lot=true in comparison to speedy trial.
>
> - Flawed proposal making it through activation is a failure of review
> process
>
> - Supermajority hashpower percentage decided by bitcoin core developers
> can choose to not follow old or new consensus rules at any point
>
> - Speedy trial makes it worse by misleading lot of bitcoin users including
> miners to consider signaling as voting and majority votes decide if a soft
> fork gets activated
>
> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus
> rules as they do right now if they wish to mine blocks for subsidy and fees.
>
>
> Note: Mining pools or individual miners can participate in soft fork
> discussions regardless of activation method and share their concern which
> can be evaluated based on technical merits.
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220330/60a6697e/attachment.html>;

📅 Original date posted:2022-03-22 📝 Original message:> ...

2023-06-08T01:06:10+02:00

In reply to nevent1q…trev
_________________________

📅 Original date posted:2022-03-22
📝 Original message:> If you vote by making transactions, then someone could capture that and
broadcast to nodes
> you can only send that to your network

What do you mean "capture that" and "your network"? I was imagining a
scenario where these poll messages are always broadcast globally. Are you
implying more of a private poll?

> If it will be sent anywhere else, it will be invalid

I still don't understand. Why would a signed transaction be invalid
anywhere? Wouldn't a signed transaction be valid everywhere?

> Another reason to sign transactions and not just some custom data is to
make it compatible with "signet way of making signatures", the same as used
in signet challenge.

Perhaps I don't understand how signet works well enough to understand this,
but I would think that signing an message would work with signet just as
well as mainnet. I get the feeling perhaps we're misunderstanding each
other in some fundamental way.

> Even if it is not needed, it is kind of "free" if you take transaction
size into account

But it would require an on-chain transaction. We don't want 6 billion
people to have to send an on-chain transaction all in the same week in
order to register their preference on something.

On Mon, Mar 21, 2022 at 10:56 AM <vjudeu at gazeta.pl> wrote:

> > I don't quite understand this part. I don't understand how this would
> make your signature useless in a different context. Could you elaborate?
>
> It is simple. If you vote by making transactions, then someone could
> capture that and broadcast to nodes. If your signature is "useless in a
> different context", then you can only send that to your network. If it will
> be sent anywhere else, it will be invalid, so also useless. Another reason
> to sign transactions and not just some custom data is to make it compatible
> with "signet way of making signatures", the same as used in signet
> challenge.
>
> > I don't think any kind of chain is necessary to store this data.
>
> Even if it is not needed, it is kind of "free" if you take transaction
> size into account. Because each person moving coins on-chain could attach
> "OP_RETURN <commitment>" in TapScript, just to save commitments. Then, even
> if someone is not in your network from the very beginning, that person
> could still collect commitments and find out how they are connected with
> on-chain transactions.
>
> > Perhaps one day it could be used for something akin to voting, but
> certainly if we were going to implement this to help decide on the next
> soft fork, it would very likely be a quite biased set of responders.
>
> If it will be ever implemented, it should be done in a similar way as
> difficulty: if you want 90%, you should calculate, what amount in satoshis
> is needed to reach that 90%, and update it every two weeks, based on all
> votes. In this way, you reduce floating-point operations to a bare minimum,
> and have a system, where you can compare uint64 amounts to quickly get
> "yes/no" answer to the question, if something should be triggered (also,
> you can compress it to 32 bits in the same way as 256-bit target is
> compressed).
>
> > But on that note, I was thinking that it might be interesting to have an
> optional human readable message into these poll messages.
>
> As I said, "OP_RETURN <commitment>" inside TapScript is enough to produce
> all commitments of arbitrary size for "free", so that on-chain transaction
> size is constant, no matter how large that commitment is. And about
> storage: you could create a separate chain for that, you could store that
> in the same way as LN nodes store data, you could use something else, it
> doesn't really matter, because on-chain commitments could be constructed in
> the same way (also, as long as the transaction creator keeps those
> commitments as a secret, there is no way to get them; that means you can
> add them later if needed and easily pretend that "it was always possible").
>
>
> On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good Evening ZmnSCPxj,
>
>
> > I need to be able to invalidate the previous signal, one that is tied
> to the fulfillment of the forwarding request.
>
>
> You're right that there's some nuance there. You could add a block hash
> into the poll message and define things so any subsequent poll message sent
> with a newer block hash overrides the old poll message at the block with
> that hash and later blocks. That way if a channel balance changes
> significantly, a new poll message can be sent out.
>
>
> Or you could remove the ability to specify fractional support/opposition
> and exclude multiparty UTXOs from participation. I tend to like the idea of
> the possibility of full participation tho, even in a world that mainly uses
> lightning.
>
>
> > if the signaling is done onchain
>
>
> I don't think any of this signaling needs to be done on-chain. Anyone who
> wants to keep a count of the poll can simply collect together all these
> poll messages and count up the weighted preferences. Yes, it would be
> possible for one person to send out many conflicting poll messages, but
> this could be handled without any commitment to the blockchain. A simple
> thing to do would be to simply invalidate poll messages that conflict (ie
> include them both in your list of counted messages, but ignore them in your
> weighted-sums of poll preferences). As long as these polls are simply used
> to inform action rather than to trigger action, it should be ok that
> someone can produce biased incomplete counts, since anyone can show a
> provably more complete set (a superset) of poll messages. Also, since this
> would generally be a time-bound thing, where this poll information would
> for example be used to gauge support for a soft fork, there isn't much of a
> need to keep the poll messages on an immutable ledger. Old poll data is
> inherently not very practically useful compared to recent poll data. So we
> can kind of side step things like history attacks by simply ignoring polls
> that aren't recent.
>
>
> > Semantically, we would consider the "cold" key to be the "true" owner of
> the fund, with "hot" key being delegates who are semi-trusted, but not as
> trusted as the "cold" key.
>
>
> I'm not sure I agree with those semantics as a hard rule. I don't consider
> a "key" to be an owner of anything. A person owns a key, which gives them
> access to funds. A key is a tool, and the owner of a key or wallet vault
> can define whatever semantics they want. If they want to designate a hot
> key as their poll-signing key, that's their prerogative. If they want to
> require a cold-key as their message-signing key or even require multisig
> signing, that's up to them as well. You could even mirror wallet-vault
> constructs by overriding a poll message signed with fewer key using one
> signed with more keys. The trade offs you bring up are reasonable
> considerations, and I think which trade offs to choose may vary by the
> individual in question and their individual situation. However, I think the
> time-bound and non-binding nature of a poll makes the risks here pretty
> small for most situations you would want to use this in (eg in a soft-fork
> poll). It should be reasonable to consider any signed poll message valid,
> regardless of possibilities of theft or key renting shinanigans. Nacho keys
> nacho coins would of course be important in this scenario.
>
>
> > if I need to be able to somehow indicate that a long-term-cold-storage
> UTXO has a signaling pubkey, I imagine this mechanism of indioating might
> itself require a softfork, so you have a chicken-and-egg problem...
>
>
> If such a thing did need a soft fork, the chicken and egg question would
> be easy to answer: the soft fork comes first. We've done soft forks before
> having this mechanism, and if necessary we could do another one to enable
> it.
>
>
> However, I think taproot can enable this mechanism without a soft fork. It
> should be possible to include a taproot leaf that has the data necessary to
> validate a signaling signature. The tapleaf would contain an invalid script
> that has an alternative interpretation, where your poll message can include
> the merkle path to tapleaf (the invalid-script), and the data at that leaf
> would be a public key you can then verify the signaling signature against.
>
>
> @vjudeu
>
> > It should not be expressed in percents, but in amounts
>
>
> Agreed. You make a good case for that.
>
>
> > it could be just some kind of transaction, where you have utxo_id just
> as transaction input, amount of coins as some output, and then add your
> message as "OP_RETURN <commitment>" in your input, in this way your
> signature would be useless in a different context than voting.
>
> I don't quite understand this part. I don't understand how this would make
> your signature useless in a different context. Could you elaborate?
>
> > it does not really matter if you store that commitments on-chain to
> preserve signalling results in consensus rules or if there would be some
> separate chain for storing commitments and nothing else
>
> I don't think any kind of chain is necessary to store this data. I'm
> primarily suggesting this as a method to help the debate about a soft fork
> have better information about what broader users think about a particular
> soft fork proposal, so such data would simply inform whether or not we
> decide to continue work on an upgrade. I don't think you'd want to require
> any validation of this data by all full nodes, because the data could be
> hundreds of gigabytes in size (let's say 1 billion people respond). You'd
> have to run some kind of random sampling (more like actual proof of stake)
> to get this data down to a manageable size.
>
>
> > It would be Proof of Stake, where users would put their coins at stake
> to vote.
>
>
> Sure, as long as by this you mean simply proof of coin ownership. Just as
> any bitcoin transaction involves proof of coin ownership.
>
>
> I was pretty careful to avoid the word "voting", since I'm not proposing
> that this be used with definite thresholds that trigger action, but more of
> an information gathering mechanism. Perhaps one day it could be used for
> something akin to voting, but certainly if we were going to implement this
> to help decide on the next soft fork, it would very likely be a quite
> biased set of responders. We would want to take that into account when
> deciding how to interpret the data. Even with biased data tho, it could be
> a useful tool for resolving some contention.
>
>
> But on that note, I was thinking that it might be interesting to have an
> optional human readable message into these poll messages. Those messages
> could be then read through to gain a better understanding of why people are
> supporting and why people are rejecting a particular thing. It could inform
> how we might change how we explain a technical change to make it easier for
> less technical folks (who don't post on twitter) to understand. It could
> potentially give insight into an otherwise quiet majority (or large
> minority).
>
>
> > it sounds similar to "Merged Signing"
>
>
> Interesting. I'm not sure I fully grok his idea, but I think he was
> suggesting that a proof of stake consensus protocol pay attention to
> bitcoin transactions formatted in a particular way. I think I've hopefully
> clarified above why the idea I'm suggesting is rather different from this
> (eg in that no special commitments need to be made).
>
>
> Cheers,
> BT
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Billy,
>
> > @Jorge
> > > Any user polling system is going to be vulnerable to sybil attacks.
> >
> > Not the one I'll propose right here. What I propose specifically is
> a coin-weighted signature-based poll with the following components:
> > A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90%
> support:10%}> for each UTXO they want to respond to the poll with.
> > B. A signed message like that is valid only while that UTXO has not been
> spent.
> > C. Poll results are considered only at each particular block height,
> where the support and opposition responses are weighted by the UTXO amount
> (and the support/oppose fraction in the message). This means you'd
> basically see a rolling poll through the blockchain as new signed poll
> messages come in and as their UTXOs are spent.
> >
> > This is not vulnerable to sybil attacks because it requires access to
> UTXOs and response-weight is directly tied to UTXO amount. If someone signs
> a poll message with a key that can unlock (or is in some other designated
> way associated with) a UTXO, and then spends that UTXO, their poll response
> stops being counted for all block heights after the UTXO was spent.
> >
> > Why put support and oppose fractions in the message? Who would want to
> both support and oppose something? Any multiple participant UTXO would. Eg
> lightning channels would, where each participant disagrees with the other.
> They need to sign together, so they can have an agreement to sign for the
> fractions that match their respective channel balances (using a force
> channel close as a last resort against an uncooperative partner as usual).
>
> This does not quite work, as lightning channel balances can be changed at
> any time.
> I might agree that you have 90% of the channel and I have 10% of the
> channel right now, but if you then send a request to forward your funds
> out, I need to be able to invalidate the previous signal, one that is tied
> to the fulfillment of the forwarding request.
> This begins to add complexity.
>
> More pointedly, if the signaling is done onchain, then a forward on the LN
> requires that I put up invalidations of previous signals, also onchain,
> otherwise you could cheaty cheat your effective balance by moving your
> funds around.
> But the point of LN is to avoid putting typical everyday forwards onchain.
>
> > This does have the potential issue of public key exposure prior to
> spending for current addresses. But that could be fixed with a new address
> type that has two public keys / spend paths: one for spending and one for
> signing.
>
> This issue is particularly relevant to vault constructions.
> Typically a vault has a "cold" key that is the master owner of the fund,
> with "hot" keys having partial access.
> Semantically, we would consider the "cold" key to be the "true" owner of
> the fund, with "hot" key being delegates who are semi-trusted, but not as
> trusted as the "cold" key.
>
> So, we should consider a vote from the "cold" key only.
> However, the point is that the "cold" key wants to be kept offline as much
> as possible for security.
>
> I suppose the "cold" key could be put online just once to create the
> signal message, but vault owners might not want to vote because of the
> risk, and their weight might be enough to be important in your voting
> scheme (consider that the point of vaults is to protect large funds).
>
>
> A sub-issue here with the spend/signal pubkey idea is that if I need to be
> able to somehow indicate that a long-term-cold-storage UTXO has a signaling
> pubkey, I imagine this mechanism of indioating might itself require a
> softfork, so you have a chicken-and-egg problem...
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220322/c5541312/attachment-0001.html>;

📅 Original date posted:2022-03-21 📝 Original message:Good ...

2023-06-08T01:06:08+02:00

In reply to nevent1q…06ne
_________________________

📅 Original date posted:2022-03-21
📝 Original message:Good Evening ZmnSCPxj,

> I need to be able to invalidate the previous signal, one that is tied to
the fulfillment of the forwarding request.

You're right that there's some nuance there. You could add a block hash
into the poll message and define things so any subsequent poll message sent
with a newer block hash overrides the old poll message at the block with
that hash and later blocks. That way if a channel balance changes
significantly, a new poll message can be sent out.

Or you could remove the ability to specify fractional support/opposition
and exclude multiparty UTXOs from participation. I tend to like the idea of
the possibility of full participation tho, even in a world that mainly uses
lightning.

> if the signaling is done onchain

I don't think any of this signaling needs to be done on-chain. Anyone who
wants to keep a count of the poll can simply collect together all these
poll messages and count up the weighted preferences. Yes, it would be
possible for one person to send out many conflicting poll messages, but
this could be handled without any commitment to the blockchain. A simple
thing to do would be to simply invalidate poll messages that conflict (ie
include them both in your list of counted messages, but ignore them in your
weighted-sums of poll preferences). As long as these polls are simply used
to inform action rather than to trigger action, it should be ok that
someone can produce biased incomplete counts, since anyone can show a
provably more complete set (a superset) of poll messages. Also, since this
would generally be a time-bound thing, where this poll information would
for example be used to gauge support for a soft fork, there isn't much of a
need to keep the poll messages on an immutable ledger. Old poll data is
inherently not very practically useful compared to recent poll data. So we
can kind of side step things like history attacks by simply ignoring polls
that aren't recent.

> Semantically, we would consider the "cold" key to be the "true" owner of
the fund, with "hot" key being delegates who are semi-trusted, but not as
trusted as the "cold" key.

I'm not sure I agree with those semantics as a hard rule. I don't consider
a "key" to be an owner of anything. A person owns a key, which gives them
access to funds. A key is a tool, and the owner of a key or wallet vault
can define whatever semantics they want. If they want to designate a hot
key as their poll-signing key, that's their prerogative. If they want to
require a cold-key as their message-signing key or even require multisig
signing, that's up to them as well. You could even mirror wallet-vault
constructs by overriding a poll message signed with fewer key using one
signed with more keys. The trade offs you bring up are reasonable
considerations, and I think which trade offs to choose may vary by the
individual in question and their individual situation. However, I think the
time-bound and non-binding nature of a poll makes the risks here pretty
small for most situations you would want to use this in (eg in a soft-fork
poll). It should be reasonable to consider any signed poll message valid,
regardless of possibilities of theft or key renting shinanigans. Nacho keys
nacho coins would of course be important in this scenario.

> if I need to be able to somehow indicate that a long-term-cold-storage
UTXO has a signaling pubkey, I imagine this mechanism of indioating might
itself require a softfork, so you have a chicken-and-egg problem...

If such a thing did need a soft fork, the chicken and egg question would be
easy to answer: the soft fork comes first. We've done soft forks before
having this mechanism, and if necessary we could do another one to enable
it.

However, I think taproot can enable this mechanism without a soft fork. It
should be possible to include a taproot leaf that has the data necessary to
validate a signaling signature. The tapleaf would contain an invalid script
that has an alternative interpretation, where your poll message can include
the merkle path to tapleaf (the invalid-script), and the data at that leaf
would be a public key you can then verify the signaling signature against.

@vjudeu

> It should not be expressed in percents, but in amounts

Agreed. You make a good case for that.

> it could be just some kind of transaction, where you have utxo_id just as
transaction input, amount of coins as some output, and then add your
message as "OP_RETURN <commitment>" in your input, in this way your
signature would be useless in a different context than voting.

I don't quite understand this part. I don't understand how this would make
your signature useless in a different context. Could you elaborate?

> it does not really matter if you store that commitments on-chain to
preserve signalling results in consensus rules or if there would be some
separate chain for storing commitments and nothing else

I don't think any kind of chain is necessary to store this data. I'm
primarily suggesting this as a method to help the debate about a soft fork
have better information about what broader users think about a particular
soft fork proposal, so such data would simply inform whether or not we
decide to continue work on an upgrade. I don't think you'd want to require
any validation of this data by all full nodes, because the data could be
hundreds of gigabytes in size (let's say 1 billion people respond). You'd
have to run some kind of random sampling (more like actual proof of stake)
to get this data down to a manageable size.

> It would be Proof of Stake, where users would put their coins at stake to
vote.

Sure, as long as by this you mean simply proof of coin ownership. Just as
any bitcoin transaction involves proof of coin ownership.

I was pretty careful to avoid the word "voting", since I'm not proposing
that this be used with definite thresholds that trigger action, but more of
an information gathering mechanism. Perhaps one day it could be used for
something akin to voting, but certainly if we were going to implement this
to help decide on the next soft fork, it would very likely be a quite
biased set of responders. We would want to take that into account when
deciding how to interpret the data. Even with biased data tho, it could be
a useful tool for resolving some contention.

But on that note, I was thinking that it might be interesting to have an
optional human readable message into these poll messages. Those messages
could be then read through to gain a better understanding of why people are
supporting and why people are rejecting a particular thing. It could inform
how we might change how we explain a technical change to make it easier for
less technical folks (who don't post on twitter) to understand. It could
potentially give insight into an otherwise quiet majority (or large
minority).

> it sounds similar to "Merged Signing"

Interesting. I'm not sure I fully grok his idea, but I think he was
suggesting that a proof of stake consensus protocol pay attention to
bitcoin transactions formatted in a particular way. I think I've hopefully
clarified above why the idea I'm suggesting is rather different from this
(eg in that no special commitments need to be made).

Cheers,
BT

On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Billy,
>
> > @Jorge
> > > Any user polling system is going to be vulnerable to sybil attacks.
> >
> > Not the one I'll propose right here. What I propose specifically is
> a coin-weighted signature-based poll with the following components:
> > A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90%
> support:10%}> for each UTXO they want to respond to the poll with.
> > B. A signed message like that is valid only while that UTXO has not been
> spent.
> > C. Poll results are considered only at each particular block height,
> where the support and opposition responses are weighted by the UTXO amount
> (and the support/oppose fraction in the message). This means you'd
> basically see a rolling poll through the blockchain as new signed poll
> messages come in and as their UTXOs are spent.
> >
> > This is not vulnerable to sybil attacks because it requires access to
> UTXOs and response-weight is directly tied to UTXO amount. If someone signs
> a poll message with a key that can unlock (or is in some other designated
> way associated with) a UTXO, and then spends that UTXO, their poll response
> stops being counted for all block heights after the UTXO was spent.
> >
> > Why put support and oppose fractions in the message? Who would want to
> both support and oppose something? Any multiple participant UTXO would. Eg
> lightning channels would, where each participant disagrees with the other.
> They need to sign together, so they can have an agreement to sign for the
> fractions that match their respective channel balances (using a force
> channel close as a last resort against an uncooperative partner as usual).
>
> This does not quite work, as lightning channel balances can be changed at
> any time.
> I might agree that you have 90% of the channel and I have 10% of the
> channel right now, but if you then send a request to forward your funds
> out, I need to be able to invalidate the previous signal, one that is tied
> to the fulfillment of the forwarding request.
> This begins to add complexity.
>
> More pointedly, if the signaling is done onchain, then a forward on the LN
> requires that I put up invalidations of previous signals, also onchain,
> otherwise you could cheaty cheat your effective balance by moving your
> funds around.
> But the point of LN is to avoid putting typical everyday forwards onchain.
>
> > This does have the potential issue of public key exposure prior to
> spending for current addresses. But that could be fixed with a new address
> type that has two public keys / spend paths: one for spending and one for
> signing.
>
> This issue is particularly relevant to vault constructions.
> Typically a vault has a "cold" key that is the master owner of the fund,
> with "hot" keys having partial access.
> Semantically, we would consider the "cold" key to be the "true" owner of
> the fund, with "hot" key being delegates who are semi-trusted, but not as
> trusted as the "cold" key.
>
> So, we should consider a vote from the "cold" key only.
> However, the point is that the "cold" key wants to be kept offline as much
> as possible for security.
>
> I suppose the "cold" key could be put online just once to create the
> signal message, but vault owners might not want to vote because of the
> risk, and their weight might be enough to be important in your voting
> scheme (consider that the point of vaults is to protect large funds).
>
>
> A sub-issue here with the spend/signal pubkey idea is that if I need to be
> able to somehow indicate that a long-term-cold-storage UTXO has a signaling
> pubkey, I imagine this mechanism of indioating might itself require a
> softfork, so you have a chicken-and-egg problem...
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220320/214af426/attachment.html>;

📅 Original date posted:2022-03-17 📝 Original message:@Jorge ...

2023-06-08T01:06:07+02:00

In reply to nevent1q…enm6
_________________________

📅 Original date posted:2022-03-17
📝 Original message:@Jorge
> Any user polling system is going to be vulnerable to sybil attacks.

Not the one I'll propose right here. What I propose specifically is
a coin-weighted signature-based poll with the following components:
A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90%
support:10%}> for each UTXO they want to respond to the poll with.
B. A signed message like that is valid only while that UTXO has not been
spent.
C. Poll results are considered only at each particular block height, where
the support and opposition responses are weighted by the UTXO amount (and
the support/oppose fraction in the message). This means you'd basically see
a rolling poll through the blockchain as new signed poll messages come in
and as their UTXOs are spent.

This is not vulnerable to sybil attacks because it requires access to UTXOs
and response-weight is directly tied to UTXO amount. If someone signs a
poll message with a key that can unlock (or is in some other designated way
associated with) a UTXO, and then spends that UTXO, their poll response
stops being counted for all block heights after the UTXO was spent.

Why put support and oppose fractions in the message? Who would want to both
support and oppose something? Any multiple participant UTXO would. Eg
lightning channels would, where each participant disagrees with the other.
They need to sign together, so they can have an agreement to sign for the
fractions that match their respective channel balances (using a force
channel close as a last resort against an uncooperative partner as usual).

This does have the potential issue of public key exposure prior to spending
for current addresses. But that could be fixed with a new address type that
has two public keys / spend paths: one for spending and one for signing.

> In perfect competition the mining power costs per chain tends to equal
the rewards offered by that chain, both in subsidy and transaction fees.

Agreed, but it takes time for an economic shock to reach its new
equilibrium. That period of time, which might be rather precarious, should
be considered in a plan to preserve a minority fork.

> Would you rather that proposal be deployed with speedy trial activation
or with BIP8+LOT=true activation?

For a proposal I don't want to succeed, I absolutely would prefer speedy
trial over BIP8+LOT=true. Speedy trial at 90% signaling threshold can
quickly determine that the proposal (hopefully) does not have enough
consensus among miners. By contrast, BIP8+LOT=true could polarize the
debate, worsening the community's ability to communicate and talk through
issues. It would also basically guarantee that a fork happens, which in the
best case (in my hypothetical point of view where I don't like the
proposal) would mean some small minority forks off the network, which
reduces the main chain's value somewhat (at least temporarily). Worst case
a small majority forces the issue at near 50% which would cause all sorts
of blockchain issues and would have a high probability of leading to a
hardfork by the minority.

All this sounds rather more tenable with speedy trial. Any proposal has
less chance of causing an actual fork (soft or otherwise) with speedy trial
vs LOT=true. LOT=true guarantees a fork if even a single person is running
it. LOT=true could certainly come in handy to initiate a UASF, but IMO
that's better left as a plan B or C.

> segwit... all the consequences of the change are not opt in.

I definitely agree there. The consequences of a soft fork are not always
opt in. That's basically what my example of a "dumb majority soft fork" is,
and sounds like what your "evil fork" basically is.

On Thu, Mar 17, 2022 at 7:19 AM Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon at jtimon.cc> wrote:
> > A mechanism of soft-forking against activation exists. What more do you
> want? Are we supposed to write the code on behalf of this hypothetical
> group of users who may or may not exist for them just so that they can have
> a node that remains stalled on Speedy Trial lockin? That simply isn't
> reasonable, but if you think it is, I invite you to create such a fork.
>
> I want BIP+LOT=true to be used. I want speedy trial not to be used.
> Luke wrote the code to resist BIP8+LOT=true, and if he didn't, I could
> write it myself, yes.
> If you think that's not reasonable code to ever run, I don't think
> you're really getting the "softfork THAT YOU OPPOSE" part of the
> hypothetical right. Let me try to help with an example, although I
> hope we don't get derailed in the implementation details of the
> hypothetical evil proposal.
>
> Suppose someone proposes a weight size limit increase by a extension
> block softfork.
> Or instead of that, just imagine the final version of the covenants
> proposal has a backdoor in it or something.
>
>
> Would you rather that proposal be deployed with speedy trial
> activation or with BIP8+LOT=true activation?
>
> >>
> >> Please, try to imagine an example for an activation that you wouldn't
> like yourself. Imagine it gets proposed and you, as a user, want to resist
> it.
> >
> >
> > If I believe I'm in the economic majority then I'll just refuse to
> upgrade my node, which was option 2. I don't know why you dismissed it.
>
> Not upgrading your node doesn't prevent the softfork from being
> activated in your chain.
> A softfork may affect you indirectly even if you don't use the new
> features yourself directly.
> You may chose to stay in the old chain even if you don't consider
> you're "in the economic majority" at that moment.
>
> > Not much can prevent a miner cartel from enforcing rules that users
> don't want other than hard forking a replacement POW. There is no
> effective difference between some developers releasing a malicious
> soft-fork of Bitcoin and the miners releasing a malicious version
> themselves. And when the miner cartel forms, they aren't necessarily going
> to be polite enough to give a transparent signal of their new rules.
> However, without the economic majority enforcing their set of rules, the
> cartel continuously risks falling apart from the temptation of transaction
> fees of the censored transactions.
>
> It is true that a mining cartel doesn't need to use speedy trial or
> BIP8+LOT=true to apply rule changes they want just because we do.
> But they would do if they wanted to maintain the appearance of benevolence.
>
> > On the other hand, If I find out I'm in the economic minority then I
> have little choice but to either accept the existence of the new rules or
> sell my Bitcoin. Look, you cannot have the perfect system of money all by
> your lonesome self. Money doesn't have economic value if no one else wants
> to trade you for it. Just ask that poor user who YOLO'd his own taproot
> activation in advance all by themselves. I'm sure they think they've got
> just the perfect money system, with taproot early and everything. But now
> their node is stuck at block 692261 and hasn't made progress since. No
> doubt they are hunkered down for the long term, absolutely committed to
> their fork and just waiting for the rest of the world to come around to how
> much better their version of Bitcoin is than the rest of us.
>
> Well, you could also have the option to stay in the old chain with the
> economic minority, it doesn't have to be you alone.
> We agree that one person alone can't use a currency.
>
> > Even though you've dismissed it, one of the considerations of taproot
> was that it is opt-in for users to use the functionality. Future
> soft-forks ought to have the same considerations to the extent possible.
>
> Well, the same could be said about segwit. And yet all the
> consequences of the change are not opt in.
> For example, segwit contained a block size limit increase.
> Sure, you can just not validate the witnesses, but then you're no
> longer a full node.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220317/082e92f9/attachment.html>;

📅 Original date posted:2022-03-17 📝 Original message:@Aj ...

2023-06-08T01:06:05+02:00

In reply to nevent1q…nwzl
_________________________

📅 Original date posted:2022-03-17
📝 Original message:@Aj Your steps seem reasonable. I definitely agree step one (talking to
each other) is obviously the ideal solution, when it works.

Step 2 (futures market) is the option I would say I understand the least.
In any case, a futures market seems like it only incorporates the
opinions/predictions of the group of people willing to bet money on things
like this. This is likely to be a rather small group of particular types of
people. I find it a bit difficult to reconcile the theories that betting
rings like this are good at predicting against the inherent selection bias
of the group of betting individuals. Going just by number of individuals
(or probably even by amount of currency risked) this seems like a futures
market would inherently be a small and biased group. Potentially useful,
but I wouldn't assume that it could be taken stand-alone as a proxy for
consensus.

I'm curious what you think about a coin-weighted poll like I suggested here
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019022.html>;
being
added to that list of steps? Surely this would be a broader group of people
than a futures market, tho still obviously a group subject to selection
bias.

@jeremy drops the bomb. I'm sure Jorge will be running this within the
year.

On Tue, Mar 15, 2022 at 12:25 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Boker tov bitcoin devs,
>
> A mechanism of soft-forking against activation exists. What more do you
>> want?
>>
>
> Agreed -- that should be enough.
>
>
>
>> Are we supposed to write the code on behalf of this hypothetical group of
>> users who may or may not exist for them just so that they can have a node
>> that remains stalled on Speedy Trial lockin?
>>
> That simply isn't reasonable, but if you think it is, I invite you to
>> create such a fork.
>>
>
> Disagree.
>
> It is a reasonable ask.
>
> I've done it in about 40 lines of python:
> https://github.com/jeremyrubin/forkd
>
> Merry Christmas Jorge, please vet the code carefully before running.
>
> Peace,
>
> Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220316/0bf6deff/attachment.html>;

📅 Original date posted:2022-03-12 📝 Original message:> ...

2023-06-08T01:06:03+02:00

In reply to nevent1q…4zz8
_________________________

📅 Original date posted:2022-03-12
📝 Original message:> If I find out I'm in the economic minority then I have little choice but
to either accept the existence of the new rules or sell my Bitcoin

I do worry about what I have called a "dumb majority soft fork". This is
where, say, mainstream adoption has happened, some crisis of some magnitude
happens that convinces a lot of people something needs to change now. Let's
say it's another congestion period where fees spike for months. Getting
into and out of lighting is hard and maybe even the security of lightning's
security model is called into question because it would either take too
long to get a transaction on chain or be too expensive. Panicy people might
once again think something like "let's increase the block size to 1GB, then
we'll never have this problem again". This could happen in a segwit-like
soft fork.

In a future where Bitcoin is the dominant world currency, it might not be
unrealistic to imagine that an economic majority might not understand why
such a thing would be so dangerous, or think the risk is low enough to be
worth it. At that point, we in the economic minority would need a plan to
hard fork away. One wouldn't necessarily need to sell all their majority
fork Bitcoin, but they could.

That minority fork would of course need some mining power. How much? I
don't know, but we should think about how small of a minority chain we
could imagine might be worth saving. Is 5% enough? 1%? How long would the
chain stall if hash power dropped to 1%?

TBH I give the world a ~50% chance that something like this happens in the
next 100 years. Maybe Bitcoin will ossify and we'll lose all the people
that had deep knowledge on these kinds of things because almost no one's
actively working on it. Maybe the crisis will be too much for people to
remain rational and think long term. Who knows? But I think that at some
point it will become dangerous if there isn't a well discussed well vetted
plan for what to do in such a scenario. Maybe we can think about that 10
years from now, but we probably shouldn't wait much longer than that. And
maybe it's as simple as: tweak the difficulty recalculation and then just
release a soft fork aware Bitcoin version that rejects the new rules or
rejects a specific existing post-soft-fork block. Would it be that simple?

On Sat, Mar 12, 2022, 07:35 Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon at jtimon.cc> wrote:
>
>>
>> A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr. It turns out that, at
>>> the time of that proposal, a large amount of hash power simply did not have
>>> the firmware required to support signalling. That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mining
>>> power offline if it had been deployed. Imagine if the firmware couldn't be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>>>> Yes, I like this solution too, with a little caveat: an easy mechanism
>>>> for users to actively oppose a proposal.
>>>> Luke alao talked about this.
>>>> If users oppose, they should use activation as a trigger to fork out of
>>>> the network by invalidating the block that produces activation.
>>>> The bad scenario here is that miners want to deploy something but users
>>>> don't want to.
>>>> "But that may lead to a fork". Yeah, I know.
>>>> I hope imagining a scenario in which developers propose something that
>>>> most miners accept but some users reject is not taboo.
>>>>
>>>
>>> This topic is not taboo.
>>>
>>> There are a couple of ways of opting out of taproot. Firstly, users can
>>> just not use taproot. Secondly, users can choose to not enforce taproot
>>> either by running an older version of Bitcoin Core or otherwise forking the
>>> source code. Thirdly, if some users insist on a chain where taproot is
>>> "not activated", they can always softk-fork in their own rule that
>>> disallows the version bits that complete the Speedy Trial activation
>>> sequence, or alternatively soft-fork in a rule to make spending from (or
>>> to) taproot addresses illegal.
>>>
>>
>> Since it's about activation in general and not about taproot
>> specifically, your third point is the one that applies.
>> Users could have coordinated to have "activation x" never activated in
>> their chains if they simply make a rule that activating a given proposal
>> (with bip8) is forbidden in their chain.
>> But coordination requires time.
>>
>
> A mechanism of soft-forking against activation exists. What more do you
> want? Are we supposed to write the code on behalf of this hypothetical
> group of users who may or may not exist for them just so that they can have
> a node that remains stalled on Speedy Trial lockin? That simply isn't
> reasonable, but if you think it is, I invite you to create such a fork.
>
>
>> Please, try to imagine an example for an activation that you wouldn't
>> like yourself. Imagine it gets proposed and you, as a user, want to resist
>> it.
>>
>
> If I believe I'm in the economic majority then I'll just refuse to upgrade
> my node, which was option 2. I don't know why you dismissed it.
>
> Not much can prevent a miner cartel from enforcing rules that users don't
> want other than hard forking a replacement POW. There is no effective
> difference between some developers releasing a malicious soft-fork of
> Bitcoin and the miners releasing a malicious version themselves. And when
> the miner cartel forms, they aren't necessarily going to be polite enough
> to give a transparent signal of their new rules. However, without the
> economic majority enforcing their set of rules, the cartel continuously
> risks falling apart from the temptation of transaction fees of the censored
> transactions.
>
> On the other hand, If I find out I'm in the economic minority then I have
> little choice but to either accept the existence of the new rules or sell
> my Bitcoin. Look, you cannot have the perfect system of money all by your
> lonesome self. Money doesn't have economic value if no one else wants to
> trade you for it. Just ask that poor user who YOLO'd his own taproot
> activation in advance all by themselves. I'm sure they think they've got
> just the perfect money system, with taproot early and everything. But now
> their node is stuck at block 692261
> <https://b10c.me/blog/007-spending-p2tr-pre-activation/>; and hasn't made
> progress since. No doubt they are hunkered down for the long term,
> absolutely committed to their fork and just waiting for the rest of the
> world to come around to how much better their version of Bitcoin is than
> the rest of us.
>
> Even though you've dismissed it, one of the considerations of taproot was
> that it is opt-in for users to use the functionality. Future soft-forks
> ought to have the same considerations to the extent possible.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220312/95ceba55/attachment-0001.html>;

📅 Original date posted:2022-03-11 📝 Original message:> ...

2023-06-08T01:06:01+02:00

In reply to nevent1q…zsmn
_________________________

📅 Original date posted:2022-03-11
📝 Original message:> BIP 8 did in fact have broad consensus

I hear you claim this often Luke, but claiming its so does not make it so.
Do you think BIP8 still has broad consensus? If that's the case, maybe all
that's needed is to gather some evidence
<https://www.youtube.com/watch?v=U7rXOgL4oFQ>; and present it.

On Thu, Mar 10, 2022 at 6:38 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote:
> > The "no-miner-veto" concerns are, to an extent, addressed by the short
> > timeline of Speedy Trial. No more waiting 2 years on the miners dragging
> > their feet.
>
> It's still a miner veto. The only way this works is if the full deployment
> (with UASF fallback) is released in parallel.
>
> > If you are so concerned about listening to legitimate criticism, maybe
> you
> > can design a new deployment mechanism that addresses the concerns of the
> > "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> > faction.
>
> BIP8 already does that.
>
> > A major contender to the Speedy Trial design at the time was to mandate
> > eventual forced signalling, championed by luke-jr. It turns out that, at
> > the time of that proposal, a large amount of hash power simply did not
> have
> > the firmware required to support signalling. That activation proposal
> > never got broad consensus,
>
> BIP 8 did in fact have broad consensus before some devs decided to ignore
> the
> community and do their own thing. Why are you trying to rewrite history?
>
> > and rightly so, because in retrospect we see
> > that the design might have risked knocking a significant fraction of
> mining
> > power offline if it had been deployed. Imagine if the firmware couldn't
> be
> > quickly updated or imagine if the problem had been hardware related.
>
> They had 18 months to fix their broken firmware. That's plenty of time.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220310/c8344427/attachment-0001.html>;

📅 Original date posted:2022-03-04 📝 Original message:> ...

2023-06-08T01:05:03+02:00

In reply to nevent1q…0552
_________________________

📅 Original date posted:2022-03-04
📝 Original message:> "these sidechains are terrible" on Monday and then "these sidechains are
so good they will replace the mainchain" on Tuesday

Your premise is that a sidechain might come to dominate bitcoin, and that
this would be better than an altcoin dominating bitcoin. Did I
misunderstand you? Not quite sure why you're balking at me simply
confirming your premise.

> sidechains cannot exist without their mainchain .. imagine .. a zcash
sidechain, and someone claims they deposited 1000 BTC

A sidechain could stop supporting deposits from or withdrawals to bitcoin
and completely break any relationship with the main chain. I agree this is
not as sure of a thing as starting with an altcoin (which of course never
has that kind of relationship with bitcoin). So I do think there are some
merits to sidechains in your scenario. However, I don't think its quite
accurate to say it completely solves the problem (of a less-secure altcoin
becoming dominant).

Your anecdote about not running a full node is amusing, and I've often
found myself in that position. I certainly agree different people are
different and so different trade offs can be better for different
people. However,
the question is: what tradeoffs does a largeblock sidechain do better than
both eg Visa and lightning?

>Wouldn't life be better, if we Bitcoiners could easily sweep those fiat transactions into *some* part of the BTC universe? (For example, a family of largeblock sidechains). To me the answer is clearly yes.

I guess its not as clear to me. We agree it wouldn't significantly burden
Bitcoin-only nodes, but not being a burden is not a sufficient reason to do
something, only reason to not prevent it. But what are the benefits to a
user of that chain? Slightly lower fees than main bitcoin? More
decentralization than Visa or Venmo? Doesn't lightning already do better on
both accounts?

On Tue, Mar 1, 2022 at 6:00 PM Paul Sztorc <truthcoin at gmail.com> wrote:

> On 3/1/2022 12:39 AM, Billy Tetrud wrote:
>
> This entire issue is avoided completely, if all the chains --decentralized and centralized-- and in the same monetary unit. Then, the monetary network effects never interfere, and the decentralized chain is always guaranteed to exist.
>
> It sounds like what you're saying is that without side chains, everyone might switch entirely to some altcoin and bitcoin will basically die. And at that point, the insecurity of that coin people switched to can be heavily exploited by some attacker(s). Is that right?
>
> Yes, precisely.
>
> Its an interesting thought experiment. However, it leads me to wonder: if a sidechain gets so popular that it dominates the main chain, why would people keep that main chain around at all?
>
> For some reason, this is a very popular question. I suppose if you believe in "one size fits all" chain philosophy (see comment below), it makes sense to say "these sidechains are terrible" on Monday and then "these sidechains are so good they will replace the mainchain" on Tuesday.
>
> In any event, sidechains cannot exist without their mainchain (as I see it). For example, imagine that you are on a zcash sidechain, and someone claims they deposited 1000 BTC, from Bitcoin Core into this sidechain? Do you give them 1000 z-BTC, or not? Without the mainchain,
> you can't tell.
>
> If you run the Bip300 DriveNet demo software (drivechain.info/releases), you will see for yourself: the test-sidechains are absolutely inert, UNTIL they have rpc access to the mainchain. (Exactly the same way that a LN node needs a Bitcoin Core node.)
>
>
>
> > someone is actually in the wrong, if they proactively censor an experiment of any type. If a creator is willing to stand behind something, then it should be tried.
>
> > it makes no difference if users have their funds stolen from a centralized Solana contract or from a bip300 centralized bit-Solana sidechain. I don't see why the tears shed would be any different.
>
> I agree with you. My point was not that we should stop anyone from doing this. My point was only that we shouldn't advocate for ideas we think aren't good. You were advocating for a "largeblock sidechain", and unless you have good reasons to think that is an idea likely to succeed and want to share them with us, then you shouldn't be advocating for that. But certainly if someone *does* think so and has their own reasons, I wouldn't want to censor or stop them. But I wouldn't advocate for them to do it unless their ideas were convincing to me, because I know enough to know the dangers of large block blockchains.
>
> Yes, I strongly agree, that we should only advocate for ideas we believe in.
>
> I do not believe in naive layer1 largeblockerism. But I do believe in sidechain largeblockism.
>
> Something funny once happened to me when I was on a Bitcoin conference panel*. There were three people: myself, a Blockstream person, and an (ex)BitPay person. The first two of us, were valiantly defending the small block position. I gave my usual speech: that node costs must remain low, so that people can run full nodes. The largeblocker mentioned that they ran many nodes (including BCH nodes etc) and didn't mind the cost, so I disclosed --in a good-natured way-- that I do not even run a BTC full node myself (out of choice). Thus, I was yammering about software I wasn't even running, I had no skin in the game! Lo and behold -- my Blockstream smallblocker ally-on-the-panel, immediately admitted to everyone that he did not run a full node either. The only node-runner was the largeblocker. The audience found this very amusing (as did I).
>
> We smallblockers, justified our sinful nodeless behavior, as follows (paraphrasing): we receive BTC mainly from people that we know (and have a long-term relationship with); our receipts are not time sensitive; we are not paid in BTC that often; if payments turned out to be forged we would have enormous recourse against our counterparties; etc.
>
> We did not run full nodes, because we did not need to draw on the blockchain's powers, **for those transactions**.
>
> Which is my point: people are different, and transactions are different. I make many transactions today, with VISA or Venmo. These are not censorship-resistant, but somehow I survive the month, without bursting into flames.
>
> Wouldn't life be better, if we Bitcoiners could easily sweep those fiat transactions into *some* part of the BTC universe? (For example, a family of largeblock sidechains). To me the answer is clearly yes.
>
> Unlike layer1-largeblockism, no one running Bitcoin Core ever needs to see these 'btc' transactions (the same as we don't see them today, on account of them not existing at all); they do not burden Bitcoin Core full nodes. Hence why it seems like a good idea to me.
>
> An SPV-wallet-of-a-largeblock-sidechain, is of course, a *disgrace* compared to a full-node-of-smallblock-mainchain-Bitcoin-Core. But, it is emphatically superior to Venmo / VISA or even "custodial LN". And certainly superior to nothing.
>
> Paul
>
> * https://www.youtube.com/watch?v=V3cvH2eWqfU
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220304/40846e4a/attachment-0001.html>;

📅 Original date posted:2022-03-01 📝 Original message:@Paul ...

2023-06-08T01:05:02+02:00

In reply to nevent1q…urmj
_________________________

📅 Original date posted:2022-03-01
📝 Original message:@Paul
> I believe that money has very strong network effects. ... users will
"clump up" and get "stuck".

I'm of the same opinion.

> This entire issue is avoided completely, if all the chains
--decentralized and centralized-- and in the same monetary unit. Then, the
monetary network effects never interfere, and the decentralized chain is
always guaranteed to exist.

It sounds like what you're saying is that without side chains, everyone
might switch entirely to some altcoin and bitcoin will basically die. And
at that point, the insecurity of that coin people switched to can be
heavily exploited by some attacker(s). Is that right? Its an interesting
thought experiment. However, it leads me to wonder: if a sidechain gets so
popular that it dominates the main chain, why would people keep that main
chain around at all? A sidechain could eject the main chain and all its
baggage if it got so big. So I don't think it can really be said that the
problem can be avoided "completely". But in any case, I see your line of
thinking.

> someone is actually in the wrong, if they proactively censor an
experiment of any type. If a creator is willing to stand behind something,
then it should be tried.
> it makes no difference if users have their funds stolen from a
centralized Solana contract or from a bip300 centralized bit-Solana
sidechain. I don't see why the tears shed would be any different.

I agree with you. My point was not that we should stop anyone from doing
this. My point was only that we shouldn't advocate for ideas we think
aren't good. You were advocating for a "largeblock sidechain", and unless
you have good reasons to think that is an idea likely to succeed and want
to share them with us, then you shouldn't be advocating for that. But
certainly if someone *does* think so and has their own reasons, I wouldn't
want to censor or stop them. But I wouldn't advocate for them to do it
unless their ideas were convincing to me, because I know enough to know the
dangers of large block blockchains.

On Mon, Feb 28, 2022 at 4:55 PM Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On 2/28/2022 1:49 AM, ZmnSCPxj wrote:
>
> ...
>
> ...
>
> Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 bytes.
>
> If so, a "rich man" could open a LN channel, and gradually transfer it to new people.
>
> Such a technique would need to meet two requirements (or, so it seems to me):
> #1: The layer1 UTXO (that defines the channel) can never change (ie, the 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay what-they-were when the channel was opened).
> #2: The new part-owners (who are getting coins from the rich man), will have new pubkeys which are NOT known, until AFTER the channel is opened and confirmed on the blockchain.
>
> Not sure how you would get both #1 and #2 at the same time. But I am not up to date on the latest LN research.
>
> Yes, using channel factories.
>
> I think you may be wrong about this.
> ...
>
> I am not wrong about this.
>
> Well, let's take a closer look then.
>
> The topic was: "a way, to LN-onboard [a new pubkey] WITHOUT needing new layer1 bytes".
>
> By which I meant, that I could generate a new pubkey right now, and add it to the LN, without any onchain action.
>
> I can shorten and restate the two requirements (and reorder them) as:
> #2: Can later add a new public key to the membership set.
> #1: Without an onchain action.
>
> And yet you yourself say, very clearly:
>
>
> ... That is why I said changing the membership set requires onchain action.
>
> Which would seem to directly contradict what you say about channel
> factories. Unless you can show me how to add my new pubkey_4, to a 3-of-3
> channel factory opened last year. Without using an onchain action. You seem
> to want to instead change the subject. (To something like: 'we can do
> better the rate (32 bytes per 5 onboards), from your footnote'.) Which is
> fine. But it is not what I bought up.
>
> ***
>
> In general, you seem to have a future in mind, where new users onboard via factory.
> For example, 50,000 new users want to onboard in the next block. These strangers, spontaneously organize into 1000 factories of 55 people each, (50 newbies with zero coins + 5 wealthier BTCs who have lots of coins). They then broadcast into the block and join Bitcoin.
> And this one factory provides them with many channels, so it can meet most/all of their needs.
>
> I am not here to critique factories. I was simply observing that your logic "sidechains don't scale, because you have to share your messages" is not quite airtight, because in the case of onboarding the situation is reversed and so supports the exact opposite conclusion.
> I believe I have made my point by now. It should be easy for people to see what each of us has in mind, and the strengths and weaknesses.
>
> I am curious about something, though. Maybe you can help me.
> Presumably there are risks to large factories. Perhaps an attacker could join each new factory with just $1 of BTC, spend this $1, and then refuse to cooperate with the factory any further. Thus they can disable the factory at a cost of $1 rented dollar.
> If 1000 factories are opened per block, this would be 52.5 M factories per year, $52.5 million USD per year to disable all the factories out of spite. (All of which they would eventually get back.) I can think of a few people who might try it.
>
>
> I mean, like, LN ... has a lot more onboarding activity than half-hearted sidechains like Liquid or Rootstock.
>
> I don't see the relevance of this. We are talking about the future
> (theoretical), not the past (empirical). For example, someone could say
> "Ethereum has a lot more onboarding activity than LN ..." but this would
> also make no difference to anything.
>
> ...The onboarding rate only needs to be as fast as the rate at which people want to join Bitcoin.
> ...
>
> As I pointed out in the other thread:
>
> * LN:
> * Funds can be stolen IF:
> * There is a 51% miner, AND
> * The 51% miner is a member of a channel/channel factory you are in.
> * Drivechains:
> * Funds can be stolen IF:
> * There is a 51% miner.
> ...
> So there is a real degradation of security in Drivechains, and if you compute the numbers, I am reasonably sure that 33% of the world is unlikely to want to use Bitcoin within one month.
> I mean we already had a pandemic and everyone going online and so on, and yet Bitcoin blockchain feerates are *still* small, I had to fix a bug in CLBOSS that came up only due to hitting the minimum feerate, so no --- people are not joining Bitcoin at a rate faster than Bitcoin + LN can handle it, even with a pretty good reason to move payments online.
>
> Worse, once 100% of the world is onboarded, the extra onboarding capacity is useless since the onboarding rate can only match the birth rate (including birth of legal persons such as corporations), which we expect is much lower than 33% increase per ***month***.
>
> You are buying too much capacity at a real degradation in security, and I am not convinced the extra capacity is worth the loss of security.
>
> Separating the onboarding rate from the payment rate is a *good thing*, because we can then design their structures differently.
> Make onboarding slow but secure (so that their money is very secure), but make payment rate faster and less secure (because in-flight payments are likely to be much smaller than the total owned funds).
>
> Obviously I don't agree with any of these sentences (most are irrelevant, some false). But I would only be repeating myself.
>
> Paul
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220228/388b93e2/attachment.html>;

📅 Original date posted:2022-02-26 📝 Original ...

2023-06-08T01:03:35+02:00

In reply to nevent1q…hp7e
_________________________

📅 Original date posted:2022-02-26
📝 Original message:@ZmnSCPxj
> we have already rejected Drivechains

I also think this is kind of dubious. I don't remember consensus being to
"reject" drivechains, as much as consensus was that it wasn't a priority
and there wasn't a lot of interest in doing on it from many people (I'm
sure Paul could comment further on that).

> sidechains on Drivechains become a block size increase.

While this would be true for those who opt into a particular drivechain, I
think its important to note that it would *not* be identical to a
main-chain block size increase in a very important way: normal bitcoin
miners and nodes nodes that don't care about drivechains would not see a
blocksize increase.

But even in the hypothetical scenario where *all* mainchain miners expand
their business to sidechains, it still does not negatively affect normal
bitcoin nodes that don't care about drivechains. The important things
<https://github.com/fresheneesz/bitcoinThroughputAnalysis>; about a "normal"
blocksize increase are:

A. It increases the machine resources necessary for IBD, transaction relay,
and validation
B. It probably increases the growth rate of the UTXO set, increasing memory
necessary to store that.
C. It increases the cost of storing the blockchain on non-pruned nodes
D. It increases the average propagation time of new blocks, which increases
miner centralization pressure.

The existence of drivechains with every miner opted into (some of) them
would only negatively impact item D. Normal bitcoin nodes wouldn't need to
use any extra resources if they don't care about drivechains. And miners
would only have additional centralization pressure proportional to what
drivechains they're opted into. The reason for that is that if a miner is
opted into drivechain X, and propagation of transaction data for
drivechain X is significantly slower than the normal bitcoin network, a
miner may not have the latest drivechain X block to merge mine on top of.
However that miner can still mine bitcoin with no additional latency, and
so that centralization pressure is minimal unless a significant fraction of
the miner's revenue comes from drivechains with slow data propagation.
Beyond that, by my calculations, miner centralization is quite far from
being significantly affected by blocksize increases. So unless drivechains
become the dominant use case of the bitcoin blockchain, this really isn't
something that I expect to cause any substantial miner centralization or
other blocksize related problems.

ZmnSCPaj, are you arguing that drivechains are bad for bitcoin or are you
arguing that it would be unwise to opt into a drivechain? Those are very
different arguments. If drivechains compromised things for normal bitcoin
nodes that ignore drivechains, then I agree that would be serious reason to
reject drivechains outright and reject things that allow it to happen.
However, if all you're saying is that people can shoot themselves in the
foot with drivechains, then avoiding drivechains should not be a
significant design consideration for bitcoin but rather for those who might
consider spending their time working on drivechains.

On Thu, Feb 24, 2022 at 6:03 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning aj,
>
> > > Logically, if the construct is general enough to form Drivechains, and
> > > we rejected Drivechains, we should also reject the general construct.
> >
> > Not providing X because it can only be used for E, may generalise to not
> > providing Y which can also only be used for E, but it doesn't necessarily
> > generalise to not providing Z which can be used for both G and E.
>
> Does this not work only if the original objection to merging in BIP-300
> was of the form:
>
> * X implements E.
> * Z implements G and E.
> * Therefore, we should not merge in X and instead should merge in the more
> general construct Z.
>
> ?
>
> Where:
>
> * E = Drivechains
> * X = BIP-300
> * Z = some general computation facility
> * G = some feature.
>
> But my understanding is that most of the NACKs on the BIP-300 were of the
> form:
>
> * X implements E.
> * E is bad.
> * Therefore, we should not merge in X.
>
> If the above statement "E is bad" holds, then:
>
> * Z implements G and E.
> * Therefore, we should not merge in Z.
>
> Where Z = something that implements recursive covenants.
>
> I think we really need someone who NACKed BIP-300 to speak up.
> If my understanding is correct and that the original objection was
> "Drivechains are bad for reasons R[0], R[1]...", then:
>
> * You can have either of these two positions:
> * R[0], R[1] ... are specious arguments and Drivechains are not bad,
> therefore we can merge in a feature that enables Recursive Covenants ->
> Turing-Completeness -> Drivechains.
> * Even if you NACKed before, you *are* allowed to change your mind and
> move to this position.
> * R[0], R[1] ... are valid arguments are Drivechains are bad, therefore
> we should **NOT** merge in a feature that implements Recursive Covenants ->
> Turing-Completeness -> Drivechains.
>
> You cannot have it both ways.
> Admittedly, there may be some set of restrictions that prevent
> Turing-Completeness from implementing Drivechains, but you have to
> demonstrate a proof of that set of restrictions existing.
>
> > I think it's pretty reasonable to say:
> >
> > a) adding dedicated consensus features for drivechains is a bad idea
> > in the absence of widespread consensus that drivechains are likely
> > to work as designed and be a benefit to bitcoin overall
> >
> > b) if you want to risk your own funds by leaving your coins on an
> > exchange or using lightning or eltoo or tumbling/coinjoin or payment
> > pools or drivechains or being #reckless in some other way, and aren't
> > asking for consensus changes, that's your business
>
> *Shrug* I do not really see the distinction here --- in a world with
> Drivechains, you are free to not put your coins in a Drivechain-backed
> sidechain, too.
>
> (Admittedly, Drivechains does get into a Mutually Assured Destruction
> argument, so that may not hold.
> But if Drivechains going into a MAD argument is an objection, then I do
> not see why covenant-based Drivechains would also not get into the same MAD
> argument --- and if you want to avoid the MADness, you cannot support
> recursive covenants, either.
> Remember, 51% attackers can always censor the blockchain, regardless of
> whether you put the Drivechain commitments into the coinbase, or in an
> ostensibly-paid-by-somebody-else transaction.)
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220225/80a77548/attachment.html>;

📅 Original date posted:2022-01-25 📝 Original message:There ...

2023-06-08T01:02:45+02:00

In reply to nevent1q…5fdg
_________________________

📅 Original date posted:2022-01-25
📝 Original message:There was a protocol someone mentioned a while back called Sabu that had
the same goals. As i recall, it had some pretty promising constructs, but
would have a critical vulnerability that could be exploited by miners. This
is the write up:

https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180

Perhaps some of the techniques there could be combined with your ideas to
get closer to a solution.

On Mon, Jan 24, 2022, 08:51 AdamISZ via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello list,
>
> I took the time to write up this rather out-there idea:
>
> Imagine you wanted to send a coin just like email, i.e. just transfer data
> to the counterparty.
>
> Clearly this is in general entirely impossible; but with what restrictions
> and assumptions could you create a toy version of it?
>
> See this gist for a detailed build up of the idea:
>
> https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da
>
> Basically: using signature adaptors and CTV or a similar covenant, you
> could create a fully trustless transfer of control of a utxo from one party
> to another with no interaction with the rest of the group, at the time of
> transfer (modulo of course lots and lots of one-time setup).
>
> The limitations are extreme and as you'd imagine. In the gist I feel like
> I got round one of them, but not the others.
>
> (I very briefly mention comparison to e.g. statechains or payment pools;
> they are making other tradeoffs against the 'digital cash' type of goal.
> There is no claim that this 'pathcoin' idea is even viable yet, let alone
> better than those ideas).
>
> Publishing this because I feel like it's the kind of thing imaginative
> minds like the ones here, may be able to develop further. Possibly!
>
>
> waxwing / AdamISZ
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220125/a599352b/attachment.html>;

📅 Original date posted:2022-01-19 📝 Original message:> ...

2023-06-08T01:01:52+02:00

In reply to nevent1q…zasj
_________________________

📅 Original date posted:2022-01-19
📝 Original message:> because you make transactions third party malleable it becomes possible
to bundle and unbundle transactions.

What I was suggesting doesn't make it possible to malleate someone else's
transaction. I guess maybe my proposal of using a sighash flag might have
been unclear. Imagine it as a script opcode that just says "this
transaction must be mined with this other transaction" - the only
difference being that you can use any output with any encumberance as an
input for fee bumping. It doesn't prevent the original transaction from
being mined on its own. So adding junk inputs would be no more of a problem
than dust attacks already are. It would be used exactly like cpfp, except
it doesn't spend the parent.

I don't think what I was suggesting is as different from your proposal. All
the problems of fee revenue optimization and feerate rules that you
mentioned seem like they'd also exist for your proposal, or for cpfp. Let
me know if I should clarify further.

On Tue, Jan 18, 2022 at 8:51 PM Jeremy <jlrubin at mit.edu> wrote:

> The issue with sighash flags is that because you make transactions third
> party malleable it becomes possible to bundle and unbundle transactions.
>
> This means there are circumstances where an attacker could e.g. see your
> txn, and then add a lot of junk change/inputs + 25 descendants and strongly
> anchor your transaction to the bottom of the mempool.
>
> because of rbf rules requiring more fee and feerate, this means you have
> to bump across the whole package and that can get really messy.
>
> more generally speaking, you could imagine a future where mempools track
> many alternative things that might want to be in a transaction.
>
> suppose there are N inputs each with a weight and an amount of fee being
> added and the sighash flags let me pick any subset of them. However, for a
> txn to be standard it must be < 100k bytes and for it to be consensus <
> 1mb. Now it is possible you have to solve a knapsack problem in order to
> rationally bundle this transaction out of all possibilities.
>
> This problem can get even thornier, suppose that the inputs I'm adding
> themselves are the outputs of another txn in the mempool, now i have to
> track and propagate the feerates of that child back up to the parent txn
> and track all these dependencies.
>
> perhaps with very careful engineering these issues can be tamed. however
> it seems with sponsors or fee accounts, by separating the pays-for from the
> participates-in concerns we can greatly simplify it to something like:
> compute effective feerate for a txn, including all sponsors that pay more
> than the feerate of the base txn. Mine that txn and it's subsidies using
> the normal algo. If you run out of space, all subsidies are same-sized so
> just take the ones that pay the highest amount up until the added marginal
> feerate is less than the next eligible txn.
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> I see, its not primarily to make it cheaper to append fees, but also
>> allows appending fees in cases that aren't possible now. Is that right? I
>> can certainly see the benefit of a more general way to add a fee to any
>> transaction, regardless of whether you're related to that transaction or
>> not.
>>
>> How would you compare the pros and cons of your account-based approach to
>> something like a new sighash flag? Eg a sighash flag that says "I'm signing
>> this transaction, but the signature is only valid if mined in the same
>> block as transaction X (or maybe transactions LIST)". This could be named
>> SIGHASH_EXTERNAL. Doing this would be a lot more similar to other bitcoin
>> transactions, and no special account would need to be created. Any
>> transaction could specify this. At least that's the first thought I would
>> have in designing a way to arbitrarily bump fees. Have you compared your
>> solution to something more familiar like that?
>>
>> On Tue, Jan 18, 2022 at 11:43 AM Jeremy <jlrubin at mit.edu> wrote:
>>
>>> Can you clarify what you mean by "improve the situation"?
>>>
>>> There's a potential mild bytes savings, but the bigger deal is that the
>>> API should be much less vulnerable to pinning issues, fix dust leakage for
>>> eltoo like protocols, and just generally allow protocol designs to be fully
>>> abstracted from paying fees. You can't easily mathematically quantify API
>>> improvements like that.
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>> <https://twitter.com/JeremyRubin>;
>>>
>>>
>>> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud <billy.tetrud at gmail.com>
>>> wrote:
>>>
>>>> Do you have any back-of-the-napkin math on quantifying how much this
>>>> would improve the situation vs existing methods (eg cpfp)?
>>>>
>>>>
>>>>
>>>> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Happy new years devs,
>>>>>
>>>>> I figured I would share some thoughts for conceptual review that have
>>>>> been bouncing around my head as an opportunity to clean up the fee paying
>>>>> semantics in bitcoin "for good". The design space is very wide on the
>>>>> approach I'll share, so below is just a sketch of how it could work which
>>>>> I'm sure could be improved greatly.
>>>>>
>>>>> Transaction fees are an integral part of bitcoin.
>>>>>
>>>>> However, due to quirks of Bitcoin's transaction design, fees are a
>>>>> part of the transactions that they occur in.
>>>>>
>>>>> While this works in a "Bitcoin 1.0" world, where all transactions are
>>>>> simple on-chain transfers, real world use of Bitcoin requires support for
>>>>> things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
>>>>> and other long lived Smart Contracts that can't predict future fee rates.
>>>>> Having the fees paid in band makes writing these contracts much more
>>>>> difficult as you can't merely express the logic you want for the
>>>>> transaction, but also the fees.
>>>>>
>>>>> Previously, I proposed a special type of transaction called a
>>>>> "Sponsor" which has some special consensus + mempool rules to allow
>>>>> arbitrarily appending fees to a transaction to bump it up in the mempool.
>>>>>
>>>>> As an alternative, we could establish an account system in Bitcoin as
>>>>> an "extension block".
>>>>>
>>>>> *Here's how it might work:*
>>>>>
>>>>> 1. Define a special anyone can spend output type that is a "fee
>>>>> account" (e.g. segwit V2). Such outputs have a redeeming key and an amount
>>>>> associated with them, but are overall anyone can spend.
>>>>> 2. All deposits to these outputs get stored in a separate UTXO
>>>>> database for fee accounts
>>>>> 3. Fee accounts can sign only two kinds of transaction: A: a fee
>>>>> amount and a TXID (or Outpoint?); B: a withdraw amount, a fee, and
>>>>> an address
>>>>> 4. These transactions are committed in an extension block merkle tree.
>>>>> While the actual signature must cover the TXID/Outpoint, the committed data
>>>>> need only cover the index in the block of the transaction. The public key
>>>>> for account lookup can be recovered from the message + signature.
>>>>> 5. In any block, any of the fee account deposits can be: released into
>>>>> fees if there is a corresponding tx; consolidated together to reduce the
>>>>> number of utxos (this can be just an OP_TRUE no metadata needed); or
>>>>> released into fees *and paid back* into the requested withdrawal key
>>>>> (encumbering a 100 block timeout). Signatures must be unique in a block.
>>>>> 6. Mempool logic is updated to allow attaching of account fee spends
>>>>> to transactions, the mempool can restrict that an account is not allowed
>>>>> more spend more than it's balance.
>>>>>
>>>>> *But aren't accounts "bad"?*
>>>>>
>>>>> Yes, accounts are bad. But these accounts are not bad, because any
>>>>> funds withdrawn from the fee extension are fundamentally locked for 100
>>>>> blocks as a coinbase output, so there should be no issues with any series
>>>>> of reorgs. Further, since there is no "rich state" for these accounts, the
>>>>> state updates can always be applied in a conflict-free way in any order.
>>>>>
>>>>>
>>>>> *Improving the privacy of this design:*
>>>>>
>>>>> This design could likely be modified to implement something like
>>>>> Tornado.cash or something else so that the fee account paying can be
>>>>> unlinked from the transaction being paid for, improving privacy at the
>>>>> expense of being a bit more expensive.
>>>>>
>>>>> Other operations could be added to allow a trustless mixing to be done
>>>>> by miners automatically where groups of accounts with similar values are
>>>>> trustlessly split into a common denominator and change, and keys are
>>>>> derived via a verifiable stealth address like protocol (so fee balances can
>>>>> be discovered by tracing the updates posted). These updates could also be
>>>>> produced by individuals rather than miners, and miners could simply honor
>>>>> them with better privacy. While a miner generating an update would be able
>>>>> to deanonymize their mixes, if you have your account mixed several times by
>>>>> independent miners that could potentially add sufficient privacy.
>>>>>
>>>>> The LN can also be used with PTLCs to, in theory, have another
>>>>> individual paid to sponsor a transaction on your behalf only if they reveal
>>>>> a valid sig from their fee paying account, although under this model it's
>>>>> hard to ensure that the owner doesn't pay a fee and then 'cancel' by
>>>>> withdrawing the rest. However, this could be partly solved by using
>>>>> reputable fee accounts (reputation could be measured somewhat
>>>>> decentralized-ly by longevity of the account and transactions paid for
>>>>> historically).
>>>>>
>>>>> *Scalability*
>>>>>
>>>>> This design is fundamentally 'decent' for scalability because adding
>>>>> fees to a transaction does not require adding inputs or outputs and does
>>>>> not require tracking substantial amounts of new state.
>>>>>
>>>>> Paying someone else to pay for you via the LN also helps make this
>>>>> more efficient if the withdrawal issues can be fixed.
>>>>>
>>>>> *Lightning:*
>>>>>
>>>>> This type of design works really well for channels because the
>>>>> addition of fees to e.g. a channel state does not require any sort of
>>>>> pre-planning (e.g. anchors) or transaction flexibility (SIGHASH flags).
>>>>> This sort of design is naturally immune to pinning issues since you could
>>>>> offer to pay a fee for any TXID and the number of fee adding offers does
>>>>> not need to be restricted in the same way the descendant transactions would
>>>>> need to be.
>>>>>
>>>>> *Without a fork?*
>>>>>
>>>>> This type of design could be done as a federated network that bribes
>>>>> miners -- potentially even retroactively after a block is formed. That
>>>>> might be sufficient to prove the concept works before a consensus upgrade
>>>>> is deployed, but such an approach does mean there is a centralizing layer
>>>>> interfering with normal mining.
>>>>>
>>>>>
>>>>> Happy new year!!
>>>>>
>>>>> Jeremy
>>>>>
>>>>> --
>>>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>>>> <https://twitter.com/JeremyRubin>;
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at 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/20220118/59a75bc9/attachment-0001.html>;

📅 Original date posted:2022-01-19 📝 Original message:I see, ...

2023-06-08T01:01:51+02:00

In reply to nevent1q…8qds
_________________________

📅 Original date posted:2022-01-19
📝 Original message:I see, its not primarily to make it cheaper to append fees, but also allows
appending fees in cases that aren't possible now. Is that right? I can
certainly see the benefit of a more general way to add a fee to any
transaction, regardless of whether you're related to that transaction or
not.

How would you compare the pros and cons of your account-based approach to
something like a new sighash flag? Eg a sighash flag that says "I'm signing
this transaction, but the signature is only valid if mined in the same
block as transaction X (or maybe transactions LIST)". This could be named
SIGHASH_EXTERNAL. Doing this would be a lot more similar to other bitcoin
transactions, and no special account would need to be created. Any
transaction could specify this. At least that's the first thought I would
have in designing a way to arbitrarily bump fees. Have you compared your
solution to something more familiar like that?

On Tue, Jan 18, 2022 at 11:43 AM Jeremy <jlrubin at mit.edu> wrote:

> Can you clarify what you mean by "improve the situation"?
>
> There's a potential mild bytes savings, but the bigger deal is that the
> API should be much less vulnerable to pinning issues, fix dust leakage for
> eltoo like protocols, and just generally allow protocol designs to be fully
> abstracted from paying fees. You can't easily mathematically quantify API
> improvements like that.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> Do you have any back-of-the-napkin math on quantifying how much this
>> would improve the situation vs existing methods (eg cpfp)?
>>
>>
>>
>> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Happy new years devs,
>>>
>>> I figured I would share some thoughts for conceptual review that have
>>> been bouncing around my head as an opportunity to clean up the fee paying
>>> semantics in bitcoin "for good". The design space is very wide on the
>>> approach I'll share, so below is just a sketch of how it could work which
>>> I'm sure could be improved greatly.
>>>
>>> Transaction fees are an integral part of bitcoin.
>>>
>>> However, due to quirks of Bitcoin's transaction design, fees are a part
>>> of the transactions that they occur in.
>>>
>>> While this works in a "Bitcoin 1.0" world, where all transactions are
>>> simple on-chain transfers, real world use of Bitcoin requires support for
>>> things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
>>> and other long lived Smart Contracts that can't predict future fee rates.
>>> Having the fees paid in band makes writing these contracts much more
>>> difficult as you can't merely express the logic you want for the
>>> transaction, but also the fees.
>>>
>>> Previously, I proposed a special type of transaction called a "Sponsor"
>>> which has some special consensus + mempool rules to allow arbitrarily
>>> appending fees to a transaction to bump it up in the mempool.
>>>
>>> As an alternative, we could establish an account system in Bitcoin as an
>>> "extension block".
>>>
>>> *Here's how it might work:*
>>>
>>> 1. Define a special anyone can spend output type that is a "fee account"
>>> (e.g. segwit V2). Such outputs have a redeeming key and an amount
>>> associated with them, but are overall anyone can spend.
>>> 2. All deposits to these outputs get stored in a separate UTXO database
>>> for fee accounts
>>> 3. Fee accounts can sign only two kinds of transaction: A: a fee amount
>>> and a TXID (or Outpoint?); B: a withdraw amount, a fee, and an address
>>> 4. These transactions are committed in an extension block merkle tree.
>>> While the actual signature must cover the TXID/Outpoint, the committed data
>>> need only cover the index in the block of the transaction. The public key
>>> for account lookup can be recovered from the message + signature.
>>> 5. In any block, any of the fee account deposits can be: released into
>>> fees if there is a corresponding tx; consolidated together to reduce the
>>> number of utxos (this can be just an OP_TRUE no metadata needed); or
>>> released into fees *and paid back* into the requested withdrawal key
>>> (encumbering a 100 block timeout). Signatures must be unique in a block.
>>> 6. Mempool logic is updated to allow attaching of account fee spends to
>>> transactions, the mempool can restrict that an account is not allowed more
>>> spend more than it's balance.
>>>
>>> *But aren't accounts "bad"?*
>>>
>>> Yes, accounts are bad. But these accounts are not bad, because any funds
>>> withdrawn from the fee extension are fundamentally locked for 100 blocks as
>>> a coinbase output, so there should be no issues with any series of reorgs.
>>> Further, since there is no "rich state" for these accounts, the state
>>> updates can always be applied in a conflict-free way in any order.
>>>
>>>
>>> *Improving the privacy of this design:*
>>>
>>> This design could likely be modified to implement something like
>>> Tornado.cash or something else so that the fee account paying can be
>>> unlinked from the transaction being paid for, improving privacy at the
>>> expense of being a bit more expensive.
>>>
>>> Other operations could be added to allow a trustless mixing to be done
>>> by miners automatically where groups of accounts with similar values are
>>> trustlessly split into a common denominator and change, and keys are
>>> derived via a verifiable stealth address like protocol (so fee balances can
>>> be discovered by tracing the updates posted). These updates could also be
>>> produced by individuals rather than miners, and miners could simply honor
>>> them with better privacy. While a miner generating an update would be able
>>> to deanonymize their mixes, if you have your account mixed several times by
>>> independent miners that could potentially add sufficient privacy.
>>>
>>> The LN can also be used with PTLCs to, in theory, have another
>>> individual paid to sponsor a transaction on your behalf only if they reveal
>>> a valid sig from their fee paying account, although under this model it's
>>> hard to ensure that the owner doesn't pay a fee and then 'cancel' by
>>> withdrawing the rest. However, this could be partly solved by using
>>> reputable fee accounts (reputation could be measured somewhat
>>> decentralized-ly by longevity of the account and transactions paid for
>>> historically).
>>>
>>> *Scalability*
>>>
>>> This design is fundamentally 'decent' for scalability because adding
>>> fees to a transaction does not require adding inputs or outputs and does
>>> not require tracking substantial amounts of new state.
>>>
>>> Paying someone else to pay for you via the LN also helps make this more
>>> efficient if the withdrawal issues can be fixed.
>>>
>>> *Lightning:*
>>>
>>> This type of design works really well for channels because the addition
>>> of fees to e.g. a channel state does not require any sort of pre-planning
>>> (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
>>> design is naturally immune to pinning issues since you could offer to pay a
>>> fee for any TXID and the number of fee adding offers does not need to be
>>> restricted in the same way the descendant transactions would need to be.
>>>
>>> *Without a fork?*
>>>
>>> This type of design could be done as a federated network that bribes
>>> miners -- potentially even retroactively after a block is formed. That
>>> might be sufficient to prove the concept works before a consensus upgrade
>>> is deployed, but such an approach does mean there is a centralizing layer
>>> interfering with normal mining.
>>>
>>>
>>> Happy new year!!
>>>
>>> Jeremy
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>> <https://twitter.com/JeremyRubin>;
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at 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/20220118/3c72c1c7/attachment-0001.html>;

📅 Original date posted:2022-01-18 📝 Original message:Do you ...

2023-06-08T01:01:49+02:00

In reply to nevent1q…swtr
_________________________

📅 Original date posted:2022-01-18
📝 Original message:Do you have any back-of-the-napkin math on quantifying how much this would
improve the situation vs existing methods (eg cpfp)?

On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Happy new years devs,
>
> I figured I would share some thoughts for conceptual review that have been
> bouncing around my head as an opportunity to clean up the fee paying
> semantics in bitcoin "for good". The design space is very wide on the
> approach I'll share, so below is just a sketch of how it could work which
> I'm sure could be improved greatly.
>
> Transaction fees are an integral part of bitcoin.
>
> However, due to quirks of Bitcoin's transaction design, fees are a part of
> the transactions that they occur in.
>
> While this works in a "Bitcoin 1.0" world, where all transactions are
> simple on-chain transfers, real world use of Bitcoin requires support for
> things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
> and other long lived Smart Contracts that can't predict future fee rates.
> Having the fees paid in band makes writing these contracts much more
> difficult as you can't merely express the logic you want for the
> transaction, but also the fees.
>
> Previously, I proposed a special type of transaction called a "Sponsor"
> which has some special consensus + mempool rules to allow arbitrarily
> appending fees to a transaction to bump it up in the mempool.
>
> As an alternative, we could establish an account system in Bitcoin as an
> "extension block".
>
> *Here's how it might work:*
>
> 1. Define a special anyone can spend output type that is a "fee account"
> (e.g. segwit V2). Such outputs have a redeeming key and an amount
> associated with them, but are overall anyone can spend.
> 2. All deposits to these outputs get stored in a separate UTXO database
> for fee accounts
> 3. Fee accounts can sign only two kinds of transaction: A: a fee amount
> and a TXID (or Outpoint?); B: a withdraw amount, a fee, and an address
> 4. These transactions are committed in an extension block merkle tree.
> While the actual signature must cover the TXID/Outpoint, the committed data
> need only cover the index in the block of the transaction. The public key
> for account lookup can be recovered from the message + signature.
> 5. In any block, any of the fee account deposits can be: released into
> fees if there is a corresponding tx; consolidated together to reduce the
> number of utxos (this can be just an OP_TRUE no metadata needed); or
> released into fees *and paid back* into the requested withdrawal key
> (encumbering a 100 block timeout). Signatures must be unique in a block.
> 6. Mempool logic is updated to allow attaching of account fee spends to
> transactions, the mempool can restrict that an account is not allowed more
> spend more than it's balance.
>
> *But aren't accounts "bad"?*
>
> Yes, accounts are bad. But these accounts are not bad, because any funds
> withdrawn from the fee extension are fundamentally locked for 100 blocks as
> a coinbase output, so there should be no issues with any series of reorgs.
> Further, since there is no "rich state" for these accounts, the state
> updates can always be applied in a conflict-free way in any order.
>
>
> *Improving the privacy of this design:*
>
> This design could likely be modified to implement something like
> Tornado.cash or something else so that the fee account paying can be
> unlinked from the transaction being paid for, improving privacy at the
> expense of being a bit more expensive.
>
> Other operations could be added to allow a trustless mixing to be done by
> miners automatically where groups of accounts with similar values are
> trustlessly split into a common denominator and change, and keys are
> derived via a verifiable stealth address like protocol (so fee balances can
> be discovered by tracing the updates posted). These updates could also be
> produced by individuals rather than miners, and miners could simply honor
> them with better privacy. While a miner generating an update would be able
> to deanonymize their mixes, if you have your account mixed several times by
> independent miners that could potentially add sufficient privacy.
>
> The LN can also be used with PTLCs to, in theory, have another individual
> paid to sponsor a transaction on your behalf only if they reveal a valid
> sig from their fee paying account, although under this model it's hard to
> ensure that the owner doesn't pay a fee and then 'cancel' by withdrawing
> the rest. However, this could be partly solved by using reputable fee
> accounts (reputation could be measured somewhat decentralized-ly by
> longevity of the account and transactions paid for historically).
>
> *Scalability*
>
> This design is fundamentally 'decent' for scalability because adding fees
> to a transaction does not require adding inputs or outputs and does not
> require tracking substantial amounts of new state.
>
> Paying someone else to pay for you via the LN also helps make this more
> efficient if the withdrawal issues can be fixed.
>
> *Lightning:*
>
> This type of design works really well for channels because the addition of
> fees to e.g. a channel state does not require any sort of pre-planning
> (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
> design is naturally immune to pinning issues since you could offer to pay a
> fee for any TXID and the number of fee adding offers does not need to be
> restricted in the same way the descendant transactions would need to be.
>
> *Without a fork?*
>
> This type of design could be done as a federated network that bribes
> miners -- potentially even retroactively after a block is formed. That
> might be sufficient to prove the concept works before a consensus upgrade
> is deployed, but such an approach does mean there is a centralizing layer
> interfering with normal mining.
>
>
> Happy new year!!
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20220118/655b3d36/attachment.html>;

📅 Original date posted:2021-08-05 📝 Original message:> A ...

2023-06-08T00:57:25+02:00

In reply to nevent1q…0e4l
_________________________

📅 Original date posted:2021-08-05
📝 Original message:> A maximum amount is allowed to be spent within EVERY epoch.

It sounds like you're proposing an opcode that takes in epochStart and
epochEnd as parameters. I still don't understand why its useful to specify
those as absolute block heights. You mentioned that this enables more
straightforward validation logic, but I don't see how. Eg, if you have a
UTXO encumbered by rateLimit(epochStart = 800100, epochEnd = 800200, limit
= 100k, remain = 100k), what happens if you don't spend that UTXO before
block 800200? Is the output no longer rate limited then? Or is the opcode
calculating 800200-800100 = 100 and applying a rate limit for the next
epoch? If the first, then the UTXO must be spent within one epoch to remain
rate limited. If the second, then it seems nearly identical to simply
specifying window=100 as a parameter instead of epochStart and epochEnd.

> then there must be only a single (rate-limited) output

This rule would make transactions tricky if you're sending money into
someone else's wallet that may be rate limited. If the requirement is that
only you yourself can send money into a rate limited wallet, then this
point is moot but it would be ideal to not have such a requirement.

This is how I'd imagine creating an opcode like this:

rateLimit(windowSize = 144 blocks, limit = 100k sats)

This would define that the epoch is 1 day's worth of blocks. This would
evenly divide bitcoin's retarget period and so each window would start and
end at those dividing lines (eg the first 144 blocks of the retargetting
period, then the second, then the third, etc).

When this output is spent, it ensures that there's a maximum of 100k sats
is sent to addresses other than the originating address. It also records
the amount spent in the current 144 block window for that address (eg by
simply recording the already-spent amount on the resulting UTXO and having
an index that allows looking up UTXOs by address and adding them up). That
way, when any output from that address is spent again, if a new 144 block
window has started, the limit is reset, but if its still within the same
window, the already-spent amounts for UTXOs from that address are added up
and subtracted from the limit, and that number is the remaining limit a
subsequent transaction needs to adhere to.

This way, 3rd party could send transactions into an address like this, and
multiple outputs can be combined and used to spend to arbitrary outputs (up
to the rate limit of course).

On Wed, Aug 4, 2021 at 3:48 AM Zac Greenwood <zachgrw at gmail.com> wrote:

> > Ah I see, this is all limited to within a single epoch.
>
> No, that wouldn't be useful. A maximum amount is allowed to be spent
> within EVERY epoch.
>
> Consider an epoch length of 100 blocks with a spend limit of 200k per
> epoch. The following is allowed:
>
> epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for
> epoch1: 80k;
> epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining for
> epoch1: 20k;
> epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for
> epoch2: 40k.
>
> Since the limit pertains to each individual epoch, it is allowed to spend
> up to the full limit at the start of any new epoch. In this example, the
> spending was as follows:
>
> 800140: 120k
> 800195: 60k
> 800201: 160k.
>
> Note that in a span of 62 blocks a total of 340k sats was spent. This may
> seem to violate the 200k limit per 100 blocks, but this is the result of
> using a per-epoch limit. This allows a maximum of 400k to be spent in 2
> blocks llke so: 200k in the last block of an epoch and another 200k in the
> first block of the next epoch. However this is inconsequential for the
> intended goal of rate-limiting which is to enable small spends over time
> from a large amount and to prevent theft of a large amount with a single
> transaction.
>
> To explain the proposed design more clearly, I have renamed the params as
> follows:
>
> epochStart: block height of first block of the current epoch (was: h0);
> epochEnd: block height of last block of the current epoch (was: h1);
> limit: the maximum total amount allowed to be spent within the current
> epoch (was: a);
> remain: the remaining amount allowed to be spent within the current epoch
> (was: a_remaining);
>
> Also, to illustrate that the params are specific to a transaction, I will
> hence precede the param with the transaction name like so:
> tx8_limit, tx31c_remain, tx42z_epochStart, ... etc.
>
> For simplicity, only transactions with no more than one rate-limited input
> are considered, and with no more than two outputs: one rate-limited change
> output, and a normal (not rate-limited) output.
>
> Normally, a simple transaction generates two outputs: one for a payment to
> a third party and one for the change address. Again for simplicity, we
> demand that a transaction which introduces rate-limiting must have only a
> single, rate-limited output. The validation rule might be: if a transaction
> has rate-limiting params and none of its inputs are rate-limited, then
> there must be only a single (rate-limited) output (and no second or change
> output).
>
> Consider rate limiting transactions tx1 having one or more normal (non
> rate-limited) inputs:
>
> tx1 gets included at block height 800004;
> The inputs of tx1 are not rate-limited => tx1 must have only a single
> output which will become rate-limited;
> params: tx1_epochStart=800001, tx1_epochEnd=800100, tx1_limit=200k,
> tx1_remain=200k;
> => This defines that an epoch has 100 blocks and no more than 200k sats
> may be spent in any one epoch. Within the current epoch, 200k sats may
> still be spent.
>
> This transaction begins to rate-limit a set of inputs, so it has a single
> rate-limited output.
> Let's explore transactions that have the output of tx1 as their input. I
> will denote the output of tx1 as "out1".
>
> tx2a has out1 as its only input;
> tx2a spends 50k sats and gets included at block height 803050;
> tx2a specifies the following params for its change output "chg2a":
> chg2a_epochStart=803001, chg2a_epochEnd=803100;
> chg2a_limit=200k, chg2a_remain=150k.
>
> To enforce rate-limiting, the system must validate the params of the
> change output chg2a to ensure that overspending is not allowed.
>
> The above params are allowed because:
> => 1. the epoch does not become smaller than 100 blocks [(chg2a_epochEnd -
> chg2a_epochStart) >= (tx1_epochEnd - tx1_epochStart)]
> => 2. tx1_limit has not been increased (ch2a_limit <= tx1_limit)
> => 3. the amount spent (50k sats) does not exceed tx1_remain AND does not
> exceed chg2a_limit;
> => 4. chg2a_remain" is 50k sats less than chg2a_limit.
>
> A transaction may also further constrain further spending like so:
>
> tx2b has out1as its only input;
> tx2b spends 8k sats and gets included at block height 808105;
> tx2b specifies the following params for its change output "chg2b":
> chg2b_epochStart=808101, chg2b_epochEnd=808250;
> chg2b_limit=10k, chg2b_remain=0.
>
> These params are allowed because:
> => 1. the epoch does not become smaller than100 blocks. It is fine to
> increase the epoch to 150 blocks because it does not enable exceeding the
> original rate-limit;
> => 2. the limit (chg2b_limit) has been decreased to 10k sats, further
> restricting the maximum amount allowed to be spent within the current and
> any subsequent epochs;
> => 3. the amount spent (10k sats) does not exceed tx1_remain AND does not
> exceed chg2b_limit;
> => 4. chg2b_remain has been set to zero, meaning that within the current
> epoch (block height 808101 to and including 808250), tx2b cannot be used as
> a spending input to any transaction.
>
> Starting from block height 808251, a new epoch will start and the
> rate-limited output of tx2b may again be used as an input for a subsequent
> rate-limited transaction tx3b. This transaction tx3b must again be
> accompanied by params that do not violate the rate-limit as defined by the
> params of tx2b and which are stored with output out2b. So, the epoch of
> tx3b must be at minimum 150 blocks, the maximum that is allowed to be spent
> per epoch is at most 10k sats, and chg3b_remain must be decreased by at
> least the amount spent by tx3b.
>
> From the above, the rate-limiting mechanics should hopefully be clear and
> full set of validation rules could be defined in a more generalized way
> with little additional effort.
>
> Note that I conveniently avoided talking about how to represent the
> parameters within transactions or outputs, simply because I currently lack
> enough understanding to reason about this. I am hoping that others may
> offer help.
>
> Zac
>
>
> On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> > To enable more straightforward validation logic.
>> > within the current epoch
>>
>> Ah I see, this is all limited to within a single epoch. I think that
>> sufficiently limits the window of time in which nodes have to store
>> information for rate limited outputs. However, I don't see how specifying
>> block ranges simplifies the logic - wouldn't this complicate the logic with
>> additional user-specified constraints? It also prevents the output from
>> being able to be rate limited over the span of multiple epochs, which would
>> seem to make it a lot more difficult to use for certain types of wallets
>> (eg cold wallets).
>>
>> I think I see the logic of your 'remaining' parameter there. If you start
>> with a single rate-limited input, you can split that into many outputs,
>> only one of which have a 'remaining' balance. The rest can simply remain
>> unspendable for the rest of the epoch. That way these things don't need to
>> be tied together. However, that doesn't solve the problem of 3rd parties
>> being able to send money into the wallet.
>>
>> > I don't believe that the marginal added functionality would justify the
>> increased implementation complexity
>>
>> Perhaps, but I think there is a lot of benefit in allowing these kinds of
>> things to operate as similarly as possible to normal transactions, for one
>> because of usability reasons. If each opcode has its own quirks that are
>> not intuitively related to their purpose (eg if a rate-limited wallet had
>> no way to get a receiving address), it would confuse end-users (eg who
>> wonder how to get a receiving address and how they can ask people to send
>> money into their wallet) or require a lot of technical complexity in
>> applications (eg to support something like cooperatively connecting with
>> their wallet so that a transaction can be made that creates a new
>> single-output for the wallet). A little complexity in this opcode can save
>> a lot of external complexity here I think.
>>
>> > my understanding of Bitcoin is way too low to be able to write a BIP
>> and do the implementation
>>
>> You might be able to find people willing to help. I would be willing to
>> help write the BIP spec. I'm not the right person to help with the
>> implementation, but perhaps you could find someone else who is. Even if the
>> BIP isn't adopted, it could be a starting point or inspiration for someone
>> else to write an improved version.
>>
>> On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>>
>>> [Note: I've moved your reply to the newly started thread]
>>>
>>> Hi Billy,
>>>
>>> Thank you for your kind and encouraging feedback.
>>>
>>> I don't quite understand why you'd want to define a specific span of
>>>> blocks for the rate limit. Why not just specify the size of the window (in
>>>> blocks) to rate limit within, and the limit?
>>>
>>>
>>> To enable more straightforward validation logic.
>>>
>>> You mentioned change addresses, however, with the parameters you
>>>> defined, there would be no way to connect together the change address with
>>>> the original address, meaning they would have completely separate rate
>>>> limits, which wouldn't work since the change output would ignore the
>>>> previous rate limit.
>>>
>>>
>>> The rate-limiting parameters must be re-specified for each rate-limited
>>> input. So, a transaction that has a rate-limited input is only valid if its
>>> output is itself rate-limited such that it does not violate the
>>> rate-limiting constraints of its input.
>>>
>>> In my thread-starter, I gave the below example of a rate-limited address
>>> a2 that serves as input for transaction t2:
>>>
>>> a2: 99.8 sats at height 800100;
>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>>
>>> Transaction t2:
>>> Included at block height 800200
>>> Spend: 400k + fees.
>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>>>
>>> Note how transaction t2 re-specifies the rate-limiting parameters.
>>> Validation must ensure that the re-specified parameters are within bounds,
>>> i.e., do not allow more spending per epoch than the rate-limiting
>>> parameters of its input address a2. Re-specifying the rate-limiting
>>> parameters offers the flexibility to further restrict spending, or to
>>> disable any additional spending within the current epoch by setting
>>> a_remaining to zero.
>>>
>>> Result:
>>> Value at destination address: 400k sats;
>>> Rate limiting params at destination address: none;
>>> Value at change address a3: 99.4m sats;
>>> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k,
>>> a_remaining=100k.
>>>
>>> As a design principle I believe it makes sense if the system is able to
>>> verify the validity of a transaction without having to consider any
>>> transactions that precede its inputs. As a side-note, doing away with this
>>> design principle would however enable more sophisticated rate-limiting
>>> (such as rate-limiting per sliding window instead of rate-limiting per
>>> epoch having a fixed start and end block), but while at the same time
>>> reducing the size of per rate-limiting transaction (because it would enable
>>> specifying the rate-limiting parameters more space-efficiently). To test
>>> the waters and to keep things relatively simple, I chose not to go into
>>> this enhanced form of rate-limiting.
>>>
>>> I haven't gone into how to process a transaction having multiple
>>> rate-limited inputs. The easiest way to handle this case is to not allow
>>> any transaction having more than one rate-limited input. One could imagine
>>> complex logic to handle transactions having multiple rate-limited inputs by
>>> creating multiple rate-limited change addresses. However at first glance I
>>> don't believe that the marginal added functionality would justify the
>>> increased implementation complexity.
>>>
>>> I'd be interested in seeing you write a BIP for this.
>>>
>>>
>>> Thank you, but sadly my understanding of Bitcoin is way too low to be
>>> able to write a BIP and do the implementation. However I see tremendous
>>> value in this functionality. Favorable feedback of the list regarding the
>>> usefulness and the technical feasibility of rate-limiting functionality
>>> would of course be an encouragement for me to descend further down the
>>> rabbit hole.
>>>
>>> Zac
>>>
>>>
>>> On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>>>
>>>> [Resubmitting to list with minor edits. My previous submission ended up
>>>> inside an existing thread, apologies.]
>>>>
>>>> Hi list,
>>>>
>>>> I'd like to explore whether it is feasible to implement new scripting
>>>> capabilities in Bitcoin that enable limiting the output amount of a
>>>> transaction based on the total value of its inputs. In other words, to
>>>> implement the ability to limit the maximum amount that can be sent from an
>>>> address.
>>>>
>>>> Two use cases come to mind:
>>>>
>>>> UC1: enable a user to add additional protection their funds by
>>>> rate-limiting the amount that they are allowed to send during a certain
>>>> period (measured in blocks). A typical use case might be a user that
>>>> intends to hodl their bitcoin, but still wishes to occasionally send small
>>>> amounts. Rate-limiting avoids an attacker from sweeping all the users'
>>>> funds in a single transaction, allowing the user to become aware of the
>>>> theft and intervene to prevent further thefts.
>>>>
>>>> UC2: exchanges may wish to rate-limit addresses containing large
>>>> amounts of bitcoin, adding warm- or hot-wallet functionality to a
>>>> cold-storage address. This would enable an exchange to drastically reduce
>>>> the number of times a cold wallet must be accessed with private keys that
>>>> give access to the full amount.
>>>>
>>>> In a typical setup, I'd envision using multisig such that the user has
>>>> two sets of private keys to their encumbered address (with a "set" of keys
>>>> meaning "one or more" keys). One set of private keys allows only for
>>>> sending with rate-limiting restrictions in place, and a second set of
>>>> private keys allowing for sending any amount without rate-limiting,
>>>> effectively overriding such restriction.
>>>>
>>>> The parameters that define in what way an output is rate-limited might
>>>> be defined as follows:
>>>>
>>>> Param 1: a block height "h0" indicating the first block height of an
>>>> epoch;
>>>> Param 2: a block height "h1" indicating the last block height of an
>>>> epoch;
>>>> Param 3: an amount "a" in satoshi indicating the maximum amount that is
>>>> allowed to be sent in any epoch;
>>>> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum
>>>> amount that is allowed to be sent within the current epoch.
>>>>
>>>> For example, consider an input containing 100m sats (1 BTC) which has
>>>> been rate-limited with parameters (h0, h1, a, a_remaining) of (800000,
>>>> 800143, 500k, 500k). These parameters define that the address is
>>>> rate-limited to sending a maximum of 500k sats in the current epoch that
>>>> starts at block height 800000 and ends at height 800143 (or about one day
>>>> ignoring block time variance) and that the full amount of 500k is still
>>>> sendable. These rate-limiting parameters ensure that it takes at minimum
>>>> 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to
>>>> spend the full 100m sats. As noted earlier, in a typical setup a user
>>>> should retain the option to transact the entire amount using a second (set
>>>> of) private key(s).
>>>>
>>>> For rate-limiting to work, any change output created by a transaction
>>>> from a rate-limited address must itself be rate-limited as well. For
>>>> instance, expanding on the above example, assume that the user spends 200k
>>>> sats from a rate-limited address a1 containing 100m sats:
>>>>
>>>> Start situation:
>>>> At block height 800000: rate-limited address a1 is created;
>>>> Value of a1: 100.0m sats;
>>>> Rate limiting params of a1: h0=800000, h1=800143, a=500k,
>>>> a_remaining=500k;
>>>>
>>>> Transaction t1:
>>>> Included at block height 800100;
>>>> Spend: 200k + fee;
>>>> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k.
>>>>
>>>> Result:
>>>> Value at destination address: 200k sats;
>>>> Rate limiting params at destination address: none;
>>>> Value at change address a2: 99.8m sats;
>>>> Rate limiting params at change address a2: h0=800000, h1=800143,
>>>> a=500k, a_remaining=300k.
>>>>
>>>> In order to properly enforce rate limiting, the change address must be
>>>> rate-limited such that the original rate limit of 500k sats per 144 blocks
>>>> cannot be exceeded. In this example, the change address a2 were given the
>>>> same rate limiting parameters as the transaction that served as its input.
>>>> As a result, from block 800100 up until and including block 800143, a
>>>> maximum amount of 300k sats is allowed to be spent from the change address.
>>>>
>>>> Example continued:
>>>> a2: 99.8 sats at height 800100;
>>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>>>
>>>> Transaction t2:
>>>> Included at block height 800200
>>>> Spend: 400k + fees.
>>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>>>>
>>>> Result:
>>>> Value at destination address: 400k sats;
>>>> Rate limiting params at destination address: none;
>>>> Value at change address a3: 99.4m sats;
>>>> Rate limiting params at change address a3: h0=800144, h1=800287,
>>>> a=500k, a_remaining=100k.
>>>>
>>>> Transaction t2 is allowed because it falls within the next epoch
>>>> (running from 800144 to 800287) so a spend of 400k does not violate the
>>>> constraint of 500k per epoch.
>>>>
>>>> As could be seen, the rate limiting parameters are part of the
>>>> transaction and chosen by the user (or their wallet). This means that the
>>>> parameters must be validated to ensure that they do not violate the
>>>> intended constraints.
>>>>
>>>> For instance, this transaction should not be allowed:
>>>> a2: 99.8 sats at height 800100;
>>>> Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>>>
>>>> Transaction t2a:
>>>> Included at block height 800200;
>>>> Spend: 400k + fees;
>>>> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k.
>>>>
>>>> This transaction t2a attempts to shift the epoch forward by 20 blocks
>>>> such that it starts at 800124 instead of 800144. Shifting the epoch forward
>>>> like this must not be allowed because it enables spending more that the
>>>> rate limit allows, which is 500k in any epoch of 144 blocks. It would
>>>> enable overspending:
>>>>
>>>> t1: spend 200k at 800100 (epoch 1: total: 200k);
>>>> t2a: spend 400k at 800200 (epoch 2: total: 400k);
>>>> t3a: spend 100k at 800201 (epoch 2: total: 500k);
>>>> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for
>>>> epoch 2).
>>>>
>>>> Specifying the rate-limiting parameters explicitly at every transaction
>>>> allows the user to tighten the spending limit by setting tighter limits or
>>>> for instance by setting a_remainder to 0 if they wish to enforce not
>>>> spending more during an epoch. A second advantage of explicitly specifying
>>>> the four rate-limiting parameters with each transaction is that it allows
>>>> the system to fully validate the transaction without having to consider any
>>>> previous transactions within an epoch.
>>>>
>>>> I will stop here because I would like to gauge interest in this idea
>>>> first before continuing work on other aspects. Two main pieces of work jump
>>>> to mind:
>>>>
>>>> Define all validations;
>>>> Describe aggregate behaviour of multiple (rate-limited) inputs, proof
>>>> that two rate-limited addresses cannot spend more than the sum of their
>>>> individual limits.
>>>>
>>>> Zac
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210804/ecdc6902/attachment-0001.html>;

📅 Original date posted:2021-08-02 📝 Original message:Hey ...

2023-06-08T00:57:20+02:00

In reply to nevent1q…25m7
_________________________

📅 Original date posted:2021-08-02
📝 Original message:Hey Zac,

I think this could be a useful opcode. It kinda seems like UC1 and UC2 are
basically the same use case: using rate-limiting to reduce risk of theft or
mistake. I think this could be a helpful addition to a good wallet setup.

I don't quite understand why you'd want to define a specific span of blocks
for the rate limit. Why not just specify the size of the window (in blocks)
to rate limit within, and the limit?

You mentioned change addresses, however, with the parameters you defined,
there would be no way to connect together the change address with the
original address, meaning they would have completely separate rate limits,
which wouldn't work since the change output would ignore the previous rate
limit. I can think of the following options:

A. You could always send change back to the *same* address. This is the
simplest option, and the only downside I can think of is exposing the
public key of an address. I'm not quite sure what the consensus is on the
dangers of exposing the public key. It theoretically reduces quantum
resistance a bit, but I think I read that some of taproot's mechanisms
expose the bare public key, so maybe consensus has changed about that in
recent years?

B. Have some way to specify connected addresses in the output. This has the
edge case that one of the addresses wouldn't be able to specify all the
addresses that it should be connected with, because it would create a hash
loop (ie if you had address A and B that should be connected, you can
create address A and then specify that address B be connected to address A,
but address A cannot specify its connection to B because A was created
before B was created). You wouldn't want one address to be able to simply
define a connection to another address, because this would open up attack
vectors where people could encumber other people's addresses with rate
limits connected to theirs. You could define connections based on
signatures, which could be done without creating a hash loop, however it
would require exposing the public keys of other addresses when you do that,
at which point you might as well go with option A.

C. You could specify that rate limits follow a certain output. Eg, if you
create a transaction with destination output 1 and change output 2, your
rate limiting opcode could specify that output 2 should inherit the rate
limit. These inherited rate limits could all be connected together
automatically.

Another consideration is what to use for a receive-address. I would say the
simplest option here is to receive at an address that contains an existing
output already. If you allowed receiving at an address that contains no
coins, you'd have to specify at least one other address to connect it with.
This could work, but I don't see any advantage to it, since you don't gain
any privacy by creating a new address if you're going to immediately
programmatically tie it to the other addresses.

One thing to consider is the cost of carrying around and checking these
rate limits. Ideally it should be a very small amount of data carried
around in the UTXO set, and be very cheap to verify when the opcode comes
up. I think it would make sense for such an opcode to only be able to track
rate-limits over short spans, like a month or less. Allowing the user to
specify an arbitrary window over which to track a rate-limit seems like
something that would probably open up a dos vector or other node resource
usage abuse attacks. It might be useful enough to simply rate limit over
each epoch (two weeks), but having a small set of options could also be
useful (eg 1 day, 1 week, or 1 month).

In any case, I'd be interested in seeing you write a BIP for this. Of
course, don't take my word as community interest. I'm reasonably new to the
bitcoin dev community, so definitely don't jump the gun based on my
interest.

On Sat, Jul 31, 2021 at 2:51 PM Zac Greenwood via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi list,
>
> I'd like to explore whether it is feasible to implement new scripting
> capabilities in Bitcoin that enable limiting the output amount of a
> transaction based on the total value of its inputs. In other words, to
> implement the ability to limit the maximum amount that can be sent from an
> address.
>
> Two use cases come to mind:
>
> UC1: enable a user to add additional protection their funds by
> rate-limiting the amount they are able to send during a certain period
> (measured in blocks). A typical use case might be a user that intends to
> hodl their bitcoin, but still wishes to occasionally send small amounts.
> This avoids an attacker from sweeping all their funds in a single
> transaction, allowing the user to become aware of the theft and intervene
> to prevent further theft.
>
> UC2: exchanges may wish to rate-limit addresses containing large amounts
> of bitcoin, adding warm- or hot-wallet functionality to a cold-storage
> address. This would enable an exchange to drastically reduce the number of
> times a cold wallet must be accessed with private keys that enable access
> to the full amount.
>
> In a typical setup, I'd envision using multisig such that the user has two
> sets of private keys to their encumbered address (with a "set" of keys
> meaning "one or more" keys). One set of private keys allows only for
> sending with rate-limiting restrictions in place, and a s second set of
> private keys allowing for sending any amount without rate-limiting,
> effectively overriding such restriction.
>
> The parameters that define in what way an output is rate-limited might be
> defined as follows:
>
> Param 1: a block height "h0" indicating the first block height of an epoch;
> Param 2: a block height "h1" indicating the last block height of an epoch;
> Param 3: an amount "a" in satoshi indicating the maximum amount that is
> allowed to be sent in any epoch;
> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum
> amount that is allowed to be sent within the current epoch.
>
> For example, consider an input containing 100m sats (1 BTC) which has been
> rate-limited with parameters (h0, h1, a, a_remaning) of (800000, 800143,
> 500k, 500k). These parameters define that the address is rate-limited to
> sending a maximum of 500k sats in the current epoch that starts at block
> height 800000 and ends at height 800143 (or about one day ignoring block
> time variance) and that the full amount of 500k is still sendable. These
> rate-limiting parameters ensure that it takes at minimum 100m / 500k = 200
> transactions and 200 x 144 blocks or about 200 days to spend the full 100m
> sats. As noted earlier, in a typical setup a user should retain the option
> to transact the entire amount using a second (set of) private key(s).
>
> For rate-limiting to work, any change output created by a transaction from
> a rate-limited address must itself be rate-limited as well. For instance,
> expanding on the above example, assume that the user spends 200k sats from
> a rate-limited address a1 containing 100m sats:
>
> Start situation:
> At block height 800000: rate-limited address a1 is created;
> Value of a1: 100.0m sats;
> Rate limiting params of a1: h0=800000, h1=800143, a=500k, a_remaining=500k;
>
> Transaction t1:
> Included at block height 800100;
> Spend: 200k + fee;
> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k.
>
> Result:
> Value at destination address: 200k sats;
> Rate limiting params at destination address: none;
> Value at change address a2: 99.8m sats;
> Rate limiting params at change address a2: h0=800000, h1=800143, a=500k,
> a_remaining=300k.
>
> In order to properly enforce rate limiting, the change address must be
> rate-limited such that the original rate limit of 500k sats per 144 blocks
> cannot be exceeded. In this example, the change address a2 were given the
> same rate limiting parameters as the transaction that served as its input.
> As a result, from block 800100 up until and including block 800143, a
> maximum amount of 300k sats is allowed to be spent from the change address.
>
> Example continued:
> a2: 99.8 sats at height 800100;
> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>
> Transaction t2:
> Included at block height 800200
> Spend: 400k + fees.
> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>
> Result:
> Value at destination address: 400k sats;
> Rate limiting params at destination address: none;
> Value at change address a3: 99.4m sats;
> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k,
> a_remaining=100k.
>
> Transaction t2 is allowed because it falls within the next epoch (running
> from 800144 to 800287) so a spend of 400k does not violate the constraint
> of 500k per epoch.
>
> As could be seen, the rate limiting parameters are part of the transaction
> and chosen by the user (or their wallet). This means that the parameters
> must be validated to ensure that they do not violate the intended
> constraints.
>
> For instance, this transaction should not be allowed:
> a2: 99.8 sats at height 800100;
> Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k;
>
> Transaction t2a:
> Included at block height 800200;
> Spend: 400k + fees;
> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k.
>
> This transaction t2a attempts to shift the epoch forward by 20 blocks such
> that it starts at 800124 instead of 800144. Shifting the epoch forward like
> this must not be allowed because it enables spending more that the rate
> limit allows, which is 500k in any epoch of 144 blocks. It would enable
> overspending:
>
> t1: spend 200k at 800100 (epoch 1: total: 200k);
> t2a: spend 400k at 800200 (epoch 2: total: 400k);
> t3a: spend 100k at 800201 (epoch 2: total: 500k);
> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch
> 2).
>
> Specifying the rate-limiting parameters explicitly at every transaction
> allows the user to tighten the spending limit by setting tighter limits or
> for instance by setting a_remainder to 0 if they wish to enforce not
> spending more during an epoch.
>
> I will stop here because I would like to gauge interest in this idea first
> before continuing work on other aspects. Two main pieces of work jump to
> mind:
>
> Define all validations;
> Describe aggregate behaviour of multiple (rate-limited) inputs, proof that
> two rate-limited addresses cannot spend more than the sum of their
> individual limits.
>
> Zac
>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20210801/731b3ebe/attachment-0001.html>;

📅 Original date posted:2021-07-21 📝 Original message:Hi ...

2023-06-08T00:57:07+02:00

In reply to nevent1q…5kh6
_________________________

📅 Original date posted:2021-07-21
📝 Original message:Hi All,

I have been working on a proposal for an opcode I call
OP_CONSTRAINDESTINATION. The purpose of the opcode is to allow a spend-path
to restrict the destination address that an output's coins can be directed
to. When the destination address is something like a P2SH address, this
allows step-wise covenant scripts (where one script must lead to another).

This involves both specifying particular addresses the output is allowed to
send coins to, as well as constraining the amount of the fee that output is
allowed to contribute to. For example, if you had an output that contains
1000 satoshi, you could specify that a maximum of ~100 sats of that output
go to the miner fee and the other ~900 sats must go to one of a list of
specified addresses (~ meaning approximately, because the fee is specified
relative to recent median fee rates - details in the proposal).

This opcode has a few different applications, but my primary motivation for
creating this opcode is to create more flexible wallet vaults
<https://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults>;
.

To compare this opcode to OP_CHECKTEMPLATEVERIFY, wallet vaults that can be
created with OP_CTV must be created in specified chunks: the address is
explicitly tied to a particular utxo sent to it. To retrieve coins from the
vault, the output must be spent by one of a specific set of transactions
(potentially one per spend path). Outputs cannot be arbitrarily combined
into a transaction, and there is no flexibility whatsoever in deciding
options at the time of spending from the vault - all options must be
premeditated and encoded into the address itself when sending money to the
vault. This has some related foot-gun scenarios, where the wallet vault has
addresses that if sent to would generally result in burning those coins,
unless done in a very specific way by the owner of the vault.

By contrast, OP_CD allows a lot more flexibility because it only constrains
the address to be sent to from the vault, but doesn't put additional
constraints on the transaction. This means that outputs can be combined
into a single transaction like you would expect in a normal transaction. It
also means that external users (people who don't own the vault) can safely
send money directly into the vault without coins being burned.

*I have the proposal for this opcode up here:
https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>;*.
I'd love to hear what people think about it, what problems it might have
that I've missed, or other issues or suggestions surrounding this. I'd also
appreciate any input that would help me improve the presentation of the
opcode.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210720/71264b19/attachment.html>;

📅 Original date posted:2021-07-09 📝 Original ...

2023-06-08T00:56:46+02:00

In reply to nevent1q…cpxu
_________________________

📅 Original date posted:2021-07-09
📝 Original message:@Voskuil
> You can prove that in your own wallet. All other scenarios imply lending
(which is what is implied by “reserve”) and lending cannot be 100% reserve.

You're using terms in non-standard ways. Putting money into a bank is not
considered "lending" to the bank. You may make a case that you're lending
to a bank, and that they legally owe you repayment of that money on demand
limited by the terms you mentioned. But regardless of a case that can be
made there, pretty much no one considers that "lending". Since you you like
defining things legally, depositing money in a bank is legally not defined
as lending to the bank.

So no, all other scenarios do not imply lending. You can have your coins in
custody with someone else, and that someone else can keep 100% reserves if
they choose (or agreed to) and can prove it to you via the method I
described or the methods others have linked to.

> They are time deposits, read your bank agreement.

You are not correct
<https://www.investopedia.com/terms/t/timedeposit.asp#:~:text=A%20time%20deposit%20is%20an,pre%2Dset%20date%20of%20maturity.&text=Time%20deposits%20generally%20pay%20a,of%20investment%20is%20term%20deposit.>;.
Another source
<https://www.slsp.sk/en/personal/faq/what-is-the-difference-between-a-term-deposit-and-savings-account>;
if you don't believe me. The only way you would be correct is if banks were
committing fraud and calling something a "savings account" when it isn't in
fact a savings account.

> money markets have had no reserve requirement and have a nearly spotless
record of satisfying their obligations.

Lol, money markets are so new that they've had no opportunity to show their
true risk. In the finance world, things work fine for a long time until
they fail spectacularly, losing more than the gain they made in the first
place. This is a regular occurence. Its the reason bitcoin was created.

> Irrelevant.

It is certainly not irrelevant. People have been lead to believe that they
can withdraw their money from their accounts. People expect this. Banks are
doing nothing to educate people on the limitations of that fact. PoR would
give people the ability to see quite accurately how much reserves there are
and can use this knowledge to put pressure on institutions to keep the
reserves those people think they should keep.

> Without 100% “reserve” there is no way to cryptographically demonstrate
“solvency”.

You can show proof that you're 80% solvent, and then claim the other 20% is
in other assets. This is, again, still useful.

>The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or
state seizure, no matter what the reserve

You're right, but that's irrelevant.

But it seems like you're not interested in understanding what I'm saying or
discussing these things honestly. So I'm going to end my conversation with
you here.

On Fri, Jul 9, 2021 at 11:32 AM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> > On Jul 9, 2021, at 10:44, Billy Tetrud <billy.tetrud at gmail.com> wrote:
> >
> > > there is an unsupportable leap being made here
> >
> > You think that because you're misinterpreting me. I'm in no way claiming
> that any solvent company can prove it, I'm simply claiming that any company
> can prove that they have bitcoin reserves to cover bitcoins promised as
> account balances.
>
> You can prove that in your own wallet. All other scenarios imply lending
> (which is what is implied by “reserve”) and lending cannot be 100% reserve.
>
> > > Banks (lending institutions) do not operate under any such pretense
> >
> > You seem to be saying that banks are under no legal obligation to serve
> cash on demand to customers. While you might be right,
>
> I am, as banks are lending institutions.
>
> > again you're misinterpreting me. Banks do in fact make claims to their
> customers that they'll be able to get cash out of their account on demand.
>
> Up to the insured limit, in 7 days. This is of course true because the
> taxpayer has insured the bank to that level.
>
> > They're called demand deposit accounts for a reason.
>
> They are time deposits, read your bank agreement. Not that it makes any
> difference. How the contract is satisfied is not a term of the contract,
> just that it is. And as I pointed out, money markets have had no reserve
> requirement and have a nearly spotless record of satisfying their
> obligations.
>
> > And certainly customers expect to be able to withdraw their cash on
> demand.
>
> Irrelevant.
>
> > > With a 100% of investment cash hoard, there is zero lending and zero
> return
> >
> > I did say "pretend" did I not?
>
> See above.
>
> > > “relate to” is a far cry from 100% “reserve”
> >
> > Indeed. Again, you seem to be misunderstanding me. You're putting the
> words "100% reserve" in my mouth, when I never said any such thing. Proof
> of 80%/50%/20% reserves is still useful if that's the clear expectation for
> the customer/client.
>
> Without 100% “reserve” there is no way to cryptographically demonstrate
> “solvency”. And even with that, investors would have to accept the promise
> that there are no other liabilities.
>
> The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or
> state seizure, no matter what the reserve.
>
> It’s information, sure, but it’s not what people seem to think. If one
> wants full reserve banking, use a wallet. If one wants to invest, the money
> will be spent - that’s why it was raised. There can be no covenant placed
> on it that will ensure it’s return.
>
> e
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20210709/35b046ea/attachment.html>;

📅 Original date posted:2021-07-06 📝 Original ...

2023-06-08T00:56:39+02:00

In reply to nevent1q…hk7x
_________________________

📅 Original date posted:2021-07-06
📝 Original message:@ZmnSCPxj
> a thief (or "thief") who has gotten a copy of the key can sign a
transaction that spends it, one second after the proof-of-reserves is made.

Sure, but anyone can easily see that transaction happen and can discount
that part of the attestation. The same isn't true on lightning.

> *knowledge* is easily copyable.

Knowledge isn't even really needed. Custodians could collude to sign each
other's balance attestations. However, if the network of proof of reserves
is cohesive, people could validate that addresses (and their balances)
aren't shared by anyone that's part of that PoR network.

> There is no way to prove that there is no alternate copy of the privkeys

Well there are only really 2 cases:

1. Only one entity has the keys
2. Two entities have the keys and trust each other

In case 1, the attestation is accurate. In case 2, its really another way
of saying case 1: you can view the two trusting entities as a single
entity. In the case there are 2 non-trusting entities, its very likely that
one would steal from the other, or that they would be very uncomfortable
with the situation such that it wouldn't last long.

But you can't prove that someone won't steal the reserves. You can't prove
cryptographically that the reserves aren't promised to someone else in a
legal contract (unless of course you make the proof of reserves system
legally binding). But this is why anyone that recommends PoR also
recommends independent audits to attest that the PoR actually matches
reality.

So yes, there are limitations, but I don't think that means that PoR isn't
worth doing. Is that what you're implying?

> we can show evidence that we live in a landlocked city far from any
lakes, seas, or rivers

I think that's the idea, if I understand you correctly.

@Eric
Auditability Fallacy
<https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy>;

> A solvency audit requires simultaneous (atomic) proof of both the full
amount of the asset held by a custodian and the securities issued against
it.

> in the case where the security is issued on a distinct public chain the
atomicity requirement is not satisfied.

I think what its saying is that you can't get atomicity of both the
security and the reserve. While this is true, what you can get is a system
where the order of events can be established to a degree of precision. Ie,
you can know that between reserve-snapshot A and B, the balances add up to
X. Each user can validate that their balance was indeed that value between
A and B. With reserve snapshots and balance snapshots frequent enough, this
can allow reasonably high accuracy of estimated solvency. However, it does
seem clear that perfect accuracy is not possible.

> Historically it has not been difficult to detect such deviations. The
difficulty arises in stopping them.

I disagree here that it has not been difficult to detect deviations
(insolvency). I mean, "difficulty" isn't the right word. These things
always become clear eventually. But I think its important to detect
insolvency quickly. Historically insolvency has certainly not been detected
quickly. Insolvency is instead practically perpetual, and the question is
only how insolvent and when will it explode?

I'm of the opinion that you can't prevent insolvency. Places will have
money troubles and will try to cover it up, since usually there is no
downside (admitting insolvency can lead to bankrupcy, and failure to
conceal insolvency has the same result - so why not try to conceal it and
hope you can shore it up). However, its important that people know the
institutions they have their money in are insolvent, or to what degree they
are. If that information were well tracked, it could become clear over time
that a 10% insolvent company rarely goes out of business, but a 20%
insolvent company usually does. Then people can have parameters where
they're ok with a certain measurable degree of insolvency, but react
swiftly and strongly when a company is too reckless. Currently the amount
of recklessness any given company engages in is basically a company secret
that their clients don't have insight into. PoR would greatly help this I
think. You don't think so?

On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil <eric at voskuil.org> wrote:

> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
>
> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Billy,
>
>
>
> The two participants in the channel can sign a plaintext containing
> their node pubkeys and how much each owns
>
>
> Sure, but even if both participants in the channel sign a correct
> statement of truth, one of the participants can send funds out in the next
> second, invalidating that truth. While proof of ownership of on-chain UTXOs
> can be seen publicly in real time if they are spent, LN transactions aren't
> public like that. So any balance attestation is at best only valid the
> instant its taken, and can't be used as verification the money is still
> owned by the same channel partner in the next second.
>
>
> The same problem really also exists onchain --- a thief (or "thief") who
> has gotten a copy of the key can sign a transaction that spends it, one
> second after the proof-of-reserves is made.
>
> Really, though, the issue is that ownership of funds is conditional on
> *knowledge* of keys.
> And *knowledge* is easily copyable.
>
> Thus, it is possible that the funds that are "proven" to be the reserve of
> a custodian is actually *also* owned by someone else who has gotten to the
> privkeys (e.g. somebody threw a copy of it from a boating accident and a
> fearless scuba diver rescued it), and thus can also move the funds outside
> of the control of the custodian.
> This condition can remain for many months or years, as well, without
> knowledge of the custodian clients, *or* of the custodian itself.
>
> There is no way to prove that there is no alternate copy of the privkeys,
> hence "if only one could prove that he won't get into a boating accident".
>
> On the other hand, one could argue that at least the onchain proof
> requires more conditions to occur, so we might plausibly live with "we
> cannot prove we will never get into a boating accident but we can show
> evidence that we live in a landlocked city far from any lakes, seas, or
> rivers".
>
> Regards,
> ZmnSCPxj
>
>
> a custodian Lightning node is unable to "freeze" a snapshot of its
> current state and make an atomic proof-of-reserves of *all* channels
>
>
> That would be a neat trick. But yeah, I don't know how that would be
> possible.
>
>
> I believe it is one reason why custodian proof-of-reserves is not that
> popular ... it does not prove that the key will not get lost
>
>
> True, but at least if funds do get lost, it would be come clear far
> quicker. Today, an insolvent company could go many months without the
> public finding out.
>
>
> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>
> Good morning e,
>
>
> If only one could prove that he won’t get into a boating accident.
>
>
> At least in the context of Lightning channels, if one party in the channel
> loses its key in a boating accident, the other party (assuming it is a true
> separate person and not a sockpuppet) has every incentive to unilaterally
> close the channel, which reveals the exact amounts (though not necessarily
> who owns which).
>
> If the other party then uses its funds in a new proof-of-reserves, then
> obviously the other output of the unilateral close was the one lost in the
> boating accident.
>
>
> On the other hand, yes, custodians losing custodied funds in boating
> accidents is much too common.
>
> I believe it is one reason why custodian proof-of-reserves is not that
> popular --- it only proves that the funds were owned under a particular key
> at some snapshot of the past, it does not prove that the key will not get
> lost (or "lost and then salvaged by a scuba diver") later.
>
>
> Regards,
>
> ZmnSCPxj
>
>
>
> e
>
>
> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev
> bitcoin-dev at lists.linuxfoundation.org wrote:
>
> Good morning Billy,
>
>
> I wonder if there would be some way to include the ability to prove
> balances held on the lightning network, but I suspect that isn't generally
> possible.
>
>
> Thinking about this in terms of economic logic:
>
> Every channel is anchored onchain, and that anchor (the funding txout) is
> proof of the existence, and size, of the channel.
>
> The two participants in the channel can sign a plaintext containing their
> node pubkeys and how much each owns.
>
> One of the participants should provably be the custodian.
>
>
> - If the counterparty is a true third party, it has no incentive to lie
> about its money.
>
> - Especially if the counterparty is another custodian who wants
> proof-of-reserves, it has every incentive to overreport, but then the first
> party will refuse to sign.
>
> It has a disincentive to underreport, and would itself refuse to sign
> a dishonest report that assigns more funds to the first party.
>
> The only case that would be acceptable to both custodians would be to
> honestly report their holdings in the Lightning channel.
>
>
> - If the counterparty is a sockpuppet of the custodian, then the entire
> channel is owned by the custodian and it would be fairly dumb of he
> custodian to claim to have less funds than the entire channel.
>
>
> Perhaps a more practical problem is that Lightning channel states change
> fairly quickly, and there are possible race conditions, due to network
> latency (remember, both nodes need to sign, meaning both of them need to
> communicate with each other, thus hit by network latency and other race
> conditions) where a custodian Lightning node is unable to "freeze" a
> snapshot of its current state and make an atomic proof-of-reserves of all
> channels.
>
> Regards,
>
> ZmnSCPxj
>
>
> bitcoin-dev mailing list
>
> bitcoin-dev at 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/20210705/b2c7cab2/attachment-0001.html>;

📅 Original date posted:2021-07-05 📝 Original message:I had ...

2023-06-08T00:56:36+02:00

In reply to nevent1q…9y4m
_________________________

📅 Original date posted:2021-07-05
📝 Original message:I had the idea recently for proof of reserves
<https://niccarter.info/proof-of-reserves/>; done in a way that can be used
to verify reserves are sufficient on an ongoing basis. I'm curious if there
are any current approaches out there to proof of reserves that are similar.

The idea is to have users create actual private keys using a seed in pretty
much the normal way. Users would generate a public key from this seed to
represent their account, and would give the public key to the custodian to
represent their account in a public record of account balances.

When a user's account is credited, the custodian would update a map of
addresses (created from the public key of each account) to balances - this
map could be structured into a merkle tree in the usual "merkle approach".
The custodian would also store funds on one or more HD wallets (each with
many addresses) and create a proof that they own each HD wallet. The proof
could be as simple as a single signature created with the xpub for the
wallet, which would be sufficient for proving ownership over the whole
list/tree of addresses.

These two structures (the map and the HD wallet) would be combined and
hashed, and the hash published in an on chain transaction (possibly along
with a URI where the full data can be found), on something like a daily
basis. Software for each user could continuously validate that their
account has a balance that matches what it's supposed to have, and could
also verify that owned addresses have funds that have at least as many
coins as promised to accounts. If these things aren't verifiable (either
because the balances total to more than the HD wallet contains, or because
of data unavailability), people can raise hell about it.

To give user's additional proving ability, a receipt system could be added.
Users could request a receipt for any balance update. Eg the user would
create a message with a timestamp, their custodial "address", and the new
balance. The user would sign this receipt and send it to the custodian, who
would also sign it and send it back. This way, if something goes wrong, a
user can use this signed receipt to show that the custodian did in fact
promise a new updated balance at a particular time (which would cover the
case that the custodian records the wrong value in their map). Conversely,
the receipt would be useful to honest custodians as well, since they could
show the user's signed receipt request in the case a user is trying to lie
about what balance they should have. There is still the case that the
custodian simply refuses to return a signed receipt, in which case the
user's only recourse is to yell about it immediately and demand a receipt
or a refund.

Why record it on chain? Doing that gives a clear record of proof of
reserves that can be verified later by anyone in the future. It prevents a
custodian from being able to change history when it suits them (by creating
a new records with false timestamps in the past). Many of these records
could be aggregated together and recorded in the same transaction (with a
single hash), so a single transaction per day could record the records of
all participating custodians. If all custodians are using a standard
system, one can cross verify that addresses claimed by one custodian aren't
also claimed by another custodian.

Even tho the user is responsible for their keys in order to properly
verify, losing the keys isn't that big of a deal, since they could simply
create a new seed and give a new public key to the custodian - who would
have other identifying information they could use to validate that they own
the account. So it places less responsibility on the user, while still
introducing people, in a light-weight way, to self custody of keys.

Having a record like this every day would reduce the possibility of
shenanigans like taking a short term loan of a large amount of
cryptocurrency. Sure, they could take a 10 minute loan once per day, but it
would also be possible to trace on-chain transactions so you could tell if
such a thing was going on. I wonder if there would be some way to include
the ability to prove balances held on the lightning network, but I suspect
that isn't generally possible.

In any case, I'm curious what people think of this kind of thing, and if
systems with similar properties are already out there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210705/fc1967cb/attachment.html>;

📅 Original date posted:2021-07-06 📝 Original message:> ...

2023-06-08T00:56:27+02:00

In reply to nevent1q…jyq2
_________________________

📅 Original date posted:2021-07-06
📝 Original message:> when people are talking about enabling covenants, we are talking about
whether OP_CAT should be allowed or not

Are they? Are you implying that anything that enables covenants is
equivalent to enabling OP_CAT? Generally when I think about enabling
covenants, I'm thinking more about OP_CTV (or some similarly specific opcode
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bip-constraindestination.md>;
).

> OP_TWEAK

I wasn't able to find anything about what that is. Would you mind
clarifying what that concept is?

On Mon, Jul 5, 2021 at 10:20 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi ZmnSCPxj,
>
> I don't believe we need to ban Turing completeness for the sake of banning
> Turing completeness. My concerns have always been around ensuring that
> transaction and block validation is not unduly burdensome for nodes. So
> for Bitcoin Script, we want to bound the amount of resources needed to
> execute it, preferably as a linear function of weight[1], and preferably
> have it clear what the evaluation costs are going to be prior to
> evaluation[2]. We also want to keep Script execution as a pure function of
> the transaction data so that nodes do not need to reevaluate their mempool
> on every new block. For consensus purposes we prefer to have simple
> primitive operations that have clear and precise semantics that are as
> likely as possible to be reimplemented correctly if they are reimplemented
> (or at least let us not make this problem worse than it already is). In
> particular, Script needs to be easy to parse to avoid weird parsing
> machines that lead to security vulnerabilities within node software.
>
> While the above design constraints imply a prohibition on Turing complete
> computation within a single Script, they do not imply a prohibition on
> arbitrary, covenant-enabled computations that spans across multiple
> transactions. Neither would these constraints prohibit some kind of STARK
> or SNARK tapleaf version that was somehow capable of succinctly
> representing arbitrary computations, so long as validation costs remain
> bounded.
>
> And while it is true that covenant-enabled computations could allow users
> to put their funds at risk through weird machines that manipulate their
> money on the blockchain, as longs as that weirdness stays at that level of
> the abstract Bitcoin Script machine, then I suppose it is *caveat emptor*;
> don't send your funds to random unverified Bitcoin Scripts, advice that is
> already the case today. We can keep that potential weirdness at bay by
> keeping Script simple, and maintaining our understanding that the Script
> programs (like the rest of the blockchain data) are untrusted inputs and
> they need to be validated and scrutinized before interpretation.
>
> [1] In tapscript I believe all operations are linear time with the
> exception of OP_ROLL. However OP_ROLL is still constrained by global
> limits on stack size, etc.
> [2] In Bitcoin Script, without loops of any kind, every opcode is
> evaluated at most once, so counting opcodes is an easy way to put an upper
> bound on your costs before evaluation.
>
> On Sun, Jul 4, 2021 at 8:51 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning Dave,
>>
>> > On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:
>> >
>> > > However, I think the broader community is unconvinced by the cost
>> benefit
>> > > of arbitrary covenants. See
>> > >
>> https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
>> > > as a recent example. Therefore as a critical part of building
>> consensus on
>> > > various techniques I've worked to emphasize that specific additions
>> do not
>> > > entail risk of accidentally introducing more than was bargained for to
>> > > respect the concerns of others.
>> >
>> > Respecting the concerns of others doesn't require lobotomizing useful
>> > tools. Being respectful can also be accomplished by politely showing
>> > that their concerns are unfounded (or at least less severe than they
>> > thought). This is almost always the better course IMO---it takes much
>> > more effort to satisfy additional engineering constraints (and prove to
>> > reviewers that you've done so!) than it does to simply discuss those
>> > concerns with reasonable stakeholders. As a demonstration, let's look
>> > at the concerns from Shinobi's post linked above:
>> >
>> > They seem to be worried that some Bitcoin users will choose to accept
>> > coins that can't subsequently be fungibily mixed with other bitcoins.
>> > But that's already been the case for a decade: users can accept altcoins
>> > that are non-fungible with bitcoins.
>> >
>> > They talk about covenants where spending is controlled by governments,
>> > but that seems to me exactly like China's CBDC trial.
>> >
>> > They talk about exchanges depositing users' BTC into a covenant, but
>> > that's just a variation on the classic not-your-keys-not-your-bitcoins
>> > problem. For all you know, your local exchange is keeping most of its
>> > BTC balance commitments in ETH or USDT.
>> >
>> > To me, it seems like the worst-case problems Shinobi describes with
>> > covenants are some of the same problems that already exist with
>> > altcoins. I don't see how recursive covenants could make any of those
>> > problems worse, and so I don't see any point in limiting Bitcoin's
>> > flexibility to avoid those problems when there are so many interesting
>> > and useful things that unlimited covenants could do.
>>
>> The "altcoins are even worse" argument does seem quite convincing, and if
>> Bitcoin can survive altcoins, surely it can survive covenants too?
>>
>> In before "turns out covenants are the next ICO".
>> i.e. ICOs are just colored coins, which are useful for keeping track of
>> various stuff, but have then been used as a vehicle to scam people.
>> But I suppose that is a problem that humans will always have: limited
>> cognition, so that *good* popular things that are outside your specific
>> field of study are indistinguishable from *bad* popular things.
>> So perhaps it should not be a concern on a technical level.
>> Maybe we should instead make articles about covenants so boring nobody
>> will hype about it (^^;)v.
>>
>> Increased functionality implies increased processing, and hopefully
>> computation devices are getting cheap enough that the increased processing
>> implied by new features should not be too onerous.
>>
>>
>>
>> To my mind, an "inescapable" covenant (i.e. one that requires the output
>> to be paid to the same covenant) is basically a Turing machine, and
>> equivalent to a `while (true);` loop.
>> In a `while (true);` loop, the state of the machine reverts back to the
>> same state, and it repeats again.
>> In an inescpable covenant, the control of some amount of funds reverts
>> back to the same controlling SCRIPT, and it repeats again.
>> Yes, you can certainly add more functionality on top of that loop, just
>> think of program main loops for games or daemons, which are, in essence,
>> "just" `while (true) ...`.
>> But basically, such unbounded infinite loops are possible only under
>> Turing machines, thus I consider covenants to be Turing-complete.
>> Principle of Least Power should make us wonder if we need full Turing
>> machines for the functionality.
>>
>> On the other hand --- codata processing *does* allow for unbounded loops,
>> without requiring full Turing-completeness; they just require total
>> functionality, not partial (and Turing-completeness is partial, not total).
>> Basically, data structures are unbounded storage, while codata structures
>> are unbounded processing.
>> Perhaps covenants can encode an upper bound on the number of recursions,
>> which prevents full Turing-completeness while allowing for a large number
>> of use-cases.
>>
>> (if the above paragraph makes no sense to you, hopefully this Wikipedia
>> article will help:
>> https://en.wikipedia.org/wiki/Total_functional_programming )
>> (basically my argument here is based on academic programming stuff, and
>> might not actually matter in real life)
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20210705/b9e7f0c5/attachment.html>;

📅 Original date posted:2021-06-29 📝 Original message:@Jorge ...

2023-06-08T00:55:35+02:00

In reply to nevent1q…zn37
_________________________

📅 Original date posted:2021-06-29
📝 Original message:@Jorge

>I don't think we should avoid splits at all costs.

I absolutely agree that we shouldn't avoid splits at all costs. There are
some costs too high to pay to avoid a split. If an economic majority
started wanting to increase bitcoin's blocksize to 1 GB next year, we
should absolutely hard fork away from that mess with a minority chain.

> I don't think we should avoid splits when possible,

I want to see why exactly we disagree about avoiding chain splits "when
possible". Are you really saying that we should just hard fork every time
instead of soft fork? Should we even bother to get widespread buy in at
all, or should we just release the software, hardfork away, and let anyone
that wants to follow us follow us later? Are you not at all worried about
the costs associated with an increased orphan rate and reorg rate? Are you
not worried that an update might happen too fast and that a significant
fraction of people that could have come along with us to the new update
might be left behind because they didn't have time to evaluate the
changed rules?

Do you agree that, in a conversation about rule changes, some people want
it their way no matter what and will hardfork to get the rules they want,
and some people want it their way, but only if enough other people agree to
follow those rules too? Some people might want a rule change, but aren't
willing to follow, say, a 20% minority fork. Perhaps their personal cut-off
is 40% or 50% or 75% or 90%. Do you agree those people exist?

If you do, then I don't understand why you disagree that we should avoid
chain splits even "when possible". Maybe you could elaborate as to what you
mean there.

@Luke

Are you in agreement with Jorge here that we should not even attempt to
avoid chain splits?

> The only alternative to a split in the problematic scenarios are 1)
concede centralised miner control over the network, and 2) have
inconsistent enforcement of rules by users who don't agree on what the
correct rules are, again leading to centralised miner control over the
network.

There is not simply a binary "do or do not". There is also timing.
Non-contentious changes can happen fast. Contentious changes need more time
for discussion, preparation, or coordination, even if the eventual outcome
is the same. Do you disagree that timing issues can be
important, that delays can be useful and help to avoid chain splits? Do you
agree that miners have a (large) incentive to follow the economic majority?
Is the goal here to do what the economic majority wants, or some other
group? If so, do you think we have an accurate way of measuring what the
economic majority wants? Will that mechanism continue to be accurate into
the future?

I'm asking these questions to try and figure out why we disagree here.

On Tue, Jun 29, 2021 at 12:44 PM Eric Voskuil <eric at voskuil.org> wrote:

>
> On Jun 29, 2021, at 12:28, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>
> "Confirmation" isn't needed for softforks.
>
>
> All transactions require confirmation. Splitting does not change this.
>
> Softforks are not compatible without miner enforcement. So soft forking
> without it has essentially the same effect as hard forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> It is extremely disappointing to see how few developers seem to ubderstand
> this, or even care about users deciding or miners not deciding the rules.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil <eric at voskuil.org> wrote:
>
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr <luke at dashjr.org> wrote:
>> >
>> > The only alternative to a split in the problematic scenarios are 1)
>> concede
>> > centralised miner control over the network,
>>
>> Miners control confirmation, entirely.
>>
>> This is the nature of bitcoin. And merchants control validation,
>> entirely. Anyone can be a miner or a merchant. Neither is inherently
>> “better” than the other. The largest merchants are likely a handful of
>> exchanges, likely at least as centralized as miners are pooled.
>>
>> Splitting does not change this.
>>
>> > and 2) have inconsistent
>> > enforcement of rules by users who don't agree on what the correct rules
>> are,
>>
>> There are no “correct” rules. Whatever rules one enforces determine what
>> network he chooses to participate in.
>>
>> > again leading to centralised miner control over the network.
>>
>> Leading to? Miners control confirmation, always. Whether that is
>> centralized, just as with merchanting, is up to individuals.
>>
>> > In other words, in this context, accepting a split between disagreeing
>> users
>> > is the ONLY way Bitcoin can possibly continue as a decentralised
>> currency.
>>
>> No, it is not. You are proposing splitting as the method of censorship
>> resistance inherent to Bitcoin. Coordinating this split requires
>> coordinated action. The whole point of bitcoin is coordinate that action
>> based on mining (proof of work). Replacing that with a political process is
>> just a reversion to political money.
>>
>> > Making that split as clean and well-defined as possible not only
>> ensures the
>> > best opportunity for both sides of the disagreement,
>>
>> Trivially accomplished, just change a rule. This isn’t about that. It’s
>> about how one gets others to go along with the new coin, or stay with the
>> old. An entirely political process, which is clearly evident from the
>> campaigns around such attempts.
>>
>> > but also minimises the
>> > risk that the split occurs at all (since the "losing" side needs to
>> concede,
>> > rather than passively continue the disagreement ongoing after the
>> attempted
>> > protocol change).
>>
>> Nobody “needs to” concede once a split has occurred, which is evident in
>> existing splits.
>>
>> e
>>
>> > Luke
>> >
>> >
>> >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
>> >> At least we are now acknowledging that splitting is what it’s about.
>> That’s
>> >> progress.
>> >>
>> >> e
>> >>
>> >>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon at jtimon.cc> wrote:
>> >>>
>> >>>
>> >>> I think the option of "permanent failure because miners veto" should
>> >>> actually be abandoned. No, I don't think we should avoid splits when
>> >>> possible, I don't think we should avoid splits at all costs.
>> >>>
>> >>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud at gmail.com>
>> wrote:
>> >>>> @Luke
>> >>>>
>> >>>>> They can still slow it down.
>> >>>>
>> >>>> Absolutely. However I think that the option of permanent failure is
>> >>>> important. It certainly would be ideal to ensure that enough bitcoin
>> >>>> users support the upgrade *before* releasing it, however
>> realistically
>> >>>> this can never be more than an estimate, and estimates can sometimes
>> be
>> >>>> wildly wrong. It would be unfortunate if miners had a substantially
>> >>>> different estimate of user support than the people putting in the
>> work
>> >>>> to release bitcoin upgrades. Even if upgrades are never released
>> before
>> >>>> it becomes clear that a large supermajority of users want the
>> upgrade,
>> >>>> if miners don't agree with the estimate a harmful chain split could
>> >>>> occur. And I agree with Eric that the goal here is to prevent a chain
>> >>>> split during an upgrade when possible. This includes permanent
>> failure
>> >>>> of an upgrade when there is unexpectedly large miner opposition.
>> >>>>
>> >>>> This of course does not prevent a UASF-style deployment to be done
>> after
>> >>>> an initial failure to deploy occurs. My proposal is essentially a
>> >>>> mechanism to improve upon the speedy-trial idea, allowing for even
>> >>>> speedier releases (than speedy trial) without adding additional risk
>> of
>> >>>> undesired chain splits.
>> >>>>
>> >>>>> [BIP8] already has the trinary state you seem to be describing
>> >>>>
>> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow
>> the
>> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
>> >>>> non-upgraded chain. I agree. However the trinary state in my
>> proposal is
>> >>>> materially different - it is the signaling itself that is trinary,
>> not
>> >>>> just which chain is being followed. This allows others to know and
>> make
>> >>>> programmatic decisions (in software) based on that signaling. I'm
>> sure
>> >>>> you can agree that does not exist in BIP8.
>> >>>>
>> >>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>> users, NOT miners
>> >>>>
>> >>>> And yet there is miner involvement, as you rightly pointed out.
>> Miners
>> >>>> are needed to set the nVersion in the header. So when you say "no
>> >>>> additional bit is needed", could you please be clearer as to what you
>> >>>> mean? Do you mean that signaling of opposition in a block can be done
>> >>>> without any "additional bit"? Or are you just saying that it is
>> >>>> redundant to consider what miners might be opposing an upgrade?
>> >>>>
>> >>>> @Jorge
>> >>>>
>> >>>>> If different users want different incompatible things... there's no
>> >>>>> way to avoid the split
>> >>>>
>> >>>> I agree. This happened with bcash, and that's fine. It was painful,
>> but
>> >>>> there were a significant amount of users that disagreed, and they
>> have
>> >>>> the chain they want now.
>> >>>>
>> >>>> But we generally all want to avoid a chain split when possible.
>> Because
>> >>>> chain splits have a cost, and that cost can be high, its likely that
>> >>>> many users would rather choose the chain with the most support rather
>> >>>> than choosing the chain with their preferred rules.
>> >>>>
>> >>>> However, the question here is: how do we estimate what fraction of
>> users
>> >>>> wants which rules? We don't have a divining rod to determine with
>> >>>> certainty what users want. We can only make polls of various levels
>> of
>> >>>> inaccuracy. The methods bitcoin has been using is community
>> discussion
>> >>>> and social consensus estimation as well as miner signaling during the
>> >>>> actual deployment period. Neither of these are perfect, but they are
>> >>>> both reasonable enough mechanisms. However, because both of these
>> >>>> mechanisms are very rough estimates of user sentiment, we need to
>> >>>> consider the possibility that sometimes the estimate may be
>> >>>> substantially inaccurate when we design deployment procedures. This
>> >>>> inaccuracy is why we need multiple barriers in place for an upgrade,
>> and
>> >>>> why we need to have higher thresholds of success (require larger
>> >>>> supermajorities in both consensus and miner signaling).
>> >>>>
>> >>>> Developers obviously care about bitcoin and have an incentive
>> (personal
>> >>>> and probably financial) to do it right. And miners have both an
>> >>>> incentive to keep the system healthy, as well as an incentive to
>> mine on
>> >>>> the chain that the economic majority of users is using. But measuring
>> >>>> the consensus of the bitcoin community can be extraordinarily
>> difficult
>> >>>> to do with consistent accuracy, and so I think miner signaling as it
>> has
>> >>>> been used as a second barrier to entry for an upgrade is quite
>> >>>> appropriate.
>> >>>>
>> >>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric at voskuil.org>
>> wrote:
>> >>>>> I have not objected to anyone splitting. As I said, a split is
>> always
>> >>>>> possible, and of course has been done on a large scale. It is only
>> the
>> >>>>> misleading statements about inherent soft fork “compatibility” and
>> the
>> >>>>> implication that activation without hash power enforcement does not
>> >>>>> create a split that I object to. People who know better should be
>> >>>>> honest about it.
>> >>>>>
>> >>>>> Far too many people have been led to believe there is some sort of
>> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed
>> down”).
>> >>>>> There is only a choice between creating a split and hash power
>> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>> >>>>> unless enforced by majority hash power.
>> >>>>>
>> >>>>> The statements below are grossly misleading and need to be called
>> out
>> >>>>> as such so that people can actually make this decision you speak of.
>> >>>>> This idea that “users” decide the rules is not the question. The
>> >>>>> question is only how to avoid a split. If one does not care he can
>> >>>>> split at any time, no discussion required.
>> >>>>>
>> >>>>> e
>> >>>>>
>> >>>>>> On Jun 27, 2021, at 01:47, Jorge Timón <jtimon at jtimon.cc> wrote:
>> >>>>>>
>> >>>>>> If different users want different incompatible things (enough on
>> >>>>>> each side), there's no way to avoid the split. We shouldn't try to
>> >>>>>> avoid such a split.
>> >>>>>> Users decide the rules, not miners nor developers.
>> >>>>>>
>> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>>>>>
>> >>>>>>> Ultimately there is only one answer to this question. Get majority
>> >>>>>>> hash power support.
>> >>>>>>>
>> >>>>>>> Soft fork enforcement is the same act as any other censorship
>> >>>>>>> enforcement, the difference is only a question of what people
>> want.
>> >>>>>>> Given that there is no collective “we”, those wants differ.
>> Bitcoin
>> >>>>>>> resolves this question of conflicting wants, but it is not a
>> >>>>>>> democracy, it’s a market. One votes by trading.
>> >>>>>>>
>> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>> >>>>>>> accomplished by mining (or paying others to do so). Anyone can
>> mine,
>> >>>>>>> so everyone gets a say. Mining is trading capital now for more
>> >>>>>>> later. If enough people want to do that, they can enforce a soft
>> >>>>>>> fork. It’s time Bitcoiners stop thinking of miners as other
>> people.
>> >>>>>>> Anyone can mine, and that’s your vote.
>> >>>>>>>
>> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But
>> it’s
>> >>>>>>> dishonest to imply that one can do this and all others will surely
>> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
>> >>>>>>> that has been shown to not always pay off.
>> >>>>>>>
>> >>>>>>> e
>> >>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org>
>> wrote:
>> >>>>>>>>
>> >>>>>>>> For some definitions of “block”.
>> >>>>>>>>
>> >>>>>>>> Without majority hash power support, activation simply means you
>> >>>>>>>> are off on a chain split. Anyone can of course split off from a
>> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
>> >>>>>>>> is a bit of an empty claim.
>> >>>>>>>>
>> >>>>>>>> Nobody can stop a person from splitting. The relevant question is
>> >>>>>>>> how to *prevent* a split. And activation without majority hash
>> >>>>>>>> power certainly does not “ensure” this.
>> >>>>>>>>
>> >>>>>>>> e
>> >>>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
>> >>>>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
>> >>>>>>>>> entirely. They can still slow it down.
>> >>>>>>>>>
>> >>>>>>>>> It also already has the trinary state you seem to be describing
>> >>>>>>>>> (although perhaps this could be better documented in the BIP):
>> >>>>>>>>> users who oppose the softfork can and should treat the
>> successful
>> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they
>> do
>> >>>>>>>>> not follow a chain with the rules in force.
>> >>>>>>>>>
>> >>>>>>>>> No additional bit is needed, as softforks are coordinated
>> between
>> >>>>>>>>> users, NOT miners (who have no particular say in them, aside
>> from
>> >>>>>>>>> their role as also being users). The miner involvement is only
>> out
>> >>>>>>>>> of necessity (to set the bit in the header, which users
>> coordinate
>> >>>>>>>>> with) and potentially to accelerate activation by protecting
>> >>>>>>>>> upgrade-lagging users.
>> >>>>>>>>>
>> >>>>>>>>> Luke
>> >>>>>>>>>
>> >>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>> >>>>>>>>>> ways to solve the problems that both sides brought up. In
>> short,
>> >>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners
>> failing
>> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
>> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
>> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>> >>>>>>>>>> have created a proposal
>> >>>>>>>>>> <
>> https://github.com/fresheneesz/bip-trinary-version-signaling/blo
>> >>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades
>> that
>> >>>>>>>>>> solve both problems.
>> >>>>>>>>>>
>> >>>>>>>>>> The proposal uses trinary version signaling rather than binary
>> >>>>>>>>>> signaling. For any particular prospective soft fork upgrade,
>> this
>> >>>>>>>>>> allows for three signaling states:
>> >>>>>>>>>>
>> >>>>>>>>>> * Actively support the change.
>> >>>>>>>>>> * Actively oppose the change.
>> >>>>>>>>>> * Not signaling (neither support or oppose). This is the
>> default
>> >>>>>>>>>> state.
>> >>>>>>>>>>
>> >>>>>>>>>> Using this additional information, we can release
>> non-contentious
>> >>>>>>>>>> upgrades much quicker (with a much lower percent of miners
>> >>>>>>>>>> signaling support). For contentious upgrades, miners who oppose
>> >>>>>>>>>> the change are incentivized to update their software to a
>> version
>> >>>>>>>>>> that can actively signal opposition to the change. The more
>> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock
>> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in
>> >>>>>>>>>> the proposal, this chart shows how much support signaling would
>> >>>>>>>>>> be necessary given a particular amount of active opposition
>> >>>>>>>>>> signaling:
>> >>>>>>>>>>
>> >>>>>>>>>> [image: thresholdChart.png]
>> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should
>> be
>> >>>>>>>>>> relatively safe because it is a supermajority amount that is
>> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
>> >>>>>>>>>> miners support the change today, its unlikely that less than a
>> >>>>>>>>>> majority of miners would support the change a year or two from
>> >>>>>>>>>> now), and if no one is signaling opposition, chances are that
>> the
>> >>>>>>>>>> vast majority of the other 40% would also eventually signal
>> >>>>>>>>>> support.
>> >>>>>>>>>>
>> >>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if
>> they
>> >>>>>>>>>> actually oppose the change while at the same time allowing
>> these
>> >>>>>>>>>> lazy miners to remain lazy without slowing down the soft fork
>> >>>>>>>>>> activation much.
>> >>>>>>>>>>
>> >>>>>>>>>> I think now is the right time to discuss new soft fork upgrade
>> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
>> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to
>> discuss
>> >>>>>>>>>> this will only delay things and cause contention again like it
>> >>>>>>>>>> did with taproot.
>> >>>>>>>>>>
>> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I
>> >>>>>>>>>> would appreciate any comments here, or written as github issues
>> >>>>>>>>>> on the proposal repo itself.
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks,
>> >>>>>>>>>> BT
>> >>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> bitcoin-dev mailing list
>> >>>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> bitcoin-dev mailing list
>> >>>>>>> bitcoin-dev at 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/20210629/015cb80c/attachment-0001.html>;

📅 Original date posted:2021-06-27 📝 Original message:@Luke ...

2023-06-08T00:55:27+02:00

In reply to nevent1q…c3kt
_________________________

📅 Original date posted:2021-06-27
📝 Original message:@Luke
> They can still slow it down.

Absolutely. However I think that the option of permanent failure is
important. It certainly would be ideal to ensure that enough bitcoin users
support the upgrade *before* releasing it, however realistically this can
never be more than an estimate, and estimates can sometimes be wildly
wrong. It would be unfortunate if miners had a substantially different
estimate of user support than the people putting in the work to release
bitcoin upgrades. Even if upgrades are never released before it becomes
clear that a large supermajority of users want the upgrade, if miners don't
agree with the estimate a harmful chain split could occur. And I agree with
Eric that the goal here is to prevent a chain split during an upgrade when
possible. This includes permanent failure of an upgrade when there is
unexpectedly large miner opposition.

This of course does not prevent a UASF-style deployment to be done after an
initial failure to deploy occurs. My proposal is essentially a mechanism to
improve upon the speedy-trial idea, allowing for even speedier releases
(than speedy trial) without adding additional risk of undesired chain
splits.

> [BIP8] already has the trinary state you seem to be describing

It sounds like you're saying the trinary state of BIP8 is A. Follow the
longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded
chain. I agree. However the trinary state in my proposal is materially
different - it is the signaling itself that is trinary, not just which
chain is being followed. This allows others to know and make programmatic
decisions (in software) based on that signaling. I'm sure you can agree
that does not exist in BIP8.

> No additional bit is needed, as softforks are coordinated between users,
NOT miners

And yet there is miner involvement, as you rightly pointed out. Miners are
needed to set the nVersion in the header. So when you say "no additional
bit is needed", could you please be clearer as to what you mean? Do you
mean that signaling of opposition in a block can be done without any
"additional bit"? Or are you just saying that it is redundant to consider
what miners might be opposing an upgrade?

@Jorge
> If different users want different incompatible things... there's no way
to avoid the split

I agree. This happened with bcash, and that's fine. It was painful, but
there were a significant amount of users that disagreed, and they have the
chain they want now.

But we generally all want to avoid a chain split when possible. Because
chain splits have a cost, and that cost can be high, its likely that many
users would rather choose the chain with the most support rather than
choosing the chain with their preferred rules.

However, the question here is: how do we estimate what fraction of users
wants which rules? We don't have a divining rod to determine with certainty
what users want. We can only make polls of various levels of inaccuracy.
The methods bitcoin has been using is community discussion and social
consensus estimation as well as miner signaling during the actual
deployment period. Neither of these are perfect, but they are both
reasonable enough mechanisms. However, because both of these mechanisms are
very rough estimates of user sentiment, we need to consider the possibility
that sometimes the estimate may be substantially inaccurate when we design
deployment procedures. This inaccuracy is why we need multiple barriers in
place for an upgrade, and why we need to have higher thresholds of success
(require larger supermajorities in both consensus and miner signaling).

Developers obviously care about bitcoin and have an incentive (personal and
probably financial) to do it right. And miners have both an incentive to
keep the system healthy, as well as an incentive to mine on the chain that
the economic majority of users is using. But measuring the consensus of the
bitcoin community can be extraordinarily difficult to do with consistent
accuracy, and so I think miner signaling as it has been used as a second
barrier to entry for an upgrade is quite appropriate.

On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric at voskuil.org> wrote:

> I have not objected to anyone splitting. As I said, a split is always
> possible, and of course has been done on a large scale. It is only the
> misleading statements about inherent soft fork “compatibility” and the
> implication that activation without hash power enforcement does not create
> a split that I object to. People who know better should be honest about it.
>
> Far too many people have been led to believe there is some sort of
> activation choice with “ensured” equal outcomes (maybe “slowed down”).
> There is only a choice between creating a split and hash power enforcement.
> Soft forks are rule changes, and thereby incompatible - unless enforced by
> majority hash power.
>
> The statements below are grossly misleading and need to be called out as
> such so that people can actually make this decision you speak of. This idea
> that “users” decide the rules is not the question. The question is only how
> to avoid a split. If one does not care he can split at any time, no
> discussion required.
>
> e
>
> > On Jun 27, 2021, at 01:47, Jorge Timón <jtimon at jtimon.cc> wrote:
> >
> > If different users want different incompatible things (enough on each
> > side), there's no way to avoid the split. We shouldn't try to avoid
> > such a split.
> > Users decide the rules, not miners nor developers.
> >
> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Ultimately there is only one answer to this question. Get majority hash
> power support.
> >>
> >> Soft fork enforcement is the same act as any other censorship
> enforcement, the difference is only a question of what people want. Given
> that there is no collective “we”, those wants differ. Bitcoin resolves this
> question of conflicting wants, but it is not a democracy, it’s a market.
> One votes by trading.
> >>
> >> If one wants to enforce a soft fork (or otherwise censor) this is
> accomplished by mining (or paying others to do so). Anyone can mine, so
> everyone gets a say. Mining is trading capital now for more later. If
> enough people want to do that, they can enforce a soft fork. It’s time
> Bitcoiners stop thinking of miners as other people. Anyone can mine, and
> that’s your vote.
> >>
> >> Otherwise, as mentioned below, anyone can start a new coin. But it’s
> dishonest to imply that one can do this and all others will surely follow.
> This cannot be known, it’s merely a gamble. And it’s one that has been
> shown to not always pay off.
> >>
> >> e
> >>
> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org> wrote:
> >>>
> >>> For some definitions of “block”.
> >>>
> >>> Without majority hash power support, activation simply means you are
> off on a chain split. Anyone can of course split off from a chain by
> changing a rule (soft or otherwise) at any time, so this is a bit of an
> empty claim.
> >>>
> >>> Nobody can stop a person from splitting. The relevant question is how
> to *prevent* a split. And activation without majority hash power certainly
> does not “ensure” this.
> >>>
> >>> e
> >>>
> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>
> >>>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely.
> They can
> >>>> still slow it down.
> >>>>
> >>>> It also already has the trinary state you seem to be describing
> (although
> >>>> perhaps this could be better documented in the BIP): users who oppose
> the
> >>>> softfork can and should treat the successful signal (whether MASF or
> UASF) as
> >>>> invalid, thereby ensuring they do not follow a chain with the rules
> in force.
> >>>>
> >>>> No additional bit is needed, as softforks are coordinated between
> users, NOT
> >>>> miners (who have no particular say in them, aside from their role as
> also
> >>>> being users). The miner involvement is only out of necessity (to set
> the bit
> >>>> in the header, which users coordinate with) and potentially to
> accelerate
> >>>> activation by protecting upgrade-lagging users.
> >>>>
> >>>> Luke
> >>>>
> >>>>
> >>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev
> wrote:
> >>>>> Given the recent controversy over upgrade mechanisms for the
> >>>>> non-controversial taproot upgrade, I have been thinking about ways
> to solve
> >>>>> the problems that both sides brought up. In short, BIP8 LOT=true
> proponents
> >>>>> make the point that lazy miners failing to upgrade in a timely
> manner slow
> >>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> >>>>> proponents make the point that LOT=true can lead to undesirable
> forks that
> >>>>> might cause a lot of chaos. I believe both points are essentially
> correct
> >>>>> and have created a proposal
> >>>>> <
> https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
> >>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both
> problems.
> >>>>>
> >>>>> The proposal uses trinary version signaling rather than binary
> signaling.
> >>>>> For any particular prospective soft fork upgrade, this allows for
> three
> >>>>> signaling states:
> >>>>>
> >>>>> * Actively support the change.
> >>>>> * Actively oppose the change.
> >>>>> * Not signaling (neither support or oppose). This is the default
> state.
> >>>>>
> >>>>> Using this additional information, we can release non-contentious
> upgrades
> >>>>> much quicker (with a much lower percent of miners signaling
> support). For
> >>>>> contentious upgrades, miners who oppose the change are incentivized
> to
> >>>>> update their software to a version that can actively signal
> opposition to
> >>>>> the change. The more opposition there is, the higher the threshold
> >>>>> necessary to lock in the upgrade. With the parameters I currently
> >>>>> recommended in the proposal, this chart shows how much support
> signaling
> >>>>> would be necessary given a particular amount of active opposition
> >>>>> signaling:
> >>>>>
> >>>>> [image: thresholdChart.png]
> >>>>> If literally no one signals opposition, a 60% threshold should be
> >>>>> relatively safe because it is a supermajority amount that is
> unlikely to
> >>>>> change significantly very quickly (ie if 60% of miners support the
> change
> >>>>> today, its unlikely that less than a majority of miners would
> support the
> >>>>> change a year or two from now), and if no one is signaling
> opposition,
> >>>>> chances are that the vast majority of the other 40% would also
> eventually
> >>>>> signal support.
> >>>>>
> >>>>> This both gives an incentive for "lazy" miners to upgrade if they
> actually
> >>>>> oppose the change while at the same time allowing these lazy miners
> to
> >>>>> remain lazy without slowing down the soft fork activation much.
> >>>>>
> >>>>> I think now is the right time to discuss new soft fork upgrade
> mechanisms,
> >>>>> when there are no pressing soft fork upgrades ready to deploy.
> Waiting
> >>>>> until we need to deploy a soft fork to discuss this will only delay
> things
> >>>>> and cause contention again like it did with taproot.
> >>>>>
> >>>>> I'm very curious to know what people think of this mechanism. I would
> >>>>> appreciate any comments here, or written as github issues on the
> proposal
> >>>>> repo itself.
> >>>>>
> >>>>> Thanks,
> >>>>> BT
> >>>>
> >>>> _______________________________________________
> >>>> bitcoin-dev mailing list
> >>>> bitcoin-dev at lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at 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/20210627/e5faf2f4/attachment-0001.html>;

📅 Original date posted:2021-06-26 📝 Original message:Given ...

2023-06-08T00:55:24+02:00

In reply to nevent1q…c3wl
_________________________

📅 Original date posted:2021-06-26
📝 Original message:Given the recent controversy over upgrade mechanisms for the
non-controversial taproot upgrade, I have been thinking about ways to solve
the problems that both sides brought up. In short, BIP8 LOT=true proponents
make the point that lazy miners failing to upgrade in a timely manner slow
down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
proponents make the point that LOT=true can lead to undesirable forks that
might cause a lot of chaos. I believe both points are essentially correct
and have created a proposal
<https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/bip-trinary-version-bits.md>;
for soft fork upgrades that solve both problems.

The proposal uses trinary version signaling rather than binary signaling.
For any particular prospective soft fork upgrade, this allows for three
signaling states:

* Actively support the change.
* Actively oppose the change.
* Not signaling (neither support or oppose). This is the default state.

Using this additional information, we can release non-contentious upgrades
much quicker (with a much lower percent of miners signaling support). For
contentious upgrades, miners who oppose the change are incentivized to
update their software to a version that can actively signal opposition to
the change. The more opposition there is, the higher the threshold
necessary to lock in the upgrade. With the parameters I currently
recommended in the proposal, this chart shows how much support signaling
would be necessary given a particular amount of active opposition signaling:

[image: thresholdChart.png]
If literally no one signals opposition, a 60% threshold should be
relatively safe because it is a supermajority amount that is unlikely to
change significantly very quickly (ie if 60% of miners support the change
today, its unlikely that less than a majority of miners would support the
change a year or two from now), and if no one is signaling opposition,
chances are that the vast majority of the other 40% would also eventually
signal support.

This both gives an incentive for "lazy" miners to upgrade if they actually
oppose the change while at the same time allowing these lazy miners to
remain lazy without slowing down the soft fork activation much.

I think now is the right time to discuss new soft fork upgrade mechanisms,
when there are no pressing soft fork upgrades ready to deploy. Waiting
until we need to deploy a soft fork to discuss this will only delay things
and cause contention again like it did with taproot.

I'm very curious to know what people think of this mechanism. I would
appreciate any comments here, or written as github issues on the proposal
repo itself.

Thanks,
BT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210626/7131cbaf/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thresholdChart.png
Type: image/png
Size: 11132 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210626/7131cbaf/attachment.png>;

📅 Original date posted:2021-06-23 📝 Original message:> ...

2023-06-08T00:54:17+02:00

In reply to nevent1q…f0z7
_________________________

📅 Original date posted:2021-06-23
📝 Original message:> This is not true in a Proof of Work system and this difference
absolutely should not be trivialized.

That is in fact true of Proof of Work as well. If a colluding coalition of
miners with more than 50% of the hashrate want to censor transactions, they
absolutely can do that by orphaning blocks that contain transactions
they want to censor. This is not different in proof of stake.

On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland <
keagan.mcclelland at gmail.com> wrote:

> > Premise: There is a healthy exchange market for PoS Coin X with tens of
> thousands of participants bidding to buy and sell the coin for other
> currencies on the market.
>
> The difference here though is that Proof of Stake allows the quorum of
> coin holders to block the exchange of said coins if they are going to a
> particular destination. Nothing requires these staking nodes to include
> particular transactions into a block. With that in mind, it isn't just that
> you require the permission of the person who sold you the coins, which I
> can agree is a less dangerous form of permission, but you must also require
> the permission of at least 51% of the coin holders to even receive those
> coins in the first place. This is not true in a Proof of Work system and
> this difference absolutely should not be trivialized.
>
> Keagan
>
> On Wed, Jun 23, 2021 at 2:30 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > Barrier to entry in PoS is being given permission by the previous
>> owner of a token
>>
>> The idea that proof of stake is not permissionless is completely invalid.
>> It pains me to see such an argument here. Perhaps we can come to an
>> agreement by being more specific. I'd like to propose the following:
>>
>> Premise: There is a healthy exchange market for PoS Coin X with tens of
>> thousands of participants bidding to buy and sell the coin for other
>> currencies on the market.
>>
>> If the premise above is true, then there is no significant permission
>> needed to enter the market for minting blocks for PoS Coin X. If you make a
>> bid on someone's coins and they don't like you and refuse, you can move on
>> to any one of the other tens of thousands of people in that marketplace.
>> Would you agree, Cloud Strife, that this situation couldn't be considered
>> "permissioned"?
>>
>> If not, consider that participation in *any* decentralized system
>> requires the permission of at least one user in that system. If there are
>> thousands of bitcoin public nodes, you require the permission of at least
>> one of them to participate in bitcoin. No one considers bitcoin
>> "permissioned" because of this. Do you agree?
>>
>> On Thu, Jun 17, 2021 at 1:15 PM Cloud Strife via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Barrier to entry in PoW is matter for hardware and energy is
>>> permissionless and exist all over the universe, permissionless cost which
>>> exists for everyone no matter who because it's unforgeable.
>>>
>>> Barrier to entry in PoS is being given permission by the previous owner
>>> of a token for you to have it via transfer or sale, both choices they never
>>> have to make since there are no continuous costs with producing blocks
>>> forcing it. A permission is an infinitely high barrier to entry if the
>>> previous owner, like the premining party, refuses to give up the token they
>>> control.
>>>
>>> You're skipping the part where you depend on a permission of a central
>>> party in control of the authority token before you can produce blocks on
>>> your rasberry Pi.
>>>
>>> Proof of stake is not in any possible way relevant to permissionless
>>> protocols, and thus not possibly relevant to decentralized protocols where
>>> control must be distributed to independent (i.e. permissionless) parties.
>>>
>>> There's nothing of relevance to discuss and this has been figured out
>>> long long ago.
>>>
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
>>>
>>>
>>> https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca
>>>
>>>
>>>
>>>
>>> On Tue, Jun 15, 2021 at 7:13 AM James MacWhyte via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>>
>>>> @Lloyd wrote:
>>>>
>>>> Of course in reality no one wants to keep their coin holding keys
>>>>> online so in Alogorand you can authorize a set of "participation keys"[1]
>>>>> that will be used to create blocks on your coin holding key's behalf.
>>>>> Hopefully you've spotted the problem.
>>>>> You can send your participation keys to any malicious party with a
>>>>> nice website (see random example [2]) offering you a good return.
>>>>> Damn it's still Proof-of-SquareSpace!
>>>>>
>>>>
>>>> I believe we are talking about a comparison to PoW, correct? If you
>>>> want to mine PoW, you need to buy expensive hardware and configure it to
>>>> work, and wait a long time to get any return by solo mining. Or you can
>>>> join a mining pool, which might use your hashing power for nefarious
>>>> purposes. Or you might skip the hardware all together and fall for some
>>>> "cloud mining" scheme with a pretty website and a high rate of advertised
>>>> return. So as you can see, Proof-of-SquareSpace exists in PoW as well!
>>>>
>>>> The PoS equivalent of buying mining hardware is setting up your own
>>>> validator and not outsourcing that to anyone else. So both PoW and PoS have
>>>> the professional/expert way of participating, and the fraud-prone, amateur
>>>> way of participating. The only difference is, with PoS the
>>>> professional/expert way is accessible to anyone with a raspberry Pi and a
>>>> web connection, which is a much lower barrier to entry than PoW.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at 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/20210623/e39ec2e6/attachment-0001.html>;

📅 Original date posted:2021-06-07 📝 Original ...

2023-06-08T00:54:14+02:00

In reply to nevent1q…hs4n
_________________________

📅 Original date posted:2021-06-07
📝 Original message:@SatoshiSingh PoLW sounds like a hybrid of PoW and proof of burn. I agree
with befreeandopen that proof of burn is basically a form of proof of
stake. My conclusion from this exploration
<https://github.com/fresheneesz/proofOfTimeOwnership>; is that hybrid
protocols are a dead end because hybrid protocols have one weaker link
that's easier to attack.

In this case, miners are burning coinbase rewards. The proof of stake is
the burn itself. However, a miner would only burn coins if doing so lead to
greater rewards in the future. So the burned coins are in fact actually
earned, and still have value. Therefore I would think that miners would
still do an amount of work totaling up to the full value of the block
reward, regardless of whether they burn it, because any burnt coins should
be expected to lead to more coins in the future than were burned. What am I
missing?

On Wed, Jun 2, 2021 at 10:30 PM SatoshiSingh <SatoshiSingh at protonmail.com>
wrote:

> Great conversation everyone. I'm happy we're still engaged with this
> discussion. To add food for thought I'm bringing back something that was
> introduced in this mailing list sometime ago, which is Proof of Less Work.
>
> PoLW may or may not be it but we can certainly get more ideas from it to
> keep the discussion going.
>
> https://raw.githubusercontent.com/alephium/research/master/polw.pdf
>
>
> Sent with ProtonMail Secure Email.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210606/1ff6314d/attachment-0001.html>;

📅 Original date posted:2021-05-24 📝 Original message:Before ...

2023-06-08T00:53:58+02:00

In reply to nevent1q…4kgg
_________________________

📅 Original date posted:2021-05-24
📝 Original message:Before we can decide on tradeoffs that reduce security in favor of less
energy usage, or less inflation, or whatever goal you might have for
reducing (or delaying) coinbase rewards, we need to decide as a community
how much security bitcoin *needs*.

Do we need to be secure against an attacker with a budget of $1
billion/year for an attack? $10 billion/year? More?

An upper limit would be the budget of the largest government: the US. The
US federal budget is almost $5 trillion/year. But they certainly couldn't
spend all that budget attacking bitcoin. About $3 trillion of that is
mandatory spending, which couldn't be allocated to such an attack. About
$1.5 trillion is discretionary, which includes the military budget. It
seems like an upper limit on the amount that could be siphoned from that
budget to attack bitcoin would be 5%. That would take massive political
cooperation and wheeling and dealing. Likely spending that much would not
be politically feasible, but it seems possible, since a 5% reduction in
other activities is something other departments would likely be able to
sustain with just a bit of downsizing. Or that money could simply come from
more borrowing. 5% of $1.5 trillion is $75 billion. So that seems like a
pretty solid upper limit on the amount the US could allocate to an attack
in a year, in that it seems incredibly unlikely that more money than that
could be allocated. Such an expenditure might be eventually seen as
justified since the federal reserve has been inflating the supply of
dollars by 17.5% on average every year, which would be $1 trillion next
year (and more the next, etc). A similar story is told if you calculate the
amount of seigniorage banks get access to by their ability to use
fractional reserve to inflate the supply of M2 money. It should be
considered tho that this seigniorage doesn't give its beneficiaries that
full value, but rather some fraction of that value - say 5% earned by being
first to buy with that new money and earning interest on it. So 5% of a
trillion is $50 billion. Still, over just two years, that's enough to pay
for an attack of at least that size ($75 billion).

The budget for the government of China is about $3.6 trillion, the second
largest in the world. And since they're an authoritarian country, they can
basically do whatever they want with that money. It still seems unlikely
they would spend more than 5% of that budget on doing something like
attacking bitcoin. However, consider that China's M2 money supply has been
increasing at a rate of almost $3 trillion per year. Protecting the ability
to do this is seems like something worth spending some (printed) money on.
So perhaps at some point, spending 10 or 20% of their budget for a year or
two to attack bitcoin might seem like a good idea to some mickey mouse in
the government. That would be $720 billion/year.

So given the amount of seigniorage taken in every year by these central
banks, it would seem to justify large expenditures. I'm not sure how
realistic it would be, politically speaking, to gather $720 billion in a
single year to attack bitcoin. It seems far fetched, even if the
seigniorage they're protecting seems to justify it.

So is this the level of attack we want to be resilient to? Nearly a $1
trillion attack? I don't know. But we should figure that out as a
community. And keep in mind, the level of attack we need to defend against
depends on the size of bitcoin. The more valuable bitcoins are, the more
damaging, more lucrative, and more valuable an attack would be for
attackers. Its seems reasonable to assume that this is a linear
relationship - that if bitcoins are worth twice as much, we need twice as
much security (ie we want to make attacking bitcoin twice as costly).

The next step is figuring out a reasonable lower bound for how much it
takes to attack bitcoin. There are many attacks that can be done on
bitcoin, but the one relevant to the discussion here is a 51% attack.
Bitcoin's PoW basically is attackable buy buying about 25% of the existing
mining power (for reasons like the selfish economic attack
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-attack>;
and
the economic mining monopoly attack
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#economic-mining-monopoly-attack>;),
which is about 40 exahashes/second.

If you bought 400,000 WhatsMiner M30S+ rigs
<https://www.buybitcoinworldwide.com/mining/hardware/>; at current market
price, you'd need $1 billion to buy them all (which doesn't include the
cost of setting up all that equipment, powering it, building the network
infrastructure for it, etc etc). Let's say all that infra doubles the price
to $2 billion. Even then, you couldn't simply buy half a million mining
rigs from the market. That many just aren't available. An attacker would
have to spend year and years building up their mining operation before they
could actually perform the attack. They'd basically have to mine at a
slight (probably insignificant) loss for that time. Their demand would push
up the price of these mining rigs for at least a year or two until supply
comes up to meet it. So lets say this doubles the price of the mining rigs
(it could very well do significantly more than that). That makes for $3
billion to build up this malicious mining operation. China could seize a
mining pool, but likely couldn't do it quietly. They'd have to seize the
pool and immediately use it to attack before miners stop using the pool
(which might take a week or two). Maybe this would save them half the cost?

So, lower bound on cost of attack is $1.5 billion. Upper bound on US govt
attack is $72 billion. Upper bound on China govt attack is $720 billion. So
based on this back-of-the-napkin line of thinking, its not super clear that
reducing bitcoin's security is "enough" yet. There is also the question of:
does a $1 trillion currency need to be secure against a $720 billion
attack? Probably not. But should it be secure against a $10 billion attack?
Maybe.

However, the security will go up with price. If bitcoin goes up by 10x, as
it is wont to do, that's nearly 10x the security (nearly, since coinbase
rewards 10x, but the real value of fees almost certainly wouldn't go up as
much). So that brings us to $15 billion of security. Still not clear
without doing some more accurate analysis to determine more confidence in
tighter bounds on cost of attack and likely attack budgets.

But it certainly seems likely that my attack cost bounds are an order of
magnitude too low, and its equally possible my estimates of potential
available attack budgets are an order of magnitude too high. It doesn't
seem quite as likely the reverse is true (that my bounds aren't good
bounds).

It seems possible that we currently have enough security, but seems
likelier that we don't. It just isn't clear to me. Maybe someone has done
some more accurate analysis that could help here.

But before we talk about whether we should reduce our security to save
costs, we need to determine how much security we need and how much security
we have. Without good estimates with confident bounds, we simply can't make
an informed decision to reduce security.

> I don't think 99% of transactions need that level of security

Well you can't get security for the 1% of transactions that need it without
giving that security to all transactions on the chain. Also, the blockchain
security created by miners isn't really a per transaction thing anyway. An
attack would affect all bitcoins regardless of what transactions they do or
do not take part in.

On Sun, May 23, 2021 at 9:52 AM Karl via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> >> The turn-around time for that takes a population of both users and
> >> miners to cause. Increasing popularity of bitcoin has a far bigger
> >> impact here, and it is already raising fees and energy use at an
> >> established rate.
> >>
> >> If it becomes an issue, as bandwidth increases block size could be
> >> raised to lower fees.
> >>
> >
> > Which increases block rewards somewhat (at least to some level that
> matches
> > the overall security of the network) and you still have the same amount
> of
> > energy consumed.
>
> If you mean to implicitly propose that even if halved all the way with
> very large blocks, block rewards would just increase to the same
> level, meaning that any attempt to decrease them has no effect, I
> disagree. I expect that if you raise the block size, eventually
> there is so much supply for transactions that there are no fees at all
> (nor security). The numbers are all things the devs, miners, and
> users can together control.
>
> > How to prove this is not happening?
> > The best you can do is to have some number of authorities sign off on
> > whether or not they are doing this.
> > The problem is that authorities are bribeable.
>
> You could make the proof of work be a proof of environmental kindness
> by coding incentives for people to place and verify proof on the
> chain, and then rewarding people for acting on it as desired. You
> could code the chain to pay people to investigate and prove miners'
> business practices, for example. You could define the main chain as
> one where everyone consents the proofs are valid. There are a lot of
> issues to resolve and it would be a very different chain.
>
> There is not a single solution here. There are innumerable possible
> solutions, any one of which could be made to work with enough brains
> working on it. To use one, we need to agree on what kinds of
> solutions are acceptable.
>
> > Alternately, other entities in the locality can use force to require the
> > polluting entity to clean up or suffer significant consequences.
> > This at least is better incentive-wise, as they others in the same
> locality
> > are the ones most affected, but the ability to enforce may be difficult
> due
> > to various political constructions; the miners could be in such deep
> cahoots
> > with the local government that the local government would willingly hurt
> > other local entities in the vicinity of the polluting entity.
>
> As bitcoin grows, if people ask some locality to enforce behavior,
> they may need to be willing to enforce it themselves, too, or they
> might outcompete the locality.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20210524/8be26505/attachment-0001.html>;

📅 Original date posted:2021-05-26 📝 Original ...

2023-06-08T00:53:04+02:00

In reply to nevent1q…mzne
_________________________

📅 Original date posted:2021-05-26
📝 Original message:@befreeandopen I guess I misunderstood your selfish minting attack. Let me
make sure I understand it. You're saying it would go as follows?:

1. The malicious actor comes across an opportunity to mint the next 3
blocks. But they hold off and don't release their blocks just yet.
2. They receive a new block minted by someone else.
3. The malicious actor then chooses to release their other 2 blocks on on
the second from the top block if it gives them more blocks in the future
than minting on the top block. And instead lets the top block proceed if it
gives them more blocks in the future (also figuring in the 3 blocks they're
missing out on minting).
4. Profit!

The problem with this attack is that any self respecting PoS system
wouldn't have the information available for minters to know how blocks will
affect their future prospects of minting. Otherwise this would introduce
the problem of stake grinding. This can be done using collaborative
randomness (where numbers from many parties are combined to create a random
number that no individual party could predict). In fact, that's what the
Casper protocol does to decide quorums. In a non quorum case, you can do
something like record a hash of a number in the block header, and then have
a second step to release that number later. Rewards can be given can be
used to ensure minters act honestly here by minting messages that release
these numbers and not releasing their secret numbers too early.

Fun fact tho: there is an attack called the "selfish mining attack" for
proof of work, and it reduces the security of PoW by at least 1/3rd
<https://bitcoinmagazine.com/technical/selfish-mining-a-25-attack-against-the-bitcoin-network-1383578440>;
.

> the problem is not as hard as you think

I don't claim to know just how hard finding the IP address associated with
a bitcoin address is. However, the DOS risk can be solved more completely
by only allowing the owner of coins themselves to know whether they can
mint a block. Eg by determining whether someone can mint a block based on
their public key hidden behind hashes (as normal in addresses). Only when
someone does in fact mint a block do they reveal their hidden public key in
order to prove they are allowed to mint the block.

> I agree that introduction of punishment itself does not imply introducing
a problem elsewhere (which I did not claim if you reread my previous
message)

I'm glad we agree there. Perhaps I misunderstood what you meant by "you
should not omit to mention that by doing so, typically, you have introduced
another problem elsewhere."

> As long as the staker makes sure (which is not that hard) that she does
not miss a chance to create a block, her significance in the system will
always increase in time. It will increase relative to all normal users who
do not stake

Well, if you're in the closed system of the cryptocurrency, sure. But we
don't live in that closed system. Minters will earn some ROI from minting
just like any other financial activity. Others may find more success
spending their time doing things other than figuring out how to mint coins.
In that case, they'll be able to earn more coin that they could later
decide to use to mint blocks if they decide to.

> Just because of the above we must reject PoS as being critically insecure

I think the only thing we can conclude from this is that you have come up
with an insecure proof of stake protocol. I don't see how anything you've
brought up amounts to substantial evidence that all possible PoS protocols
are insecure.

On Tue, May 25, 2021 at 11:10 AM befreeandopen <befreeandopen at protonmail.com>
wrote:

>
> @befreeandopen " An attacker can calculate whether or not she can prolong
> this chain or not and if so with what timestamp."
>
> The scenario you describe would only be likely to happen at all if the
> malicious actor has a very large fraction of the stake - probably quite
> close to 50%. At that point, you're talking about a 51% attack, not the
> nothing at stake problem. The nothing at stake problem is the problem where
> anyone will mint on any chain. Its clear that if there's a substantial
> punishment for minting on chains other than the one that eventually wins,
> every minter without a significant fraction of the stake will be honest and
> not attempt to mint on old blocks or support someone else's attempt to mint
> on old blocks (until and if it becomes the heaviest chain). Because the
> attacker would need probably >45% of the active stake (take a look at the reasoning
> here
> <https://github.com/fresheneesz/ValidatedProofOfStake#security-the-minimum-cost-of-attack>;
> for a deeper analysis of that statement), I don't agree that punishment is
> not a sufficient mitigation of the nothing at stake problem. To exploit the
> nothing at stake problem, you basically need to 51% attack, at which point
> you've exceeded the operating conditions of the system, so of course its
> gonna have problems, just like a 51% attack would cause with PoW.
>
>
> This is not at all the case. The attacker benefits using the described
> technique at any size of the stake and significantly so with just 5% of the
> stake. By significantly, I do not mean that the attacker is able to
> completely take control the network (in short term), but rather that the
> attacker has significant advantage in the number of blocks she creates
> compared to what she "should be able to create". This means the attacker's
> stake increases significantly faster than of the honest nodes, which in
> long term is very serious in PoS system. If you believe close to 50% is
> needed for that, you need to redo your math. So no, you are wrong stating
> that "to exploit nothing at stake problem you basically need to 51%
> attack". It is rather the opposite - eventually, nothing at stake attack
> leads to ability to perform 51% attack.
>
>
>
> > I am not sure if this is what you call quorum-based PoS
>
> Yes, pre-selected minters is exactly what I mean by that.
>
> > it allows the attacker to know who to attack at which point with
> powerful DDOS in order to hurt liveness of such system
>
> Just like in bitcoin, associating keys with IP addresses isn't generally
> an easy thing to do on the fly like that. If you know someone's IP address,
> you can target them. But if you only know their address or public key, the
> reverse isn't as easy. With a quorum-based PoS system, you can see their
> public key and address, but finding out their IP to DOS would be a huge
> challenge I think.
>
>
> I do not dispute that the problem is not trivial, but the problem is not
> as hard as you think. The network graph analysis is a known technique and
> it is not trivial, but not very hard either. Introducing a large number of
> nodes to the system to achieve very good success rate of analysis of area
> of origin of blocks is doable and has been done in past. So again, I very
> much disagree with your conclusion that this is somehow secure. It is
> absolutely insecure.
>
>
>
> Note, tho, that quorum-based PoS generally also have punishments as part
> of the protocol. The introduction of punishments do indeed handily solve
> the nothing at stake problem. And you didn't mention a single problem that
> the punishments introduce that weren't already there before punishments.
> There are tradeoffs with introducing punishments (eg in some cases you
> might punish honest actors), but they are minor in comparison to solving
> the nothing at stake problem.
>
>
> While I agree that introduction of punishment itself does not imply
> introducing a problem elsewhere (which I did not claim if you reread my
> previous message), it does introduce additional complexity which may
> introduce problem, but more importantly, while it slightly improves
> resistance against the nothing at stake attack, it solves absolutely
> nothing. Your claim is based on wrong claim of needed close to 50% stake,
> but that could not be farther from the truth. It is not true even in
> optimal conditions when all participants of the network stake or delegate
> their stake. These optimal conditions rarely, if ever, occur. And that's
> another thing that we have not mention in our debate, so please allow me to
> introduce another problem to PoS.
>
> Consider what is needed for such optimal conditions to occur - all coins
> are always part of the stake, which means that they need to somehow
> automatically part of the staking process even when they are moved. But in
> many PoS systems you usually require some age (in terms of confirmations)
> of the coin before you allow it to be used for participation in staking
> process and that is for a good reason - to prevent various grinding
> attacks. In some systems the coin must be specifically registered before it
> can be staked, in others, simply waiting for enough confirmations enables
> you to stake with the coin. I am not sure if there is a system which does
> not have this cooling period for a coin that has been moved. Maybe it is
> possible though, but AFAIK it is not common and not battle tested feature.
>
> Then if we admit that achieving the optimal condition is rather
> theoretical. Then if we do not have the optimal condition, it means that a
> staker with K% of the total available supply increases it's percentage over
> time to some amounts >K%. As long as the staker makes sure (which is not
> that hard) that she does not miss a chance to create a block, her
> significance in the system will always increase in time. It will increase
> relative to all normal users who do not stake (if there are any) and
> relative to all other stakers who make mistakes or who are not wealthy
> enough to afford not selling any position ever. But powerful attacker is
> exactly in such position and thus she will gain significance in such a
> system. The technique I have described, and that you mistakenly think is
> viable only with huge amounts of stake, only puts the attacker to even
> greater advantage. But even without the described attack (which exploits
> nothing at stake), the PoS system converges to a system more and more
> controlled by powerful entity, which we can assume is the attacker.
>
>
> So I don't think it is at all misleading to claim that "nothing at stake"
> is a solved problem. I do in fact mean that the solutions to that problem
> don't introduce any other problems with anywhere near the same level of
> significance.
>
>
> It still stands as truly misleading claim. I disagree that introducing
> DDOS opportunity with medium level of difficulty for the attacker to
> implement it, in case of "quorum-based PoS" is not a problem anywhere near
> the same level of significance. Such an attack vector allows you to turn
> off the network if you spend some time and money. That is hardly acceptable.
>
> Just because of the above we must reject PoS as being critically insecure
> until someone invents and demonstrates an actual way of solving these
> issues.
>
>
>
> On Tue, May 25, 2021 at 3:00 AM Erik Aronesty <erik at q32.com> wrote:
>
>> > > you burn them to be used at a future particular block height
>>
>> > This sounds exploitable. It seems like an attacker could simply focus
>> all their burns on a particular set of 6 blocks to double spend, minimizing
>> their cost of attack.
>>
>> could be right. the original idea was to have burns decay over time,
>> like ASIC's.
>>
>> anyway the point was not that "i had a magic formula"
>>
>> the point was that proof of burn is almost always better than proof of
>> stake - simply because the "proof" is on-chain, not sitting on a node
>> somewhere waiting to be stolen.
>>
>> On Mon, May 24, 2021 at 9:53 PM Billy Tetrud <billy.tetrud at gmail.com>
>> wrote:
>> >
>> > Is this the kind of proof of burn you're talking about?
>> >
>> > > if i have a choice between two chains, one longer and one shorter,
>> i can only choose one... deterministically
>> >
>> > What prevents you from attempting to mine block 553 on both chains?
>> >
>> > > miners have a very strong, long-term, investment in the stability of
>> the chain.
>> >
>> > Yes, but the same can be said of any coin, even ones that do have the
>> nothing at stake problem. This isn't sufficient tho because the chain is a
>> common good, and the tragedy of the commons holds for it.
>> >
>> > > you burn them to be used at a future particular block height
>> >
>> > This sounds exploitable. It seems like an attacker could simply focus
>> all their burns on a particular set of 6 blocks to double spend, minimizing
>> their cost of attack.
>> >
>> > > i can imagine scenarios where large stakeholders can collude to
>> punish smaller stakeholders simply to drive them out of business, for
>> example
>> >
>> > Are you talking about a 51% attack? This is possible in any
>> decentralized cryptocurrency.
>> >
>> >
>> > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty <erik at q32.com> wrote:
>> >>
>> >> > > your burn investment is always "at stake", any redaction can
>> result in a loss-of-burn, because burns can be tied, precisely, to
>> block-heights
>> >> > I'm fuzzy on how proof of burn works.
>> >>
>> >> when you burn coins, you burn them to be used at a future particular
>> >> block height: so if i'm burning for block 553, i can only use them to
>> >> mine block 553. if i have a choice between two chains, one longer
>> >> and one shorter, i can only choose one... deterministically, for that
>> >> burn: the chain with the height 553. if we fix the "lead time" for
>> >> burned coins to be weeks or even months in advance, miners have a very
>> >> strong, long-term, investment in the stability of the chain.
>> >>
>> >> therefore there is no "nothing at stake" problem. it's
>> >> deterministic, so miners have no choice. they can *only* choose the
>> >> transactions that go into the block. they cannot choose which chain
>> >> to mine, and it's time-locked, so rollbacks and instability always
>> >> hurt miners the most.
>> >>
>> >> the "punishment" systems of PoS are "weird at best", certainly
>> >> unproven. i can imagine scenarios where large stakeholders can
>> >> collude to punish smaller stakeholders simply to drive them out of
>> >> business, for example. and then you have to put checks in place to
>> >> prevent that, and more checks for those prevention system...
>> >>
>> >> in PoB, there is no complexity. simpler systems like this are
>> >> typically more secure.
>> >>
>> >> PoB also solves problems caused by "energy dependence", which could
>> >> lead to state monopolies on mining (like the new Bitcoin Mining
>> >> Council). these consortiums, if state sanctioned, could become a
>> >> source of censorship, for example. Since PoB doesn't require you to
>> >> have a live, well-connected node, it's harder to censor & harder to
>> >> trace.
>> >>
>> >> Eliminating this weakness seems to be in the best interests of
>> >> existing stakeholders
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, May 24, 2021 at 4:44 PM Billy Tetrud <billy.tetrud at gmail.com>
>> wrote:
>> >> >
>> >> > > proof of burn clearly solves this, since nothing is held online
>> >> >
>> >> > Well.. the coins to be burned need to be online when they're burned.
>> But yes, only a small fraction of the total coins need to be online.
>> >> >
>> >> > > your burn investment is always "at stake", any redaction can
>> result in a loss-of-burn, because burns can be tied, precisely, to
>> block-heights
>> >> >
>> >> > So you're saying that if say someone tries to mine a block on a
>> shorter chain, that requires them to send a transaction burning their
>> coins, and that transaction could also be spent on the longest chain, which
>> means their coins are burned even if the chain they tried to mine on
>> doesn't win? I'm fuzzy on how proof of burn works.
>> >> >
>> >> > > proof of burn can be more secure than proof-of-stake
>> >> >
>> >> > FYI, proof of stake can be done without the "nothing at stake"
>> problem. You can simply punish people who mint on shorter chains (by
>> rewarding people who publish proofs of this happening on the main chain).
>> In quorum-based PoS, you can punish people in the quorum that propose or
>> sign multiple blocks for the same height. The "nothing at stake" problem is
>> a solved problem at this point for PoS.
>> >> >
>> >> >
>> >> >
>> >> > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty <erik at q32.com> wrote:
>> >> >>
>> >> >> > I don't see a way to get around the conflicting requirement that
>> the keys for large amounts of coins should be kept offline but those are
>> exactly the coins we need online to make the scheme secure.
>> >> >>
>> >> >> proof of burn clearly solves this, since nothing is held online
>> >> >>
>> >> >> > how does proof of burn solve the "nothing at stake" problem in
>> your view?
>> >> >>
>> >> >> definition of nothing at stake: in the event of a fork, whether the
>> >> >> fork is accidental or a malicious, the optimal strategy for any
>> miner
>> >> >> is to mine on every chain, so that the miner gets their reward no
>> >> >> matter which fork wins. indeed in proof-of-stake, the proofs are
>> >> >> published on the very chains mines, so the incentive is magnified.
>> >> >>
>> >> >> in proof-of-burn, your burn investment is always "at stake", any
>> >> >> redaction can result in a loss-of-burn, because burns can be tied,
>> >> >> precisely, to block-heights
>> >> >>
>> >> >> as a result, miners no longer have an incentive to mine all chains
>> >> >>
>> >> >> in this way proof of burn can be more secure than proof-of-stake,
>> and
>> >> >> even more secure than proof of work
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >>
>> >> >> On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
>> >> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> >> >
>> >> >> > Hi Billy,
>> >> >> >
>> >> >> > I was going to write a post which started by dismissing many of
>> the weak arguments that are made against PoS made in this thread and
>> elsewhere.
>> >> >> > Although I don't agree with all your points you have done a
>> decent job here so I'll focus on the second part: why I think
>> Proof-of-Stake is inappropriate for a Bitcoin-like system.
>> >> >> >
>> >> >> > Proof of stake is not fit for purpose for a global settlement
>> layer in a pure digital asset (i.e. "digital gold") which is what Bitcoin
>> is trying to be.
>> >> >> > PoS necessarily gives responsibilities to the holders of coins
>> that they do not want and cannot handle.
>> >> >> > In Bitcoin, large unsophisticated coin holders can put their
>> coins in cold storage without a second thought given to the health of the
>> underlying ledger.
>> >> >> > As much as hardcore Bitcoiners try to convince them to run their
>> own node, most don't, and that's perfectly acceptable.
>> >> >> > At no point do their personal decisions affect the underlying
>> consensus -- it only affects their personal security assurance (not that of
>> the system itself).
>> >> >> > In PoS systems this clean separation of responsibilities does not
>> exist.
>> >> >> >
>> >> >> > I think that the more rigorously studied PoS protocols will work
>> fine within the security claims made in their papers.
>> >> >> > People who believe that these protocols are destined for
>> catastrophic consensus failure are certainly in for a surprise.
>> >> >> > But the devil is in the detail.
>> >> >> > Let's look at what the implications of using the leading proof of
>> stake protocols would have on Bitcoin:
>> >> >> >
>> >> >> > ### Proof of SquareSpace (Cardano, Polkdadot)
>> >> >> >
>> >> >> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with
>> an inbuilt on-chain delegation system[5].
>> >> >> > In these protocols, coin holders who do not want to run their
>> node with their hot keys in it delegate it to a "Stake Pool".
>> >> >> > I call the resulting system Proof-of-SquareSpace since most will
>> choose a pool by looking around for one with a nice website and offering
>> the largest share of the block reward.
>> >> >> > On the surface this might sound no different than someone with an
>> mining rig shopping around for a good mining pool but there are crucial
>> differences:
>> >> >> >
>> >> >> > 1. The person making the decision is forced into it just because
>> they own the currency -- someone with a mining rig has purchased it with
>> the intent to make profit by participating in consensus.
>> >> >> >
>> >> >> > 2. When you join a mining pool your systems are very much still
>> online. You are just partaking in a pool to reduce your profit variance.
>> You still see every block that you help create and *you never help create a
>> block without seeing it first*.
>> >> >> >
>> >> >> > 3. If by SquareSpace sybil attack you gain a dishonest majority
>> and start censoring transactions how are the users meant to redelegate
>> their stake to honest pools?
>> >> >> > I guess they can just send a transaction delegating to another
>> pool...oh wait I guess that might be censored too! This seems really really
>> bad.
>> >> >> > In Bitcoin, miners can just join a different pool at a whim.
>> There is nothing the attacker can do to stop them. A temporary dishonest
>> majority heals relatively well.
>> >> >> >
>> >> >> > There is another severe disadvantage to this on-chain delegation
>> system: every UTXO must indicate which staking account this UTXO belongs to
>> so the appropriate share of block rewards can be transferred there.
>> >> >> > Being able to associate every UTXO to an account ruins one of the
>> main privacy advantages of the UTXO model.
>> >> >> > It also grows the size of the blockchain significantly.
>> >> >> >
>> >> >> > ### "Pure" proof of stake (Algorand)
>> >> >> >
>> >> >> > Algorand's[4] approach is to only allow online stake to
>> participate in the protocol.
>> >> >> > Theoretically, This means that keys holding funds have to be
>> online in order for them to author blocks when they are chosen.
>> >> >> > Of course in reality no one wants to keep their coin holding keys
>> online so in Alogorand you can authorize a set of "participation keys"[1]
>> that will be used to create blocks on your coin holding key's behalf.
>> >> >> > Hopefully you've spotted the problem.
>> >> >> > You can send your participation keys to any malicious party with
>> a nice website (see random example [2]) offering you a good return.
>> >> >> > Damn it's still Proof-of-SquareSpace!
>> >> >> > The minor advantage is that at least the participation keys
>> expire after a certain amount of time so eventually the SquareSpace
>> attacker will lose their hold on consensus.
>> >> >> > Importantly there is also less junk on the blockchain because the
>> participation keys are delegated off-chain and so are not making as much of
>> a mess.
>> >> >> >
>> >> >> > ### Conclusion
>> >> >> >
>> >> >> > I don't see a way to get around the conflicting requirement that
>> the keys for large amounts of coins should be kept offline but those are
>> exactly the coins we need online to make the scheme secure.
>> >> >> > If we allow delegation then we open up a new social attack
>> surface and it degenerates to Proof-of-SquareSpace.
>> >> >> >
>> >> >> > For a "digital gold" like system like Bitcoin we optimize for
>> simplicity and desperately want to avoid extraneous responsibilities for
>> the holder of the coin.
>> >> >> > After all, gold is an inert element on the periodic table that
>> doesn't confer responsibilities on the holder to maintain the quality of
>> all the other bars of gold out there.
>> >> >> > Bitcoin feels like this too and in many ways is more inert and
>> beautifully boring than gold.
>> >> >> > For Bitcoin to succeed I think we need to keep it that way and
>> Proof-of-Stake makes everything a bit too exciting.
>> >> >> >
>> >> >> > I suppose in the end the market will decide what is real digital
>> gold and whether these bad technical trade offs are worth being able to say
>> it uses less electricity. It goes without saying that making bad technical
>> decisions to appease the current political climate is an anathema to
>> Bitcoin.
>> >> >> >
>> >> >> > Would be interested to know if you or others think differently on
>> these points.
>> >> >> >
>> >> >> > [1]:
>> https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
>> >> >> > [2]: https://staking.staked.us/algorand-staking
>> >> >> > [3]: https://eprint.iacr.org/2017/573.pdf
>> >> >> > [4]:
>> https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
>> >> >> > [5]:
>> https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf
>> >> >> >
>> >> >> > Cheers,
>> >> >> >
>> >> >> > LL
>> >> >> >
>> >> >> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> >> >>
>> >> >> >> I think there is a lot of misinformation and bias against Proof
>> of Stake. Yes there have been lots of shady coins that use insecure PoS
>> mechanisms. Yes there have been massive issues with distribution of PoS
>> coins (of course there have also been massive issues with PoW coins as
>> well). However, I want to remind everyone that there is a difference
>> between "proved to be impossible" and "have not achieved recognized success
>> yet". Most of the arguments levied against PoS are out of date or rely on
>> unproven assumptions or extrapolation from the analysis of a particular PoS
>> system. I certainly don't think we should experiment with bitcoin by
>> switching to PoS, but from my research, it seems very likely that there is
>> a proof of stake consensus protocol we could build that has substantially
>> higher security (cost / capital required to execute an attack) while at the
>> same time costing far less resources (which do translate to fees on the
>> network) *without* compromising any of the critical security properties
>> bitcoin relies on. I think the critical piece of this is the disagreements
>> around hardcoded checkpoints, which is a critical piece solving attacks
>> that could be levied on a PoS chain, and how that does (or doesn't) affect
>> the security model.
>> >> >> >>
>> >> >> >> @Eric Your proof of stake fallacy seems to be saying that PoS is
>> worse when a 51% attack happens. While I agree, I think that line of
>> thinking omits important facts:
>> >> >> >> * The capital required to 51% attack a PoS chain can be made
>> substantially greater than on a PoS chain.
>> >> >> >> * The capital the attacker stands to lose can be substantially
>> greater as well if the attack is successful.
>> >> >> >> * The effectiveness of paying miners to raise the honest
>> fraction of miners above 50% may be quite bad.
>> >> >> >> * Allowing a 51% attack is already unacceptable. It should be
>> considered whether what happens in the case of a 51% may not be
>> significantly different. The currency would likely be critically damaged in
>> a 51% attack regardless of consensus mechanism.
>> >> >> >>
>> >> >> >> > Proof-of-stake tends towards oligopolistic control
>> >> >> >>
>> >> >> >> People repeat this often, but the facts support this. There is
>> no centralization pressure in any proof of stake mechanism that I'm aware
>> of. IE if you have 10 times as much coin that you use to mint blocks, you
>> should expect to earn 10x as much minting revenue - not more than 10x. By
>> contrast, proof of work does in fact have clear centralization pressure -
>> this is not disputed. Our goal in relation to that is to ensure that the
>> centralization pressure remains insignifiant. Proof of work also clearly
>> has a lot more barriers to entry than any proof of stake system does. Both
>> of these mean the tendency towards oligopolistic control is worse for PoW.
>> >> >> >>
>> >> >> >> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>> >> >> >>
>> >> >> >> I certainly agree. Bitcoin's energy usage at the moment is I
>> think quite warranted. However, the question is: can we do substantially
>> better. I think if we can, we probably should... eventually.
>> >> >> >>
>> >> >> >> > Proof of Stake is only resilient to ⅓ of the network
>> demonstrating a Byzantine Fault, whilst Proof of Work is resilient up to
>> the ½ threshold
>> >> >> >>
>> >> >> >> I see no mention of this in the pos.pdf you linked to. I'm not
>> aware of any proof that all PoS systems have a failure threshold of 1/3. I
>> know that staking systems like Casper do in fact have that 1/3 requirement.
>> However there are PoS designs that should exceed that up to nearly 50% as
>> far as I'm aware. Proof of work is not in fact resilient up to the 1/2
>> threshold in the way you would think. IE, if 100% of miners are currently
>> honest and have a collective 100 exahashes/s hashpower, an attacker does
>> not need to obtain 100 exahashes/s, but actually only needs to accumulate
>> 50 exahashes/s. This is because as the attacker accumulates hashpower, it
>> drives honest miners out of the market as the difficulty increases to
>> beyond what is economically sustainable. Also, its been shown that the best
>> proof of work can do is require an attacker to obtain 33% of the hashpower
>> because of the selfish mining attack discussed in depth in this paper:
>> https://arxiv.org/abs/1311.0243. Together, both of these things reduce
>> PoW's security by a factor of about 83% (1 - 50%*33%).
>> >> >> >>
>> >> >> >> > Proof of Stake requires other trade-offs which are
>> incompatible with Bitcoin's objective (to be a trustless digital cash) —
>> specifically the famous "security vs. liveness" guarantee
>> >> >> >>
>> >> >> >> Do you have a good source that talks about why you think proof
>> of stake cannot be used for a trustless digital cash?
>> >> >> >>
>> >> >> >> > You cannot gain tokens without someone choosing to give up
>> those coins - a form of permission.
>> >> >> >>
>> >> >> >> This is not a practical constraint. Just like in mining, some
>> nodes may reject you, but there will likely be more that will accept you,
>> some sellers may reject you, but most would accept your money as payment
>> for bitcoins. I don't think requiring the "permission" of one of millions
>> of people in the market can be reasonably considered a "permissioned
>> currency".
>> >> >> >>
>> >> >> >> > 2. Proof of stake must have a trusted means of timestamping to
>> regulate overproduction of blocks
>> >> >> >>
>> >> >> >> Both PoW and PoS could mine/mint blocks twice as fast if
>> everyone agreed to double their clock speeds. Both systems rely on an
>> honest majority sticking to standard time.
>> >> >> >>
>> >> >> >>
>> >> >> >> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> >> >>>
>> >> >> >>> Ah sorry, I didn't realize this was, in fact, a different
>> thread! :)
>> >> >> >>>
>> >> >> >>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <
>> mike at powx.org> wrote:
>> >> >> >>>>
>> >> >> >>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the
>> BIP itself. PoS, VDFs, and so on are interesting but I guess there are
>> other threads going on these topics already where they would be relevant.
>> >> >> >>>>
>> >> >> >>>> Also, it's important to distinguish between oPoW and these
>> other "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't
>> alter the core game theory or security assumptions of Hashcash and actually
>> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>> >> >> >>>>
>> >> >> >>>> Cheers,
>> >> >> >>>> Mike
>> >> >> >>>>
>> >> >> >>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> >> >>>>>
>> >> >> >>>>> 1. i never suggested vdf's to replace pow.
>> >> >> >>>>>
>> >> >> >>>>> 2. my suggestion was specifically *in the context of* a
>> working
>> >> >> >>>>> proof-of-burn protocol
>> >> >> >>>>>
>> >> >> >>>>> - vdfs used only for timing (not block height)
>> >> >> >>>>> - blind-burned coins of a specific age used to replace proof
>> of work
>> >> >> >>>>> - the required "work" per block would simply be a competition
>> to
>> >> >> >>>>> acquire rewards, and so miners would have to burn coins, well
>> in
>> >> >> >>>>> advance, and hope that their burned coins got rewarded in
>> some far
>> >> >> >>>>> future
>> >> >> >>>>> - the point of burned coins is to mimic, in every meaningful
>> way, the
>> >> >> >>>>> value gained from proof of work... without some of the
>> security
>> >> >> >>>>> drawbacks
>> >> >> >>>>> - the miner risks losing all of his burned coins (like all
>> miners risk
>> >> >> >>>>> losing their work in each block)
>> >> >> >>>>> - new burns can't be used
>> >> >> >>>>> - old burns age out (like ASICs do)
>> >> >> >>>>> - other requirements on burns might be needed to properly
>> mirror the
>> >> >> >>>>> properties of PoW and the incentives Bitcoin uses to mine
>> honestly.
>> >> >> >>>>>
>> >> >> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf
>> system"
>> >> >> >>>>> might be more secure in the long run, and that if the entire
>> space
>> >> >> >>>>> agreed that such an endeavor was worthwhile, a test net could
>> be spun
>> >> >> >>>>> up, and a hard-fork could be initiated.
>> >> >> >>>>>
>> >> >> >>>>> 4. i would never suggest such a thing unless i believed it was
>> >> >> >>>>> possible that consensus was possible. so no, this is not an
>> "alt
>> >> >> >>>>> coin"
>> >> >> >>>>>
>> >> >> >>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <
>> zachgrw at gmail.com> wrote:
>> >> >> >>>>> >
>> >> >> >>>>> > Hi ZmnSCPxj,
>> >> >> >>>>> >
>> >> >> >>>>> > Please note that I am not suggesting VDFs as a means to
>> save energy, but solely as a means to make the time between blocks more
>> constant.
>> >> >> >>>>> >
>> >> >> >>>>> > Zac
>> >> >> >>>>> >
>> >> >> >>>>> >
>> >> >> >>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <
>> ZmnSCPxj at protonmail.com> wrote:
>> >> >> >>>>> >>
>> >> >> >>>>> >> Good morning Zac,
>> >> >> >>>>> >>
>> >> >> >>>>> >> > VDFs might enable more constant block times, for
>> instance by having a two-step PoW:
>> >> >> >>>>> >> >
>> >> >> >>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF
>> being subject to difficulty adjustments similar to the as-is). As per the
>> property of VDFs, miners are able show proof of work.
>> >> >> >>>>> >> >
>> >> >> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so
>> finding a block takes 1 minute on average, again subject to as-is
>> difficulty adjustments.
>> >> >> >>>>> >> >
>> >> >> >>>>> >> > As a result, variation in block times will be greatly
>> reduced.
>> >> >> >>>>> >>
>> >> >> >>>>> >> As I understand it, another weakness of VDFs is that they
>> are not inherently progress-free (their sequential nature prevents that;
>> they are inherently progress-requiring).
>> >> >> >>>>> >>
>> >> >> >>>>> >> Thus, a miner which focuses on improving the amount of
>> energy that it can pump into the VDF circuitry (by overclocking and
>> freezing the circuitry), could potentially get into a winner-takes-all
>> situation, possibly leading to even *worse* competition and even *more*
>> energy consumption.
>> >> >> >>>>> >> After all, if you can start mining 0.1s faster than the
>> competition, that is a 0.1s advantage where *only you* can mine *in the
>> entire world*.
>> >> >> >>>>> >>
>> >> >> >>>>> >> Regards,
>> >> >> >>>>> >> ZmnSCPxj
>> >> >> >>>>> _______________________________________________
>> >> >> >>>>> bitcoin-dev mailing list
>> >> >> >>>>> bitcoin-dev at lists.linuxfoundation.org
>> >> >> >>>>>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> --
>> >> >> >>>> Michael Dubrovsky
>> >> >> >>>> Founder; PoWx
>> >> >> >>>> www.PoWx.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> Michael Dubrovsky
>> >> >> >>> Founder; PoWx
>> >> >> >>> www.PoWx.org
>> >> >> >>> _______________________________________________
>> >> >> >>> bitcoin-dev mailing list
>> >> >> >>> bitcoin-dev at lists.linuxfoundation.org
>> >> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> bitcoin-dev mailing list
>> >> >> >> bitcoin-dev at lists.linuxfoundation.org
>> >> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > bitcoin-dev mailing list
>> >> >> > bitcoin-dev at 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/20210525/92b5d4d1/attachment-0001.html>;

📅 Original date posted:2021-05-25 📝 Original ...

2023-06-08T00:53:02+02:00

In reply to nevent1q…t2z6
_________________________

📅 Original date posted:2021-05-25
📝 Original message:@befreeandopen " An attacker can calculate whether or not she can prolong
this chain or not and if so with what timestamp."

The scenario you describe would only be likely to happen at all if the
malicious actor has a very large fraction of the stake - probably quite
close to 50%. At that point, you're talking about a 51% attack, not the
nothing at stake problem. The nothing at stake problem is the problem where
anyone will mint on any chain. Its clear that if there's a substantial
punishment for minting on chains other than the one that eventually wins,
every minter without a significant fraction of the stake will be honest and
not attempt to mint on old blocks or support someone else's attempt to mint
on old blocks (until and if it becomes the heaviest chain). Because the
attacker would need probably >45% of the active stake (take a look at
the reasoning
here
<https://github.com/fresheneesz/ValidatedProofOfStake#security-the-minimum-cost-of-attack>;
for a deeper analysis of that statement), I don't agree that punishment is
not a sufficient mitigation of the nothing at stake problem. To exploit the
nothing at stake problem, you basically need to 51% attack, at which point
you've exceeded the operating conditions of the system, so of course its
gonna have problems, just like a 51% attack would cause with PoW.

> I am not sure if this is what you call quorum-based PoS

Yes, pre-selected minters is exactly what I mean by that.

> it allows the attacker to know who to attack at which point with powerful
DDOS in order to hurt liveness of such system

Just like in bitcoin, associating keys with IP addresses isn't generally an
easy thing to do on the fly like that. If you know someone's IP address,
you can target them. But if you only know their address or public key, the
reverse isn't as easy. With a quorum-based PoS system, you can see their
public key and address, but finding out their IP to DOS would be a huge
challenge I think.

Note, tho, that quorum-based PoS generally also have punishments as part of
the protocol. The introduction of punishments do indeed handily solve the
nothing at stake problem. And you didn't mention a single problem that the
punishments introduce that weren't already there before punishments. There
are tradeoffs with introducing punishments (eg in some cases you might
punish honest actors), but they are minor in comparison to solving the
nothing at stake problem.

So I don't think it is at all misleading to claim that "nothing at stake"
is a solved problem. I do in fact mean that the solutions to that problem
don't introduce any other problems with anywhere near the same level of
significance.

On Tue, May 25, 2021 at 3:00 AM Erik Aronesty <erik at q32.com> wrote:

> > > you burn them to be used at a future particular block height
>
> > This sounds exploitable. It seems like an attacker could simply focus
> all their burns on a particular set of 6 blocks to double spend, minimizing
> their cost of attack.
>
> could be right. the original idea was to have burns decay over time,
> like ASIC's.
>
> anyway the point was not that "i had a magic formula"
>
> the point was that proof of burn is almost always better than proof of
> stake - simply because the "proof" is on-chain, not sitting on a node
> somewhere waiting to be stolen.
>
> On Mon, May 24, 2021 at 9:53 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
> >
> > Is this the kind of proof of burn you're talking about?
> >
> > > if i have a choice between two chains, one longer and one shorter, i
> can only choose one... deterministically
> >
> > What prevents you from attempting to mine block 553 on both chains?
> >
> > > miners have a very strong, long-term, investment in the stability of
> the chain.
> >
> > Yes, but the same can be said of any coin, even ones that do have the
> nothing at stake problem. This isn't sufficient tho because the chain is a
> common good, and the tragedy of the commons holds for it.
> >
> > > you burn them to be used at a future particular block height
> >
> > This sounds exploitable. It seems like an attacker could simply focus
> all their burns on a particular set of 6 blocks to double spend, minimizing
> their cost of attack.
> >
> > > i can imagine scenarios where large stakeholders can collude to punish
> smaller stakeholders simply to drive them out of business, for example
> >
> > Are you talking about a 51% attack? This is possible in any
> decentralized cryptocurrency.
> >
> >
> > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty <erik at q32.com> wrote:
> >>
> >> > > your burn investment is always "at stake", any redaction can result
> in a loss-of-burn, because burns can be tied, precisely, to block-heights
> >> > I'm fuzzy on how proof of burn works.
> >>
> >> when you burn coins, you burn them to be used at a future particular
> >> block height: so if i'm burning for block 553, i can only use them to
> >> mine block 553. if i have a choice between two chains, one longer
> >> and one shorter, i can only choose one... deterministically, for that
> >> burn: the chain with the height 553. if we fix the "lead time" for
> >> burned coins to be weeks or even months in advance, miners have a very
> >> strong, long-term, investment in the stability of the chain.
> >>
> >> therefore there is no "nothing at stake" problem. it's
> >> deterministic, so miners have no choice. they can *only* choose the
> >> transactions that go into the block. they cannot choose which chain
> >> to mine, and it's time-locked, so rollbacks and instability always
> >> hurt miners the most.
> >>
> >> the "punishment" systems of PoS are "weird at best", certainly
> >> unproven. i can imagine scenarios where large stakeholders can
> >> collude to punish smaller stakeholders simply to drive them out of
> >> business, for example. and then you have to put checks in place to
> >> prevent that, and more checks for those prevention system...
> >>
> >> in PoB, there is no complexity. simpler systems like this are
> >> typically more secure.
> >>
> >> PoB also solves problems caused by "energy dependence", which could
> >> lead to state monopolies on mining (like the new Bitcoin Mining
> >> Council). these consortiums, if state sanctioned, could become a
> >> source of censorship, for example. Since PoB doesn't require you to
> >> have a live, well-connected node, it's harder to censor & harder to
> >> trace.
> >>
> >> Eliminating this weakness seems to be in the best interests of
> >> existing stakeholders
> >>
> >>
> >>
> >>
> >> On Mon, May 24, 2021 at 4:44 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
> >> >
> >> > > proof of burn clearly solves this, since nothing is held online
> >> >
> >> > Well.. the coins to be burned need to be online when they're burned.
> But yes, only a small fraction of the total coins need to be online.
> >> >
> >> > > your burn investment is always "at stake", any redaction can result
> in a loss-of-burn, because burns can be tied, precisely, to block-heights
> >> >
> >> > So you're saying that if say someone tries to mine a block on a
> shorter chain, that requires them to send a transaction burning their
> coins, and that transaction could also be spent on the longest chain, which
> means their coins are burned even if the chain they tried to mine on
> doesn't win? I'm fuzzy on how proof of burn works.
> >> >
> >> > > proof of burn can be more secure than proof-of-stake
> >> >
> >> > FYI, proof of stake can be done without the "nothing at stake"
> problem. You can simply punish people who mint on shorter chains (by
> rewarding people who publish proofs of this happening on the main chain).
> In quorum-based PoS, you can punish people in the quorum that propose or
> sign multiple blocks for the same height. The "nothing at stake" problem is
> a solved problem at this point for PoS.
> >> >
> >> >
> >> >
> >> > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty <erik at q32.com> wrote:
> >> >>
> >> >> > I don't see a way to get around the conflicting requirement that
> the keys for large amounts of coins should be kept offline but those are
> exactly the coins we need online to make the scheme secure.
> >> >>
> >> >> proof of burn clearly solves this, since nothing is held online
> >> >>
> >> >> > how does proof of burn solve the "nothing at stake" problem in
> your view?
> >> >>
> >> >> definition of nothing at stake: in the event of a fork, whether the
> >> >> fork is accidental or a malicious, the optimal strategy for any miner
> >> >> is to mine on every chain, so that the miner gets their reward no
> >> >> matter which fork wins. indeed in proof-of-stake, the proofs are
> >> >> published on the very chains mines, so the incentive is magnified.
> >> >>
> >> >> in proof-of-burn, your burn investment is always "at stake", any
> >> >> redaction can result in a loss-of-burn, because burns can be tied,
> >> >> precisely, to block-heights
> >> >>
> >> >> as a result, miners no longer have an incentive to mine all chains
> >> >>
> >> >> in this way proof of burn can be more secure than proof-of-stake, and
> >> >> even more secure than proof of work
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >>
> >> >> On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
> >> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >> >
> >> >> > Hi Billy,
> >> >> >
> >> >> > I was going to write a post which started by dismissing many of
> the weak arguments that are made against PoS made in this thread and
> elsewhere.
> >> >> > Although I don't agree with all your points you have done a decent
> job here so I'll focus on the second part: why I think Proof-of-Stake is
> inappropriate for a Bitcoin-like system.
> >> >> >
> >> >> > Proof of stake is not fit for purpose for a global settlement
> layer in a pure digital asset (i.e. "digital gold") which is what Bitcoin
> is trying to be.
> >> >> > PoS necessarily gives responsibilities to the holders of coins
> that they do not want and cannot handle.
> >> >> > In Bitcoin, large unsophisticated coin holders can put their coins
> in cold storage without a second thought given to the health of the
> underlying ledger.
> >> >> > As much as hardcore Bitcoiners try to convince them to run their
> own node, most don't, and that's perfectly acceptable.
> >> >> > At no point do their personal decisions affect the underlying
> consensus -- it only affects their personal security assurance (not that of
> the system itself).
> >> >> > In PoS systems this clean separation of responsibilities does not
> exist.
> >> >> >
> >> >> > I think that the more rigorously studied PoS protocols will work
> fine within the security claims made in their papers.
> >> >> > People who believe that these protocols are destined for
> catastrophic consensus failure are certainly in for a surprise.
> >> >> > But the devil is in the detail.
> >> >> > Let's look at what the implications of using the leading proof of
> stake protocols would have on Bitcoin:
> >> >> >
> >> >> > ### Proof of SquareSpace (Cardano, Polkdadot)
> >> >> >
> >> >> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with
> an inbuilt on-chain delegation system[5].
> >> >> > In these protocols, coin holders who do not want to run their node
> with their hot keys in it delegate it to a "Stake Pool".
> >> >> > I call the resulting system Proof-of-SquareSpace since most will
> choose a pool by looking around for one with a nice website and offering
> the largest share of the block reward.
> >> >> > On the surface this might sound no different than someone with an
> mining rig shopping around for a good mining pool but there are crucial
> differences:
> >> >> >
> >> >> > 1. The person making the decision is forced into it just because
> they own the currency -- someone with a mining rig has purchased it with
> the intent to make profit by participating in consensus.
> >> >> >
> >> >> > 2. When you join a mining pool your systems are very much still
> online. You are just partaking in a pool to reduce your profit variance.
> You still see every block that you help create and *you never help create a
> block without seeing it first*.
> >> >> >
> >> >> > 3. If by SquareSpace sybil attack you gain a dishonest majority
> and start censoring transactions how are the users meant to redelegate
> their stake to honest pools?
> >> >> > I guess they can just send a transaction delegating to another
> pool...oh wait I guess that might be censored too! This seems really really
> bad.
> >> >> > In Bitcoin, miners can just join a different pool at a whim. There
> is nothing the attacker can do to stop them. A temporary dishonest majority
> heals relatively well.
> >> >> >
> >> >> > There is another severe disadvantage to this on-chain delegation
> system: every UTXO must indicate which staking account this UTXO belongs to
> so the appropriate share of block rewards can be transferred there.
> >> >> > Being able to associate every UTXO to an account ruins one of the
> main privacy advantages of the UTXO model.
> >> >> > It also grows the size of the blockchain significantly.
> >> >> >
> >> >> > ### "Pure" proof of stake (Algorand)
> >> >> >
> >> >> > Algorand's[4] approach is to only allow online stake to
> participate in the protocol.
> >> >> > Theoretically, This means that keys holding funds have to be
> online in order for them to author blocks when they are chosen.
> >> >> > Of course in reality no one wants to keep their coin holding keys
> online so in Alogorand you can authorize a set of "participation keys"[1]
> that will be used to create blocks on your coin holding key's behalf.
> >> >> > Hopefully you've spotted the problem.
> >> >> > You can send your participation keys to any malicious party with a
> nice website (see random example [2]) offering you a good return.
> >> >> > Damn it's still Proof-of-SquareSpace!
> >> >> > The minor advantage is that at least the participation keys expire
> after a certain amount of time so eventually the SquareSpace attacker will
> lose their hold on consensus.
> >> >> > Importantly there is also less junk on the blockchain because the
> participation keys are delegated off-chain and so are not making as much of
> a mess.
> >> >> >
> >> >> > ### Conclusion
> >> >> >
> >> >> > I don't see a way to get around the conflicting requirement that
> the keys for large amounts of coins should be kept offline but those are
> exactly the coins we need online to make the scheme secure.
> >> >> > If we allow delegation then we open up a new social attack surface
> and it degenerates to Proof-of-SquareSpace.
> >> >> >
> >> >> > For a "digital gold" like system like Bitcoin we optimize for
> simplicity and desperately want to avoid extraneous responsibilities for
> the holder of the coin.
> >> >> > After all, gold is an inert element on the periodic table that
> doesn't confer responsibilities on the holder to maintain the quality of
> all the other bars of gold out there.
> >> >> > Bitcoin feels like this too and in many ways is more inert and
> beautifully boring than gold.
> >> >> > For Bitcoin to succeed I think we need to keep it that way and
> Proof-of-Stake makes everything a bit too exciting.
> >> >> >
> >> >> > I suppose in the end the market will decide what is real digital
> gold and whether these bad technical trade offs are worth being able to say
> it uses less electricity. It goes without saying that making bad technical
> decisions to appease the current political climate is an anathema to
> Bitcoin.
> >> >> >
> >> >> > Would be interested to know if you or others think differently on
> these points.
> >> >> >
> >> >> > [1]:
> https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
> >> >> > [2]: https://staking.staked.us/algorand-staking
> >> >> > [3]: https://eprint.iacr.org/2017/573.pdf
> >> >> > [4]:
> https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
> >> >> > [5]:
> https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf
> >> >> >
> >> >> > Cheers,
> >> >> >
> >> >> > LL
> >> >> >
> >> >> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >> >>
> >> >> >> I think there is a lot of misinformation and bias against Proof
> of Stake. Yes there have been lots of shady coins that use insecure PoS
> mechanisms. Yes there have been massive issues with distribution of PoS
> coins (of course there have also been massive issues with PoW coins as
> well). However, I want to remind everyone that there is a difference
> between "proved to be impossible" and "have not achieved recognized success
> yet". Most of the arguments levied against PoS are out of date or rely on
> unproven assumptions or extrapolation from the analysis of a particular PoS
> system. I certainly don't think we should experiment with bitcoin by
> switching to PoS, but from my research, it seems very likely that there is
> a proof of stake consensus protocol we could build that has substantially
> higher security (cost / capital required to execute an attack) while at the
> same time costing far less resources (which do translate to fees on the
> network) *without* compromising any of the critical security properties
> bitcoin relies on. I think the critical piece of this is the disagreements
> around hardcoded checkpoints, which is a critical piece solving attacks
> that could be levied on a PoS chain, and how that does (or doesn't) affect
> the security model.
> >> >> >>
> >> >> >> @Eric Your proof of stake fallacy seems to be saying that PoS is
> worse when a 51% attack happens. While I agree, I think that line of
> thinking omits important facts:
> >> >> >> * The capital required to 51% attack a PoS chain can be made
> substantially greater than on a PoS chain.
> >> >> >> * The capital the attacker stands to lose can be substantially
> greater as well if the attack is successful.
> >> >> >> * The effectiveness of paying miners to raise the honest fraction
> of miners above 50% may be quite bad.
> >> >> >> * Allowing a 51% attack is already unacceptable. It should be
> considered whether what happens in the case of a 51% may not be
> significantly different. The currency would likely be critically damaged in
> a 51% attack regardless of consensus mechanism.
> >> >> >>
> >> >> >> > Proof-of-stake tends towards oligopolistic control
> >> >> >>
> >> >> >> People repeat this often, but the facts support this. There is no
> centralization pressure in any proof of stake mechanism that I'm aware of.
> IE if you have 10 times as much coin that you use to mint blocks, you
> should expect to earn 10x as much minting revenue - not more than 10x. By
> contrast, proof of work does in fact have clear centralization pressure -
> this is not disputed. Our goal in relation to that is to ensure that the
> centralization pressure remains insignifiant. Proof of work also clearly
> has a lot more barriers to entry than any proof of stake system does. Both
> of these mean the tendency towards oligopolistic control is worse for PoW.
> >> >> >>
> >> >> >> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
> >> >> >>
> >> >> >> I certainly agree. Bitcoin's energy usage at the moment is I
> think quite warranted. However, the question is: can we do substantially
> better. I think if we can, we probably should... eventually.
> >> >> >>
> >> >> >> > Proof of Stake is only resilient to ⅓ of the network
> demonstrating a Byzantine Fault, whilst Proof of Work is resilient up to
> the ½ threshold
> >> >> >>
> >> >> >> I see no mention of this in the pos.pdf you linked to. I'm not
> aware of any proof that all PoS systems have a failure threshold of 1/3. I
> know that staking systems like Casper do in fact have that 1/3 requirement.
> However there are PoS designs that should exceed that up to nearly 50% as
> far as I'm aware. Proof of work is not in fact resilient up to the 1/2
> threshold in the way you would think. IE, if 100% of miners are currently
> honest and have a collective 100 exahashes/s hashpower, an attacker does
> not need to obtain 100 exahashes/s, but actually only needs to accumulate
> 50 exahashes/s. This is because as the attacker accumulates hashpower, it
> drives honest miners out of the market as the difficulty increases to
> beyond what is economically sustainable. Also, its been shown that the best
> proof of work can do is require an attacker to obtain 33% of the hashpower
> because of the selfish mining attack discussed in depth in this paper:
> https://arxiv.org/abs/1311.0243. Together, both of these things reduce
> PoW's security by a factor of about 83% (1 - 50%*33%).
> >> >> >>
> >> >> >> > Proof of Stake requires other trade-offs which are
> incompatible with Bitcoin's objective (to be a trustless digital cash) —
> specifically the famous "security vs. liveness" guarantee
> >> >> >>
> >> >> >> Do you have a good source that talks about why you think proof of
> stake cannot be used for a trustless digital cash?
> >> >> >>
> >> >> >> > You cannot gain tokens without someone choosing to give up
> those coins - a form of permission.
> >> >> >>
> >> >> >> This is not a practical constraint. Just like in mining, some
> nodes may reject you, but there will likely be more that will accept you,
> some sellers may reject you, but most would accept your money as payment
> for bitcoins. I don't think requiring the "permission" of one of millions
> of people in the market can be reasonably considered a "permissioned
> currency".
> >> >> >>
> >> >> >> > 2. Proof of stake must have a trusted means of timestamping to
> regulate overproduction of blocks
> >> >> >>
> >> >> >> Both PoW and PoS could mine/mint blocks twice as fast if everyone
> agreed to double their clock speeds. Both systems rely on an honest
> majority sticking to standard time.
> >> >> >>
> >> >> >>
> >> >> >> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >> >>>
> >> >> >>> Ah sorry, I didn't realize this was, in fact, a different
> thread! :)
> >> >> >>>
> >> >> >>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <
> mike at powx.org> wrote:
> >> >> >>>>
> >> >> >>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the
> BIP itself. PoS, VDFs, and so on are interesting but I guess there are
> other threads going on these topics already where they would be relevant.
> >> >> >>>>
> >> >> >>>> Also, it's important to distinguish between oPoW and these
> other "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't
> alter the core game theory or security assumptions of Hashcash and actually
> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
> >> >> >>>>
> >> >> >>>> Cheers,
> >> >> >>>> Mike
> >> >> >>>>
> >> >> >>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >> >>>>>
> >> >> >>>>> 1. i never suggested vdf's to replace pow.
> >> >> >>>>>
> >> >> >>>>> 2. my suggestion was specifically *in the context of* a working
> >> >> >>>>> proof-of-burn protocol
> >> >> >>>>>
> >> >> >>>>> - vdfs used only for timing (not block height)
> >> >> >>>>> - blind-burned coins of a specific age used to replace proof
> of work
> >> >> >>>>> - the required "work" per block would simply be a competition
> to
> >> >> >>>>> acquire rewards, and so miners would have to burn coins, well
> in
> >> >> >>>>> advance, and hope that their burned coins got rewarded in some
> far
> >> >> >>>>> future
> >> >> >>>>> - the point of burned coins is to mimic, in every meaningful
> way, the
> >> >> >>>>> value gained from proof of work... without some of the security
> >> >> >>>>> drawbacks
> >> >> >>>>> - the miner risks losing all of his burned coins (like all
> miners risk
> >> >> >>>>> losing their work in each block)
> >> >> >>>>> - new burns can't be used
> >> >> >>>>> - old burns age out (like ASICs do)
> >> >> >>>>> - other requirements on burns might be needed to properly
> mirror the
> >> >> >>>>> properties of PoW and the incentives Bitcoin uses to mine
> honestly.
> >> >> >>>>>
> >> >> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf
> system"
> >> >> >>>>> might be more secure in the long run, and that if the entire
> space
> >> >> >>>>> agreed that such an endeavor was worthwhile, a test net could
> be spun
> >> >> >>>>> up, and a hard-fork could be initiated.
> >> >> >>>>>
> >> >> >>>>> 4. i would never suggest such a thing unless i believed it was
> >> >> >>>>> possible that consensus was possible. so no, this is not an
> "alt
> >> >> >>>>> coin"
> >> >> >>>>>
> >> >> >>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <
> zachgrw at gmail.com> wrote:
> >> >> >>>>> >
> >> >> >>>>> > Hi ZmnSCPxj,
> >> >> >>>>> >
> >> >> >>>>> > Please note that I am not suggesting VDFs as a means to save
> energy, but solely as a means to make the time between blocks more constant.
> >> >> >>>>> >
> >> >> >>>>> > Zac
> >> >> >>>>> >
> >> >> >>>>> >
> >> >> >>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <
> ZmnSCPxj at protonmail.com> wrote:
> >> >> >>>>> >>
> >> >> >>>>> >> Good morning Zac,
> >> >> >>>>> >>
> >> >> >>>>> >> > VDFs might enable more constant block times, for instance
> by having a two-step PoW:
> >> >> >>>>> >> >
> >> >> >>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF
> being subject to difficulty adjustments similar to the as-is). As per the
> property of VDFs, miners are able show proof of work.
> >> >> >>>>> >> >
> >> >> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so
> finding a block takes 1 minute on average, again subject to as-is
> difficulty adjustments.
> >> >> >>>>> >> >
> >> >> >>>>> >> > As a result, variation in block times will be greatly
> reduced.
> >> >> >>>>> >>
> >> >> >>>>> >> As I understand it, another weakness of VDFs is that they
> are not inherently progress-free (their sequential nature prevents that;
> they are inherently progress-requiring).
> >> >> >>>>> >>
> >> >> >>>>> >> Thus, a miner which focuses on improving the amount of
> energy that it can pump into the VDF circuitry (by overclocking and
> freezing the circuitry), could potentially get into a winner-takes-all
> situation, possibly leading to even *worse* competition and even *more*
> energy consumption.
> >> >> >>>>> >> After all, if you can start mining 0.1s faster than the
> competition, that is a 0.1s advantage where *only you* can mine *in the
> entire world*.
> >> >> >>>>> >>
> >> >> >>>>> >> Regards,
> >> >> >>>>> >> ZmnSCPxj
> >> >> >>>>> _______________________________________________
> >> >> >>>>> bitcoin-dev mailing list
> >> >> >>>>> bitcoin-dev at lists.linuxfoundation.org
> >> >> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> --
> >> >> >>>> Michael Dubrovsky
> >> >> >>>> Founder; PoWx
> >> >> >>>> www.PoWx.org
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>> Michael Dubrovsky
> >> >> >>> Founder; PoWx
> >> >> >>> www.PoWx.org
> >> >> >>> _______________________________________________
> >> >> >>> bitcoin-dev mailing list
> >> >> >>> bitcoin-dev at lists.linuxfoundation.org
> >> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> bitcoin-dev mailing list
> >> >> >> bitcoin-dev at lists.linuxfoundation.org
> >> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >> >
> >> >> > _______________________________________________
> >> >> > bitcoin-dev mailing list
> >> >> > bitcoin-dev at 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/20210525/f0981968/attachment-0001.html>;

📅 Original date posted:2021-05-24 📝 Original message:Is ...

2023-06-08T00:53:00+02:00

In reply to nevent1q…4rnr
_________________________

📅 Original date posted:2021-05-24
📝 Original message:Is this <https://en.bitcoin.it/wiki/Proof_of_burn>; the kind of proof of
burn you're talking about?

> if i have a choice between two chains, one longer and one shorter, i
can only choose one... deterministically

What prevents you from attempting to mine block 553 on both chains?

> miners have a very strong, long-term, investment in the stability of the
chain.

Yes, but the same can be said of any coin, even ones that do have the
nothing at stake problem. This isn't sufficient tho because the chain is a
common good, and the tragedy of the commons holds for it.

> you burn them to be used at a future particular block height

This sounds exploitable. It seems like an attacker could simply focus all
their burns on a particular set of 6 blocks to double spend, minimizing
their cost of attack.

> i can imagine scenarios where large stakeholders can collude to punish
smaller stakeholders simply to drive them out of business, for example

Are you talking about a 51% attack? This is possible in any decentralized
cryptocurrency.

On Mon, May 24, 2021 at 11:49 AM Erik Aronesty <erik at q32.com> wrote:

> > > your burn investment is always "at stake", any redaction can result in
> a loss-of-burn, because burns can be tied, precisely, to block-heights
> > I'm fuzzy on how proof of burn works.
>
> when you burn coins, you burn them to be used at a future particular
> block height: so if i'm burning for block 553, i can only use them to
> mine block 553. if i have a choice between two chains, one longer
> and one shorter, i can only choose one... deterministically, for that
> burn: the chain with the height 553. if we fix the "lead time" for
> burned coins to be weeks or even months in advance, miners have a very
> strong, long-term, investment in the stability of the chain.
>
> therefore there is no "nothing at stake" problem. it's
> deterministic, so miners have no choice. they can *only* choose the
> transactions that go into the block. they cannot choose which chain
> to mine, and it's time-locked, so rollbacks and instability always
> hurt miners the most.
>
> the "punishment" systems of PoS are "weird at best", certainly
> unproven. i can imagine scenarios where large stakeholders can
> collude to punish smaller stakeholders simply to drive them out of
> business, for example. and then you have to put checks in place to
> prevent that, and more checks for those prevention system...
>
> in PoB, there is no complexity. simpler systems like this are
> typically more secure.
>
> PoB also solves problems caused by "energy dependence", which could
> lead to state monopolies on mining (like the new Bitcoin Mining
> Council). these consortiums, if state sanctioned, could become a
> source of censorship, for example. Since PoB doesn't require you to
> have a live, well-connected node, it's harder to censor & harder to
> trace.
>
> Eliminating this weakness seems to be in the best interests of
> existing stakeholders
>
>
>
>
> On Mon, May 24, 2021 at 4:44 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
> >
> > > proof of burn clearly solves this, since nothing is held online
> >
> > Well.. the coins to be burned need to be online when they're burned. But
> yes, only a small fraction of the total coins need to be online.
> >
> > > your burn investment is always "at stake", any redaction can result in
> a loss-of-burn, because burns can be tied, precisely, to block-heights
> >
> > So you're saying that if say someone tries to mine a block on a shorter
> chain, that requires them to send a transaction burning their coins, and
> that transaction could also be spent on the longest chain, which means
> their coins are burned even if the chain they tried to mine on doesn't win?
> I'm fuzzy on how proof of burn works.
> >
> > > proof of burn can be more secure than proof-of-stake
> >
> > FYI, proof of stake can be done without the "nothing at stake" problem.
> You can simply punish people who mint on shorter chains (by rewarding
> people who publish proofs of this happening on the main chain). In
> quorum-based PoS, you can punish people in the quorum that propose or sign
> multiple blocks for the same height. The "nothing at stake" problem is a
> solved problem at this point for PoS.
> >
> >
> >
> > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty <erik at q32.com> wrote:
> >>
> >> > I don't see a way to get around the conflicting requirement that the
> keys for large amounts of coins should be kept offline but those are
> exactly the coins we need online to make the scheme secure.
> >>
> >> proof of burn clearly solves this, since nothing is held online
> >>
> >> > how does proof of burn solve the "nothing at stake" problem in your
> view?
> >>
> >> definition of nothing at stake: in the event of a fork, whether the
> >> fork is accidental or a malicious, the optimal strategy for any miner
> >> is to mine on every chain, so that the miner gets their reward no
> >> matter which fork wins. indeed in proof-of-stake, the proofs are
> >> published on the very chains mines, so the incentive is magnified.
> >>
> >> in proof-of-burn, your burn investment is always "at stake", any
> >> redaction can result in a loss-of-burn, because burns can be tied,
> >> precisely, to block-heights
> >>
> >> as a result, miners no longer have an incentive to mine all chains
> >>
> >> in this way proof of burn can be more secure than proof-of-stake, and
> >> even more secure than proof of work
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >
> >>
> >> On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >
> >> > Hi Billy,
> >> >
> >> > I was going to write a post which started by dismissing many of the
> weak arguments that are made against PoS made in this thread and elsewhere.
> >> > Although I don't agree with all your points you have done a decent
> job here so I'll focus on the second part: why I think Proof-of-Stake is
> inappropriate for a Bitcoin-like system.
> >> >
> >> > Proof of stake is not fit for purpose for a global settlement layer
> in a pure digital asset (i.e. "digital gold") which is what Bitcoin is
> trying to be.
> >> > PoS necessarily gives responsibilities to the holders of coins that
> they do not want and cannot handle.
> >> > In Bitcoin, large unsophisticated coin holders can put their coins in
> cold storage without a second thought given to the health of the underlying
> ledger.
> >> > As much as hardcore Bitcoiners try to convince them to run their own
> node, most don't, and that's perfectly acceptable.
> >> > At no point do their personal decisions affect the underlying
> consensus -- it only affects their personal security assurance (not that of
> the system itself).
> >> > In PoS systems this clean separation of responsibilities does not
> exist.
> >> >
> >> > I think that the more rigorously studied PoS protocols will work fine
> within the security claims made in their papers.
> >> > People who believe that these protocols are destined for catastrophic
> consensus failure are certainly in for a surprise.
> >> > But the devil is in the detail.
> >> > Let's look at what the implications of using the leading proof of
> stake protocols would have on Bitcoin:
> >> >
> >> > ### Proof of SquareSpace (Cardano, Polkdadot)
> >> >
> >> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an
> inbuilt on-chain delegation system[5].
> >> > In these protocols, coin holders who do not want to run their node
> with their hot keys in it delegate it to a "Stake Pool".
> >> > I call the resulting system Proof-of-SquareSpace since most will
> choose a pool by looking around for one with a nice website and offering
> the largest share of the block reward.
> >> > On the surface this might sound no different than someone with an
> mining rig shopping around for a good mining pool but there are crucial
> differences:
> >> >
> >> > 1. The person making the decision is forced into it just because they
> own the currency -- someone with a mining rig has purchased it with the
> intent to make profit by participating in consensus.
> >> >
> >> > 2. When you join a mining pool your systems are very much still
> online. You are just partaking in a pool to reduce your profit variance.
> You still see every block that you help create and *you never help create a
> block without seeing it first*.
> >> >
> >> > 3. If by SquareSpace sybil attack you gain a dishonest majority and
> start censoring transactions how are the users meant to redelegate their
> stake to honest pools?
> >> > I guess they can just send a transaction delegating to another
> pool...oh wait I guess that might be censored too! This seems really really
> bad.
> >> > In Bitcoin, miners can just join a different pool at a whim. There is
> nothing the attacker can do to stop them. A temporary dishonest majority
> heals relatively well.
> >> >
> >> > There is another severe disadvantage to this on-chain delegation
> system: every UTXO must indicate which staking account this UTXO belongs to
> so the appropriate share of block rewards can be transferred there.
> >> > Being able to associate every UTXO to an account ruins one of the
> main privacy advantages of the UTXO model.
> >> > It also grows the size of the blockchain significantly.
> >> >
> >> > ### "Pure" proof of stake (Algorand)
> >> >
> >> > Algorand's[4] approach is to only allow online stake to participate
> in the protocol.
> >> > Theoretically, This means that keys holding funds have to be online
> in order for them to author blocks when they are chosen.
> >> > Of course in reality no one wants to keep their coin holding keys
> online so in Alogorand you can authorize a set of "participation keys"[1]
> that will be used to create blocks on your coin holding key's behalf.
> >> > Hopefully you've spotted the problem.
> >> > You can send your participation keys to any malicious party with a
> nice website (see random example [2]) offering you a good return.
> >> > Damn it's still Proof-of-SquareSpace!
> >> > The minor advantage is that at least the participation keys expire
> after a certain amount of time so eventually the SquareSpace attacker will
> lose their hold on consensus.
> >> > Importantly there is also less junk on the blockchain because the
> participation keys are delegated off-chain and so are not making as much of
> a mess.
> >> >
> >> > ### Conclusion
> >> >
> >> > I don't see a way to get around the conflicting requirement that the
> keys for large amounts of coins should be kept offline but those are
> exactly the coins we need online to make the scheme secure.
> >> > If we allow delegation then we open up a new social attack surface
> and it degenerates to Proof-of-SquareSpace.
> >> >
> >> > For a "digital gold" like system like Bitcoin we optimize for
> simplicity and desperately want to avoid extraneous responsibilities for
> the holder of the coin.
> >> > After all, gold is an inert element on the periodic table that
> doesn't confer responsibilities on the holder to maintain the quality of
> all the other bars of gold out there.
> >> > Bitcoin feels like this too and in many ways is more inert and
> beautifully boring than gold.
> >> > For Bitcoin to succeed I think we need to keep it that way and
> Proof-of-Stake makes everything a bit too exciting.
> >> >
> >> > I suppose in the end the market will decide what is real digital gold
> and whether these bad technical trade offs are worth being able to say it
> uses less electricity. It goes without saying that making bad technical
> decisions to appease the current political climate is an anathema to
> Bitcoin.
> >> >
> >> > Would be interested to know if you or others think differently on
> these points.
> >> >
> >> > [1]:
> https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
> >> > [2]: https://staking.staked.us/algorand-staking
> >> > [3]: https://eprint.iacr.org/2017/573.pdf
> >> > [4]:
> https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
> >> > [5]:
> https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf
> >> >
> >> > Cheers,
> >> >
> >> > LL
> >> >
> >> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >>
> >> >> I think there is a lot of misinformation and bias against Proof of
> Stake. Yes there have been lots of shady coins that use insecure PoS
> mechanisms. Yes there have been massive issues with distribution of PoS
> coins (of course there have also been massive issues with PoW coins as
> well). However, I want to remind everyone that there is a difference
> between "proved to be impossible" and "have not achieved recognized success
> yet". Most of the arguments levied against PoS are out of date or rely on
> unproven assumptions or extrapolation from the analysis of a particular PoS
> system. I certainly don't think we should experiment with bitcoin by
> switching to PoS, but from my research, it seems very likely that there is
> a proof of stake consensus protocol we could build that has substantially
> higher security (cost / capital required to execute an attack) while at the
> same time costing far less resources (which do translate to fees on the
> network) *without* compromising any of the critical security properties
> bitcoin relies on. I think the critical piece of this is the disagreements
> around hardcoded checkpoints, which is a critical piece solving attacks
> that could be levied on a PoS chain, and how that does (or doesn't) affect
> the security model.
> >> >>
> >> >> @Eric Your proof of stake fallacy seems to be saying that PoS is
> worse when a 51% attack happens. While I agree, I think that line of
> thinking omits important facts:
> >> >> * The capital required to 51% attack a PoS chain can be made
> substantially greater than on a PoS chain.
> >> >> * The capital the attacker stands to lose can be substantially
> greater as well if the attack is successful.
> >> >> * The effectiveness of paying miners to raise the honest fraction of
> miners above 50% may be quite bad.
> >> >> * Allowing a 51% attack is already unacceptable. It should be
> considered whether what happens in the case of a 51% may not be
> significantly different. The currency would likely be critically damaged in
> a 51% attack regardless of consensus mechanism.
> >> >>
> >> >> > Proof-of-stake tends towards oligopolistic control
> >> >>
> >> >> People repeat this often, but the facts support this. There is no
> centralization pressure in any proof of stake mechanism that I'm aware of.
> IE if you have 10 times as much coin that you use to mint blocks, you
> should expect to earn 10x as much minting revenue - not more than 10x. By
> contrast, proof of work does in fact have clear centralization pressure -
> this is not disputed. Our goal in relation to that is to ensure that the
> centralization pressure remains insignifiant. Proof of work also clearly
> has a lot more barriers to entry than any proof of stake system does. Both
> of these mean the tendency towards oligopolistic control is worse for PoW.
> >> >>
> >> >> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
> >> >>
> >> >> I certainly agree. Bitcoin's energy usage at the moment is I think
> quite warranted. However, the question is: can we do substantially better.
> I think if we can, we probably should... eventually.
> >> >>
> >> >> > Proof of Stake is only resilient to ⅓ of the network demonstrating
> a Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
> >> >>
> >> >> I see no mention of this in the pos.pdf you linked to. I'm not aware
> of any proof that all PoS systems have a failure threshold of 1/3. I know
> that staking systems like Casper do in fact have that 1/3 requirement.
> However there are PoS designs that should exceed that up to nearly 50% as
> far as I'm aware. Proof of work is not in fact resilient up to the 1/2
> threshold in the way you would think. IE, if 100% of miners are currently
> honest and have a collective 100 exahashes/s hashpower, an attacker does
> not need to obtain 100 exahashes/s, but actually only needs to accumulate
> 50 exahashes/s. This is because as the attacker accumulates hashpower, it
> drives honest miners out of the market as the difficulty increases to
> beyond what is economically sustainable. Also, its been shown that the best
> proof of work can do is require an attacker to obtain 33% of the hashpower
> because of the selfish mining attack discussed in depth in this paper:
> https://arxiv.org/abs/1311.0243. Together, both of these things reduce
> PoW's security by a factor of about 83% (1 - 50%*33%).
> >> >>
> >> >> > Proof of Stake requires other trade-offs which are incompatible
> with Bitcoin's objective (to be a trustless digital cash) — specifically
> the famous "security vs. liveness" guarantee
> >> >>
> >> >> Do you have a good source that talks about why you think proof of
> stake cannot be used for a trustless digital cash?
> >> >>
> >> >> > You cannot gain tokens without someone choosing to give up those
> coins - a form of permission.
> >> >>
> >> >> This is not a practical constraint. Just like in mining, some nodes
> may reject you, but there will likely be more that will accept you, some
> sellers may reject you, but most would accept your money as payment for
> bitcoins. I don't think requiring the "permission" of one of millions of
> people in the market can be reasonably considered a "permissioned currency".
> >> >>
> >> >> > 2. Proof of stake must have a trusted means of timestamping to
> regulate overproduction of blocks
> >> >>
> >> >> Both PoW and PoS could mine/mint blocks twice as fast if everyone
> agreed to double their clock speeds. Both systems rely on an honest
> majority sticking to standard time.
> >> >>
> >> >>
> >> >> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >>>
> >> >>> Ah sorry, I didn't realize this was, in fact, a different thread! :)
> >> >>>
> >> >>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org>
> wrote:
> >> >>>>
> >> >>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP
> itself. PoS, VDFs, and so on are interesting but I guess there are other
> threads going on these topics already where they would be relevant.
> >> >>>>
> >> >>>> Also, it's important to distinguish between oPoW and these other
> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
> the core game theory or security assumptions of Hashcash and actually
> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
> >> >>>>
> >> >>>> Cheers,
> >> >>>> Mike
> >> >>>>
> >> >>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >>>>>
> >> >>>>> 1. i never suggested vdf's to replace pow.
> >> >>>>>
> >> >>>>> 2. my suggestion was specifically *in the context of* a working
> >> >>>>> proof-of-burn protocol
> >> >>>>>
> >> >>>>> - vdfs used only for timing (not block height)
> >> >>>>> - blind-burned coins of a specific age used to replace proof of
> work
> >> >>>>> - the required "work" per block would simply be a competition to
> >> >>>>> acquire rewards, and so miners would have to burn coins, well in
> >> >>>>> advance, and hope that their burned coins got rewarded in some far
> >> >>>>> future
> >> >>>>> - the point of burned coins is to mimic, in every meaningful way,
> the
> >> >>>>> value gained from proof of work... without some of the security
> >> >>>>> drawbacks
> >> >>>>> - the miner risks losing all of his burned coins (like all miners
> risk
> >> >>>>> losing their work in each block)
> >> >>>>> - new burns can't be used
> >> >>>>> - old burns age out (like ASICs do)
> >> >>>>> - other requirements on burns might be needed to properly mirror
> the
> >> >>>>> properties of PoW and the incentives Bitcoin uses to mine
> honestly.
> >> >>>>>
> >> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
> >> >>>>> might be more secure in the long run, and that if the entire space
> >> >>>>> agreed that such an endeavor was worthwhile, a test net could be
> spun
> >> >>>>> up, and a hard-fork could be initiated.
> >> >>>>>
> >> >>>>> 4. i would never suggest such a thing unless i believed it was
> >> >>>>> possible that consensus was possible. so no, this is not an "alt
> >> >>>>> coin"
> >> >>>>>
> >> >>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com>
> wrote:
> >> >>>>> >
> >> >>>>> > Hi ZmnSCPxj,
> >> >>>>> >
> >> >>>>> > Please note that I am not suggesting VDFs as a means to save
> energy, but solely as a means to make the time between blocks more constant.
> >> >>>>> >
> >> >>>>> > Zac
> >> >>>>> >
> >> >>>>> >
> >> >>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> >> >>>>> >>
> >> >>>>> >> Good morning Zac,
> >> >>>>> >>
> >> >>>>> >> > VDFs might enable more constant block times, for instance by
> having a two-step PoW:
> >> >>>>> >> >
> >> >>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being
> subject to difficulty adjustments similar to the as-is). As per the
> property of VDFs, miners are able show proof of work.
> >> >>>>> >> >
> >> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so
> finding a block takes 1 minute on average, again subject to as-is
> difficulty adjustments.
> >> >>>>> >> >
> >> >>>>> >> > As a result, variation in block times will be greatly
> reduced.
> >> >>>>> >>
> >> >>>>> >> As I understand it, another weakness of VDFs is that they are
> not inherently progress-free (their sequential nature prevents that; they
> are inherently progress-requiring).
> >> >>>>> >>
> >> >>>>> >> Thus, a miner which focuses on improving the amount of energy
> that it can pump into the VDF circuitry (by overclocking and freezing the
> circuitry), could potentially get into a winner-takes-all situation,
> possibly leading to even *worse* competition and even *more* energy
> consumption.
> >> >>>>> >> After all, if you can start mining 0.1s faster than the
> competition, that is a 0.1s advantage where *only you* can mine *in the
> entire world*.
> >> >>>>> >>
> >> >>>>> >> Regards,
> >> >>>>> >> ZmnSCPxj
> >> >>>>> _______________________________________________
> >> >>>>> bitcoin-dev mailing list
> >> >>>>> bitcoin-dev at lists.linuxfoundation.org
> >> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> Michael Dubrovsky
> >> >>>> Founder; PoWx
> >> >>>> www.PoWx.org
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Michael Dubrovsky
> >> >>> Founder; PoWx
> >> >>> www.PoWx.org
> >> >>> _______________________________________________
> >> >>> bitcoin-dev mailing list
> >> >>> bitcoin-dev at lists.linuxfoundation.org
> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >>
> >> >> _______________________________________________
> >> >> bitcoin-dev mailing list
> >> >> bitcoin-dev at lists.linuxfoundation.org
> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev at 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/20210524/8f5565cc/attachment-0001.html>;

📅 Original date posted:2021-05-24 📝 Original message:> ...

2023-06-08T00:52:57+02:00

In reply to nevent1q…2swx
_________________________

📅 Original date posted:2021-05-24
📝 Original message:> proof of burn clearly solves this, since nothing is held online

Well.. the coins to be burned need to be online when they're burned. But
yes, only a small fraction of the total coins need to be online.

> your burn investment is always "at stake", any redaction can result in a
loss-of-burn, because burns can be tied, precisely, to block-heights

So you're saying that if say someone tries to mine a block on a shorter
chain, that requires them to send a transaction burning their coins, and
that transaction could also be spent on the longest chain, which means
their coins are burned even if the chain they tried to mine on doesn't win?
I'm fuzzy on how proof of burn works.

> proof of burn can be more secure than proof-of-stake

FYI, proof of stake can be done without the "nothing at stake" problem. You
can simply punish people who mint on shorter chains (by rewarding people
who publish proofs of this happening on the main chain). In quorum-based
PoS, you can punish people in the quorum that propose or sign multiple
blocks for the same height. The "nothing at stake" problem is a solved
problem at this point for PoS.

On Mon, May 24, 2021 at 3:47 AM Erik Aronesty <erik at q32.com> wrote:

> > I don't see a way to get around the conflicting requirement that the
> keys for large amounts of coins should be kept offline but those are
> exactly the coins we need online to make the scheme secure.
>
> proof of burn clearly solves this, since nothing is held online
>
> > how does proof of burn solve the "nothing at stake" problem in your
> view?
>
> definition of nothing at stake: in the event of a fork, whether the
> fork is accidental or a malicious, the optimal strategy for any miner
> is to mine on every chain, so that the miner gets their reward no
> matter which fork wins. indeed in proof-of-stake, the proofs are
> published on the very chains mines, so the incentive is magnified.
>
> in proof-of-burn, your burn investment is always "at stake", any
> redaction can result in a loss-of-burn, because burns can be tied,
> precisely, to block-heights
>
> as a result, miners no longer have an incentive to mine all chains
>
> in this way proof of burn can be more secure than proof-of-stake, and
> even more secure than proof of work
>
>
>
>
>
>
>
> >
>
> On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Hi Billy,
> >
> > I was going to write a post which started by dismissing many of the weak
> arguments that are made against PoS made in this thread and elsewhere.
> > Although I don't agree with all your points you have done a decent job
> here so I'll focus on the second part: why I think Proof-of-Stake is
> inappropriate for a Bitcoin-like system.
> >
> > Proof of stake is not fit for purpose for a global settlement layer in a
> pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to
> be.
> > PoS necessarily gives responsibilities to the holders of coins that they
> do not want and cannot handle.
> > In Bitcoin, large unsophisticated coin holders can put their coins in
> cold storage without a second thought given to the health of the underlying
> ledger.
> > As much as hardcore Bitcoiners try to convince them to run their own
> node, most don't, and that's perfectly acceptable.
> > At no point do their personal decisions affect the underlying consensus
> -- it only affects their personal security assurance (not that of the
> system itself).
> > In PoS systems this clean separation of responsibilities does not exist.
> >
> > I think that the more rigorously studied PoS protocols will work fine
> within the security claims made in their papers.
> > People who believe that these protocols are destined for catastrophic
> consensus failure are certainly in for a surprise.
> > But the devil is in the detail.
> > Let's look at what the implications of using the leading proof of stake
> protocols would have on Bitcoin:
> >
> > ### Proof of SquareSpace (Cardano, Polkdadot)
> >
> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an
> inbuilt on-chain delegation system[5].
> > In these protocols, coin holders who do not want to run their node with
> their hot keys in it delegate it to a "Stake Pool".
> > I call the resulting system Proof-of-SquareSpace since most will choose
> a pool by looking around for one with a nice website and offering the
> largest share of the block reward.
> > On the surface this might sound no different than someone with an mining
> rig shopping around for a good mining pool but there are crucial
> differences:
> >
> > 1. The person making the decision is forced into it just because they
> own the currency -- someone with a mining rig has purchased it with the
> intent to make profit by participating in consensus.
> >
> > 2. When you join a mining pool your systems are very much still online.
> You are just partaking in a pool to reduce your profit variance. You still
> see every block that you help create and *you never help create a block
> without seeing it first*.
> >
> > 3. If by SquareSpace sybil attack you gain a dishonest majority and
> start censoring transactions how are the users meant to redelegate their
> stake to honest pools?
> > I guess they can just send a transaction delegating to another pool...oh
> wait I guess that might be censored too! This seems really really bad.
> > In Bitcoin, miners can just join a different pool at a whim. There is
> nothing the attacker can do to stop them. A temporary dishonest majority
> heals relatively well.
> >
> > There is another severe disadvantage to this on-chain delegation system:
> every UTXO must indicate which staking account this UTXO belongs to so the
> appropriate share of block rewards can be transferred there.
> > Being able to associate every UTXO to an account ruins one of the main
> privacy advantages of the UTXO model.
> > It also grows the size of the blockchain significantly.
> >
> > ### "Pure" proof of stake (Algorand)
> >
> > Algorand's[4] approach is to only allow online stake to participate in
> the protocol.
> > Theoretically, This means that keys holding funds have to be online in
> order for them to author blocks when they are chosen.
> > Of course in reality no one wants to keep their coin holding keys online
> so in Alogorand you can authorize a set of "participation keys"[1] that
> will be used to create blocks on your coin holding key's behalf.
> > Hopefully you've spotted the problem.
> > You can send your participation keys to any malicious party with a nice
> website (see random example [2]) offering you a good return.
> > Damn it's still Proof-of-SquareSpace!
> > The minor advantage is that at least the participation keys expire after
> a certain amount of time so eventually the SquareSpace attacker will lose
> their hold on consensus.
> > Importantly there is also less junk on the blockchain because the
> participation keys are delegated off-chain and so are not making as much of
> a mess.
> >
> > ### Conclusion
> >
> > I don't see a way to get around the conflicting requirement that the
> keys for large amounts of coins should be kept offline but those are
> exactly the coins we need online to make the scheme secure.
> > If we allow delegation then we open up a new social attack surface and
> it degenerates to Proof-of-SquareSpace.
> >
> > For a "digital gold" like system like Bitcoin we optimize for simplicity
> and desperately want to avoid extraneous responsibilities for the holder of
> the coin.
> > After all, gold is an inert element on the periodic table that doesn't
> confer responsibilities on the holder to maintain the quality of all the
> other bars of gold out there.
> > Bitcoin feels like this too and in many ways is more inert and
> beautifully boring than gold.
> > For Bitcoin to succeed I think we need to keep it that way and
> Proof-of-Stake makes everything a bit too exciting.
> >
> > I suppose in the end the market will decide what is real digital gold
> and whether these bad technical trade offs are worth being able to say it
> uses less electricity. It goes without saying that making bad technical
> decisions to appease the current political climate is an anathema to
> Bitcoin.
> >
> > Would be interested to know if you or others think differently on these
> points.
> >
> > [1]:
> https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
> > [2]: https://staking.staked.us/algorand-staking
> > [3]: https://eprint.iacr.org/2017/573.pdf
> > [4]:
> https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
> > [5]:
> https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf
> >
> > Cheers,
> >
> > LL
> >
> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> I think there is a lot of misinformation and bias against Proof of
> Stake. Yes there have been lots of shady coins that use insecure PoS
> mechanisms. Yes there have been massive issues with distribution of PoS
> coins (of course there have also been massive issues with PoW coins as
> well). However, I want to remind everyone that there is a difference
> between "proved to be impossible" and "have not achieved recognized success
> yet". Most of the arguments levied against PoS are out of date or rely on
> unproven assumptions or extrapolation from the analysis of a particular PoS
> system. I certainly don't think we should experiment with bitcoin by
> switching to PoS, but from my research, it seems very likely that there is
> a proof of stake consensus protocol we could build that has substantially
> higher security (cost / capital required to execute an attack) while at the
> same time costing far less resources (which do translate to fees on the
> network) *without* compromising any of the critical security properties
> bitcoin relies on. I think the critical piece of this is the disagreements
> around hardcoded checkpoints, which is a critical piece solving attacks
> that could be levied on a PoS chain, and how that does (or doesn't) affect
> the security model.
> >>
> >> @Eric Your proof of stake fallacy seems to be saying that PoS is worse
> when a 51% attack happens. While I agree, I think that line of thinking
> omits important facts:
> >> * The capital required to 51% attack a PoS chain can be made
> substantially greater than on a PoS chain.
> >> * The capital the attacker stands to lose can be substantially greater
> as well if the attack is successful.
> >> * The effectiveness of paying miners to raise the honest fraction of
> miners above 50% may be quite bad.
> >> * Allowing a 51% attack is already unacceptable. It should be
> considered whether what happens in the case of a 51% may not be
> significantly different. The currency would likely be critically damaged in
> a 51% attack regardless of consensus mechanism.
> >>
> >> > Proof-of-stake tends towards oligopolistic control
> >>
> >> People repeat this often, but the facts support this. There is no
> centralization pressure in any proof of stake mechanism that I'm aware of.
> IE if you have 10 times as much coin that you use to mint blocks, you
> should expect to earn 10x as much minting revenue - not more than 10x. By
> contrast, proof of work does in fact have clear centralization pressure -
> this is not disputed. Our goal in relation to that is to ensure that the
> centralization pressure remains insignifiant. Proof of work also clearly
> has a lot more barriers to entry than any proof of stake system does. Both
> of these mean the tendency towards oligopolistic control is worse for PoW.
> >>
> >> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
> >>
> >> I certainly agree. Bitcoin's energy usage at the moment is I think
> quite warranted. However, the question is: can we do substantially better.
> I think if we can, we probably should... eventually.
> >>
> >> > Proof of Stake is only resilient to ⅓ of the network demonstrating a
> Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
> >>
> >> I see no mention of this in the pos.pdf you linked to. I'm not aware of
> any proof that all PoS systems have a failure threshold of 1/3. I know that
> staking systems like Casper do in fact have that 1/3 requirement. However
> there are PoS designs that should exceed that up to nearly 50% as far as
> I'm aware. Proof of work is not in fact resilient up to the 1/2 threshold
> in the way you would think. IE, if 100% of miners are currently honest and
> have a collective 100 exahashes/s hashpower, an attacker does not need to
> obtain 100 exahashes/s, but actually only needs to accumulate 50
> exahashes/s. This is because as the attacker accumulates hashpower, it
> drives honest miners out of the market as the difficulty increases to
> beyond what is economically sustainable. Also, its been shown that the best
> proof of work can do is require an attacker to obtain 33% of the hashpower
> because of the selfish mining attack discussed in depth in this paper:
> https://arxiv.org/abs/1311.0243. Together, both of these things reduce
> PoW's security by a factor of about 83% (1 - 50%*33%).
> >>
> >> > Proof of Stake requires other trade-offs which are incompatible with
> Bitcoin's objective (to be a trustless digital cash) — specifically the
> famous "security vs. liveness" guarantee
> >>
> >> Do you have a good source that talks about why you think proof of stake
> cannot be used for a trustless digital cash?
> >>
> >> > You cannot gain tokens without someone choosing to give up those
> coins - a form of permission.
> >>
> >> This is not a practical constraint. Just like in mining, some nodes may
> reject you, but there will likely be more that will accept you, some
> sellers may reject you, but most would accept your money as payment for
> bitcoins. I don't think requiring the "permission" of one of millions of
> people in the market can be reasonably considered a "permissioned currency".
> >>
> >> > 2. Proof of stake must have a trusted means of timestamping to
> regulate overproduction of blocks
> >>
> >> Both PoW and PoS could mine/mint blocks twice as fast if everyone
> agreed to double their clock speeds. Both systems rely on an honest
> majority sticking to standard time.
> >>
> >>
> >> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> Ah sorry, I didn't realize this was, in fact, a different thread! :)
> >>>
> >>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org>
> wrote:
> >>>>
> >>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP
> itself. PoS, VDFs, and so on are interesting but I guess there are other
> threads going on these topics already where they would be relevant.
> >>>>
> >>>> Also, it's important to distinguish between oPoW and these other
> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
> the core game theory or security assumptions of Hashcash and actually
> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
> >>>>
> >>>> Cheers,
> >>>> Mike
> >>>>
> >>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>>
> >>>>> 1. i never suggested vdf's to replace pow.
> >>>>>
> >>>>> 2. my suggestion was specifically *in the context of* a working
> >>>>> proof-of-burn protocol
> >>>>>
> >>>>> - vdfs used only for timing (not block height)
> >>>>> - blind-burned coins of a specific age used to replace proof of work
> >>>>> - the required "work" per block would simply be a competition to
> >>>>> acquire rewards, and so miners would have to burn coins, well in
> >>>>> advance, and hope that their burned coins got rewarded in some far
> >>>>> future
> >>>>> - the point of burned coins is to mimic, in every meaningful way, the
> >>>>> value gained from proof of work... without some of the security
> >>>>> drawbacks
> >>>>> - the miner risks losing all of his burned coins (like all miners
> risk
> >>>>> losing their work in each block)
> >>>>> - new burns can't be used
> >>>>> - old burns age out (like ASICs do)
> >>>>> - other requirements on burns might be needed to properly mirror the
> >>>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
> >>>>>
> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
> >>>>> might be more secure in the long run, and that if the entire space
> >>>>> agreed that such an endeavor was worthwhile, a test net could be spun
> >>>>> up, and a hard-fork could be initiated.
> >>>>>
> >>>>> 4. i would never suggest such a thing unless i believed it was
> >>>>> possible that consensus was possible. so no, this is not an "alt
> >>>>> coin"
> >>>>>
> >>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com>
> wrote:
> >>>>> >
> >>>>> > Hi ZmnSCPxj,
> >>>>> >
> >>>>> > Please note that I am not suggesting VDFs as a means to save
> energy, but solely as a means to make the time between blocks more constant.
> >>>>> >
> >>>>> > Zac
> >>>>> >
> >>>>> >
> >>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> >>>>> >>
> >>>>> >> Good morning Zac,
> >>>>> >>
> >>>>> >> > VDFs might enable more constant block times, for instance by
> having a two-step PoW:
> >>>>> >> >
> >>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being
> subject to difficulty adjustments similar to the as-is). As per the
> property of VDFs, miners are able show proof of work.
> >>>>> >> >
> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a
> block takes 1 minute on average, again subject to as-is difficulty
> adjustments.
> >>>>> >> >
> >>>>> >> > As a result, variation in block times will be greatly reduced.
> >>>>> >>
> >>>>> >> As I understand it, another weakness of VDFs is that they are not
> inherently progress-free (their sequential nature prevents that; they are
> inherently progress-requiring).
> >>>>> >>
> >>>>> >> Thus, a miner which focuses on improving the amount of energy
> that it can pump into the VDF circuitry (by overclocking and freezing the
> circuitry), could potentially get into a winner-takes-all situation,
> possibly leading to even *worse* competition and even *more* energy
> consumption.
> >>>>> >> After all, if you can start mining 0.1s faster than the
> competition, that is a 0.1s advantage where *only you* can mine *in the
> entire world*.
> >>>>> >>
> >>>>> >> Regards,
> >>>>> >> ZmnSCPxj
> >>>>> _______________________________________________
> >>>>> bitcoin-dev mailing list
> >>>>> bitcoin-dev at lists.linuxfoundation.org
> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Michael Dubrovsky
> >>>> Founder; PoWx
> >>>> www.PoWx.org
> >>>
> >>>
> >>>
> >>> --
> >>> Michael Dubrovsky
> >>> Founder; PoWx
> >>> www.PoWx.org
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at 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/20210524/4796a55c/attachment-0001.html>;

📅 Original date posted:2021-05-23 📝 Original message:I made ...

2023-06-08T00:52:55+02:00

In reply to nevent1q…j8hw
_________________________

📅 Original date posted:2021-05-23
📝 Original message:I made a couple typos and mistakes in my couple previous emails:

* "People repeat this often, but the facts support this" -> "the facts *don't
*support this"
* "Together, both of these things reduce PoW's security by a factor of
about 83% (1 - 50%*33%)." -> "factor of about 83% (1 - 50%**(50% - 33%)/50%*)."
(I made a mistake that happened to come out to an almost identical result
coincidentally).
* "And pools could simply require full custody of the coins." -> "*But *pools
could..."

On Sun, May 23, 2021 at 9:10 AM Billy Tetrud <billy.tetrud at gmail.com> wrote:

> @Lloyd
>
> > Proof-of-SquareSpace
>
> I agree with your points about delegated proof of stake. I wrote my own
> critique about that
> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#analysis-of-delegated-proof-of-stake-dpos>; as
> well. And your point, that other forms of PoS devolve to DPoS by virtue of
> people wanting to actively mint blocks without exposing their coins in hot
> wallets, is an interesting one.
>
> > how are the users meant to redelegate their stake to honest pools?
>
> This could be mitigated partially if delegation didn't require any kind of
> blockchain transaction. For example, users could simply send a signed
> message saying "this other key can mint blocks with my coins", and then
> minting a block using those coins would require presenting the delegation
> signature. This only partially mitigates the problem since the dishonest
> pool would still be able to use those coins as well, so it would be a race
> at that point. Still better than nothing. And pools could simply require
> full custody of the coins.
>
> From what you mentioned, it sounds like maybe Algorand does something
> similar to this.
>
> > I don't see a way to get around the conflicting requirement that the
> keys for large amounts of coins should be kept offline but those are
> exactly the coins we need online to make the scheme secure.
>
> There are a couple solutions you didn't mention. One is your "traditional"
> locked-stake kind of systems, where participants are required to lock their
> stake for long periods of time. Since normal users aren't likely to want to
> do this, it will likely be left to more sophisticated stakers likely
> staking very large amounts.
>
> Both mechanisms you mentioned allow delegation, and it might seem like
> maybe there'd be a way to disallow delegation, however since users can
> always give custody of their coins to trusted pools, that would be a
> delgation mechanism of last resort that can't be removed. So you can do
> things that make it hard (for both users and pool operators) to delegate
> trustlessly, but you can't get rid of the ability to delgate entirely.
>
> In general, the situations where I see people not pooling are:
>
> A. They are entirely prevented by technical means. It seems reasonably
> clear that this is impossible.
> B. The downsides are more than unsophisticated users are willing to incur
> (eg stake locking).
> C. The rewards are so small that it isn't worth it for people to put in
> much effort to gain them.
> D. The rewards are so frequent that pooling is unnecessary.
>
> B excludes a lot of people from being able to help secure the chain, but
> this is not materially different from PoW mining in that regard. D is a bit
> border line. With 1 billion people attempting to participate and 10 minute
> blocks, 232 people would need to share the block reward in order to expect
> a payout on average once per month. With 8 billion people that would turn
> into more like 1700 people. This seems potentially doable (eg via cosigner
> requirements on minted blocks), but it is a lot of participants per block.
>
> I think options C and D combined would be an ideal approach here. Because
> minting uses very few real resources, minting could be pretty much have
> arbitrarily low ongoing costs. This means fees can be low and blocks can
> have low payouts. If the reward was low and people could expect to see it
> once every couple years, people could simply treat it like a lottery. Great
> if they win it now, but nothing that anyone needs to rely on (which would
> incentivize the pools to reduce variance that we want to avoid). If there
> is no locked stake or other major barriers in place to minting blocks, that
> would also help avoid the compultion to use a pool.
>
> In any case, you bring up good points, and they certainly complicate the
> issue. By the way, if you were confused as to what VPoS was in the section
> from my above link, this might satisfy your curiosity
> <https://github.com/fresheneesz/ValidatedProofOfStake>;.
>
> Cheers
>
>
>
>
> On Sat, May 22, 2021 at 5:41 PM Lloyd Fournier <lloyd.fourn at gmail.com>
> wrote:
>
>> Hi Billy,
>>
>> I was going to write a post which started by dismissing many of the weak
>> arguments that are made against PoS made in this thread and elsewhere.
>> Although I don't agree with all your points you have done a decent job
>> here so I'll focus on the second part: why I think Proof-of-Stake is
>> inappropriate for a Bitcoin-like system.
>>
>> Proof of stake is not fit for purpose for a global settlement layer in a
>> pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to
>> be.
>> PoS necessarily gives responsibilities to the holders of coins that they
>> do not want and cannot handle.
>> In Bitcoin, large unsophisticated coin holders can put their coins in
>> cold storage without a second thought given to the health of the underlying
>> ledger.
>> As much as hardcore Bitcoiners try to convince them to run their own
>> node, most don't, and that's perfectly acceptable.
>> At no point do their personal decisions affect the underlying consensus
>> -- it only affects their personal security assurance (not that of the
>> system itself).
>> In PoS systems this clean separation of responsibilities does not exist.
>>
>> I think that the more rigorously studied PoS protocols will work fine
>> within the security claims made in their papers.
>> People who believe that these protocols are destined for catastrophic
>> consensus failure are certainly in for a surprise.
>> But the devil is in the detail.
>> Let's look at what the implications of using the leading proof of stake
>> protocols would have on Bitcoin:
>>
>> ### Proof of SquareSpace (Cardano, Polkdadot)
>>
>> Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an
>> inbuilt on-chain delegation system[5].
>> In these protocols, coin holders who do not want to run their node with
>> their hot keys in it delegate it to a "Stake Pool".
>> I call the resulting system Proof-of-SquareSpace since most will choose a
>> pool by looking around for one with a nice website and offering the largest
>> share of the block reward.
>> On the surface this might sound no different than someone with an mining
>> rig shopping around for a good mining pool but there are crucial
>> differences:
>>
>> 1. The person making the decision is forced into it just because they own
>> the currency -- someone with a mining rig has purchased it with the intent
>> to make profit by participating in consensus.
>>
>> 2. When you join a mining pool your systems are very much still online.
>> You are just partaking in a pool to reduce your profit variance. You still
>> see every block that you help create and *you never help create a block
>> without seeing it first*.
>>
>> 3. If by SquareSpace sybil attack you gain a dishonest majority and start
>> censoring transactions how are the users meant to redelegate their stake to
>> honest pools?
>> I guess they can just send a transaction delegating to another pool...oh
>> wait I guess that might be censored too! This seems really really bad.
>> In Bitcoin, miners can just join a different pool at a whim. There is
>> nothing the attacker can do to stop them. A temporary dishonest majority
>> heals relatively well.
>>
>> There is another severe disadvantage to this on-chain delegation system:
>> every UTXO must indicate which staking account this UTXO belongs to so the
>> appropriate share of block rewards can be transferred there.
>> Being able to associate every UTXO to an account ruins one of the main
>> privacy advantages of the UTXO model.
>> It also grows the size of the blockchain significantly.
>>
>> ### "Pure" proof of stake (Algorand)
>>
>> Algorand's[4] approach is to only allow online stake to participate in
>> the protocol.
>> Theoretically, This means that keys holding funds have to be online in
>> order for them to author blocks when they are chosen.
>> Of course in reality no one wants to keep their coin holding keys online
>> so in Alogorand you can authorize a set of "participation keys"[1] that
>> will be used to create blocks on your coin holding key's behalf.
>> Hopefully you've spotted the problem.
>> You can send your participation keys to any malicious party with a nice
>> website (see random example [2]) offering you a good return.
>> Damn it's still Proof-of-SquareSpace!
>> The minor advantage is that at least the participation keys expire after
>> a certain amount of time so eventually the SquareSpace attacker will lose
>> their hold on consensus.
>> Importantly there is also less junk on the blockchain because the
>> participation keys are delegated off-chain and so are not making as much of
>> a mess.
>>
>> ### Conclusion
>>
>> I don't see a way to get around the conflicting requirement that the keys
>> for large amounts of coins should be kept offline but those are exactly the
>> coins we need online to make the scheme secure.
>> If we allow delegation then we open up a new social attack surface and it
>> degenerates to Proof-of-SquareSpace.
>>
>> For a "digital gold" like system like Bitcoin we optimize for simplicity
>> and desperately want to avoid extraneous responsibilities for the holder of
>> the coin.
>> After all, gold is an inert element on the periodic table that doesn't
>> confer responsibilities on the holder to maintain the quality of all the
>> other bars of gold out there.
>> Bitcoin feels like this too and in many ways is more inert and
>> beautifully boring than gold.
>> For Bitcoin to succeed I think we need to keep it that way and
>> Proof-of-Stake makes everything a bit too exciting.
>>
>> I suppose in the end the market will decide what is real digital gold and
>> whether these bad technical trade offs are worth being able to say it uses
>> less electricity. It goes without saying that making bad technical
>> decisions to appease the current political climate is an anathema to
>> Bitcoin.
>>
>> Would be interested to know if you or others think differently on these
>> points.
>>
>> [1]:
>> https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
>> [2]: https://staking.staked.us/algorand-staking
>> [3]: https://eprint.iacr.org/2017/573.pdf
>> [4]:
>> https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
>> [5]:
>> https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf
>>
>> Cheers,
>>
>> LL
>>
>> On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I think there is a lot of misinformation and bias against Proof of
>>> Stake. Yes there have been lots of shady coins that use insecure PoS
>>> mechanisms. Yes there have been massive issues with distribution of PoS
>>> coins (of course there have also been massive issues with PoW coins as
>>> well). However, I want to remind everyone that there is a difference
>>> between "proved to be impossible" and "have not achieved recognized success
>>> yet". Most of the arguments levied against PoS are out of date or rely on
>>> unproven assumptions or extrapolation from the analysis of a particular PoS
>>> system. I certainly don't think we should experiment with bitcoin by
>>> switching to PoS, but from my research, it seems very likely that there is
>>> a proof of stake consensus protocol we could build that has substantially
>>> higher security (cost / capital required to execute an attack) while at the
>>> same time costing far less resources (which do translate to fees on the
>>> network) *without* compromising any of the critical security properties
>>> bitcoin relies on. I think the critical piece of this is the disagreements
>>> around hardcoded checkpoints, which is a critical piece solving attacks
>>> that could be levied on a PoS chain, and how that does (or doesn't) affect
>>> the security model.
>>>
>>> @Eric Your proof of stake fallacy seems to be saying that PoS is worse
>>> when a 51% attack happens. While I agree, I think that line of thinking
>>> omits important facts:
>>> * The capital required to 51% attack a PoS chain can be made
>>> substantially greater than on a PoS chain.
>>> * The capital the attacker stands to lose can be substantially greater
>>> as well if the attack is successful.
>>> * The effectiveness of paying miners to raise the honest fraction of
>>> miners above 50% may be quite bad.
>>> * Allowing a 51% attack is already unacceptable. It should be considered
>>> whether what happens in the case of a 51% may not be significantly
>>> different. The currency would likely be critically damaged in a 51% attack
>>> regardless of consensus mechanism.
>>>
>>> > Proof-of-stake tends towards oligopolistic control
>>>
>>> People repeat this often, but the facts support this. There is no
>>> centralization pressure in any proof of stake mechanism that I'm aware of.
>>> IE if you have 10 times as much coin that you use to mint blocks, you
>>> should expect to earn 10x as much minting revenue - not more than 10x. By
>>> contrast, proof of work does in fact have clear centralization pressure -
>>> this is not disputed. Our goal in relation to that is to ensure that the
>>> centralization pressure remains insignifiant. Proof of work also clearly
>>> has a lot more barriers to entry than any proof of stake system does. Both
>>> of these mean the tendency towards oligopolistic control is worse for PoW.
>>>
>>> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>>>
>>> I certainly agree. Bitcoin's energy usage at the moment is I think quite
>>> warranted. However, the question is: can we do substantially better. I
>>> think if we can, we probably should... eventually.
>>>
>>> > Proof of Stake is only resilient to ⅓ of the network demonstrating a
>>> Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
>>>
>>> I see no mention of this in the pos.pdf
>>> <https://download.wpsoftware.net/bitcoin/pos.pdf>; you linked to. I'm
>>> not aware of any proof that *all *PoS systems have a failure threshold
>>> of 1/3. I know that staking systems like Casper do in fact have that 1/3
>>> requirement. However there are PoS designs that should exceed that up to
>>> nearly 50% as far as I'm aware. Proof of work is not in fact resilient up
>>> to the 1/2 threshold in the way you would think. IE, if 100% of miners are
>>> currently honest and have a collective 100 exahashes/s hashpower, an
>>> attacker does not need to obtain 100 exahashes/s, but actually only needs
>>> to accumulate 50 exahashes/s. This is because as the attacker accumulates
>>> hashpower, it drives honest miners out of the market as the difficulty
>>> increases to beyond what is economically sustainable. Also, its been shown
>>> that the best proof of work can do is require an attacker to obtain 33% of
>>> the hashpower because of the selfish mining attack
>>> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-attack>; discussed
>>> in depth in this paper: https://arxiv.org/abs/1311.0243. Together, both
>>> of these things reduce PoW's security by a factor of about 83% (1 -
>>> 50%*33%).
>>>
>>> > Proof of Stake requires other trade-offs which are incompatible with
>>> Bitcoin's objective (to be a trustless digital cash) — specifically the
>>> famous "security vs. liveness" guarantee
>>>
>>> Do you have a good source that talks about why you think proof of stake
>>> cannot be used for a trustless digital cash?
>>>
>>> > You cannot gain tokens without someone choosing to give up those coins
>>> - a form of permission.
>>>
>>> This is not a practical constraint. Just like in mining, some nodes may
>>> reject you, but there will likely be more that will accept you, some
>>> sellers may reject you, but most would accept your money as payment for
>>> bitcoins. I don't think requiring the "permission" of one of millions of
>>> people in the market can be reasonably considered a "permissioned
>>> currency".
>>>
>>> > 2. Proof of stake must have a trusted means of timestamping to
>>> regulate overproduction of blocks
>>>
>>> Both PoW and PoS could mine/mint blocks twice as fast if everyone agreed
>>> to double their clock speeds. Both systems rely on an honest majority
>>> sticking to standard time.
>>>
>>>
>>> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Ah sorry, I didn't realize this was, in fact, a different thread! :)
>>>>
>>>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org>
>>>> wrote:
>>>>
>>>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP
>>>>> itself. PoS, VDFs, and so on are interesting but I guess there are other
>>>>> threads going on these topics already where they would be relevant.
>>>>>
>>>>> Also, it's important to distinguish between oPoW and these other
>>>>> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
>>>>> the core game theory or security assumptions of Hashcash and actually
>>>>> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>>>>>
>>>>> Cheers,
>>>>> Mike
>>>>>
>>>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
>>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> 1. i never suggested vdf's to replace pow.
>>>>>>
>>>>>> 2. my suggestion was specifically *in the context of* a working
>>>>>> proof-of-burn protocol
>>>>>>
>>>>>> - vdfs used only for timing (not block height)
>>>>>> - blind-burned coins of a specific age used to replace proof of work
>>>>>> - the required "work" per block would simply be a competition to
>>>>>> acquire rewards, and so miners would have to burn coins, well in
>>>>>> advance, and hope that their burned coins got rewarded in some far
>>>>>> future
>>>>>> - the point of burned coins is to mimic, in every meaningful way, the
>>>>>> value gained from proof of work... without some of the security
>>>>>> drawbacks
>>>>>> - the miner risks losing all of his burned coins (like all miners risk
>>>>>> losing their work in each block)
>>>>>> - new burns can't be used
>>>>>> - old burns age out (like ASICs do)
>>>>>> - other requirements on burns might be needed to properly mirror the
>>>>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>>>>>>
>>>>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>>>>>> might be more secure in the long run, and that if the entire space
>>>>>> agreed that such an endeavor was worthwhile, a test net could be spun
>>>>>> up, and a hard-fork could be initiated.
>>>>>>
>>>>>> 4. i would never suggest such a thing unless i believed it was
>>>>>> possible that consensus was possible. so no, this is not an "alt
>>>>>> coin"
>>>>>>
>>>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com>
>>>>>> wrote:
>>>>>> >
>>>>>> > Hi ZmnSCPxj,
>>>>>> >
>>>>>> > Please note that I am not suggesting VDFs as a means to save
>>>>>> energy, but solely as a means to make the time between blocks more constant.
>>>>>> >
>>>>>> > Zac
>>>>>> >
>>>>>> >
>>>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> Good morning Zac,
>>>>>> >>
>>>>>> >> > VDFs might enable more constant block times, for instance by
>>>>>> having a two-step PoW:
>>>>>> >> >
>>>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being
>>>>>> subject to difficulty adjustments similar to the as-is). As per the
>>>>>> property of VDFs, miners are able show proof of work.
>>>>>> >> >
>>>>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a
>>>>>> block takes 1 minute on average, again subject to as-is difficulty
>>>>>> adjustments.
>>>>>> >> >
>>>>>> >> > As a result, variation in block times will be greatly reduced.
>>>>>> >>
>>>>>> >> As I understand it, another weakness of VDFs is that they are not
>>>>>> inherently progress-free (their sequential nature prevents that; they are
>>>>>> inherently progress-requiring).
>>>>>> >>
>>>>>> >> Thus, a miner which focuses on improving the amount of energy that
>>>>>> it can pump into the VDF circuitry (by overclocking and freezing the
>>>>>> circuitry), could potentially get into a winner-takes-all situation,
>>>>>> possibly leading to even *worse* competition and even *more* energy
>>>>>> consumption.
>>>>>> >> After all, if you can start mining 0.1s faster than the
>>>>>> competition, that is a 0.1s advantage where *only you* can mine *in the
>>>>>> entire world*.
>>>>>> >>
>>>>>> >> Regards,
>>>>>> >> ZmnSCPxj
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Dubrovsky
>>>>> Founder; PoWx
>>>>> www.PoWx.org <http://www.powx.org/>;
>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Dubrovsky
>>>> Founder; PoWx
>>>> www.PoWx.org <http://www.powx.org/>;
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at 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/20210523/16cfd723/attachment-0001.html>;

📅 Original date posted:2021-05-23 📝 Original message:@Lloyd ...

2023-06-08T00:52:54+02:00

In reply to nevent1q…r09d
_________________________

📅 Original date posted:2021-05-23
📝 Original message:@Lloyd

> Proof-of-SquareSpace

I agree with your points about delegated proof of stake. I wrote my own
critique about that
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#analysis-of-delegated-proof-of-stake-dpos>;
as
well. And your point, that other forms of PoS devolve to DPoS by virtue of
people wanting to actively mint blocks without exposing their coins in hot
wallets, is an interesting one.

> how are the users meant to redelegate their stake to honest pools?

This could be mitigated partially if delegation didn't require any kind of
blockchain transaction. For example, users could simply send a signed
message saying "this other key can mint blocks with my coins", and then
minting a block using those coins would require presenting the delegation
signature. This only partially mitigates the problem since the dishonest
pool would still be able to use those coins as well, so it would be a race
at that point. Still better than nothing. And pools could simply require
full custody of the coins.

>From what you mentioned, it sounds like maybe Algorand does something
similar to this.

> I don't see a way to get around the conflicting requirement that the keys
for large amounts of coins should be kept offline but those are exactly the
coins we need online to make the scheme secure.

There are a couple solutions you didn't mention. One is your "traditional"
locked-stake kind of systems, where participants are required to lock their
stake for long periods of time. Since normal users aren't likely to want to
do this, it will likely be left to more sophisticated stakers likely
staking very large amounts.

Both mechanisms you mentioned allow delegation, and it might seem like
maybe there'd be a way to disallow delegation, however since users can
always give custody of their coins to trusted pools, that would be a
delgation mechanism of last resort that can't be removed. So you can do
things that make it hard (for both users and pool operators) to delegate
trustlessly, but you can't get rid of the ability to delgate entirely.

In general, the situations where I see people not pooling are:

A. They are entirely prevented by technical means. It seems reasonably
clear that this is impossible.
B. The downsides are more than unsophisticated users are willing to incur
(eg stake locking).
C. The rewards are so small that it isn't worth it for people to put in
much effort to gain them.
D. The rewards are so frequent that pooling is unnecessary.

B excludes a lot of people from being able to help secure the chain, but
this is not materially different from PoW mining in that regard. D is a bit
border line. With 1 billion people attempting to participate and 10 minute
blocks, 232 people would need to share the block reward in order to expect
a payout on average once per month. With 8 billion people that would turn
into more like 1700 people. This seems potentially doable (eg via cosigner
requirements on minted blocks), but it is a lot of participants per block.

I think options C and D combined would be an ideal approach here. Because
minting uses very few real resources, minting could be pretty much have
arbitrarily low ongoing costs. This means fees can be low and blocks can
have low payouts. If the reward was low and people could expect to see it
once every couple years, people could simply treat it like a lottery. Great
if they win it now, but nothing that anyone needs to rely on (which would
incentivize the pools to reduce variance that we want to avoid). If there
is no locked stake or other major barriers in place to minting blocks, that
would also help avoid the compultion to use a pool.

In any case, you bring up good points, and they certainly complicate the
issue. By the way, if you were confused as to what VPoS was in the section
from my above link, this might satisfy your curiosity
<https://github.com/fresheneesz/ValidatedProofOfStake>;.

Cheers

On Sat, May 22, 2021 at 5:41 PM Lloyd Fournier <lloyd.fourn at gmail.com>
wrote:

> Hi Billy,
>
> I was going to write a post which started by dismissing many of the weak
> arguments that are made against PoS made in this thread and elsewhere.
> Although I don't agree with all your points you have done a decent job
> here so I'll focus on the second part: why I think Proof-of-Stake is
> inappropriate for a Bitcoin-like system.
>
> Proof of stake is not fit for purpose for a global settlement layer in a
> pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to
> be.
> PoS necessarily gives responsibilities to the holders of coins that they
> do not want and cannot handle.
> In Bitcoin, large unsophisticated coin holders can put their coins in cold
> storage without a second thought given to the health of the underlying
> ledger.
> As much as hardcore Bitcoiners try to convince them to run their own node,
> most don't, and that's perfectly acceptable.
> At no point do their personal decisions affect the underlying consensus --
> it only affects their personal security assurance (not that of the system
> itself).
> In PoS systems this clean separation of responsibilities does not exist.
>
> I think that the more rigorously studied PoS protocols will work fine
> within the security claims made in their papers.
> People who believe that these protocols are destined for catastrophic
> consensus failure are certainly in for a surprise.
> But the devil is in the detail.
> Let's look at what the implications of using the leading proof of stake
> protocols would have on Bitcoin:
>
> ### Proof of SquareSpace (Cardano, Polkdadot)
>
> Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an
> inbuilt on-chain delegation system[5].
> In these protocols, coin holders who do not want to run their node with
> their hot keys in it delegate it to a "Stake Pool".
> I call the resulting system Proof-of-SquareSpace since most will choose a
> pool by looking around for one with a nice website and offering the largest
> share of the block reward.
> On the surface this might sound no different than someone with an mining
> rig shopping around for a good mining pool but there are crucial
> differences:
>
> 1. The person making the decision is forced into it just because they own
> the currency -- someone with a mining rig has purchased it with the intent
> to make profit by participating in consensus.
>
> 2. When you join a mining pool your systems are very much still online.
> You are just partaking in a pool to reduce your profit variance. You still
> see every block that you help create and *you never help create a block
> without seeing it first*.
>
> 3. If by SquareSpace sybil attack you gain a dishonest majority and start
> censoring transactions how are the users meant to redelegate their stake to
> honest pools?
> I guess they can just send a transaction delegating to another pool...oh
> wait I guess that might be censored too! This seems really really bad.
> In Bitcoin, miners can just join a different pool at a whim. There is
> nothing the attacker can do to stop them. A temporary dishonest majority
> heals relatively well.
>
> There is another severe disadvantage to this on-chain delegation system:
> every UTXO must indicate which staking account this UTXO belongs to so the
> appropriate share of block rewards can be transferred there.
> Being able to associate every UTXO to an account ruins one of the main
> privacy advantages of the UTXO model.
> It also grows the size of the blockchain significantly.
>
> ### "Pure" proof of stake (Algorand)
>
> Algorand's[4] approach is to only allow online stake to participate in the
> protocol.
> Theoretically, This means that keys holding funds have to be online in
> order for them to author blocks when they are chosen.
> Of course in reality no one wants to keep their coin holding keys online
> so in Alogorand you can authorize a set of "participation keys"[1] that
> will be used to create blocks on your coin holding key's behalf.
> Hopefully you've spotted the problem.
> You can send your participation keys to any malicious party with a nice
> website (see random example [2]) offering you a good return.
> Damn it's still Proof-of-SquareSpace!
> The minor advantage is that at least the participation keys expire after a
> certain amount of time so eventually the SquareSpace attacker will lose
> their hold on consensus.
> Importantly there is also less junk on the blockchain because the
> participation keys are delegated off-chain and so are not making as much of
> a mess.
>
> ### Conclusion
>
> I don't see a way to get around the conflicting requirement that the keys
> for large amounts of coins should be kept offline but those are exactly the
> coins we need online to make the scheme secure.
> If we allow delegation then we open up a new social attack surface and it
> degenerates to Proof-of-SquareSpace.
>
> For a "digital gold" like system like Bitcoin we optimize for simplicity
> and desperately want to avoid extraneous responsibilities for the holder of
> the coin.
> After all, gold is an inert element on the periodic table that doesn't
> confer responsibilities on the holder to maintain the quality of all the
> other bars of gold out there.
> Bitcoin feels like this too and in many ways is more inert and beautifully
> boring than gold.
> For Bitcoin to succeed I think we need to keep it that way and
> Proof-of-Stake makes everything a bit too exciting.
>
> I suppose in the end the market will decide what is real digital gold and
> whether these bad technical trade offs are worth being able to say it uses
> less electricity. It goes without saying that making bad technical
> decisions to appease the current political climate is an anathema to
> Bitcoin.
>
> Would be interested to know if you or others think differently on these
> points.
>
> [1]:
> https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
> [2]: https://staking.staked.us/algorand-staking
> [3]: https://eprint.iacr.org/2017/573.pdf
> [4]:
> https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
> [5]:
> https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf
>
> Cheers,
>
> LL
>
> On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I think there is a lot of misinformation and bias against Proof of Stake.
>> Yes there have been lots of shady coins that use insecure PoS mechanisms.
>> Yes there have been massive issues with distribution of PoS coins (of
>> course there have also been massive issues with PoW coins as well).
>> However, I want to remind everyone that there is a difference between
>> "proved to be impossible" and "have not achieved recognized success yet".
>> Most of the arguments levied against PoS are out of date or rely on
>> unproven assumptions or extrapolation from the analysis of a particular PoS
>> system. I certainly don't think we should experiment with bitcoin by
>> switching to PoS, but from my research, it seems very likely that there is
>> a proof of stake consensus protocol we could build that has substantially
>> higher security (cost / capital required to execute an attack) while at the
>> same time costing far less resources (which do translate to fees on the
>> network) *without* compromising any of the critical security properties
>> bitcoin relies on. I think the critical piece of this is the disagreements
>> around hardcoded checkpoints, which is a critical piece solving attacks
>> that could be levied on a PoS chain, and how that does (or doesn't) affect
>> the security model.
>>
>> @Eric Your proof of stake fallacy seems to be saying that PoS is worse
>> when a 51% attack happens. While I agree, I think that line of thinking
>> omits important facts:
>> * The capital required to 51% attack a PoS chain can be made
>> substantially greater than on a PoS chain.
>> * The capital the attacker stands to lose can be substantially greater as
>> well if the attack is successful.
>> * The effectiveness of paying miners to raise the honest fraction of
>> miners above 50% may be quite bad.
>> * Allowing a 51% attack is already unacceptable. It should be considered
>> whether what happens in the case of a 51% may not be significantly
>> different. The currency would likely be critically damaged in a 51% attack
>> regardless of consensus mechanism.
>>
>> > Proof-of-stake tends towards oligopolistic control
>>
>> People repeat this often, but the facts support this. There is no
>> centralization pressure in any proof of stake mechanism that I'm aware of.
>> IE if you have 10 times as much coin that you use to mint blocks, you
>> should expect to earn 10x as much minting revenue - not more than 10x. By
>> contrast, proof of work does in fact have clear centralization pressure -
>> this is not disputed. Our goal in relation to that is to ensure that the
>> centralization pressure remains insignifiant. Proof of work also clearly
>> has a lot more barriers to entry than any proof of stake system does. Both
>> of these mean the tendency towards oligopolistic control is worse for PoW.
>>
>> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>>
>> I certainly agree. Bitcoin's energy usage at the moment is I think quite
>> warranted. However, the question is: can we do substantially better. I
>> think if we can, we probably should... eventually.
>>
>> > Proof of Stake is only resilient to ⅓ of the network demonstrating a
>> Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
>>
>> I see no mention of this in the pos.pdf
>> <https://download.wpsoftware.net/bitcoin/pos.pdf>; you linked to. I'm not
>> aware of any proof that *all *PoS systems have a failure threshold of
>> 1/3. I know that staking systems like Casper do in fact have that 1/3
>> requirement. However there are PoS designs that should exceed that up to
>> nearly 50% as far as I'm aware. Proof of work is not in fact resilient up
>> to the 1/2 threshold in the way you would think. IE, if 100% of miners are
>> currently honest and have a collective 100 exahashes/s hashpower, an
>> attacker does not need to obtain 100 exahashes/s, but actually only needs
>> to accumulate 50 exahashes/s. This is because as the attacker accumulates
>> hashpower, it drives honest miners out of the market as the difficulty
>> increases to beyond what is economically sustainable. Also, its been shown
>> that the best proof of work can do is require an attacker to obtain 33% of
>> the hashpower because of the selfish mining attack
>> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-attack>; discussed
>> in depth in this paper: https://arxiv.org/abs/1311.0243. Together, both
>> of these things reduce PoW's security by a factor of about 83% (1 -
>> 50%*33%).
>>
>> > Proof of Stake requires other trade-offs which are incompatible with
>> Bitcoin's objective (to be a trustless digital cash) — specifically the
>> famous "security vs. liveness" guarantee
>>
>> Do you have a good source that talks about why you think proof of stake
>> cannot be used for a trustless digital cash?
>>
>> > You cannot gain tokens without someone choosing to give up those coins
>> - a form of permission.
>>
>> This is not a practical constraint. Just like in mining, some nodes may
>> reject you, but there will likely be more that will accept you, some
>> sellers may reject you, but most would accept your money as payment for
>> bitcoins. I don't think requiring the "permission" of one of millions of
>> people in the market can be reasonably considered a "permissioned
>> currency".
>>
>> > 2. Proof of stake must have a trusted means of timestamping to regulate
>> overproduction of blocks
>>
>> Both PoW and PoS could mine/mint blocks twice as fast if everyone agreed
>> to double their clock speeds. Both systems rely on an honest majority
>> sticking to standard time.
>>
>>
>> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Ah sorry, I didn't realize this was, in fact, a different thread! :)
>>>
>>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org>
>>> wrote:
>>>
>>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP
>>>> itself. PoS, VDFs, and so on are interesting but I guess there are other
>>>> threads going on these topics already where they would be relevant.
>>>>
>>>> Also, it's important to distinguish between oPoW and these other
>>>> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
>>>> the core game theory or security assumptions of Hashcash and actually
>>>> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> 1. i never suggested vdf's to replace pow.
>>>>>
>>>>> 2. my suggestion was specifically *in the context of* a working
>>>>> proof-of-burn protocol
>>>>>
>>>>> - vdfs used only for timing (not block height)
>>>>> - blind-burned coins of a specific age used to replace proof of work
>>>>> - the required "work" per block would simply be a competition to
>>>>> acquire rewards, and so miners would have to burn coins, well in
>>>>> advance, and hope that their burned coins got rewarded in some far
>>>>> future
>>>>> - the point of burned coins is to mimic, in every meaningful way, the
>>>>> value gained from proof of work... without some of the security
>>>>> drawbacks
>>>>> - the miner risks losing all of his burned coins (like all miners risk
>>>>> losing their work in each block)
>>>>> - new burns can't be used
>>>>> - old burns age out (like ASICs do)
>>>>> - other requirements on burns might be needed to properly mirror the
>>>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>>>>>
>>>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>>>>> might be more secure in the long run, and that if the entire space
>>>>> agreed that such an endeavor was worthwhile, a test net could be spun
>>>>> up, and a hard-fork could be initiated.
>>>>>
>>>>> 4. i would never suggest such a thing unless i believed it was
>>>>> possible that consensus was possible. so no, this is not an "alt
>>>>> coin"
>>>>>
>>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > Hi ZmnSCPxj,
>>>>> >
>>>>> > Please note that I am not suggesting VDFs as a means to save energy,
>>>>> but solely as a means to make the time between blocks more constant.
>>>>> >
>>>>> > Zac
>>>>> >
>>>>> >
>>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Good morning Zac,
>>>>> >>
>>>>> >> > VDFs might enable more constant block times, for instance by
>>>>> having a two-step PoW:
>>>>> >> >
>>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being
>>>>> subject to difficulty adjustments similar to the as-is). As per the
>>>>> property of VDFs, miners are able show proof of work.
>>>>> >> >
>>>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a
>>>>> block takes 1 minute on average, again subject to as-is difficulty
>>>>> adjustments.
>>>>> >> >
>>>>> >> > As a result, variation in block times will be greatly reduced.
>>>>> >>
>>>>> >> As I understand it, another weakness of VDFs is that they are not
>>>>> inherently progress-free (their sequential nature prevents that; they are
>>>>> inherently progress-requiring).
>>>>> >>
>>>>> >> Thus, a miner which focuses on improving the amount of energy that
>>>>> it can pump into the VDF circuitry (by overclocking and freezing the
>>>>> circuitry), could potentially get into a winner-takes-all situation,
>>>>> possibly leading to even *worse* competition and even *more* energy
>>>>> consumption.
>>>>> >> After all, if you can start mining 0.1s faster than the
>>>>> competition, that is a 0.1s advantage where *only you* can mine *in the
>>>>> entire world*.
>>>>> >>
>>>>> >> Regards,
>>>>> >> ZmnSCPxj
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Dubrovsky
>>>> Founder; PoWx
>>>> www.PoWx.org <http://www.powx.org/>;
>>>>
>>>
>>>
>>> --
>>> Michael Dubrovsky
>>> Founder; PoWx
>>> www.PoWx.org <http://www.powx.org/>;
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at 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/20210523/430ad500/attachment-0001.html>;

📅 Original date posted:2021-05-21 📝 Original message:@Erik ...

2023-06-08T00:52:52+02:00

In reply to nevent1q…jm26
_________________________

📅 Original date posted:2021-05-21
📝 Original message:@Erik
> it also solves the "nothing at stake" problem

A. the "nothing at stake" problem can be and has been solved by PoS
consensus mechanisms (unless you mean it more broadly than I'm taking it),
and B. Proof of Burn should have just as much "nothing at stake" issues as
PoS. Both consensus mechanisms depend on the current state of the chain to
determine whether someone's stake or burn would allow the creation of a
block. But I am curious, how does proof of burn solve the "nothing at
stake" problem in your view?

On Fri, May 21, 2021 at 10:58 AM Erik Aronesty <erik at q32.com> wrote:

> proof of burn has all the benefits of proof of stake (if there are any)
>
> but it also solves the "nothing at stake" problem
>
> the incentive in POB is that you're making a long-term investment in
> mining, and you want a stable protocol, quality network, etc.... to
> pay off your investment.
>
> On Thu, May 20, 2021 at 8:04 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
> >
> > I think there is a lot of misinformation and bias against Proof of
> Stake. Yes there have been lots of shady coins that use insecure PoS
> mechanisms. Yes there have been massive issues with distribution of PoS
> coins (of course there have also been massive issues with PoW coins as
> well). However, I want to remind everyone that there is a difference
> between "proved to be impossible" and "have not achieved recognized success
> yet". Most of the arguments levied against PoS are out of date or rely on
> unproven assumptions or extrapolation from the analysis of a particular PoS
> system. I certainly don't think we should experiment with bitcoin by
> switching to PoS, but from my research, it seems very likely that there is
> a proof of stake consensus protocol we could build that has substantially
> higher security (cost / capital required to execute an attack) while at the
> same time costing far less resources (which do translate to fees on the
> network) *without* compromising any of the critical security properties
> bitcoin relies on. I think the critical piece of this is the disagreements
> around hardcoded checkpoints, which is a critical piece solving attacks
> that could be levied on a PoS chain, and how that does (or doesn't) affect
> the security model.
> >
> > @Eric Your proof of stake fallacy seems to be saying that PoS is worse
> when a 51% attack happens. While I agree, I think that line of thinking
> omits important facts:
> > * The capital required to 51% attack a PoS chain can be made
> substantially greater than on a PoS chain.
> > * The capital the attacker stands to lose can be substantially greater
> as well if the attack is successful.
> > * The effectiveness of paying miners to raise the honest fraction of
> miners above 50% may be quite bad.
> > * Allowing a 51% attack is already unacceptable. It should be considered
> whether what happens in the case of a 51% may not be significantly
> different. The currency would likely be critically damaged in a 51% attack
> regardless of consensus mechanism.
> >
> > > Proof-of-stake tends towards oligopolistic control
> >
> > People repeat this often, but the facts support this. There is no
> centralization pressure in any proof of stake mechanism that I'm aware of.
> IE if you have 10 times as much coin that you use to mint blocks, you
> should expect to earn 10x as much minting revenue - not more than 10x. By
> contrast, proof of work does in fact have clear centralization pressure -
> this is not disputed. Our goal in relation to that is to ensure that the
> centralization pressure remains insignifiant. Proof of work also clearly
> has a lot more barriers to entry than any proof of stake system does. Both
> of these mean the tendency towards oligopolistic control is worse for PoW.
> >
> > > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
> >
> > I certainly agree. Bitcoin's energy usage at the moment is I think quite
> warranted. However, the question is: can we do substantially better. I
> think if we can, we probably should... eventually.
> >
> > > Proof of Stake is only resilient to ⅓ of the network demonstrating a
> Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
> >
> > I see no mention of this in the pos.pdf you linked to. I'm not aware of
> any proof that all PoS systems have a failure threshold of 1/3. I know that
> staking systems like Casper do in fact have that 1/3 requirement. However
> there are PoS designs that should exceed that up to nearly 50% as far as
> I'm aware. Proof of work is not in fact resilient up to the 1/2 threshold
> in the way you would think. IE, if 100% of miners are currently honest and
> have a collective 100 exahashes/s hashpower, an attacker does not need to
> obtain 100 exahashes/s, but actually only needs to accumulate 50
> exahashes/s. This is because as the attacker accumulates hashpower, it
> drives honest miners out of the market as the difficulty increases to
> beyond what is economically sustainable. Also, its been shown that the best
> proof of work can do is require an attacker to obtain 33% of the hashpower
> because of the selfish mining attack discussed in depth in this paper:
> https://arxiv.org/abs/1311.0243. Together, both of these things reduce
> PoW's security by a factor of about 83% (1 - 50%*33%).
> >
> > > Proof of Stake requires other trade-offs which are incompatible with
> Bitcoin's objective (to be a trustless digital cash) — specifically the
> famous "security vs. liveness" guarantee
> >
> > Do you have a good source that talks about why you think proof of stake
> cannot be used for a trustless digital cash?
> >
> > > You cannot gain tokens without someone choosing to give up those coins
> - a form of permission.
> >
> > This is not a practical constraint. Just like in mining, some nodes may
> reject you, but there will likely be more that will accept you, some
> sellers may reject you, but most would accept your money as payment for
> bitcoins. I don't think requiring the "permission" of one of millions of
> people in the market can be reasonably considered a "permissioned currency".
> >
> > > 2. Proof of stake must have a trusted means of timestamping to
> regulate overproduction of blocks
> >
> > Both PoW and PoS could mine/mint blocks twice as fast if everyone agreed
> to double their clock speeds. Both systems rely on an honest majority
> sticking to standard time.
> >
> >
> > On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Ah sorry, I didn't realize this was, in fact, a different thread! :)
> >>
> >> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org>
> wrote:
> >>>
> >>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP
> itself. PoS, VDFs, and so on are interesting but I guess there are other
> threads going on these topics already where they would be relevant.
> >>>
> >>> Also, it's important to distinguish between oPoW and these other
> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
> the core game theory or security assumptions of Hashcash and actually
> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
> >>>
> >>> Cheers,
> >>> Mike
> >>>
> >>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>
> >>>> 1. i never suggested vdf's to replace pow.
> >>>>
> >>>> 2. my suggestion was specifically *in the context of* a working
> >>>> proof-of-burn protocol
> >>>>
> >>>> - vdfs used only for timing (not block height)
> >>>> - blind-burned coins of a specific age used to replace proof of work
> >>>> - the required "work" per block would simply be a competition to
> >>>> acquire rewards, and so miners would have to burn coins, well in
> >>>> advance, and hope that their burned coins got rewarded in some far
> >>>> future
> >>>> - the point of burned coins is to mimic, in every meaningful way, the
> >>>> value gained from proof of work... without some of the security
> >>>> drawbacks
> >>>> - the miner risks losing all of his burned coins (like all miners risk
> >>>> losing their work in each block)
> >>>> - new burns can't be used
> >>>> - old burns age out (like ASICs do)
> >>>> - other requirements on burns might be needed to properly mirror the
> >>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
> >>>>
> >>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
> >>>> might be more secure in the long run, and that if the entire space
> >>>> agreed that such an endeavor was worthwhile, a test net could be spun
> >>>> up, and a hard-fork could be initiated.
> >>>>
> >>>> 4. i would never suggest such a thing unless i believed it was
> >>>> possible that consensus was possible. so no, this is not an "alt
> >>>> coin"
> >>>>
> >>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com>
> wrote:
> >>>> >
> >>>> > Hi ZmnSCPxj,
> >>>> >
> >>>> > Please note that I am not suggesting VDFs as a means to save
> energy, but solely as a means to make the time between blocks more constant.
> >>>> >
> >>>> > Zac
> >>>> >
> >>>> >
> >>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> >>>> >>
> >>>> >> Good morning Zac,
> >>>> >>
> >>>> >> > VDFs might enable more constant block times, for instance by
> having a two-step PoW:
> >>>> >> >
> >>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being
> subject to difficulty adjustments similar to the as-is). As per the
> property of VDFs, miners are able show proof of work.
> >>>> >> >
> >>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a
> block takes 1 minute on average, again subject to as-is difficulty
> adjustments.
> >>>> >> >
> >>>> >> > As a result, variation in block times will be greatly reduced.
> >>>> >>
> >>>> >> As I understand it, another weakness of VDFs is that they are not
> inherently progress-free (their sequential nature prevents that; they are
> inherently progress-requiring).
> >>>> >>
> >>>> >> Thus, a miner which focuses on improving the amount of energy that
> it can pump into the VDF circuitry (by overclocking and freezing the
> circuitry), could potentially get into a winner-takes-all situation,
> possibly leading to even *worse* competition and even *more* energy
> consumption.
> >>>> >> After all, if you can start mining 0.1s faster than the
> competition, that is a 0.1s advantage where *only you* can mine *in the
> entire world*.
> >>>> >>
> >>>> >> Regards,
> >>>> >> ZmnSCPxj
> >>>> _______________________________________________
> >>>> bitcoin-dev mailing list
> >>>> bitcoin-dev at lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >>>
> >>>
> >>> --
> >>> Michael Dubrovsky
> >>> Founder; PoWx
> >>> www.PoWx.org
> >>
> >>
> >>
> >> --
> >> Michael Dubrovsky
> >> Founder; PoWx
> >> www.PoWx.org
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at 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/20210521/0d41b5ee/attachment-0001.html>;

📅 Original date posted:2021-05-20 📝 Original message:I ...

2023-06-08T00:52:48+02:00

In reply to nevent1q…8aft
_________________________

📅 Original date posted:2021-05-20
📝 Original message:I think there is a lot of misinformation and bias against Proof of Stake.
Yes there have been lots of shady coins that use insecure PoS mechanisms.
Yes there have been massive issues with distribution of PoS coins (of
course there have also been massive issues with PoW coins as well).
However, I want to remind everyone that there is a difference between
"proved to be impossible" and "have not achieved recognized success yet".
Most of the arguments levied against PoS are out of date or rely on
unproven assumptions or extrapolation from the analysis of a particular PoS
system. I certainly don't think we should experiment with bitcoin by
switching to PoS, but from my research, it seems very likely that there is
a proof of stake consensus protocol we could build that has substantially
higher security (cost / capital required to execute an attack) while at the
same time costing far less resources (which do translate to fees on the
network) *without* compromising any of the critical security properties
bitcoin relies on. I think the critical piece of this is the disagreements
around hardcoded checkpoints, which is a critical piece solving attacks
that could be levied on a PoS chain, and how that does (or doesn't) affect
the security model.

@Eric Your proof of stake fallacy seems to be saying that PoS is worse when
a 51% attack happens. While I agree, I think that line of thinking omits
important facts:
* The capital required to 51% attack a PoS chain can be made substantially
greater than on a PoS chain.
* The capital the attacker stands to lose can be substantially greater as
well if the attack is successful.
* The effectiveness of paying miners to raise the honest fraction of miners
above 50% may be quite bad.
* Allowing a 51% attack is already unacceptable. It should be considered
whether what happens in the case of a 51% may not be significantly
different. The currency would likely be critically damaged in a 51% attack
regardless of consensus mechanism.

> Proof-of-stake tends towards oligopolistic control

People repeat this often, but the facts support this. There is no
centralization pressure in any proof of stake mechanism that I'm aware of.
IE if you have 10 times as much coin that you use to mint blocks, you
should expect to earn 10x as much minting revenue - not more than 10x. By
contrast, proof of work does in fact have clear centralization pressure -
this is not disputed. Our goal in relation to that is to ensure that the
centralization pressure remains insignifiant. Proof of work also clearly
has a lot more barriers to entry than any proof of stake system does. Both
of these mean the tendency towards oligopolistic control is worse for PoW.

> Energy usage, in-and-of-itself, is nothing to be ashamed of!!

I certainly agree. Bitcoin's energy usage at the moment is I think quite
warranted. However, the question is: can we do substantially better. I
think if we can, we probably should... eventually.

> Proof of Stake is only resilient to ⅓ of the network demonstrating a
Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold

I see no mention of this in the pos.pdf
<https://download.wpsoftware.net/bitcoin/pos.pdf>; you linked to. I'm not
aware of any proof that *all *PoS systems have a failure threshold of 1/3.
I know that staking systems like Casper do in fact have that 1/3
requirement. However there are PoS designs that should exceed that up to
nearly 50% as far as I'm aware. Proof of work is not in fact resilient up
to the 1/2 threshold in the way you would think. IE, if 100% of miners are
currently honest and have a collective 100 exahashes/s hashpower, an
attacker does not need to obtain 100 exahashes/s, but actually only needs
to accumulate 50 exahashes/s. This is because as the attacker accumulates
hashpower, it drives honest miners out of the market as the difficulty
increases to beyond what is economically sustainable. Also, its been shown
that the best proof of work can do is require an attacker to obtain 33% of
the hashpower because of the selfish mining attack
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-attack>;
discussed
in depth in this paper: https://arxiv.org/abs/1311.0243. Together, both of
these things reduce PoW's security by a factor of about 83% (1 - 50%*33%).

> Proof of Stake requires other trade-offs which are incompatible with
Bitcoin's objective (to be a trustless digital cash) — specifically the
famous "security vs. liveness" guarantee

Do you have a good source that talks about why you think proof of stake
cannot be used for a trustless digital cash?

> You cannot gain tokens without someone choosing to give up those coins -
a form of permission.

This is not a practical constraint. Just like in mining, some nodes may
reject you, but there will likely be more that will accept you, some
sellers may reject you, but most would accept your money as payment for
bitcoins. I don't think requiring the "permission" of one of millions of
people in the market can be reasonably considered a "permissioned
currency".

> 2. Proof of stake must have a trusted means of timestamping to regulate
overproduction of blocks

Both PoW and PoS could mine/mint blocks twice as fast if everyone agreed to
double their clock speeds. Both systems rely on an honest majority sticking
to standard time.

On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Ah sorry, I didn't realize this was, in fact, a different thread! :)
>
> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org> wrote:
>
>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itself.
>> PoS, VDFs, and so on are interesting but I guess there are other threads
>> going on these topics already where they would be relevant.
>>
>> Also, it's important to distinguish between oPoW and these other
>> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
>> the core game theory or security assumptions of Hashcash and actually
>> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>>
>> Cheers,
>> Mike
>>
>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> 1. i never suggested vdf's to replace pow.
>>>
>>> 2. my suggestion was specifically *in the context of* a working
>>> proof-of-burn protocol
>>>
>>> - vdfs used only for timing (not block height)
>>> - blind-burned coins of a specific age used to replace proof of work
>>> - the required "work" per block would simply be a competition to
>>> acquire rewards, and so miners would have to burn coins, well in
>>> advance, and hope that their burned coins got rewarded in some far
>>> future
>>> - the point of burned coins is to mimic, in every meaningful way, the
>>> value gained from proof of work... without some of the security
>>> drawbacks
>>> - the miner risks losing all of his burned coins (like all miners risk
>>> losing their work in each block)
>>> - new burns can't be used
>>> - old burns age out (like ASICs do)
>>> - other requirements on burns might be needed to properly mirror the
>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>>>
>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>>> might be more secure in the long run, and that if the entire space
>>> agreed that such an endeavor was worthwhile, a test net could be spun
>>> up, and a hard-fork could be initiated.
>>>
>>> 4. i would never suggest such a thing unless i believed it was
>>> possible that consensus was possible. so no, this is not an "alt
>>> coin"
>>>
>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com>
>>> wrote:
>>> >
>>> > Hi ZmnSCPxj,
>>> >
>>> > Please note that I am not suggesting VDFs as a means to save energy,
>>> but solely as a means to make the time between blocks more constant.
>>> >
>>> > Zac
>>> >
>>> >
>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>>> wrote:
>>> >>
>>> >> Good morning Zac,
>>> >>
>>> >> > VDFs might enable more constant block times, for instance by having
>>> a two-step PoW:
>>> >> >
>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject
>>> to difficulty adjustments similar to the as-is). As per the property of
>>> VDFs, miners are able show proof of work.
>>> >> >
>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a
>>> block takes 1 minute on average, again subject to as-is difficulty
>>> adjustments.
>>> >> >
>>> >> > As a result, variation in block times will be greatly reduced.
>>> >>
>>> >> As I understand it, another weakness of VDFs is that they are not
>>> inherently progress-free (their sequential nature prevents that; they are
>>> inherently progress-requiring).
>>> >>
>>> >> Thus, a miner which focuses on improving the amount of energy that it
>>> can pump into the VDF circuitry (by overclocking and freezing the
>>> circuitry), could potentially get into a winner-takes-all situation,
>>> possibly leading to even *worse* competition and even *more* energy
>>> consumption.
>>> >> After all, if you can start mining 0.1s faster than the competition,
>>> that is a 0.1s advantage where *only you* can mine *in the entire world*.
>>> >>
>>> >> Regards,
>>> >> ZmnSCPxj
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> Michael Dubrovsky
>> Founder; PoWx
>> www.PoWx.org <http://www.powx.org/>;
>>
>
>
> --
> Michael Dubrovsky
> Founder; PoWx
> www.PoWx.org <http://www.powx.org/>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20210520/fec21169/attachment-0001.html>;