Nostr notes by

📅 Original date posted:2022-02-20 📝 Original message: ...

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

In reply to nevent1q…nwaa
_________________________

📅 Original date posted:2022-02-20
📝 Original message:
opt-in or explicit tagging of fee account is a bad design IMO.

As pointed out by James O'Beirne in the other email, having an explicit key
required means you have to pre-plan.... suppose you're building a vault
meant to distribute funds over many years, do you really want a *specific*
precommitted key you have to maintain? What happens to your ability to bump
should it be compromised (which may be more likely if it's intended to be a
hot-wallet function for bumping).

Furthermore, it's quite often the case that someone might do a transaction
that pays you that is low fee that you want to bump but they choose to
opt-out... then what? It's better that you should always be able to fee
bump.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Sun, Feb 20, 2022 at 6:24 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning DA,
>
>
> > Agreed, you cannot rely on a replacement transaction would somehow
> > invalidate a previous version of it, it has been spoken into the gossip
> > and exists there in mempools somewhere if it does, there is no guarantee
> > that anyone has ever heard of the replacement transaction as there is no
> > consensus about either the previous version of the transaction or its
> > replacement until one of them is mined and the block accepted. -DA.
>
> As I understand from the followup from Peter, the point is not "this
> should never happen", rather the point is "this should not happen *more
> often*."
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220220/ff758812/attachment.html>;

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

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

In reply to nevent1q…x8y9
_________________________

📅 Original date posted:2022-01-19
📝 Original message:
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/20220118/862ed586/attachment-0001.html>;

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

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

In reply to nevent1q…5gxt
_________________________

📅 Original date posted:2022-01-19
📝 Original message:
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/bde037b2/attachment-0001.html>;

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

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

In reply to nevent1q…x5d7
_________________________

📅 Original date posted:2022-01-18
📝 Original message:
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/d8324802/attachment-0001.html>;

📅 Original date posted:2021-11-29 📝 Original message: Just ...

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

In reply to nevent1q…kqry
_________________________

📅 Original date posted:2021-11-29
📝 Original message:
Just a minor curiosity I figured was worth mentioning on the composition of
delegations and anyprevout...

DA: Let full delegation be a script S such that I can sign script R and
then R may sign for a transaction T.
DB: Let partial delegation be a script S such that I can sign a tuple
(script R, transaction T) and R may sign T.

A simple version of this could be done for scriptless multisigs where S
signs T and then onion encrypts to the signers of R and distributes the
shares. However, under such a model, if T is signed by S with AnyPrevOut,
then T is now arbitrarily rebindable. Therefore let us define more strictly:
DC: Let half-delegation be a script S such that I can sign a tuple (script
R, transaction T) and R may sign T and revealing T/R does grant
authorization to any other party.

The signer of R could choose to sign with APO, in which case they make the
txn rebindable. They could also reveal the private keys for R similarly.
For "correct" use, R should sign with SIGHASH_ALL, binding the transaction
to a single instance.

Observation: a tuple script R + transaction T can, in many cases, be
represented by script R || <H(transaction T)> CTV.
Corollary: half-delegation can be derived from full delegation and a
covenant.

Therefore delegation + CTV + APO may be sufficient for making chaperone
signatures work, if they are desired by a user.

Remarks:

APO's design discussion should not revisit Chaperone signatures (hopefully
already a dead horse?) but instead consider how APO might compose with
Delegation proposals and CTV.

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211129/a63d9d54/attachment.html>;

📅 Original date posted:2021-07-27 📝 Original message: Just ...

2023-06-09T15:03:11+02:00

In reply to nevent1q…gvsl
_________________________

📅 Original date posted:2021-07-27
📝 Original message:
Just my 2 cents:

I think worrying about the size of a resolution during a contested close
scenario (too much) is not worth it. Encoding the state needed (e.g., in
op_return or whatever) is the safest option because then you guarantee the
availability of the closing transaction data in the protocol with no
external dependencies.

If you want to make it cheaper, then allow for Alice to choose to cooperate
with a contesting Bob to replace the transaction with something smaller
(quibble: we should get rid of mempool absolute fee increase rule for RBF
perhaps... otherwise, this should be done as pre-broadcast negotiation)
after observing the state published by Bob, but make it mandatory to at
least reveal it if Bob wants to use the transaction unilaterally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210727/aa52c40e/attachment.html>;

📅 Original date posted:2021-07-10 📝 Original message: ...

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

In reply to nevent1q…gl6a
_________________________

📅 Original date posted:2021-07-10
📝 Original message:
Let's say you're about to hit your sequence limits on a Eltoo channel... Do
you have to go on chain?

No, you could do a continuation where for your *final* update, you sign a
move to a new update key. E.g.,

start at: IF "N+1" CLTV DROP <pk_u> CHECKSIG ELSE 2016 CSV DROP <pk_s_i>
CHECKSIG ENDIF

before N+1 = last, sign a txn with pk_s_last that moves coins to

IF "1" CLTV DROP <*pk_u**2*> CHECKSIG ELSE 2016 CSV DROP <pk_s_i> CHECKSIG
ENDIF

This essentially lets you do 32 bits worth of updates and then fwd to a new
contract by paying 1x extra transaction.

This is potentially better than just directly closing because we keep it
off chain for longer. However... this also adds an additional CSV.

(We can get around this by modifying the script branch which ends a CLTV
domain with:
<pk_s_last> CHECKSIG
since any updates past that point are done through the continuation
state... but let's ignore that for the next part)

What if we *always* used this every update? Then we'd essentially have 64
bits of sequence space. Each layer of this trick adds 32 bytes.

Doing layers like this inherently adds a bunch of CSV layers, so it
increases resolution time linearly.

One possibility to mitigate this is to do a "semitrusted burst mode" with a
counterparty. Suppose you're at sequence M and it's a normal txn.

Party A requests to Party B to initiate burst mode. A and B move to
sequence M+1 where state M+1 passes through to a 2 step Eltoo update.

This burst now has 32 bits of sequences to blow through.

B or A then indicates to the other party to terminate the burst at
"internal state number" Q. Then B and A sign M+2 where M+2 reflects the
last state at internal state number Q. This gets rid of the temporary extra
locking time for when parties are offline.

This has a benefit for privacy as well because if this protocol is used,
then top level state numbers do not reflect the # of payments strongly as
they're more akin to how many burst mode payments were done.

The semi trusted nature of this is that if a malicious peer induces you
into starting this, you double your funds lockup time. There are some
mitigations:

1) Only enter burst mode with long lived peers
2) Only enter burst mode when initiator has more funds in the channel than
you (or has some ratio) which imposes an opportunity cost for attacking.
3) Only allow a certain % of liquidity to be moved during a burst -- e.g.,
any time the delta in balance goes above a threshold, force a higher order
channel state update.

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210710/1267b270/attachment.html>;

📅 Original date posted:2020-06-20 📝 Original message: I am ...

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

In reply to nevent1q…as98
_________________________

📅 Original date posted:2020-06-20
📝 Original message:
I am not steeped enough in Lightning Protocol issues to get the full design
space, but I'm fairly certain BIP-119 Congestion Control trees would help
with this issue.

You can bucket a tree by doing a histogram of HTLC size, so that all small
HTLCs live in a common CTV subtree and don't interfere with higher value
HTLCs. You can also play with sequencing to prevent those HTLCs from
getting longchains in the mempool until they're above a certain value.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard <antoine.riard at gmail.com>
wrote:

> Hi Rene,
>
> Thanks for disclosing this vulnerability,
>
> I think this blackmail scenario holds but sadly there is a lower scenario.
>
> Both "Flood & Loot" and your blackmail attack rely on `update_fee`
> mechanism and unbounded commitment transaction size inflation. Though the
> first to provoke block congestion and yours to lockdown in-flight fees as
> funds hostage situation.
>
> > 1. The current solution is to just not use up the max value of
> htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
>
> As of today, yes I would recommend capping commitment size both for
> ensuring competitive propagation/block selection and limiting HTLC exposure.
>
> > 2. Probably the best fix (not sure if I understand the consequences
> correctly) is coming from this PR to bitcoin core (c.f.
> https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get
> it correctly with that we could always have low fees and ask the person who
> want to claim their outputs to pay fees. This excludes overpayment and
> could happen at a later stage when fees are not spiked. Still the victim
> who offered the htlcs would have to spend those outputs at some time.
>
> It's a bit more complex, carve-out output, even combined with anchor
> output support on the LN-side won't protect against different flavors of
> pinning. I invite you to go through logs of past 2 LN dev meetings.
>
> > 3. Don't overpay fees in commitment transactions. We can't foresee the
> future anyway
>
> Once 2. is well-addressed we may deprecate `update_fee`.
>
> > 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
> value (like we do with sub dust amounts and sub satoshi amounts. This would
> at least make the attack expensive as the attacker would have to bind a lot
> of liquidity.
>
> Ideally we want dust_limit to be dynamic, dust cap should be based on HTLC
> economic value, feerate of its output, feerate of HTLC-transaction, feerate
> estimation of any CPFP to bump it. I think that's kind of worthy to do once
> we solved 3. and 4
>
> > 5. Somehow be able to aggregate htlc's. In a world where we use payment
> points instead of preimages we might be able to do so. It would be really
> cool if separate HTLC's could be combined to 1 single output. I played
> around a little bit but I have not come up with a scheme that is more
> compact in all cases. Thus I just threw in the idea.
>
> Yes we may encode all HTLC in some Taproot tree in the future. There are
> some wrinkles but for a high-level theoretical construction see my post on
> CoinPool.
>
> > 6. Split onchain fees differently (now the attacker would also lose fees
> by conducting this attack) - No I don't want to start yet another fee
> bikeshadding debate. (In particular I believe that a different split of
> fees might make the Flood & Loot attack economically more viable which
> relies on the same principle)
>
> Likely a bit more of fee bikeshedding is something we have to do to make
> LN secure... Switching fee from pre-committed ones to a single-party,
> dynamic one.
>
> > Independently I think we should have a hint in our readme file about
> where and how people can disclose attacks and vulnerabilities.
> Implementations have this but the BOLTs do not.
>
> I 100% agree, that's exactly
> https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for
> your feedback :)
>
> Cheers,
>
> Antoine
>
> Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> a écrit :
>
>>
>> Good morning all,
>>
>> >
>> > Fee futures could help against this.
>> > I remember writing about this some time ago but cannot find where (not
>> sure if it was in lightning-dev or bitcoin-dev).
>>
>> `harding` found it:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200620/3c0b6b52/attachment.html>;

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

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

In reply to nevent1q…exh0
_________________________

📅 Original date posted:2021-08-10
📝 Original message:
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/b93d8107/attachment.html>;

📅 Original date posted:2021-08-08 📝 Original message: some ...

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

In reply to nevent1q…5ude
_________________________

📅 Original date posted:2021-08-08
📝 Original message:
some additional answers/clarifications

> Question for Jeremy: would you also allow zero-value outputs? Or would
> you just move the dust limit down to a fixed 1-sat?
>

I would remove it entirely -- i don't think there's a difference between
the two realistically.

>
> Allowing 0-value or 1-sat outputs minimizes the cost for polluting the
> UTXO set during periods of low feerates.
>
>
Maybe that incentivizes people to make better use of the low
feerate periods to do more important work like consolidations so that
others do not have the opportunity to pollute (therefore eliminating the
low fee period ;)

> If your stuff is going to slow down my node and possibly reduce my
> censorship resistance, how is that not my business?
>

You don't know that's what I'm doing, it's a guess as to my future behavior.

If it weren't worth it to me, I wouldn't be doing it. Market will solve
what is worth v.s. not worth.

>
> > 2) dust outputs can be used in various authentication/delegation smart
> > contracts
>
> All of which can also use amounts that are economically rational to
> spend on their own. If you're gonna use the chain for something besides
> value transfer, and you're already wiling to pay X in fees per onchain
> use, why is it not reasonable for us to ask you to put up something on
> the order of X as a bond that you'll actually clean up your mess when
> you're no longer interested in your thing?
>

These authentication/delegation smart contracts can be a part of value
transfer e.g. some type of atomic swaps or other escrowed payment.

A bond to clean it up is a fair reason; but perhaps in a protocol it might
not make sense to clean up the utxo otherwise and so you're creating a
cleanup transaction (potentially has to be presigned in a way it can't be
done as a consolidation) and then some future consolidation to make the
dusts+eps aggregately convenient to spend. So you'd be trading a decent
amount more chainspace v.s. just ignoring the output and writing it to disk
and maybe eventually into a utreexo (e.g. imagine utreexo where the last N
years of outputs are held in memory, but eventually things get tree'd up)
so the long term costs need not be entirely bourne in permanent storage.

>
> Nope, nothing is forced. Any LN node can simply refuse to accept/route
> HTLCs below the dust limit.
>

I'd love to hear some broad thoughts on the impact of this on routing (cc
Tarun who thinks about these things a decent amount) as this means for
things like multipath routes you have much stricter constraints on which
nodes you can route payments through. The impact on capacity from every
user's pov might be not insubstantial.

>
> I also doubt your proposed solution fixes the problem. Any LN node that
> accepts an uneconomic HTLC cannot recover that value, so the money is
> lost either way. Any sane regulation would treat losing value to
> transaction fees the same as losing value to uneconomical conditions.
>
> Finally, if LN nodes start polluting the UTXO set with no economic way
> to clean up their mess, I think that's going to cause tension between
> full node operators and LN node operators.
>

My anticipation is that the LN operators would stick the uneconomic HTLCs
aggregately into a fan out utxo and try to cooperate, but failing that only
pollute the chain by O(1) for O(n) non economic HTLCs. There is a
difference between losing money and knowing exactly where it is but not
claiming it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210808/b39f4a28/attachment.html>;

📅 Original date posted:2021-08-08 📝 Original message: Under ...

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

In reply to nevent1q…2c3h
_________________________

📅 Original date posted:2021-08-08
📝 Original message:
Under no circumstances do I think we should *increase* the dust limit. That
would have a mildly confiscatory effect on current Lightning Channel
operators, among others.

Generally, the UTXO set will grow. We should work to accommodate the worst
case scenario under current consensus rules. I think this points to using
things like Utreexo or similar rather than meddling in the user's business.

I am skeptical that 0 value outputs are a real spam problem given the cost
to create. Generally one creates an output when one either believes it
would make sense to redeem it in the future. So surely this is a market
problem, if people want them they can pay what it is worth for them to have
it. Again, it's not my business.

Matt proposes that people might use a nominal amount of bitcoin on a zero
value input so that it doesn't look like dust. What Matt is asking for is
that in any protocol you pay for your space not via fees, but instead via
an assurance bond that you will eventually redeem it and clean the state
up. In my opinion, this is worse than just allowing a zero value input
since then you might accrue the need for an additional change output to
which the bond's collateral be returned.

With respect to the check in the mail analogy, cutting down trees for paper
is bad for everyone and shipping things using fossil fuels contributes to
climate change. Therefore it's a cost borne by society in some respects.
Still, if someone else decides it's worth sending a remittance of whichever
value, it is still not my business.

With respect to CT and using the range proofs to exclude dust, I'm aware
that can be done (hence compromising allowed transfers). Again, I don't
think it's quite our business what people do, but on a technical level,
this would have the impact of shrinking the anonymity set so is also
suspect to me.

---------------

If we really want to create incentives for state clean up, I think it's a
decent design space to consider.

e.g., we could set up a bottle deposit program whereby miners contribute an
amount of funds from fee revenue from creating N outputs to a "rolling
utxo" (e.g., a coinbase utxo that gets spent each block op_true to op_true
under some miner rules) and the rolling utxo can either disperse funds to
the miner reward or soak up funds from the fees in order to encourage
blocks which have a better ratio of inputs to outputs than the mean. Miners
can then apply this rule in the mempool to prioritize transactions that
help their block's ratio. This is all without directly interfering with the
user's intent to create whatever outputs they want, it just provides a way
of paying miners to clean up the public common.

Gas Token by Daian et al comes to mind, from Eth, w.r.t. many pitfalls
arbing these state space freeing return curves, but it's worth thinking
through nonetheless.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210808/8fcb4331/attachment.html>;

📅 Original date posted:2021-08-08 📝 Original message: We ...

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

In reply to nevent1q…vsj3
_________________________

📅 Original date posted:2021-08-08
📝 Original message:
We should remove the dust limit from Bitcoin. Five reasons:

1) it's not our business what outputs people want to create
2) dust outputs can be used in various authentication/delegation smart
contracts
3) dust sized htlcs in lightning (
https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)
force channels to operate in a semi-trusted mode which has implications
(AFAIU) for the regulatory classification of channels in various
jurisdictions; agnostic treatment of fund transfers would simplify this
(like getting a 0.01 cent dividend check in the mail)
4) thinly divisible colored coin protocols might make use of sats as value
markers for transactions.
5) should we ever do confidential transactions we can't prevent it without
compromising privacy / allowed transfers

The main reasons I'm aware of not allow dust creation is that:

1) dust is spam
2) dust fingerprinting attacks

1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by
well behaved wallets to not redeem outputs that cost more in fees than they
are worth.

cheers,

jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210808/c022237a/attachment.html>;

📅 Original date posted:2022-01-28 📝 Original message:Lloyd, ...

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

In reply to nevent1q…tt0k
_________________________

📅 Original date posted:2022-01-28
📝 Original message:Lloyd,

This is an excellent write up, the idea and benefits are clear.

Is it correct that in the case of a 3/5th threshold it is a total 10x * 30x
= 300x improvement? Quite impressive.

I have a few notes of possible added benefits / features of DLCs with CTV:

1) CTV also enables a "trustless timeout" branch, whereby you can have a
failover claim that returns funds to both sides.

There are a few ways to do this:

A) The simplest is just an oracle-free <STH(timeout tx)> CTV whereby the
timeout transaction has an absolute/relative timelock after the creation of
the DLC in question.

B) An alternative approach I like is to have the base DLC have a branch
`<STH(begin timeout)> CTV` which pays into a DLC that is the exact same
except it removes the just-used branch and replaces it with `<STH(timeout
tx)> CTV` which contains a relative timelock R for the desired amount of
time to resolve. This has the advantage of always guaranteeing at least R
amount of time since the Oracles have been claimed to be non-live to
"return funds" to parties participating

2) CTV DLCs are non-interactive asynchronously third-party unilaterally
creatable.

What I mean by this is that it is possible for a single party to create a
DLC on behalf of another user since there is no required per-instance
pre-signing or randomly generated state. E.g., if Alice wants to create a
DLC with Bob, and knows the contract details, oracles, and a key for Bob,
she can create the contract and pay to it unilaterally as a payment to Bob.

This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can
also be constructed and then sent (along with a specific amount) to a third
party service (such as an exchange or Lightning node) to create DLCs
without requiring the third party service to do anything other than make
the payment as requested.

3) CTV DLCs can be composed in interesting ways

Options over DLCs open up many exciting types of instrument where Alice can
do things like:
A) Create a Option expiring in 1 week where Bob can add funds to pay a
premium and "Open" a DLC on an outcome closing in 1 year
B) Create an Option expiring in 1 week where one-of-many Bobs can pay the
premium (on-chain DEX?).

See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete stuff
around this.

There are also opportunities for perpetual-like contracts where you could
combine into one logical DLC 12 DLCs closing 1 per month that can either be
payed out all at once at the end of the year, or profit pulled out
partially at any time earlier.

4) This satisfies (I think?) my request to make DLCs expressible as Sapio
contracts in https://rubin.io/bitcoin/2021/12/20/advent-23/

5) An additional performance improvement can be had for iterative DLCs in
Lightning where you might trade over a fixed set of attestation points with
variable payout curves (e.g., just modifying some set of the CTV points).
Defer to you on performance, but this could help enable some more HFT-y
experiences for DLCs in LN

Best,

Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Mon, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi dlc-dev and bitcoin-dev,
>
> tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/442b0946/attachment-0001.html>;

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

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

In reply to nevent1q…sgre
_________________________

📅 Original date posted:2022-01-19
📝 Original message: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/bitcoin-dev/attachments/20220118/862ed586/attachment-0001.html>;

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

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

In reply to nevent1q…67u7
_________________________

📅 Original date posted:2022-01-19
📝 Original message: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/bde037b2/attachment-0001.html>;

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

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

In reply to nevent1q…4v2v
_________________________

📅 Original date posted:2022-01-18
📝 Original message: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/d8324802/attachment.html>;

📅 Original date posted:2022-01-01 📝 Original message:Happy ...

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

In reply to nevent1q…zdyq
_________________________

📅 Original date posted:2022-01-01
📝 Original message: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>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220101/4cd5c38b/attachment.html>;

📅 Original date posted:2021-12-18 📝 Original message:Small ...

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

In reply to nevent1q…9t5r
_________________________

📅 Original date posted:2021-12-18
📝 Original message:Small idea:

ease into getting rid of full-rbf by keeping the flag working, but make
enforcement of non-replaceability something that happens n seconds after
first seen.

this reduces the ability to partition the mempools by broadcasting
irreplaceable conflicts all at once, and slowly eases clients off of
relying on non-RBF.

we might start with 60 seconds, and then double every release till we get
to 600 at which point we disable it.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi,
>
> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as
> the Bitcoin Core's default replacement policy in version 24.0. As a
> reminder, the next release is 22.0, aimed for August 1st, assuming
> agreement is reached, this policy change would enter into deployment phase
> a year from now.
>
> Even if this replacement policy has been deemed as highly controversial a
> few years ago, ongoing and anticipated changes in the Bitcoin ecosystem are
> motivating this proposal.
>
> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
>
> As explained in "On Mempool Funny Games against Multi-Party Funded
> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party
> funded transactions by propagating an RBF opt-out double-spend of its
> contributed input before the honest transaction is broadcasted by the
> protocol orchester. DoSes are qualified in the sense of either an attacker
> wasting timevalue of victim's inputs or forcing exhaustion of the
> fee-bumping reserve.
>
> This affects a series of Bitcoin protocols such as Coinjoin, onchain DLCs
> and dual-funded LN channels. As those protocols are still in the early
> phase of deployment, it doesn't seem to have been executed in the wild for
> now. That said, considering that dual-funded are more efficient from a
> liquidity standpoint, we can expect them to be widely relied on, once
> Lightning enters in a more mature phase. At that point, it should become
> economically rational for liquidity service providers to launch those DoS
> attacks against their competitors to hijack user traffic.
>
> Beyond that, presence of those DoSes will complicate the design and
> deployment of multi-party Bitcoin protocols such as payment
> pools/multi-party channels. Note, Lightning Pool isn't affected as there is
> a preliminary stage where batch participants are locked-in their funds
> within an account witnessScript shared with the orchestrer.
>
> Of course, even assuming full-rbf, propagation of the multi-party funded
> transactions can still be interfered with by an attacker, simply
> broadcasting a double-spend with a feerate equivalent to the honest
> transaction. However, it tightens the attack scenario to a scorched earth
> approach, where the attacker has to commit equivalent fee-bumping reserve
> to maintain the pinning and might lose the "competing" fees to miners.
>
> # RBF opt-out as a Mempools Partitions Vector
>
> A longer-term issue is the risk of mempools malicious partitions, where an
> attacker exploits network topology or divergence in mempools policies to
> partition network mempools in different subsets. From then a wide range of
> attacks can be envisioned such as package pinning [1], artificial
> congestion to provoke LN channels closure or manipulation of
> fee-estimator's feerate (the Core's one wouldn't be affected as it relies
> on block confirmation, though other fee estimators designs deployed across
> the ecosystem are likely going to be affected).
>
> Traditionally, mempools partitions have been gauged as a spontaneous
> outcome of a distributed systems like Bitcoin p2p network and I'm not aware
> it has been studied in-depth for adversarial purposes. Though, deployment
> of second-layer
> protocols, heavily relying on sanity of a local mempool for fee-estimation
> and robust propagation of their time-sensitive transactions might lead to
> reconsider this position. Acknowledging this, RBF opt-out is a low-cost
> partitioning tool, of which the existence nullifies most of potential
> progresses to mitigate malicious partitioning.
>
>
> To resume, opt-in RBF doesn't suit well deployment of robust second-layers
> protocol, even if those issues are still early and deserve more research.
> At the same time, I believe a meaningful subset of the ecosystem are still
> relying
> on 0-confs transactions, even if their security is relying on far weaker
> assumptions (opt-in RBF rule is a policy rule, not a consensus one) [2] A
> rapid change of Core's mempool rules would be harming their quality of
> services and should be
> weighed carefully. On the other hand, it would be great to nudge them
> towards more secure handling of their 0-confs flows [3]
>
> Let's examine what could be deployed ecosystem-wise as enhancements to the
> 0-confs security model.
>
> # Proactive security models : Double-spend Monitoring/Receiver-side
> Fee-Topping with Package Relay
>
> From an attacker viewpoint, opt-in RBF isn't a big blocker to successful
> double-spends. Any motivated attacker can modify Core to mass-connect to a
> wide portion of the network, announce txA to this subset, announce txA' to
> the
> merchant. TxA' propagation will be encumbered by the privacy-preserving
> inventory timers (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which an
> attacker has no care to respect.
>
> To detect a successful double-spend attempt, a Bitcoin service should run
> few full-nodes with well-spread connection graphs and unlinkable between
> them, to avoid being identified then maliciously partitioned from the rest
> of the network.
>
> I believe this tactic is already deployed by few Bitcoin services, and
> even one can throw flame at it because it over consumes network resources
> (bandwidth, connection slots, ...), it does procure a security advantage to
> the ones doing it.
>
> One further improvement on top of this protection could be to react after
> the double-spend detection by attaching a CPFP to the merchant transaction,
> with a higher package feerate than the double-spend. Expected deployment of
> package-relay as a p2p mechanism/mempool policy in Bitcoin Core should
> enable it to do so.
>
> # Reactive security models : EconomicReputation-based Compensations
>
> Another approach could be to react after the fact if a double-spend has
> been qualified. If the sender is already known to the service provider, the
> service account can be slashed. If the sender is a low-trusted
> counterparty to the merchant, "side-trust" models could be relied on. For
> e.g a LN pubkey with a stacked reputation from your autopilot, LSATs, stake
> certificates, a HTLC-as-a-fidelity-bond, ... The space is quite wide there
> but I foresee those trust-minimized, decentralized solutions being adopted
> by the LN ecosystem to patch the risks when you enter in a channel/HTLC
> operation with an anonymous counterparty.
>
> What other cool new tools could be considered to enhance 0-confs security ?
>
> To conclude, let's avoid replaying the contentious threads of a few years
> ago. What this new thread highlights is the fact that a transaction
> relay/mempool acceptance policy might be beneficial to some class of
> already-deployed
> Bitcoin applications while being detrimental to newer ones. How do we
> preserve the current interests of 0-confs users while enabling upcoming
> interests of fancy L2s to flourish is a good conversation to have. I think.
>
> If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds
> too early, let's defer it to 0.25 or 0.26. I don't think Core has a
> consistent deprecation process w.r.t to policy rules heavily relied-on by
> Bitcoin users, if we do so let sets a precedent satisfying as many folks as
> we can.
>
> Cheers,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
> [1] See scenario 3 :
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
>
> [2] https://github.com/bitcoin/bitcoin/pull/10823#issuecomment-466485121
>
> [3] And the LN ecosystem does have an interest to fix zero-confs security,
> if "turbo-channels"-like become normalized for mobile nodes
> _______________________________________________
> 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/20211218/d033f8d9/attachment.html>;

📅 Original date posted:2021-12-12 📝 Original message:Howdy, ...

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

In reply to nevent1q…8dku
_________________________

📅 Original date posted:2021-12-12
📝 Original message:Howdy, welcome to day 15!

Today's post covers a form of a mining pool that can be operated as sort of
a map-reduce over blocks without any "infrastructure".

https://rubin.io/bitcoin/2021/12/12/advent-15/

There's still some really open-ended questions (perhaps for y'all to
consider) around how to select an analyze the choice of window and payout
functions, but something like this could alleviate a lot of the
centralization pressures typically faced by pools.

Notably, compared to previous attempts, combining the payment pool payout
with this concept means that there is practically very little on-chain
overhead from this approach as the chain-load
for including payouts in every block is deferred for future cooperation
among miners. Although that can be considered cooperation itself, if you
think of it like a pipeline, the cooperation happens out of band from
mining and block production so it really is coordination free to mine.

Cheers,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211212/ac3c5c3d/attachment.html>;

📅 Original date posted:2021-10-11 📝 Original message:*> ...

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

In reply to nevent1q…u7hs
_________________________

📅 Original date posted:2021-10-11
📝 Original message:*> ... in this post I will argue against frequent soft forks with a single
or minimal*
*> set of features and instead argue for infrequent soft forks with batches*
*> of features.*

I think this type of development has been discussed in the past and has
been rejected.

from: Matt Corallo's post:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html

*Matt: Follow the will of the community, irrespective of individuals
orunreasoned objection, but without ever overruling any
reasonableobjection. Recent history also includes "objection" to soft forks
in theform of "this is bad because it doesn't fix a different problem I
wantfixed ASAP". I don't think anyone would argue this qualifies as
areasonable objection to a change, and we should be in a place, as
acommunity (never as developers or purely one group), to ignore
suchobjections and make forward progress in spite of them. We don't
makegood engineering decisions by "bundling" unrelated features together to*
*enable political football and compromise.*

*AJ: - improvements: changes might not make everyone better off, but we*

* don't want changes to screw anyone over either -- pareto improvements
in economics, "first, do no harm", etc. (if we get this right, there's no
need to make compromises and bundle multiple flawed proposals so that
everyone's an equal mix of happy and*
* miserable)*

I think Matt and AJ's PoV is widely reflected in the community that
bundling changes leads to the inclusion of suboptimal features.

This also has strong precedent in other important technical bodies, e.g.
from https://datatracker.ietf.org/doc/html/rfc7282 On Consensus and Humming
in the IETF.

Even worse is the "horse-trading" sort of compromise: "I object to
your proposal for such-and-so reasons. You object to my proposal for
this-and-that reason. Neither of us agree. If you stop objecting to
my proposal, I'll stop objecting to your proposal and we'll put them
both in." That again results in an "agreement" of sorts, but instead
of just one outstanding unaddressed issue, this sort of compromise
results in two, again ignoring them for the sake of expedience.

These sorts of "capitulation" or "horse-trading" compromises have no
place in consensus decision making. In each case, a chair who looks
for "agreement" might find it in these examples because it appears
that people have "agreed". But answering technical disagreements is
what is needed to achieve consensus, sometimes even when the people

who stated the disagreements no longer wish to discuss them.

If you would like to advocate bitcoin development run counter to that,
you should provide a much stronger refutation of these engineering
norms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211011/7c82c14f/attachment-0001.html>;

📅 Original date posted:2021-09-07 📝 Original message:If you ...

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

In reply to nevent1q…0z0a
_________________________

📅 Original date posted:2021-09-07
📝 Original message:If you make the to be reorged flag 2 bits, 1 bit can mark final block and
the other can mark to be reorged.

That way the nodes opting into reorg can see the reorg and ignore the final
blocks (until a certain time? Or until it's via a reorg?), and the nodes
wanting not to see reorgs get continuous service without disruption

On Tue, Sep 7, 2021, 9:12 AM 0xB10C via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello,
>
> tl;dr: We want to make reorgs on SigNet a reality and are looking for
> feedback on approach and parameters.
>
> One of the ideas for SigNet is the possibility for it to be reliably
> unreliable, for example, planned chain reorganizations. These have not
> been implemented yet.
>
> My summerofbitcoin.org mentee Nikhil Bartwal and I have been looking at
> implementing support for reorgs on SigNet. We are looking for feedback
> on which approach and parameters to use. Please consider answering the
> questions below if you or your company is interested in chain
> reorganizations on SigNet.
>
> With feedback from AJ and Kalle Alm (thanks again!), we came up with two
> scenarios that could be implemented in the current SigNet miner script
> [0]. Both would trigger automatically in a fixed block interval.
> Scenario 1 simulates a race scenario where two chains compete for D
> blocks. Scenario 2 simulates a chain rollback where the top D blocks get
> replaced by a chain that outgrows the earlier branch.
>
> AJ proposed to allow SigNet users to opt-out of reorgs in case they
> explicitly want to remain unaffected. This can be done by setting a
> to-be-reorged version bit flag on the blocks that won't end up in the
> most work chain. Node operators could choose not to accept to-be-reorged
> SigNet blocks with this flag set via a configuration argument.
>
> The reorg-interval X very much depends on the user's needs. One could
> argue that there should be, for example, three reorgs per day, each 48
> blocks apart. Such a short reorg interval allows developers in all time
> zones to be awake during one or two reorgs per day. Developers don't
> need to wait for, for example, a week until they can test their reorgs
> next. However, too frequent reorgs could hinder other SigNet users.
>
> We propose that the reorg depth D is deterministically random between a
> minimum and a maximum based on, e.g., the block hash or the nonce of the
> last block before the reorg. Compared to a local randint() based
> implementation, this allows reorg-handling tests and external tools to
> calculate the expected reorg depth.
>
> # Scenario 1: Race between two chains
>
> For this scenario, at least two nodes and miner scripts need to be
> running. An always-miner A continuously produces blocks and rejects
> blocks with the to-be-reorged version bit flag set. And a race-miner R
> that only mines D blocks at the start of each interval and then waits X
> blocks. A and R both have the same hash rate. Assuming both are well
> connected to the network, it's random which miner will first mine and
> propagate a block. In the end, the A miner chain will always win the race.
>
> # Scenario 2: Chain rollback
>
> This scenario only requires one miner and Bitcoin Core node but also
> works in a multiminer setup. The miners mine D blocks with the
> to-be-reorged version bit flag set at the start of the interval. After
> allowing the block at height X+D to propagate, they invalidate the block
> at height X+1 and start mining on block X again. This time without
> setting the to-be-reorged version bit flag. Non-miner nodes will reorg
> to the new tip at height X+D+1, and the first-seen branch stalls.
>
> # Questions
>
> 1. How do you currently test your applications reorg handling? Do
> the two discussed scenarios (race and chain rollback) cover your
> needs? Are we missing something you'd find helpful?
>
> 2. How often should reorgs happen on the default SigNet? Should
> there be multiple reorgs a day (e.g., every 48 or 72 blocks
> assuming 144 blocks per day) as your engineers need to be awake?
> Do you favor less frequent reorgs (once per week or month)? Why?
>
> 3. How deep should the reorgs be on average? Do you want to test
> deeper reorgs (10+ blocks) too?
>
>
> # Next Steps
>
> We will likely implement Scenario 1, the race between two chains, first.
> We'll set up a public test-SigNet along with a faucet, block explorer,
> and a block tree visualization. If there is interest in the second
> approach, chain rollbacks can be implemented too. Future work will add
> the possibility to include conflicting transactions in the two branches.
> After enough testing, the default SigNet can start to do periodical
> reorgs, too.
>
> Thanks,
> 0xB10C
>
> [0]: https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/miner
>
> _______________________________________________
> 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/20210907/4f2f687d/attachment.html>;

📅 Original date posted:2021-07-07 📝 Original message:Dear ...

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

In reply to nevent1q…a9nc
_________________________

📅 Original date posted:2021-07-07
📝 Original message:Dear Bitcoin Devs,

As mentioned previously, OP_CAT (or similar operation) can be used to make
Bitcoin "quantum safe" by signing an EC signature. This should work in both
Segwit V0 and Tapscript, although you have to use HASH160 for it to fit in
Segwit V0.

See [my blog](https://rubin.io/blog/2021/07/06/quantum-bitcoin/) for the
specific construction, reproduced below.

Yet another entry to the "OP_CAT can do that too" list.

Best,

Jeremy
-----

I recently published [a blog
post](https://rubin.io/blog/2021/07/02/signing-5-bytes/) about signing up
to a
5 byte value using Bitcoin script arithmetic and Lamport signatures.

By itself, this is neat, but a little limited. What if we could sign longer
messages? If we can sign up to 20 bytes, we could sign a HASH160 digest
which
is most likely quantum safe...

What would it mean if we signed the HASH160 digest of a signature? What the
what? Why would we do that?

Well, as it turns out, even if a quantum computer were able to crack ECDSA,
it
would yield revealing the private key but not the ability to malleate the
content of what was actually signed. I asked my good friend and
cryptographer
[Madars Virza](https://madars.org/) if my intuition was correct, and he
confirmed that it should be sufficient, but it's definitely worth closer
analysis before relying on this. While the ECDSA signature can be malleated
to a
different, negative form, if the signature is otherwise made immalleable
there
should only be one value the commitment can be opened to.

If we required the ECDSA signature be signed with a quantum proof signature
algorithm, then we'd have a quantum proof Bitcoin! And the 5 byte signing
scheme
we discussed previously is a Lamport signature, which is quantum secure.
Unfortunately, we need at least 20 contiguous bytes... so we need some sort
of
OP\_CAT like operation.

OP\_CAT can't be directly soft forked to Segwit v0 because it modifies the
stack, so instead we'll (for simplicity) also show how to use a new opcode
that
uses verify semantics, OP\_SUBSTRINGEQUALVERIFY that checks a splice of a
string
for equality.

```
... FOR j in 0..=5
<0>
... FOR i in 0..=31
SWAP hash160 DUP <H(K_j_i_1)> EQUAL IF DROP <2**i> ADD ELSE
<H(K_j_i_0)> EQUALVERIFY ENDIF
... END FOR
TOALTSTACK
... END FOR

DUP HASH160

... IF CAT AVAILABLE
FROMALTSTACK
... FOR j in 0..=5
FROMALTSTACK
CAT
... END FOR
EQUALVERIFY
... ELSE SUBSTRINGEQUALVERIFY AVAILABLE
... FOR j in 0..=5
FROMALTSTACK <0+j*4> <4+j*4> SUBSTRINGEQUALVERIFY DROP DROP DROP
... END FOR
DROP
... END IF

<pk> CHECKSIG
```

That's a long script... but will it fit? We need to verify 20 bytes of
message
each bit takes around 10 bytes script, an average of 3.375 bytes per number
(counting pushes), and two 21 bytes keys = 55.375 bytes of program space
and 21
bytes of witness element per bit.

It fits! `20*8*55.375 = 8860`, which leaves 1140 bytes less than the limit
for
the rest of the logic, which is plenty (around 15-40 bytes required for the
rest
of the logic, leaving 1100 free for custom signature checking). The stack
size
is 160 elements for the hash gadget, 3360 bytes.

This can probably be made a bit more efficient by expanding to a ternary
representation.

```
SWAP hash160 DUP <H(K_j_i_0)> EQUAL IF DROP ELSE <3**i> SWAP DUP
<H(K_j_i_T)> EQUAL IF DROP SUB ELSE <H(K_j_i_1)> EQUALVERIFY ADD ENDIF
ENDIF
```

This should bring it up to roughly 85 bytes per trit, and there should be
101
trits (`log(2**160)/log(3) == 100.94`), so about 8560 bytes... a bit
cheaper!
But the witness stack is "only" `2121` bytes...

As a homework exercise, maybe someone can prove the optimal choice of radix
for
this protocol... My guess is that base 4 is optimal!

## Taproot?

What about Taproot? As far as I'm aware the commitment scheme (`Q = pG +
hash(pG
|| m)G`) can be securely opened to m even with a quantum computer (finding
`q`
such that `qG = Q` might be trivial, but suppose key path was disabled, then
finding m and p such that the taproot equation holds should be difficult
because
of the hash, but I'd need to certify that claim better). Therefore this
script can nest inside of a Tapscript path -- Tapscript also does not
impose a
length limit, 32 byte hashes could be used as well.

Further, to make keys reusable, there could be many Lamport keys comitted
inside
a taproot tree so that an address could be used for thousands of times
before
expiring. This could be used as a measure to protect accidental use rather
than
to support it.

Lastly, Schnorr actually has a stronger non-malleability property than
ECDSA,
the signatures will be binding to the approved transaction and once Lamport
signed, even a quantum computer could not steal the funds.

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/3942eac0/attachment-0001.html>;

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

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

In reply to nevent1q…yyx5
_________________________

📅 Original date posted:2021-07-06
📝 Original message:heh -- I pointed out these evil multisig covenants in 2015 :)
https://medium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78
I'm relatively unconcerned by it except to the extent that mining
centralizes to the point of censoring other traffic.

Overall, I think this is a great conversation to be having.

However, I want to push back on David's claim that "Respecting the
concerns of others doesn't require lobotomizing useful tools.".

CHECKSIGFROMSTACK is a primitive and the opcode is not being nerfed in any
way shape or form. The argument here is that doing CSFS and not CAT is
nerfing CSFS... but CSFS is an independently useful and cool opcode that
has many of it's own merits.

Further, as described in my [blog post](
https://rubin.io/blog/2021/07/02/covenants/), CSFS has very high "design
specificity"... that is there's not *that* many design choices that could
possibly go into it. It's checking a signature. From the stack. That's all
folks! There are no design compromises in it. No lobotomy.

OP_CAT is more or less completely unrelated to CSFS. As Andrew has
[demonstrated](
https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html),
*just* OP_CAT alone (no CSFS) gives you covenants (albeit in a hacky way)
with Schnorr.

I think roconnor agrees that CAT(+CSFS?) are not really a "fantastic" way
to do covenants, that there are more direct approaches that will be better
or neccessary such as TWEAK or UPDATETAPLEAF. Let's work on those! But
let's also not hold up progress on other useful things while those are
brewing.

Non-Redundancy should be a non-goal for script -- although we strive to be
minimal, redundancy is inevitable. For example, OP_SWAP has identical
semantics to <1> ROLL, but SWAP is a common enough use that it is pragmatic
to assign it an opcode and OP_ROLL does something distinctly enhanced.
Similarly, even if we add CAT we will surely come up with saner ways to
implement covenant logic than Andrew's Schnorr tricks.

CTV in particular is designed to be a part of that story -- enough
functionality w/o OP_CAT to work *today* and serve a purpose long into the
future, but with OP_CAT (or shastream preferably) enhances it's
functionality in a useful way and with introspection opcodes (perhaps like
those being developed by elements) further gains functionality. Perhaps the
functionality available today will be redundant with a future way of doing
things, but we can only see so far into the future. However, we can see
that there are good things to build with it today.

It's the inverse of a lobotomy. Independent components that can come
together for a newer greater purpose rather than parts being torn apart
irreparably.

In the future when we have specific use cases in mind that *aren't* served
well (either efficiently or at all) by the existing primitives, it's
completely acceptable to add something new even if it makes an existing
feature redundant. APO, for example, will be redundant (afaict) will Glen
Willen's [Bitmask SigHash Flags](
https://bc-2.jp/archive/season2/materials/0203_NewElementsFeaturesEn.pdf)
should we ever get those.

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/4bf5525a/attachment.html>;

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

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

In reply to nevent1q…hq2l
_________________________

📅 Original date posted:2021-07-03
📝 Original message:Awesome to hear that!

Actually I don't think I did know (or I forgot/didn't catch it) that there
was an updated spec for elements, I searched around for what I could find
and came up empty handed. Do you have any links for that? That sounds
perfect to me.

On Sat, Jul 3, 2021, 10:50 AM Russell O'Connor <roconnor at blockstream.com>
wrote:

> Hi Jermy,
>
> As you are aware, we, and by we I mean mostly Sanket, are developing an
> updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements. The
> plan here would be to effectively support the an interface to the
> variable-length extension of BIP-0340 schnorr signatures.
>
> BIP-0340 would dispense with DER encoding (good riddance).
> BIP-0340 signatures are batch verifiable along with other BIP-0340
> transaction signatures and taproot tweak verification.
> Support for variable length messages in BIP-0340 has been discussed in <
> https://github.com/sipa/bips/issues/207>; and an implementation has
> recently been merged in <
> https://github.com/bitcoin-core/secp256k1/pull/844>;. The BIP has not yet
> been updated but the difference is that the message m does not have to be
> 32-bytes (it is recommended that the message be a 32-bit tagged hash or a
> message with a 64-bit application specific prefix). The CHECKSIGFROMSTACK
> operation (in tapscript) would use a stack item for this m value to
> BIP-0340 signature verification and would not necessarily have to be 32
> bytes.
>
> I think this design we are aiming for would be perfectly suited for
> Bitcoin as well.
>
> On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
>> specification for "CheckDataSig", more or less the same thing as
>> CHECKSIGFROMSTACK
>> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
>> In contrast to Element's implementation, it does not have Element's bugs
>> around verify semantics and uses the nullfail rule, and there is a
>> specification document so it seemed like the easiest starting point for
>> discussion v.s. drafting something from scratch.
>>
>> Does anyone have any issue with adapting this exact text and
>> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>>
>> Note that with *just* CheckSigFromStack, while you can do some very
>> valuable use cases, but without OP_CAT it does not enable sophisticated
>> covenants (and as per
>> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html
>> just CAT alone enables such uses).
>>
>> Design questions worth considering as modifications:
>>
>> 1. Should CSFS require some sort of tagged hash? Very likely answer is no
>> – tags interfere with certain use cases
>> 2. Should CSFS split the signature’s R & S value stack items for some
>> applications that otherwise may require OP_CAT? E.g. using a pinned R value
>> allows you to extract a private key if ever double signed, using 2 R values
>> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
>> desired then OP_CAT can be introduced
>> 3. Should CSFS support a cheap way to reference the taproot internal or
>> external key? Perhaps, can be handled with undefined upgradeable keytypes.
>> One might want to use the internal key, if the signed data should be valid
>> independent of the tapscript tree. One might want to use the external key,
>> if the data should only be valid for a single tapscript key + tree.
>> 4. Should invalid public keys types be a NOP to support future extended
>> pubkey types?
>>
>>
>>
>> Best,
>>
>>
>> Jeremy
>>
>>
>> ---
>> layout: specification
>> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
>> category: spec
>> date: 2018-08-20
>> activation: 1542300000
>> version: 0.6
>> ---
>>
>> OP_CHECKDATASIG
>> ===============
>>
>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid with respect to a message and a public key.
>>
>> OP_CHECKDATASIG permits data to be imported into a script, and have its validity checked against some signing authority such as an "Oracle".
>>
>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be implemented similarly to OP_CHECKSIG [1]. Conceptually, one could imagine OP_CHECKSIG functionality being replaced by OP_CHECKDATASIG, along with a separate Op Code to create a hash from the transaction based on the SigHash algorithm.
>>
>> OP_CHECKDATASIG Specification
>> -----------------------------
>>
>> ### Semantics
>>
>> OP_CHECKDATASIG fails immediately if the stack is not well formed. To be well formed, the stack must contain at least three elements [`<sig>`, `<msg>`, `<pubKey>`] in this order where `<pubKey>` is the top element and
>> * `<pubKey>` must be a validly encoded public key
>> * `<msg>` can be any string
>> * `<sig>` must follow the strict DER encoding as described in [2] and the S-value of `<sig>` must be at most the curve order divided by 2 as described in [3]
>>
>> If the stack is well formed, then OP_CHECKDATASIG pops the top three elements [`<sig>`, `<msg>`, `<pubKey>`] from the stack and pushes true onto the stack if `<sig>` is valid with respect to the raw single-SHA256 hash of `<msg>` and `<pubKey>` using the secp256k1 elliptic curve. Otherwise, it pops three elements and pushes false onto the stack in the case that `<sig>` is the empty string and fails in all other cases.
>>
>> Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature does not match the supplied public key and message hash, and the signature is not an empty byte array, the entire script fails.
>>
>> ### Opcode Number
>>
>> OP_CHECKDATASIG uses the previously unused opcode number 186 (0xba in hex encoding)
>>
>> ### SigOps
>>
>> Signature operations accounting for OP_CHECKDATASIG shall be calculated the same as OP_CHECKSIG. This means that each OP_CHECKDATASIG shall be counted as one (1) SigOp.
>>
>> ### Activation
>>
>> Use of OP_CHECKDATASIG, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>>
>> ### Unit Tests
>>
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if 15 November 2018 protocol upgrade is not yet activated.
>> - `<sig> <msg> OP_CHECKDATASIG` fails if there are fewer than 3 items on stack.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<pubKey>` is not a validly encoded public key.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass the Low S check.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass signature validation of `<msg>` and `<pubKey>`.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes false onto the stack if `<sig>` is an empty byte array.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes true onto the stack if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>>
>> OP_CHECKDATASIGVERIFY Specification
>> -----------------------------------
>>
>> ### Semantics
>>
>> OP_CHECKDATASIGVERIFY is equivalent to OP_CHECKDATASIG followed by OP_VERIFY. It leaves nothing on the stack, and will cause the script to fail immediately if the signature check does not pass.
>>
>> ### Opcode Number
>>
>> OP_CHECKDATASIGVERIFY uses the previously unused opcode number 187 (0xbb in hex encoding)
>>
>> ### SigOps
>>
>> Signature operations accounting for OP_CHECKDATASIGVERIFY shall be calculated the same as OP_CHECKSIGVERIFY. This means that each OP_CHECKDATASIGVERIFY shall be counted as one (1) SigOp.
>>
>> ### Activation
>>
>> Use of OP_CHECKDATASIGVERIFY, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>>
>> ### Unit Tests
>>
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if 15 November 2018 protocol upgrade is not yet activated.
>> - `<sig> <msg> OP_CHECKDATASIGVERIFY` fails if there are fewer than 3 item on stack.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY`fails if `<pubKey>` is not a validly encoded public key.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if signature `<sig>` is not empty and does not pass the Low S check.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a valid signature of `<msg>` with respect to `<pubKey>`.
>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` pops the top three stack elements if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>>
>> Sample Implementation [4, 5]
>> ----------------------------
>>
>> ```c++
>> case OP_CHECKDATASIG:
>> case OP_CHECKDATASIGVERIFY: {
>> // Make sure this remains an error before activation.
>> if ((flags & SCRIPT_ENABLE_CHECKDATASIG) == 0) {
>> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
>> }
>>
>> // (sig message pubkey -- bool)
>> if (stack.size() < 3) {
>> return set_error(
>> serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>> }
>>
>> valtype &vchSig = stacktop(-3);
>> valtype &vchMessage = stacktop(-2);
>> valtype &vchPubKey = stacktop(-1);
>>
>> if (!CheckDataSignatureEncoding(vchSig, flags,
>> serror) ||
>> !CheckPubKeyEncoding(vchPubKey, flags, serror)) {
>> // serror is set
>> return false;
>> }
>>
>> bool fSuccess = false;
>> if (vchSig.size()) {
>> valtype vchHash(32);
>> CSHA256()
>> .Write(vchMessage.data(), vchMessage.size())
>> .Finalize(vchHash.data());
>> uint256 message(vchHash);
>> CPubKey pubkey(vchPubKey);
>> fSuccess = pubkey.Verify(message, vchSig);
>> }
>>
>> if (!fSuccess && (flags & SCRIPT_VERIFY_NULLFAIL) &&
>> vchSig.size()) {
>> return set_error(serror, SCRIPT_ERR_SIG_NULLFAIL);
>> }
>>
>> popstack(stack);
>> popstack(stack);
>> popstack(stack);
>> stack.push_back(fSuccess ? vchTrue : vchFalse);
>> if (opcode == OP_CHECKDATASIGVERIFY) {
>> if (fSuccess) {
>> popstack(stack);
>> } else {
>> return set_error(serror,
>> SCRIPT_ERR_CHECKDATASIGVERIFY);
>> }
>> }
>> } break;
>> ```
>>
>> Sample Usage
>> ------------
>>
>> The following example shows a spend and redeem script for a basic use of CHECKDATASIG. This example validates the signature of some data, provides a placeholder where you would then process that data, and finally allows one of 2 signatures to spend based on the outcome of the data processing.
>>
>> ### spend script:
>> ```
>> push txsignature
>> push txpubkey
>> push msg
>> push sig
>> ```
>> ### redeem script:
>> ```
>> (txsig, txpubkey msg, sig)
>> OP_OVER (txsig, txpubkey, msg, sig, msg)
>> push data pubkey (txsig, txpubkey, msg, sig, msg, pubkey)
>> OP_CHECKDATASIGVERIFY (txsig, txpubkey, msg)
>> ```
>> Now that msg is on the stack top, the script can write predicates on it,
>> resulting in the message being consumed and a true/false condition left on the stack: (txpubkey, txsig, boolean)
>> ```
>> OP_IF (txsig, txpubkey)
>> OP_DUP (txsig, txpubkey, txpubkey)
>> OP_HASH160 (txsig, txpubkey, address)
>> push <p2pkh spend address> (txsig, txpubkey, address, p2pkh spend address)
>> OP_EQUALVERIFY (txsig, txpubkey)
>> OP_CHECKSIG
>> OP_ELSE
>> (same as if clause but a different <p2pkh spend address>)
>> OP_ENDIF
>> ```
>>
>> History
>> -------
>>
>> This specification is based on Andrew Stone’s OP_DATASIGVERIFY proposal [6, 7]. It is modified from Stone's original proposal based on a synthesis of all the peer-review and feedback received [8].
>>
>> References
>> ----------
>>
>> [1] [OP_CHECKSIG](https://en.bitcoin.it/wiki/OP_CHECKSIG)
>>
>> [2] [Strict DER Encoding](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki)
>>
>> [3] [Low-S and Nullfail Specification](https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki)
>>
>> [4] [Bitcoin ABC implementation](https://reviews.bitcoinabc.org/D1621)
>>
>> [5] [Bitcoin ABC implementation update](https://reviews.bitcoinabc.org/D1646)
>>
>> [6] [Andrew Stone’s OP_DATASIGVERIFY](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.3.0.0/doc/opdatasigverify.md)
>>
>> [7] [Andrew Stone's article on Scripting](https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9)
>>
>> [8] [Peer Review of Andrew Stone's Proposal](https://github.com/bitcoincashorg/bitcoincash.org/pull/10)
>>
>>
>> --
>> @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/20210703/ba67ab0b/attachment-0001.html>;

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

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

In reply to nevent1q…8y2r
_________________________

📅 Original date posted:2021-07-03
📝 Original message:Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
specification for "CheckDataSig", more or less the same thing as
CHECKSIGFROMSTACK
https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
In contrast to Element's implementation, it does not have Element's bugs
around verify semantics and uses the nullfail rule, and there is a
specification document so it seemed like the easiest starting point for
discussion v.s. drafting something from scratch.

Does anyone have any issue with adapting this exact text and implementation
to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?

Note that with *just* CheckSigFromStack, while you can do some very
valuable use cases, but without OP_CAT it does not enable sophisticated
covenants (and as per
https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html just
CAT alone enables such uses).

Design questions worth considering as modifications:

1. Should CSFS require some sort of tagged hash? Very likely answer is no –
tags interfere with certain use cases
2. Should CSFS split the signature’s R & S value stack items for some
applications that otherwise may require OP_CAT? E.g. using a pinned R value
allows you to extract a private key if ever double signed, using 2 R values
allows pay-to-reveal-key contracts. Most likely answer is no, if that is
desired then OP_CAT can be introduced
3. Should CSFS support a cheap way to reference the taproot internal or
external key? Perhaps, can be handled with undefined upgradeable keytypes.
One might want to use the internal key, if the signed data should be valid
independent of the tapscript tree. One might want to use the external key,
if the data should only be valid for a single tapscript key + tree.
4. Should invalid public keys types be a NOP to support future extended
pubkey types?

Best,

Jeremy

---
layout: specification
title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
category: spec
date: 2018-08-20
activation: 1542300000
version: 0.6
---

OP_CHECKDATASIG
===============

OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is
valid with respect to a message and a public key.

OP_CHECKDATASIG permits data to be imported into a script, and have
its validity checked against some signing authority such as an
"Oracle".

OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be
implemented similarly to OP_CHECKSIG [1]. Conceptually, one could
imagine OP_CHECKSIG functionality being replaced by OP_CHECKDATASIG,
along with a separate Op Code to create a hash from the transaction
based on the SigHash algorithm.

OP_CHECKDATASIG Specification
-----------------------------

### Semantics

OP_CHECKDATASIG fails immediately if the stack is not well formed. To
be well formed, the stack must contain at least three elements
[`<sig>`, `<msg>`, `<pubKey>`] in this order where `<pubKey>` is the
top element and
* `<pubKey>` must be a validly encoded public key
* `<msg>` can be any string
* `<sig>` must follow the strict DER encoding as described in [2]
and the S-value of `<sig>` must be at most the curve order divided by
2 as described in [3]

If the stack is well formed, then OP_CHECKDATASIG pops the top three
elements [`<sig>`, `<msg>`, `<pubKey>`] from the stack and pushes true
onto the stack if `<sig>` is valid with respect to the raw
single-SHA256 hash of `<msg>` and `<pubKey>` using the secp256k1
elliptic curve. Otherwise, it pops three elements and pushes false
onto the stack in the case that `<sig>` is the empty string and fails
in all other cases.

Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature
does not match the supplied public key and message hash, and the
signature is not an empty byte array, the entire script fails.

### Opcode Number

OP_CHECKDATASIG uses the previously unused opcode number 186 (0xba in
hex encoding)

### SigOps

Signature operations accounting for OP_CHECKDATASIG shall be
calculated the same as OP_CHECKSIG. This means that each
OP_CHECKDATASIG shall be counted as one (1) SigOp.

### Activation

Use of OP_CHECKDATASIG, unless occuring in an unexecuted OP_IF branch,
will make the transaction invalid if it is included in a block where
the median timestamp of the prior 11 blocks is less than 1542300000.

### Unit Tests

- `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if 15 November 2018
protocol upgrade is not yet activated.
- `<sig> <msg> OP_CHECKDATASIG` fails if there are fewer than 3 items on stack.
- `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<pubKey>` is not a
validly encoded public key.
- `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<sig>` is not a
validly encoded signature with strict DER encoding.
- `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>`
is not empty and does not pass the Low S check.
- `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>`
is not empty and does not pass signature validation of `<msg>` and
`<pubKey>`.
- `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and
pushes false onto the stack if `<sig>` is an empty byte array.
- `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and
pushes true onto the stack if `<sig>` is a valid signature of `<msg>`
with respect to `<pubKey>`.

OP_CHECKDATASIGVERIFY Specification
-----------------------------------

### Semantics

OP_CHECKDATASIGVERIFY is equivalent to OP_CHECKDATASIG followed by
OP_VERIFY. It leaves nothing on the stack, and will cause the script
to fail immediately if the signature check does not pass.

### Opcode Number

OP_CHECKDATASIGVERIFY uses the previously unused opcode number 187
(0xbb in hex encoding)

### SigOps

Signature operations accounting for OP_CHECKDATASIGVERIFY shall be
calculated the same as OP_CHECKSIGVERIFY. This means that each
OP_CHECKDATASIGVERIFY shall be counted as one (1) SigOp.

### Activation

Use of OP_CHECKDATASIGVERIFY, unless occuring in an unexecuted OP_IF
branch, will make the transaction invalid if it is included in a block
where the median timestamp of the prior 11 blocks is less than
1542300000.

### Unit Tests

- `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if 15 November
2018 protocol upgrade is not yet activated.
- `<sig> <msg> OP_CHECKDATASIGVERIFY` fails if there are fewer than 3
item on stack.
- `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY`fails if `<pubKey>` is
not a validly encoded public key.
- `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is
not a validly encoded signature with strict DER encoding.
- `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if signature
`<sig>` is not empty and does not pass the Low S check.
- `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is
not a valid signature of `<msg>` with respect to `<pubKey>`.
- `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` pops the top three
stack elements if `<sig>` is a valid signature of `<msg>` with respect
to `<pubKey>`.

Sample Implementation [4, 5]
----------------------------

```c++
case OP_CHECKDATASIG:
case OP_CHECKDATASIGVERIFY: {
// Make sure this remains an error before activation.
if ((flags & SCRIPT_ENABLE_CHECKDATASIG) == 0) {
return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
}

// (sig message pubkey -- bool)
if (stack.size() < 3) {
return set_error(
serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
}

valtype &vchSig = stacktop(-3);
valtype &vchMessage = stacktop(-2);
valtype &vchPubKey = stacktop(-1);

if (!CheckDataSignatureEncoding(vchSig, flags,
serror) ||
!CheckPubKeyEncoding(vchPubKey, flags, serror)) {
// serror is set
return false;
}

bool fSuccess = false;
if (vchSig.size()) {
valtype vchHash(32);
CSHA256()
.Write(vchMessage.data(), vchMessage.size())
.Finalize(vchHash.data());
uint256 message(vchHash);
CPubKey pubkey(vchPubKey);
fSuccess = pubkey.Verify(message, vchSig);
}

if (!fSuccess && (flags & SCRIPT_VERIFY_NULLFAIL) &&
vchSig.size()) {
return set_error(serror, SCRIPT_ERR_SIG_NULLFAIL);
}

popstack(stack);
popstack(stack);
popstack(stack);
stack.push_back(fSuccess ? vchTrue : vchFalse);
if (opcode == OP_CHECKDATASIGVERIFY) {
if (fSuccess) {
popstack(stack);
} else {
return set_error(serror,
SCRIPT_ERR_CHECKDATASIGVERIFY);
}
}
} break;
```

Sample Usage
------------

The following example shows a spend and redeem script for a basic use
of CHECKDATASIG. This example validates the signature of some data,
provides a placeholder where you would then process that data, and
finally allows one of 2 signatures to spend based on the outcome of
the data processing.

### spend script:
```
push txsignature
push txpubkey
push msg
push sig
```
### redeem script:
```
(txsig, txpubkey msg, sig)
OP_OVER (txsig, txpubkey, msg, sig, msg)
push data pubkey (txsig, txpubkey, msg, sig, msg, pubkey)
OP_CHECKDATASIGVERIFY (txsig, txpubkey, msg)
```
Now that msg is on the stack top, the script can write predicates on it,
resulting in the message being consumed and a true/false condition
left on the stack: (txpubkey, txsig, boolean)
```
OP_IF (txsig, txpubkey)
OP_DUP (txsig, txpubkey, txpubkey)
OP_HASH160 (txsig, txpubkey, address)
push <p2pkh spend address> (txsig, txpubkey, address, p2pkh spend address)
OP_EQUALVERIFY (txsig, txpubkey)
OP_CHECKSIG
OP_ELSE
(same as if clause but a different <p2pkh spend address>)
OP_ENDIF
```

History
-------

This specification is based on Andrew Stone’s OP_DATASIGVERIFY
proposal [6, 7]. It is modified from Stone's original proposal based
on a synthesis of all the peer-review and feedback received [8].

References
----------

[1] [OP_CHECKSIG](https://en.bitcoin.it/wiki/OP_CHECKSIG)

[2] [Strict DER
Encoding](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki)

[3] [Low-S and Nullfail
Specification](https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki)

[4] [Bitcoin ABC implementation](https://reviews.bitcoinabc.org/D1621)

[5] [Bitcoin ABC implementation update](https://reviews.bitcoinabc.org/D1646)

[6] [Andrew Stone’s
OP_DATASIGVERIFY](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.3.0.0/doc/opdatasigverify.md)

[7] [Andrew Stone's article on
Scripting](https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9)

[8] [Peer Review of Andrew Stone's
Proposal](https://github.com/bitcoincashorg/bitcoincash.org/pull/10)

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210703/f38c654f/attachment-0001.html>;

📅 Original date posted:2021-07-03 📝 Original message:Yep -- ...

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

In reply to nevent1q…ha6f
_________________________

📅 Original date posted:2021-07-03
📝 Original message:Yep -- sorry for the confusing notation but seems like you got it. C++
templates have this issue too btw :)

One cool thing is that if you have op_add for arbitrary width integers or
op_cat you can also make a quantum proof signature by signing the signature
made with checksig with the lamport.

There are a couple gotchas wrt crypto assumptions on that but I'll write it
up soon 🙂 it also works better in segwit V0 because there's no keypath
spend -- that breaks the quantum proofness of this scheme.

On Fri, Jul 2, 2021, 4:58 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Jeremy,
>
> > Dear Bitcoin Devs,
> >
> > It recently occurred to me that it's possible to do a lamport signature
> in script for arithmetic values by using a binary expanded representation.
> There are some applications that might benefit from this and I don't recall
> seeing it discussed elsewhere, but would be happy for a citation/reference
> to the technique.
> >
> > blog post here, https://rubin.io/blog/2021/07/02/signing-5-bytes/, text
> reproduced below
> >
> > There are two insights in this post:
> > 1. to use a bitwise expansion of the number
> > 2. to use a lamport signature
> > Let's look at the code in python and then translate to bitcoin script:
> > ```python
> > def add_bit(idx, preimage, image_0, image_1):
> > s = sha256(preimage)
> > if s == image_1:
> > return (1 << idx)
> > if s == image_0:
> > return 0
> > else:
> > assert False
> > def get_signed_number(witnesses : List[Hash], keys : List[Tuple[Hash,
> Hash]]):
> > acc = 0
> > for (idx, preimage) in enumerate(witnesses):
> > acc += add_bit(idx, preimage, keys[idx][0], keys[idx][1])
> > return x
> > ```
> > So what's going on here? The signer generates a key which is a list of
> pairs of
> > hash images to create the script.
> > To sign, the signer provides a witness of a list of preimages that match
> one or the other.
> > During validation, the network adds up a weighted value per preimage and
> checks
> > that there are no left out values.
> > Let's imagine a concrete use case: I want a third party to post-hoc sign
> a sequence lock. This is 16 bits.
> > I can form the following script:
> > ```
> > <pk> checksigverify
> > 0
> > SWAP sha256 DUP <H(K_0_1)> EQUAL IF DROP <1> ADD ELSE <H(K_0_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_1_1)> EQUAL IF DROP <1<<1> ADD ELSE <H(K_1_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_2_1)> EQUAL IF DROP <1<<2> ADD ELSE <H(K_2_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_3_1)> EQUAL IF DROP <1<<3> ADD ELSE <H(K_3_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_4_1)> EQUAL IF DROP <1<<4> ADD ELSE <H(K_4_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_5_1)> EQUAL IF DROP <1<<5> ADD ELSE <H(K_5_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_6_1)> EQUAL IF DROP <1<<6> ADD ELSE <H(K_6_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_7_1)> EQUAL IF DROP <1<<7> ADD ELSE <H(K_7_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_8_1)> EQUAL IF DROP <1<<8> ADD ELSE <H(K_8_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_9_1)> EQUAL IF DROP <1<<9> ADD ELSE <H(K_9_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_10_1)> EQUAL IF DROP <1<<10> ADD ELSE <H(K_10_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_11_1)> EQUAL IF DROP <1<<11> ADD ELSE <H(K_11_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_12_1)> EQUAL IF DROP <1<<12> ADD ELSE <H(K_12_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_13_1)> EQUAL IF DROP <1<<13> ADD ELSE <H(K_13_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_14_1)> EQUAL IF DROP <1<<14> ADD ELSE <H(K_14_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_15_1)> EQUAL IF DROP <1<<15> ADD ELSE <H(K_15_0)>
> EQUALVERIFY ENDIF
> > CHECKSEQUENCEVERIFY
> > ```
>
> This took a bit of thinking to understand, mostly because you use the `<<`
> operator in a syntax that uses `< >` as delimiters, which was mildly
> confusing --- at first I thought you were pushing some kind of nested
> SCRIPT representation, but in any case, replacing it with the actual
> numbers is a little less confusing on the syntax front, and I think (hope?)
> most people who can understand `1<<1` have also memorized the first few
> powers of 2....
>
> > ```
> > <pk> checksigverify
> > 0
> > SWAP sha256 DUP <H(K_0_1)> EQUAL IF DROP <1> ADD ELSE <H(K_0_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_1_1)> EQUAL IF DROP <2> ADD ELSE <H(K_1_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_2_1)> EQUAL IF DROP <4> ADD ELSE <H(K_2_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_3_1)> EQUAL IF DROP <8> ADD ELSE <H(K_3_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_4_1)> EQUAL IF DROP <16> ADD ELSE <H(K_4_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_5_1)> EQUAL IF DROP <32> ADD ELSE <H(K_5_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_6_1)> EQUAL IF DROP <64> ADD ELSE <H(K_6_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_7_1)> EQUAL IF DROP <128> ADD ELSE <H(K_7_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_8_1)> EQUAL IF DROP <256> ADD ELSE <H(K_8_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_9_1)> EQUAL IF DROP <512> ADD ELSE <H(K_9_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_10_1)> EQUAL IF DROP <1024> ADD ELSE <H(K_10_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_11_1)> EQUAL IF DROP <2048> ADD ELSE <H(K_11_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_12_1)> EQUAL IF DROP <4096> ADD ELSE <H(K_12_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_13_1)> EQUAL IF DROP <8192> ADD ELSE <H(K_13_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_14_1)> EQUAL IF DROP <16384> ADD ELSE <H(K_14_0)>
> EQUALVERIFY ENDIF
> > SWAP sha256 DUP <H(K_15_1)> EQUAL IF DROP <32768> ADD ELSE <H(K_15_0)>
> EQUALVERIFY ENDIF
> > CHECKSEQUENCEVERIFY
> > ```
>
> On the other hand LOL WTF, this is cool.
>
> Basically you are showing that if we enable something as innocuous as
> `OP_ADD`, we can implement Lamport signatures for **arbitrary** values
> representable in small binary numbers (16 bits in the above example).
>
> I was thinking "why not Merkle signatures" since the pubkey would be much
> smaller but the signature would be much larger, but (a) the SCRIPT would be
> much more complicated and (b) in modern Bitcoin, the above SCRIPT would be
> in the witness stack anyway so there is no advantage to pushing the size
> towards the signature rather than the pubkey, they all have the same
> weight, and since both Lamport and Merkle are single-use-only and we do not
> want to encourage pubkey reuse even if they were not, the Merkle has much
> larger signature size, so Merkle sigs end up more expensive.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210702/e507efdd/attachment-0001.html>;

📅 Original date posted:2021-05-10 📝 Original message:re: 2, ...

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

In reply to nevent1q…q8c3
_________________________

📅 Original date posted:2021-05-10
📝 Original message:re: 2, there's been some promising developments with Verifiable Delay
Functions that make me think that the block regulation problems are
solvable without requiring brute-force search proof of work. Are those
inapplicable for some reason?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210510/ec6b1926/attachment.html>;

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

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

In reply to nevent1q…534g
_________________________

📅 Original date posted:2021-05-07
📝 Original message:Proof-of-stake tends towards oligopolistic control, which is antithetical
to bitcoin.

Proof-of-stake also has some other security issues that make it a bad
substitute for Proof-of-work with respect to equivocation (reorgs).

Overall you'll find me *personally* in the camp that it's OK to explore
non-PoW means of consensus long term that can keep the network in consensus
in a more capital efficient manner, but that proof-of-stake is not such a
substitute. Other Bitcoiners will disagree with this invariably, but if you
truly have a novel solution for Byzantine Generals, it would be a major
contribution to not just Bitcoin but the field of computer science as a
whole and would likely get due consideration.

What's difficult is that Bitcoin PoW has some very specific properties that
may or may not be desirable around e.g. fairness that might be difficult to
ensure in other systems, so there is probably more to the puzzle than just
consensus.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Fri, May 7, 2021 at 3:50 PM SatoshiSingh via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello list,
>
> I am a lurker here and like many of you I worry about the energy usage of
> bitcoin mining. I understand a lot mining happens with renewable resources
> but the impact is still high.
>
> I want to get your opinion on implementing proof of stake for bitcoin
> mining in future. For now, proof of stake is still untested and not battle
> tested like proof of work. Though someday it will be.
>
> In the following years we'll be seeing proof of stake being implemented.
> Smaller networks can test PoS which is a luxury bitcoin can't afford.
> Here's how I see this the possibilities:
>
> 1 - Proof of stake isn't a good enough security mechanism
> 2 - Proof of state is a good security mechanism and works as intended
>
> IF PoS turns out to be good after battle testing, would you consider
> implementing it for Bitcoin? I understand this would invoke a lot of
> controversies and a hard fork that no one likes. But its important enough
> to consider a hard fork. What are your opinions provided PoS does work?
>
> Love from India.
> _______________________________________________
> 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/20210507/bdc3653f/attachment.html>;

📅 Original date posted:2021-04-23 📝 Original message:ACK ...

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

In reply to nevent1q…5ls9
_________________________

📅 Original date posted:2021-04-23
📝 Original message:ACK adding Kalle.

Kalle is a qualified reviewer / editor and well suited for this role.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Thu, Apr 22, 2021 at 7:09 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
> assist in merging PRs into the bips git repo.
>
> Since there is no explicit process to adding BIP editors, IMO it should be
> fine to use BIP 2's Process BIP progression:
>
> > A process BIP may change status from Draft to Active when it achieves
> > rough consensus on the mailing list. Such a proposal is said to have
> > rough consensus if it has been open to discussion on the development
> > mailing list for at least one month, and no person maintains any
> > unaddressed substantiated objections to it.
>
> A Process BIP could be opened for each new editor, but IMO that is
> unnecessary. If anyone feels there is a need for a new Process BIP, we can
> go
> that route, but there is prior precedent for BIP editors appointing new
> BIP
> editors, so I think this should be fine.
>
> Please speak up soon if you disagree.
>
> 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/20210422/322af051/attachment.html>;

📅 Original date posted:2021-04-22 📝 Original message:This ...

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

In reply to nevent1q…7eaj
_________________________

📅 Original date posted:2021-04-22
📝 Original message:This letter is particularly aimed at addressing Rusty Russell's quest for a
development process that respects all groups in a balance of powers.
However, in the spirit of open discussion, I'm sending it directly to the
list.

This proposal is aimed to be compatible with Taproot's ST, and I hope will
help us form some rough consensus around what we try next. Some of the
concepts here are synthesized from what I've seen discussed, but I haven't
included citations of anyone's specific ideas as I'm not sure of the exact
provenance -- I won't claim to have invented this per se, I'm trying to
capture the zeitgeist of what anyone might think to be the process if
pressed to draw it out. Lemme know how I did.

The specific parameters are up for debate, but I'm trying to make sure I've
captured the relevant state transitions.

In this diagram time flows left-to-right, and transitions happen at the
beginning, end, or middle of a block of time. It should be relatively clear
when things happen, but if not, please ask to clarify.

[image: Activation.png]

Clarifications:
- ST: Speedy trial, whereby > T% signals on a block activate the rule
- neg-ST: Speedy Trial, whereby >X% signals on a block Reject the rule
- neg-ST and ST at the same time on different bits: 11 or 00 are "abstain"
votes and are discarded. only 10 or 01 are counted. The purpose of
simultaneous bits is to allow both earlier lock in and to permit early
failure, rather than just one or the other.
- PoW Fork: If a new rule is active, but there is insufficient hashrate,
the rule must be abandoned or PoW must be changed to minimize disruption.
In order to minimize disruption, a node will consider an alternative PoW
chain if < 1/4 of the typical hash rate is seen for a day. Alternative PoW
is defined as SHA-256 10,000 layers, and starts at low difficulty. This is
selected to be maximally similar to Bitcoin's existing PoW, but
sufficiently different to obviate extant ASICS. A node will consider the
new PoW to be equal in value to the old PoW, and will select between the
two based on most-work. Work can be either within a single chain. The new
PoW should have a difficulty adjustment every day for the first month, at
which point, it will relax to every 2 weeks. The details of this should be
described in a separate BIP.
- PoW Fork Lockin: PoW fork is only *required* once the new rule is active.
Thus it's not required in the case of mandatory signalling to force the
signalling contemporaneously, but it can be used to commit to forking the
PoW at some time in the future. It may make sense to not activate the new
rule till the new PoW is active. The game theory of this should be studied
carefully, it is my opinion that the safest option is to PoW fork during
signalling as otherwise miners may protest progress at all.
- Changes: Any time the underlying activation proposal is changed, the
process is restarted. E.g., suppose taproot is rejected because Quantum
Scaries, and we hash the key. The process restarts from the beginning.
Restarts can only occur during quieting periods.
- Quieting Period 1: In the first quieting period, if reached, the "Bitcoin
Core Community" can release the next step, or change the BIP. I left out
failing in this period as a change or a redeployment should always be
attempted.
- Quieting Period 2: In the second quieting period, the outcome is either
to reject the change entirely or to agree to force it. The "Bitcoin Core
Community" may also prepare the release at this stage, and sign, but should
re-label the client as "Bitcoin Community's <Feature> Forcing Client". A
release labeled "Bitcoin Core" may also be made without mandatory
signalling and without forced activation can also be made, such a client
should have (depending on if the flag day is to use signalling) either
ability to activate in response to signalling or a hidden
<feature>activeathash parameter to allow clients to enable the feature
post-hoc of the activating block.
- Forced Signalling: It's unclear to me the merit of forced signalling
being 90% of 2016 blocks v.s. 90% of 100 blocks. A shorter forced signaling
assuages certain concerns around lost hashrate -- 1 day of disruption is a
lot better than 2 weeks.
- Timeline: As spec'd above, this whole process takes about 2 years worst
case. ST1 0 months; Quieting 1 at 3 months; ST2 at 6 months; Quieting 2 at
9 months, final attempt at 1 year. The Forcing client period should
probably be 1 yr till active. This is *a bit* slower than the "BIP8
LOT=True UASF Client", but I think not so much slower that it's unworkable.

The most contentious part of this I intuit to be the PoW Fork -- please,
let's avoid discussing the mechanic of how to most safely accomplish this.
The main point of including it in this diagram is to emphasize that if you
commit to being on a minority chain with because of a rule activation with,
say, 5% hashrate, you would experience very tangible disruption. In theory,
every fork upgrade (even signalled) entails such a risk, but we assume some
level of miner honesty (unfortunately!) that they never signal falsely.
This may be a bad assumption with mandatory signalling. The alternative is
to permit hard forks in our diagram, and allow users to downgrade their
client and deactivate this rule. Since this can lead to loss of funds, we
do not consider this a safe option, and it is a hardfork as well so is
technically compatible with the "PoW fork" branch.

Questions I have:

1) What state transitions are missing from this diagram? Are there other
paths that should be included?
2) Is it ever feasible to make a change to the upgrade and not restart the
whole process?
3) How long should all of the periods be? Can the 1st 2 ST's be 3 month?
Should we make the second one 6 month? Does it depend on previous signalled
hashrate?
4) Do we ever adjust signalling thresholds?
5) Does forced signalling need to be 2016 blocks?
6) In the second ST should the min active height be allowed to be within
signalling time if > 3 mo?
7) Under what circumstances would we *want* to skip the second ST period
and directly signal? What would we lose by committing to not skipping it,
ever (6 months?).
8) I purposefully left the purple edge from ST2 bit 2 to Quieting 2: in
theory, this edge is not there because it is overruled by the neg-ST
failing to fail. Under what circumstances might we give this precedence
over neg-ST? E.g., signalling activate < 50%?
9) How much parameter flexibility do we have during Quieting periods?
Should we be fixed beforehand?
10) who wants to write the software for any of this... *noses*
11) do we need to hard-code the PoW fork ahead of time? Or can it just be
"prepared" as an alt binary in case of emergency?

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210422/f50fe48c/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Activation.png
Type: image/png
Size: 81125 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210422/f50fe48c/attachment-0001.png>;

📅 Original date posted:2021-04-24 📝 Original message:Inline ...

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

In reply to nevent1q…ux33
_________________________

📅 Original date posted:2021-04-24
📝 Original message:Inline responses

On Fri, Apr 23, 2021, 11:18 AM David A. Harding <dave at dtrt.org> wrote:

> On Tue, Apr 20, 2021 at 08:46:07AM -0700, Jeremy via bitcoin-dev wrote:
>
>
>
>
>
> * > Script is technically "too wide" a type as what I really want is to >
> only return coins with known output types. I don't understand this
> concern. If script is too wide a type, then OP_RETURN being a scriptPubKey
> of arbitrary length up to almost a million bytes is also going to be too
> wide, right?*
>

I meant the type itself is too wide, not the length of the value. As in
Script can represent things we know nothing about. There's a bit of leaky
abstraction since the values self describe the type they are. For addresses
it's just representations IMO for the standard output types one might
expect from standard software.

Btw: According to... Oh wait... You?
https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey
the max size is 10k bytes. Still probably too big for an address, but I'd
be ok with making op_return addresses only defined for a small size (e.g.
128 bytes?)

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * > 1) Should it be human readable & checksummed or encoded? It should
> absolutely not be human readable in the sense of being meaningful to
> humans. We've seen in the past that tools and sites that display OP_RETURN
> data as ASCII encourage people to put text in the block chain that is
> offensive and illegal. This puts people running nodes at risk of social
> and legal intervention. Bitcoin's premissionless nature means we can't
> stop people from creating such problems, but we can lower the risk by
> having our tools default to meaningless representations of OP_RETURN data.
> The best advice I've seen is to display OP_RETURN data in hex. It's still
> possible to say things like "dead beef" with that, but significant abuse is
> hard. This will, of course, make even 80 byte OP_RETURN "addresses" very
> long.*
>

Is it possible/easy to, say, using bech32m make an inappropriate message in
the address? You'd have to write the message, then see what it decodes to
without checking, and then re encode? I guess this is worse than hex?

But it seems this is a general thing... If you wanted an inappropriate
message you could therefore just use bech32m addressed outputs.

> >
>
>
>
> * 2) Should it have a fixed length of max 40-80 bytes or should we support
> > arbitrary length strings? If it doesn't support the fell range,
> somebody's just going to complain later and there will have to be a v2
> address.*
>

So 10,000 bytes? Or do we care to represent outputs that would be consensus
invalid?

>
>
>
>
>
>
>
>
>
>
>
> * > 3) Should it be possible (i.e., from core) to pay into such an
> OP_RETURN or > should we categorize OP_RETURNS as a non-payable address
> type (and just use > it for parsing blockdata) I don't think including
> arbitrary data in the block chain is something that's currently useful for
> typical end users, and applications that want to use OP_RETURN with Bitcoin
> Core can already call create(psbt|rawtransaction) with the `data` field, so
> I'd be mildly opposed in including such a feature in Bitcoin Core's
> wallet. If at least a few other wallets add the feature to pay OP_RETURN
> "addresses" and it seems popular, then I'm wrong and so I would probably
> then change my position.*
>

One of the nice things is that the current psbt interface uses a blind
union type whereby the entires in an array are either [address, amount] or
["data", hex]. Having an address type would allow more uniform handling,
which is convenient for strongly typed RPC bindings (e.g. rust bitcoin uses
a hashmap of address to amount so without a patch you can't create op
returns).

>
>
>
>
>
> * Regarding "parsing block data", I don't think there's any need to change
> Bitcoin Core's current representation of OP_RETURN outputs (which is just
> showing the hex-encoded script in RPC output). For any program needing
> OP_RETURN output, hex format is going to be a the next best thing to
> getting it in raw binary. Any other address format is going to be equal or
> more work*.
>

Thats a fair point. I'm mostly thinking about this in the context of
strongly typed languages/frameworks where you'll get an address object or
enum out, rather than something *stringly* typed. But yes in terms of
stringy languages I don't think any changes are needed.

*Additionally, as mentioned in the other thread about OP_RETURN this*
*week, increasing transaction fees should increasingly push uses of*
*OP_RETURN off the network or into more efficient constructions, so it*
*doesn't seem warranted to me to spend a lot of time trying to optimize*
*how we use it when we'll be using it less and less over time.*

Hmm. I agree it should get priced out over time. However there are some
uses for this kind of stuff. E.g. stealth addresses, or a single instance
of open time stamps.

The main reason I think they merit some sort of std address type is that
I'm writing software that can handle things that we might reasonably see on
the network. And it's relatively annoying (without a custom type) to
represent OP_RETURN as a not-exceptional type of thing.

In my code what I have done is added the following type:

pub enum ExtendedAddress {
/// A regular standard address type
Address(bitcoin::Address),
/// An OP_RETURN
OpReturn(OpReturn),
/// Unknown
Unknown(bitcoin::Script),
}
Which works more or less fine, but I would much prefer to not have to do
this in a custom way, as opposed to a way which is defined in a standard
manner across all software (after all, that's the point of standards).

Best,

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210424/a12ae065/attachment-0001.html>;

📅 Original date posted:2021-04-16 📝 Original message:I ...

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

In reply to nevent1q…5egl
_________________________

📅 Original date posted:2021-04-16
📝 Original message:I think you need to hard deprecate the PoW for this to work, otherwise all
old miners are like "toxic waste".

Imagine one miner turns on a S9 and then ramps up difficulty for everyone
else.

On Fri, Apr 16, 2021, 2:08 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Not sure of the best place to workshop ideas, so please take this with
> a grain of salt.
>
> Starting with 3 assumptions:
>
> - assume that there exists a proof-of-burn that, for Bitcoin's
> purposes, accurately-enough models the investment in and development
> of ASICs to maintain miner incentive.
> - assume the resulting timing problem "how much burn is enough to keep
> blocks 10 minutes apart and what does that even mean" is also...
> perfectly solvable
> - assume "everyone unanimously loves this idea"
>
> The transition *could* look like this:
>
> - validating nodes begin to require proof-of-burn, in addition to
> proof-of-work (soft fork)
> - the extra expense makes it more expensive for miners, so POW slowly
> drops
> - on a predefined schedule, POB required is increased to 100% of the
> "required work" to mine
>
> Given all of that, am I correct in thinking that a hard fork would not
> be necessary?
>
> IE: We could transition to another "required proof" - such as a
> quantum POW or a POB (above) or something else .... in a back-compat
> way (existing nodes not aware of the rules would continue to
> validate).
> _______________________________________________
> 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/20210416/1d9aee05/attachment.html>;

📅 Original date posted:2021-04-10 📝 Original message:I ...

2023-06-07T20:31:33+02:00

In reply to nevent1q…rrkc
_________________________

📅 Original date posted:2021-04-10
📝 Original message:I concur that reviewing #21377 is the best path at this time.

However, I want to draw attention to the middle road here:

If Core chooses to not release activation params (which has been discussed
as a general concept previously), #21377 can also be used to safely issue a
community release.

It's a false dichotomy between ST released by Core and a BIP8 UASF.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Sat, Apr 10, 2021 at 9:48 AM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Bitcoin Mechanic
>
> I will attend but I will be looking at Core PR #21377 over the next
> couple of days and I would encourage other reviewers to review that PR
> too. If that PR is merged into Core I would strongly recommend any
> alternative release be fully compatible with the activation parameters
> in Core.
>
> We can discuss in the meeting what we think the cut off date should be
> for when Core should no longer be a consideration. Personally I think
> (and hope) we will see progress on #21377 in the coming days.
>
> For the sake of the mailing list Bitcoin Mechanic has set up a meeting
> to discuss an alternative release to Core with Taproot activation
> code.
>
> Thanks
> Michael
>
> > Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC
>
> > The focus of the meeting will be ratifying the Taproot activation plan
> previously discussed at the March 16th meeting (aka 2021-03 Plan Y as
> summarized here):
>
>
> https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit#gid=0
>
> > While there was never any consensus reached on the LOT parameter, there
> appears to be consensus on BIP8 and the remaining parameters, and more than
> sufficient support for LOT=True to proceed safely.
>
> > Miners will have 18 months in which to signal and accelerate activation.
> If not, taproot will activate regardless.
>
> > With a majority of the economy running this it will guarantee eventual
> lock-in of taproot with the smallest chance of a chain split.
>
> > As a reminder, the channel is also open for ongoing discussion 24/7, and
> there is a web chat client here:
>
> > https://webchat.freenode.net/?channel=##taproot-activation
>
> > Best,
>
> > Bitcoin Mechanic
>
> > Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>
>
> --
> Michael Folkson
> Email: michaelfolkson at gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> 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/20210410/94434db8/attachment-0001.html>;

📅 Original date posted:2021-04-06 📝 Original message:I ...

2023-06-07T20:31:08+02:00

In reply to nevent1q…2w69
_________________________

📅 Original date posted:2021-04-06
📝 Original message:I found the "50% chance of activating" a bit confusing of a watermark, so I
asked AJ if he didn't mind producing and tabulating the 10% chance, 50%
chance, and 90% chance to show the sharpness of the bounds better. Each
category below shows the single-shot and repeated trial odds for the range
of trials (5 to 7). Additionally, I ran the 99% & 1% band to show that
we're likely to not have a false positive if < 87% is signalling nor a
false negative if > 90% is signalling

1%:
87.61% hashpower gives 0.20188% chance of success for 0.01005% chance
over 5 trials
87.47% hashpower gives 0.14044% chance of success for 0.00979% chance
over 7 trials
86.74% hashpower gives 0.01929% chance of success for 0.00979% chance
over 51 trials
86.74% hashpower gives 0.02080% chance of success for 0.01138% chance
over 55 trials

99%:
89.34% hashpower gives 60.19226% chance of success for 0.99000% chance
over 5 trials
89.08% hashpower gives 48.20380% chance of success for 0.99000% chance
over 7 trials

87.94% hashpower gives 8.63591% chance of success for 0.99001% chance
over 51 trials
87.90% hashpower gives 8.03152% chance of success for 0.99000% chance
over 55 trials

I was also curious to see what hashrate we'd need to have the classic 5 9's
of reliability if we were to only have *two* periods to signal. This serves
a decent check for the situation where the earlier periods in a ST should
be discounted (i.e., P(signals> 90% | first 3 periods) = 0) because miners
still need time to upgrade.

91.03% hashpower gives 99.68578% chance of success for 0.99999% chance over
2 trials

I believe this demonstrates more strongly that MTP can be used to ensure a
smooth upgrade.

------------------------

Should've been 1815, and seems like I had some older code that deals
with precision better, so:

10%:
88.15% gives 2.08538% chance of success for 0.10001% chance over 5 trials
87.98% gives 1.49100% chance of success for 0.09982% chance over 7 trials

87.16% gives 0.20610% chance of success for 0.09987% chance over 51
trials
87.13% gives 0.18834% chance of success for 0.09849% chance over 55
trials

50%:
88.67% gives 12.94200% chance of success for 0.49992% chance over 5
trials
88.47% gives 9.42506% chance of success for 0.49990% chance over 7 trials

87.53% gives 1.35127% chance of success for 0.50035% chance over 51
trials
87.50% gives 1.25229% chance of success for 0.49998% chance over 55
trials

90%:
89.07% gives 36.90722% chance of success for 0.90002% chance over 5
trials
88.83% gives 28.02839% chance of success for 0.89997% chance over 7
trials

87.78% gives 4.41568% chance of success for 0.90006% chance over 51
trials
87.75% gives 4.09983% chance of success for 0.89999% chance over 55
trials

So 0.24% is the biggest difference for 5-7 trials at 90%, but the entire
range is under 2% anyway (87.13% for 55 trials to get 10% vs 89.07%
for 5 trials to get 90%).

Note, each "trial" is a retarget period here...

Code:
https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-repeated_trials-py

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Mon, Apr 5, 2021 at 3:35 AM Anthony Towns <aj at erisian.com.au> wrote:

> On Sat, Apr 03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote:
> > As such, the main conversation in this agenda item is
> > around the pros/cons of height or MTP and determining if we can reach
> consensus
> > on either approach.
>
> Here's some numbers.
>
> Given a desired signalling period of xxx days, where signaling begins
> on the first retarget boundary after the starttime and ends on the last
> retarget boundary before the endtime, this is how many retarget periods
> you get (based on blocks since 2015-01-01):
>
> 90 days: mainnet 5-7 full 2016-block retarget periods
> 180 days: mainnet 11-14
> 365 days: mainnet 25-27
> 730 days: mainnet 51-55
>
> (This applies to non-signalling periods like the activation/lock in delay
> too of course. If you change it so that it ends at the first retarget
> period after endtime, all the values just get incremented -- ie, 6-8,
> 12-15 etc)
>
> If I've got the maths right, then requiring 1814 of 2016 blocks to signal,
> means that having 7 periods instead of 5 lets you get a 50% chance of
> successful activation by maintaining 89.04% of hashpower over the entire
> period instead of 89.17%, while 55 periods instead of 51 gives you a 50%
> chance of success with 88.38% hashpower instead of 88.40% hashpower.
> So the "repeated trials" part doesn't look like it has any significant
> effect on mainnet.
>
> If you target yy periods instead of xxx days, starting and ending on a
> retarget boundary, you get the following stats from the last few years
> of mainnet (again starting at 2015-01-01):
>
> 1 period: mainnet 11-17 days (range 5.2 days)
> 7 periods: mainnet 87-103 days (range 15.4 days)
> 13 periods: mainnet 166-185 days (range 17.9 days)
> 27 periods: mainnet 352-377 days (range 24.4 days)
> 54 periods: mainnet 711-747 days (range 35.0 days)
>
> As far as I can see the questions that matter are:
>
> * is signalling still possible by the time enough miners have upgraded
> and are ready to start signalling?
>
> * have nodes upgraded to enforce the new rules by the time activation
> occurs, if it occurs?
>
> But both those benefit from less real time variance, rather than less
> variance in the numbers of signalling periods, at least in every way
> that I can think of.
>
> Corresponding numbers for testnet:
>
> 90 days: testnet 5-85
> 180 days: testnet 23-131
> 365 days: testnet 70-224
> 730 days: testnet 176-390
>
> (A 50% chance of activating within 5 periods requires sustaining 89.18%
> hashpower; within 85 periods, 88.26% hashpower; far smaller differences
> with all the other ranges -- of course, presumably the only way the
> higher block rates ever actually happen is by someone pointing an ASIC at
> testnet, and thus controlling 100% of blocks for multiple periods anyway)
>
> 1 period: testnet 5.6minutes-26 days (range 26.5 days)
> 13 periods: testnet 1-135 days (range 133.5 days)
> 27 periods: testnet 13-192 days (range 178.3 days)
> 54 periods: testnet 39-283 days (range 243.1 days)
> 100 periods: testnet 114-476 days (range 360.9 days)
> (this is the value used in [0] in order to ensure 3 months'
> worth of signalling is available)
> 132 periods: testnet 184-583 days (range 398.1 days)
> 225 periods: testnet 365-877 days (range 510.7 days)
> 390 periods: testnet 725-1403 days (range 677.1 days)
>
> [0] https://github.com/bitcoin/bips/pull/1081#pullrequestreview-621934640
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210405/6228cbf2/attachment-0001.html>;

📅 Original date posted:2021-03-06 📝 Original message:Thank ...

2023-06-07T20:30:29+02:00

In reply to nevent1q…c48d
_________________________

📅 Original date posted:2021-03-06
📝 Original message:Thank you for resurfacing and collating this concept.

At this time I don't see major issues with this course of action and think
it represents not only a reasonable compromise between all different
perspectives, but also gives us an opportunity to learn more about less
'slow' yet safe consensus upgrades. In particular, I am very happy to see
the earliest activation concept included.

Best,

Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Fri, Mar 5, 2021 at 7:44 PM David A. Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On the ##taproot-activation IRC channel, Russell O'Connor recently
> proposed a modification of the "Let's see what happens" activation
> proposal.[1] The idea received significant discussion and seemed
> acceptable to several people who could not previously agree on a
> proposal (although this doesn't necessarily make it their first
> choice). The following is my attempt at a description.
>
> 1. Start soon: shortly after the release of software containing this
> proposed activation logic, nodes will begin counting blocks towards
> the 90% threshold required to lock in taproot.[2]
>
> 2. Stop soon: if the lockin threshold isn't reached within approximately
> three months, the activation attempt fails. There is no mandatory
> activation and everyone is encouraged to try again using different
> activation parameters.
>
> 2. Delayed activation: in the happy occasion where the lockin threshold
> is reached, taproot is guaranteed to eventually activate---but not
> until approximately six months after signal tracking started.
>
> ## Example timeline
>
> (All dates approximate; see the section below about BIP9 vs BIP8.)
>
> - T+0: release of one or more full nodes with activation code
> - T+14: signal tracking begins
> - T+28: earliest possible lock in
> - T+104: locked in by this date or need to try a different activation
> process
> - T+194: activation (if lockin occurred)
>
> ## Analysis
>
> The goal of Speedy Trial is to allow a taproot activation attempt to
> either quickly succeed or quickly fail---without compromising safety in
> either case. Details below:
>
> ### Mitigating the problems of early success
>
> New rules added in a soft fork need to be enforced by a large part of
> the economy or there's a risk that a long chain of blocks breaking the
> rules will be accepted by some users and rejected by others, causing a
> chain split that can result in large direct losses to transaction
> receivers and potentially even larger indirect losses to holders due to
> reduced confidence in the safety of the Bitcoin system.
>
> One step developers have taken in the past to ensure widespread adoption
> of new consensus rules is programming in a delay between the time software
> with those rules is expected to be released and when the software starts
> tracking which blocks signal for activation. For example:
>
> Soft fork | Release | Start | Delta
> -----------------+------------+------------+----------
> BIP68 (v0.12.1) | 2016-04-15 | 2016-05-11 | 26 days
> BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
>
> Sources: BitcoinCore.org,
> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
>
> Speedy Trial replaces most of that upfront delay with a backend delay.
> No matter how fast taproot's activation threshold is reached by miners,
> there will be six months between the time signal tracking starts and when
> nodes will begin enforcing taproot's rules. This gives the userbase even
> more time to upgrade than if we had used the most recently proposed start
> date for a BIP8 activation (~July 23rd).[2]
>
> ### Succeed, or fail fast
>
> The earlier version of this proposal was documented over 200 days ago[3]
> and taproot's underlying code was merged into Bitcoin Core over 140 days
> ago.[4] If we had started Speedy Trial at the time taproot
> was merged (which is a bit unrealistic), we would've either be less than
> two months away from having taproot or we would have moved on to the
> next activation attempt over a month ago.
>
> Instead, we've debated at length and don't appear to be any closer to
> what I think is a widely acceptable solution than when the mailing list
> began discussing post-segwit activation schemes over a year ago.[5] I
> think Speedy Trial is a way to generate fast progress that will either
> end the debate (for now, if activation is successful) or give us some
> actual data upon which to base future taproot activation proposals.
>
> Of course, for those who enjoy the debate, discussion can continue while
> waiting for the results of Speedy Trial.
>
> ### Base activation protocol
>
> The idea can be implemented on top of either Bitcoin Core's existing
> BIP9 code or its proposed BIP8 patchset.[6]
>
> - BIP9 uses two time-based[7] parameters, starttime and timeout. Using
> these values plus a time-based parameter for the minimum activation
> delay would give three months for miners to activate taproot, but some
> of that time near the start or the end might not be usable due to
> signals only being measured in full retarget periods. However, the
> six month time for users to upgrade their node would be not be
> affected by either slow or fast block production.
>
> BIP9 is already part of Bitcoin Core and I think the changes being
> proposed would be relatively small, resulting in a small patch that
> could be easy to review.
>
> - BIP8 uses two height-based parameters, startheight and timeoutheight.
> Using height values would ensure miners had a certain number of
> retarget periods (6) to lock in taproot and that there'd be a certain
> number of blocks (about 24,000) until activation, although latest lock
> in and expected activation could occur moderately earlier or later
> than the estimated three and six months.
>
> BIP8 would likely be used if Speedy Trial fails, so it could be
> advantageous to base this proposal on BIP8 so that we gain
> experience running that code in production.
>
> For additional discussion about using times versus heights, see today's
> log for ##taproot-activation.[11]
>
> ### Additional concerns
>
> - Encourages false signaling: false signaling is when miners signal
> readiness to enforce rules that their nodes don't actually support.
> This was partially responsible for a six-block reorg shortly after the
> final BIP66 activation[8] and was found to still be a problem during
> the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
>
> Because Speedy Trial only gives miners a maximum of three months to
> signal support for taproot, it may encourage such false signaling. If
> taproot locks in as a result of their signaling but most of them fail
> to upgrade by the activation date several months later, unprepared
> miners could lose large amounts of money and users could see long
> reorgs (with unupgraded nodes and SPV lite clients potentially losing
> money).
>
> Compared to other activation proposals, I think the only difference is
> Speedy Trial's short timeline. False signaling is possible with any
> other proposal and the same problems can occur if miners fail to
> upgrade for any mandatory activation.
>
> ### Additional advantages
>
> - No mandatory signaling: at no time are miners required to signal by
> Speedy Trial. This includes no mandatory signaling during the
> locked_in period(s), although such signaling will be encouraged (as it
> was with BIP9[10]).
>
> - Party time: to a lesser degree, a benefit mentioned for flag day
> activation may also apply here: we could get up to six months
> advanced notice of taproot activation, allowing users, developers, and
> organizations to prepare software, announcements, and celebrations for
> that event.
>
> ## Implementation details and next steps
>
> Initial discussion about implementation may be found in today's
> ##taproot-activation log.[11] If it appears Speedy Trial may have
> traction, Russell O'Connor has offered to work on a patch against BIP8
> implementing it.
>
> ## Acknowledgments
>
> The original idea for a short-duration attempt was discussed in the
> ##taproot-activation IRC channel last July and the revised idea saw
> additional evaluation there this week. Despite growing frustration,
> discussion has been overwhelmingly constructive, for which all the
> contributors should be commended. Although this should not in any way
> imply endorsement, I'm grateful for the review and comments on a draft
> of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
> Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
> O'Connor, and IRC users maybehuman and proofofkeags
>
> ## Footnotes
>
> [1]
> https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29
>
> [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
> seemed to have near-universal support during the 2021-02-16 IRC
> meeting. See:
> https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
>
> [3]
> https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldid=68062
>
> [4] https://github.com/bitcoin/bitcoin/pull/19953
>
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
>
> [6] https://github.com/bitcoin/bitcoin/pull/19573
>
> [7] BIP9's times are based on the median of the past 11 blocks, which
> usually trails UTC by about 90 minutes but which can trail behind
> realtime significantly if miners are doing weird things.
>
> [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
>
> [9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
>
> [10]
> https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339
>
> [11] http://gnusha.org/taproot-activation/2021-03-05.log
> _______________________________________________
> 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/20210305/13bc9b4e/attachment-0001.html>;

📅 Original date posted:2021-02-28 📝 Original message:Miners ...

2023-06-07T20:29:19+02:00

In reply to nevent1q…r6he
_________________________

📅 Original date posted:2021-02-28
📝 Original message:Miners still can generate invalid blocks as a result of SPV mining, and it
could be profitable to do "bad block enhanced selfish mining" to take
advantage of it.

Hard to analyze exactly what that looks like, but...

E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate
to mine bad blocks would mean 1/4th of the time you could make 20% of the
hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One
could analyze out that the lost hash rate for bad blocks only matters for
the first difficulty adjustment period you're doing this for too, as the
hashrate drop will be accounted for -- but then a miner can switch back to
mining valid chain, giving themselves a larger % of hashrate.

So it is still possible that an un-upgraded miner will fail part 3, and
attempting to accommodate un-upgraded miners leads to some nasty
oscillating hashrate being optimal.

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> Note further that mandatory signaling isn't "just" a flag day - unlike a
> Taproot flag day (where miners running Bitcoin
> Core unmodified today will not generate invalid blocks), a mandatory
> signaling flag day blatantly ignores goal (3) from
> my original post - it results in any miner who has not taken active action
> (and ensured every part of their often-large
> infrastructure has been correctly reconfigured) generating invalid blocks.
>
> As for "Taproot" took too long, hey, at least if its locked in people can
> just build things assuming it exists. Some
> already are, but once its clearly locked in, there's no reason to not
> continue other work at the same time.
>
> Matt
>
> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
> > I agree with much of the logic presented by Matt here.
> >
> > BIP8 was intended to be simpler to agree on to maintain consensus, yet
> we find ourselves in a situation where a "tiny"
> > parameter has the potential to cause great network disruption and
> confusion (rationality is not too useful a concept
> > here given differing levels of sophistication and information). It is
> therefore much simpler and more likely to be
> > universally understood by all network participants to just have a flag
> day. It is easier to communicate what users
> > should do and when.
> >
> > This is ultimately not coercive to users because the upgrade for Taproot
> itself is provable and analyzable on its own,
> > but activation parameters based on what % of economically relevant nodes
> are running an upgrade by a certain date are
> > not. Selecting these sorts of complicated consensus parameters may
> ultimately present more opportunity for a cooptable
> > consensus process than something more straightforward.
> >
> >
> > That said, a few points strike me as worth delving into.
> >
> >
> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory
> signaling is effectively 2 flag days -- one for
> > the signaling rule, 1 for the taproot type. The reason for the 2 week
> gap between flag day for signaling and flag day
> > for taproot rules is, more or less, so that nodes who aren't taproot
> ready at the 1st flag day do not end up SPV mining
> > (using standardness rules in mempool prevents them from mining an
> invalid block on top of a valid tip, but does not
> > ensure the tip is valid).
> > 2) Con: Releasing a flag day without releasing the LOT=true code leading
> up to that flag day means that clients would
> > not be fully compatible with an early activation that could be proposed
> before the flag day is reached. E.g., LOT=true
> > is a flag day that retains the possibility of being compatible with
> other BIP8 releases without changing software.
> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm
> personally skeptical that early activation is/was
> > ever a good idea. A fixed activation date may be largely superior for
> business purposes, software engineering schedules,
> > etc. I think even with signaling BIP8, it would be possibly superior to
> activate rules at a fixed date (or a quantized
> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
> > 4) Pro: part of the argument for BIP-8=false is that it is possible that
> the rule could not activate, if signaling does
> > not occur, providing additional stopgap against dev collusion and bugs.
> But BIP-8 can activate immediately (with start
> > times being proposed 1 month after release?) so we don't have certainty
> around how much time there is for that secondary
> > review process (read -- I think it isn't that valuable) and if there
> *is* a deadly bug discovered, we might want to
> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule
> activates it enables more mining reward). So I
> > think that it's a healthier mindset to release a with definite deadline
> and not rule out having to do a hard fork if
> > there is a grave issue (we shouldn't ever release a SF if we think this
> is at all likely, mind you).
> > 5) Con: It's already taken so long for taproot, the schedule around
> taproot was based on the idea it could early
> > activate, 2022 is now too far away. I don't know how to defray this
> other than, if your preferred idea is 1 year flag
> > day, to do that via LOT=true so that taproot can still have early
> activation if desired.
> >
> > Overall I agree with the point that all the contention around LOT, makes
> a flag day look not so bad. And something
> > closer to a flag day might not be so bad either for future forks as well.
> >
> > However, I think given the appetite for early activation, if a flag day
> is desired I think LOT=true is the best option
> > at this time as it allows our flag day to remain compatible with such an
> early activation.
> >
> > I think we can also clearly communicate that LOT=true for Taproot is not
> a precedent setting occurence for any future
> > forks (hold me accountable to not using this as precedent this should I
> ever advocate for a SF with similar release
> > parameters).
> >
> >
> > _______________________________________________
> > 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/20210228/df85cf85/attachment-0001.html>;

📅 Original date posted:2021-02-28 📝 Original message:I ...

2023-06-07T20:29:18+02:00

In reply to nevent1q…mypz
_________________________

📅 Original date posted:2021-02-28
📝 Original message:I agree with much of the logic presented by Matt here.

BIP8 was intended to be simpler to agree on to maintain consensus, yet we
find ourselves in a situation where a "tiny" parameter has the potential to
cause great network disruption and confusion (rationality is not too useful
a concept here given differing levels of sophistication and information).
It is therefore much simpler and more likely to be universally understood
by all network participants to just have a flag day. It is easier to
communicate what users should do and when.

This is ultimately not coercive to users because the upgrade for Taproot
itself is provable and analyzable on its own, but activation parameters
based on what % of economically relevant nodes are running an upgrade by a
certain date are not. Selecting these sorts of complicated consensus
parameters may ultimately present more opportunity for a cooptable
consensus process than something more straightforward.

That said, a few points strike me as worth delving into.

1) Con: Mandatory signalling is no different than a flag day. Mandatory
signaling is effectively 2 flag days -- one for the signaling rule, 1 for
the taproot type. The reason for the 2 week gap between flag day for
signaling and flag day for taproot rules is, more or less, so that nodes
who aren't taproot ready at the 1st flag day do not end up SPV mining
(using standardness rules in mempool prevents them from mining an invalid
block on top of a valid tip, but does not ensure the tip is valid).
2) Con: Releasing a flag day without releasing the LOT=true code leading up
to that flag day means that clients would not be fully compatible with an
early activation that could be proposed before the flag day is reached.
E.g., LOT=true is a flag day that retains the possibility of being
compatible with other BIP8 releases without changing software.
3) Pro: BIP-8 is partially in service of "early activation" and . I'm
personally skeptical that early activation is/was ever a good idea. A fixed
activation date may be largely superior for business purposes, software
engineering schedules, etc. I think even with signaling BIP8, it would be
possibly superior to activate rules at a fixed date (or a quantized set of
fixed dates, e.g. guaranteeing at least 3 months but maybe more).
4) Pro: part of the argument for BIP-8=false is that it is possible that
the rule could not activate, if signaling does not occur, providing
additional stopgap against dev collusion and bugs. But BIP-8 can activate
immediately (with start times being proposed 1 month after release?) so we
don't have certainty around how much time there is for that secondary
review process (read -- I think it isn't that valuable) and if there *is* a
deadly bug discovered, we might want to hard-fork to fix it even if it
isn't yet signaled for (e.g., if the rule activates it enables more mining
reward). So I think that it's a healthier mindset to release a with
definite deadline and not rule out having to do a hard fork if there is a
grave issue (we shouldn't ever release a SF if we think this is at all
likely, mind you).
5) Con: It's already taken so long for taproot, the schedule around taproot
was based on the idea it could early activate, 2022 is now too far away. I
don't know how to defray this other than, if your preferred idea is 1 year
flag day, to do that via LOT=true so that taproot can still have early
activation if desired.

Overall I agree with the point that all the contention around LOT, makes a
flag day look not so bad. And something closer to a flag day might not be
so bad either for future forks as well.

However, I think given the appetite for early activation, if a flag day is
desired I think LOT=true is the best option at this time as it allows our
flag day to remain compatible with such an early activation.

I think we can also clearly communicate that LOT=true for Taproot is not a
precedent setting occurence for any future forks (hold me accountable to
not using this as precedent this should I ever advocate for a SF with
similar release parameters).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210228/5fff5317/attachment-0001.html>;

📅 Original date posted:2021-02-23 📝 Original message:Not ...

2023-06-07T20:28:59+02:00

In reply to nevent1q…nwqc
_________________________

📅 Original date posted:2021-02-23
📝 Original message:Not responding to anyone in particular, but it strikes me that one can
think about the case where a small minority (let's say H = 20%?) of nodes
select the opposite of what Core releases (LOT=false, LOT=true). I'm
ignoring the case where a critical bug is discovered in Taproot for reasons
I could expand on if anyone is interested (I don't think LOT=true/false has
much of a diff in that regard).

You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes are
clearly updated (or lying), LOT=false nodes may be un-upgraded (or however
you want to interpret it).

*# 80% on LOT=false, 20% LOT=True*

- Case 1: Activates ahead of time anyways

No issues.

- Case 2: Fails to Activate before timeout...

20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of multi
block reorgs at time of fork relatively high, especially if network does
not partition.

Implication is that activation % being 90%, then X% fewer than 70% of
miners are signaling for Taproot at this time. If X% is small the
increased orphan rate caused by the LOT=true miners will cause it to
activate anyways. If X% is larger, then there will be a consensus split.

*# 80% on LOT=true, 20% LOT=False*
- Case 1: Activates ahead of time Anyways

No issues.

- Case 2: Fails to Activate before timeout...

A% + B% + C% = 20%

A% (upgraded, signal activate) remain on majority chain with LOT=false,
blocks mined universally valid.

B% (upgraded, not signaling) succeeds in activating and maintaining
consensus, blocks are temporarily lost during the final period, but
consensus re-emerges.

C% (not upgraded/not signalling) both fail to activate (not upgraded) and
blocks are rejected (not signaling) during mandatory signalling.
Essentially becomes an SPV miner, should still not select transactions
improperly given mempool policy, but may mine a bad tip.

(I argue that group B is irrational entirely, as in this case the majority
has upgraded, inevitably winning, and is orphaning their blocks so B should
effectively be 0% or can be combined with group C as being somehow not
upgraded if they are unable to switch once it becomes clear after say the
first 100 blocks in the period that LOT > 50%. The only difference in
lumping B with C is that group C SPV mines after the fork and B should, in
theory, have full validation.).

Apologies if my base analysis is off -- happy to take corrections.

My overall summary is thus:

1) People care what Core releases because we assume the majority will
likely run it. If core were a minority project, we wouldn't really care
what core released.
2) People are upset with LOT=true being suggested as release parameters
because of the *narrative* that it puts devs in control.
3) LOT=true having a sizeable minority running it presents major issues to
majority LOT=false in terms of lost blocks during the final period and in
terms of a longer term fork.
4) Majority LOT=true has no long term instability on consensus (majority
LOT=true means the final period always activates, any instability is short
lived + irrational).
5) On the balance, the safer parameter to release *seems* to be LOT=true.
But because devs are sensitive to control narrative, LOT=false is preferred
by devs.
6) Almost paradoxically, choosing a *less safe* option for a narrative
reason is more of a show of dev control than choosing a more safe option
despite appearances.
7) This all comes down to if we think that a reasonable number of important
nodes will run LOT=true.
8) This all doesn't matter *that much* because taproot will have many
opportunities to activate before the brinksmanship period.

As a plan of action, I think that means that either:

A) Core should release LOT=true, as a less disruptive option given stated
community intentions to do LOT=true
B) Core community should vehemently anti-advocate running LOT=true to
ensure the % is as small as possible
C) Do nothing
D) Core community should release LOT=false and vehemently advocate manually
changing to LOT=true to ensure the % is supermajority, but leaving it as a
user choice.

Overall, I worry that plan B has a mild Streissand effect and would result
in boosting LOT=true (which could be OK, so long as LOT=true +
LOT=false+signal yes becomes the large majority, but would be not fun for
anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C
most likely ends up with some % doing LOT=true anyways. D feels a little
silly, but maybe a good tradeoff.

If I had to summarize the emotional dynamic among developers around
LOT=true, I think devs wish it didn't exist because it is clear LOT=true
*creates* the issues here. LOT=false would be fine if the LOT=true strategy
didn't exist at all. But unfortunately the cat is out of the bag and cannot
be put back in. To validate the emotions, I think it is fine to be angry
about LOT=true and not like it, but we should either accept that it is most
likely to create consensus OR we should find a new game theoretic
activation strategy with better pro-social equilibriums.

Personally, I think with either plan the ultimate risk of forking is low
given probability to activate before timeout, so we should just pick
something and move on, accepting that we aren't setting a precedent by
which all future forks should abide. Given my understanding of the
tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't
move to hold back a plan of LOT=false (but would probably take mitigative
steps on community advocacy if it looks like there is non majority but non
negligible LOT=true uptake).

Cheers,

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210222/019548d1/attachment-0001.html>;

📅 Original date posted:2020-09-19 📝 Original ...

2023-06-07T20:26:57+02:00

In reply to nevent1q…t67c
_________________________

📅 Original date posted:2020-09-19
📝 Original message:Antoine,

Yes I think you're a bit confused on where the actual sponsor vector is. If
you have a transaction chain A->B->C and a sponsor S_A, S_A commits to txid
A and A is unaware of S.

W.r.t your other points, I fully agree that the 1-to-N sponsored case is
very compelling. The consensus rules are clear that sponsor commitments are
non-rival, so there's no issue with allowing as many sponsors as possible
and including them in aggregate. E.g., if S_A and S'_A both sponsor A with
feerate(S*) > feerate(A), there's no reason not to include all of them in a
block. The only issue is denial of service in the mempool. In the future,
it would definitely be desirable to figure out rules that allow mempools to
track both multiple sponsors and multiple sponsor targets. But in the
interest of KISS, the current policy rules are designed to be minimally
invasive and maximally functional.

In terms of location for the sponsor vector, I'm relatively indifferent.
The annex is a possible location, but it's a bit odd as we really only need
to allow one such vector per tx, not one per input, and one per input would
enable some new use cases (maybe good, maybe bad). Further, being in the
witness space would mean that if two parties create a 2 input transaction
with a desired sponsor vector they would both need to specify it as you
can't sign another input's witness data. I wholeheartedly agree with the
sentiment though; there could be a more efficient place to put this data,
but nothing jumps out to me as both efficient and simple in implementation
(a new tx-level field sounds like a lot of complexity).

> n >=1 ? I think you can have at least one vector and this is matching the
code

yes, this has been fixed in the gist (cred to Dmitry Petukhov for pointing
it out first), but is correct in the code. Thank you for your careful
reading.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200919/109d1531/attachment.html>;

📅 Original date posted:2020-09-19 📝 Original message:Hi ...

2023-06-07T20:26:55+02:00

In reply to nevent1q…553l
_________________________

📅 Original date posted:2020-09-19
📝 Original message:Hi David!

Thanks for taking a look, and great question.

> Is this in the reference implementation?

It is indeed in the reference implementation. Please see
https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx#diff-24efdb00bfbe56b140fb006b562cc70bR741-R743

There is no requirement that there be any input in common, just that the
sponsor vectors are identical (keep in mind that we limit our sponsor
vector by policy to 1 element, because, as you rightfully point out,
multiple sponsors is more complex to implement).

> In the second case, I think Mallory can use an existing pinning
> technique to make it expensive for Bob to fee bump. The normal
> replacement policies require a replacement to pay an absolute higher fee
> than the original transaction, so Mallory can create a 100,000 vbyte
> transaction with a single-vector sponsor at the end pointing to Bob's
> transaction. This sponsor transaction pays the same feerate as Bob's
> transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee. In order
> for Bob to replace Mallory's sponsor transaction with his own sponsor
> transaction, Bob needs to pay the incremental relay feerate (10
> nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).

Yup, I was aware of this limitation but I'm not sure how practical it is as
an attack because it's quite expensive for the attacker. But there are a
few simple policies that can eliminate it:

1) A Sponsoring TX never needs to be more than, say, 2 inputs and 2
outputs. Restricting this via policy would help, or more flexibly limiting
the total size of a sponsoring paying transaction to 1000 bytes.
2) Make A Sponsoring TX not need to pay more absolute fee, just needs to
increase the feerate (perhaps with a constant relay fee bump to prevent
spam).

I think 1) is simpler and should allow full use of the sponsor mechanism
while preventing this class of issue mostly.

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200919/f57991f4/attachment-0001.html>;

📅 Original date posted:2020-09-19 📝 Original message:Hi ...

2023-06-07T20:26:54+02:00

In reply to nevent1q…d3tk
_________________________

📅 Original date posted:2020-09-19
📝 Original message:Hi Cory!

Thanks for taking a look. CC nopara as I think your questions are the same.

I think there are a few reason we won't see functionally worse privacy:

1. RBF/CPFP may require the use of an external to the original transaction
to pay sufficient fee.
2. RBF/CPFP may leak which address was the change and which was the payment.

In addition, I think there is a benefit in that:

1. RBF/CPFP requires access to the keys in the same 'security zone' as the
payment you made (e.g., if it's a multi-sig to multi-sig requires m of N to
cpfp/or RBF, whereas sponsors could be anyone).
2. Sponsors can be a fully separate arbitrary wallet.
3. You can continually coinjoin the funds in your fee-paying wallet without
tainting your main funds.
4. You can keep those funds in a lightning channel and pay your fees via
loop outs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200919/d5b8bdac/attachment.html>;

📅 Original date posted:2020-08-16 📝 Original ...

2023-06-07T20:26:23+02:00

In reply to nevent1q…etjz
_________________________

📅 Original date posted:2020-08-16
📝 Original message:Concept ack!

It might be nice to include a few negotiation utility functions either in
this bip or at the same time in a separate bip. An example we might want to
include is a "polite disconnect", whereby a node can register that you
don't want to connect in the future due to incompatibility.

It also might be nice to standardize some naming convention or negotiation
message type so that we don't end up with different negotiation systems.
Then we can also limit the bip so that we're only defining negotiation
message types as ignorable v.s. some other message type (which can also be
ignored, but maybe we want to do something else in the future).

This also makes it easier for old (but newer than this bip) nodes to apply
some generic rules around reporting/rejecting/responding to unknown feature
negotiation v.s. an untagged message which might be a negotiation or
something else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200816/6fb078d1/attachment.html>;

📅 Original date posted:2020-06-08 📝 Original message:Broke ...

2023-06-07T20:25:19+02:00

In reply to nevent1q…d4y5
_________________________

📅 Original date posted:2020-06-08
📝 Original message:Broke out to a separate thread.

At core, the reason why this method *might* work is that it's essentially
just CPFP but we can guarantee that the link we're examining is always
exactly one hop away, so we get rid of most of the CPFP graph traversal
issues.

Your description largely matches my thinking for how something like this
could work (pay for neighbor). The issue is that the extant CPFP logic is
somewhat brittle and doesn't work as expected (Child not Children, which is
problematic for multiple PFN's).

> PFN transaction would still be valid if some of 'ghost parents' are
already confirmed, so the miners could have more fees than strictly
necessary. But this is the same as with CPFP.

This is problematic and can't be done as it requires a new index of all
past txns for consensus.

My thinking is that a Fee Bump transaction can name a list of TXIDs (Or one
TXID which implies all ancestors of) that it wishes to be included in a
block with. It must be included in that block. A Fee Bump transaction may
have no unconfirmed ancestors nor any children. Potentially, it also may
not be RBF'd. You treat the Fee Bump Transactions as the lowest descendant
of whatever it targets and then set it's feerate/total fee based on the
package that would have to co-confirm for it to be worth mining. This makes
it sort like normal transactions for inclusion. You can require some
minimums for mempool inclusion at all.

If it's target is confirmed or replaced, it should drop from the mempool.

Transactions in the mempool may set a flag that opts out of CPFP for
descendants/blocks any descendants. Channel protocols should set this bit
to prevent pinning, and then use the Fee Bump to add fees to whatever txns
need to go through. If done right you can also layer a coinswap protocol
with the fee-bumping txns change so that you are getting a privacy benefit
at the same time.

BTW the annex *could* be used for this purpose, but it would also be
acceptable to have it be in some kind of anyone can spend output. Then it
would just be a anyone-can-spend tx with OP_CHECK_TXID_IN_BLOCK (or
OP_CHECK_UTXO_SPENT_IN_BLOCK), and a miner could claim all such outputs at
the end of the block. This is worse in terms of on-chain overheads, but
nice in that it's the minimal semantic change & introduces some general
purpose functionality.

But my thoughts are still pretty loose at the moment around it. I suspect
that to make fee bumping work nicely would require removing CPFP entirely,
but I don't know that to be the case concretely.

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Sun, Jun 7, 2020 at 11:02 PM Dmitry Petukhov <dp at simplexum.com> wrote:

> В Sun, 7 Jun 2020 15:45:16 -0700
> Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > What I think we'll eventually land on is a way of doing a tx
> > that contributes fee to another tx chain as a passive observer to
> > them. While this breaks one abstraction around how dependencies
> > between transactions are processed, it also could help resolve some
> > really difficult challenges we face with application-DoS (pinning and
> > other attacks) in the mempool beyond CTV. I have a napkin design for
> > how this could work, but nothing quite ready to share yet.
>
> I had an idea of 'Pay for neighbor' transaction where a transaction
> that is not directly a child of some other transaction can specify that
> it wants to pay the fee for that other transaction(s). It can become
> like 'ghost child' transaction for them, in what it cannot be mined
> unless its 'ghost parents' are confirmed, too. It will be like CPFP,
> but without direct dependency via inputs. Such 'PFN' transaction would
> not spend any coins beside what it specifies in its own inputs, of
> course.
>
> The idea required a hardfork at first, but Anthony Towns suggested
> a way to make it into a soft fork (past-taproot) by putting the txids of
> 'ghost parents' into taproot annex.
>
> PFN transaction would still be valid if some of 'ghost parents' are
> already confirmed, so the miners could have more fees than strictly
> necessary. But this is the same as with CPFP.
>
> Looking at the mempool code, it seems that only a way how parent/child
> transactions relationships are established will need to be adjusted to
> account for this 'ghost relationships', and once established, other
> logic will work as with CPFP. There could be complications regarding
> transaction package size. But I cannot claim that I understand that
> code enough to say something about this with certainty.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200607/520bf867/attachment-0001.html>;

📅 Original date posted:2020-06-07 📝 Original message:Hi ...

2023-06-07T20:25:17+02:00

In reply to nevent1q…plrc
_________________________

📅 Original date posted:2020-06-07
📝 Original message:Hi Joachim,

Fantastic questions!

I think it makes sense to think about it in terms of today, and then in
terms of a long-dated future where wallets have much richer native
understandings of these things. This helps preserve the purity of the
arguments I'm making with respect to what it would look like today v.s.
what it could look like with strong integration.

Today:
1) I would expect that exchanges do this as a CTV txn that is one initial
confirmation to a single output, and then that output expands to either all
the payments in the batch, or to a histogram of single-layer CTVs based on
priority/amount being spent. E.g, either A -> B -> {C,D,E,F,G...} or
A->B->{C -> {D,E,F}, G -> {H, I J}, K -> ....}. I would further expect that
the entire tree would include fees such that it will get into at least the
bottom of the mempool. See https://utxos.org/analysis/batching_sim/ for
more info. If txns land in the mempool, then users learn about it (even
with an un-updated wallet) just like the learn of normal unconfirmed
transactions. Even this simple two-step transaction can deliver massive
batching savings. OpTech has some coverage of this simple
commit-now-distribute-later scheme here
https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-new-opcode-for-transaction-output-commitments
.

I'd also expect that exchanges in particular already store their outbound
transactions in resilient storage (for audit and compliance as well as
liability protection), so they would likely be able to make this data
available to their customers on inquiry if discarded.

I'm all for redundancy, so exchanges can also e.g. send an email with a
backup file if they want to. But that's not necessary for it to work today,
you can just watch the mempool like wallets already do.

A slightly patched wallet can treat CTV outs as more confirmed (e.g., like
an own-change address) than a normal unconfirmed out.

2) I would expect that exchanges pay a reasonable amount of fees for the
transaction so it can expect to at least get to the bottom range of the
mempool for children, and top of the mempool for the parent. Your question
seems to be more about after this phase.

First I would note that it is truly O(log(N)), but E[O(1)], because it
amortizes. That is, to claim out all of the outputs is a total overhead of
O(N), not O(N log N). Fees in this model are paid by CPFP. Because CPFP is
currently *Child* pays for parent and not *Children* pay for parent, we
don't (unfortunately) have rational txn selection for this case. Any wallet
can construct this spend path by rebroadcasting (if evicted) the parents
and spending the txn. The exchange can also 'bound' themselves to seeing a
transaction to completion by including some change address at the leaf node
layer (not much overhead depending on radix).

Thus the payer of fees is the person who needs to spend.

3) Not exactly, the middle txns are immutable. but it may be possible to
construct a low-fee longchain which can cause transaction pinning. If you
do a shallow tree as described in (1), the current lightning carve should
help to prevent this.

Future:
1) Most likely the desirable radix for a tree is something like 4 or 5
which minimizes the amount of work on an individual basis (you can compute
this by figuring out how deep the tree would be and the per-tx overheads, 4
or 5 pop out as being minimal overhead and the benefit is recursive).
Mempool broadcast still should work, but it's possible that for privacy
reasons it's preferred to not broadcast through mempool. It's also possible
that all payouts are into non-interactive lightning channels with N-of-N
taproot at each layer, so you receive a proof through your lightning wallet
and can immediately route payments, and when you want to close
opportunistically cooperate to reduce chain overhead. You can think of CTV
as an anchor for bootstrapping these layer two protocols with an on-chain
bisection algorithm to discover online participants to re-negotiate with. A
privacy and scalability win!

I further expect business wallets (like exchanges) to be able to credit
deposits from CTV trees without requiring full expansion. This is also a
privacy win, and can decrease latency of moving large value funds (e.g.,
exceeding inter exchange channel balances) and crediting funds for trading.

2) I think we'll eventually converge on a non-destructive way of adding
fees. RBF is destructive in that you're replacing a TX. CPFP is destructive
in that you have a spend a coin to drive progress. Without a new opcode you
can emulate this with CTV by at nodes in the tree having a consumable
output that serves as a CPFP hook/a RBF hook. You can see some discussion
here (animated, so use pres mode)
https://docs.google.com/presentation/d/1XDiZOz52XyJc4LDSbiD9_JAaJobyF5QDGtR3O9qD7yg/edit#slide=id.g7d267915e2_0_44.
This adds some extra chain weight, but is possible without further
extension. What I think we'll eventually land on is a way of doing a tx
that contributes fee to another tx chain as a passive observer to them.
While this breaks one abstraction around how dependencies between
transactions are processed, it also could help resolve some really
difficult challenges we face with application-DoS (pinning and other
attacks) in the mempool beyond CTV. I have a napkin design for how this
could work, but nothing quite ready to share yet.

3) Hopefully 2 solves pinning :)
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Sun, Jun 7, 2020 at 9:51 AM Joachim Strömbergson <
joachimstr at protonmail.com> wrote:

> Hello everyone,
>
> regarding OP_CTV, I am considering the scaling use case, specifically an
> exchange (or similar) who wants to batch pay to OP_CTV to many users, and I
> wonder
>
> 1) How do you expect the exchange to communicate the proof of the payment
> to the user wallets such that they are able to construct the follow up
> transactions and accept the payment. This is UI question. Do you expect
> exchanges to provide a certain importable file/blob that the wallet will
> allow you to entry?
>
> 2) Who pays the fees and how for the transaction within the structure that
> OP_CTVed output is committed to? Say there is a tree structure and I want
> to get the coin out. Someone needs to send log(N) transactions to the chain
> in order for me to get access to the final UTXO I am interested in. Who can
> construct such transaction path and what do they need for it and who pays
> fees on that (which input)?
>
> 3) Depending on 2) above, is it not possible for a malicious entity who is
> among the many users being paid, but who has very small UTXO there relative
> to others, to construct this middle transaction and use a very small fee
> rate in order to DoS other participants. Is it even possible for this
> attacker to create the middle transaction with RBF disabled?
>
> Thank you,
> Joachim
>
>
>
> Sent with ProtonMail <https://protonmail.com>; Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, November 26, 2019 1:50 AM, Jeremy via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Bitcoin Developers,
>
> Pleased to announce refinements to the BIP draft for
> OP_CHECKTEMPLATEVERIFY (replaces previous OP_SECURETHEBAG BIP). Primarily:
>
> 1) Changed the name to something more fitting and acceptable to the
> community
> 2) Changed the opcode specification to use the argument off of the stack
> with a primitive constexpr/literal tracker rather than script lookahead
> 3) Permits future soft-fork updates to loosen or remove "constexpr"
> restrictions
> 4) More detailed comparison to alternatives in the BIP, and why
> OP_CHECKTEMPLATEVERIFY should be favored even if a future technique may
> make it semi-redundant.
>
> Please see:
> BIP: https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki
> Reference Implementation:
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify
>
> I believe this addresses all outstanding feedback on the design of this
> opcode, unless there are any new concerns with these changes.
>
> I'm also planning to host a review workshop in Q1 2020, most likely in San
> Francisco. Please fill out the form here
> https://forms.gle/pkevHNj2pXH9MGee9 if you're interested in participating
> (even if you can't physically attend).
>
> And as a "but wait, there's more":
>
> 1) RPC functions are under preliminary development, to aid in testing and
> evaluation of OP_CHECKTEMPLATEVERIFY. The new command `sendmanycompacted`
> shows one way to use OP_CHECKTEMPLATEVERIFY. See:
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-rpcs.
> `sendmanycompacted` is still under early design. Standard practices for
> using OP_CHECKTEMPLATEVERIFY & wallet behaviors may be codified into a
> separate BIP. This work generalizes even if an alternative strategy is used
> to achieve the scalability techniques of OP_CHECKTEMPLATEVERIFY.
> 2) Also under development are improvements to the mempool which will, in
> conjunction with improvements like package relay, help make it safe to lift
> some of the mempool's restrictions on longchains specifically for
> OP_CHECKTEMPLATEVERIFY output trees. See: https://github.com/bitcoin/bitcoin/pull/17268
> This work offers an improvement irrespective of OP_CHECKTEMPLATEVERIFY's
> fate.
>
>
> Neither of these are blockers for proceeding with the BIP, as they are
> ergonomics and usability improvements needed once/if the BIP is activated.
>
> See prior mailing list discussions here:
>
> *
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html
> *
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html
>
>
> Thanks to the many developers who have provided feedback on iterations of
> this design.
>
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200607/6a0f0136/attachment-0001.html>;

📅 Original date posted:2020-02-14 📝 Original message:Dave, ...

2023-06-07T20:22:53+02:00

In reply to nevent1q…txsc
_________________________

📅 Original date posted:2020-02-14
📝 Original message:Dave,

I think your point:

*When schnorr and taproot are done together, all of the following
transaction types can be part of the same set: - single-sig spends
(similar to current use of P2PKH and P2WPKH) - n-of-n spends with musig
or equivalent (similar to current use of P2SH and P2WSH 2-of-2
multisig without special features as used by Blockstream Green and LN
mutual closes) - k-of-n (for low values of n) using the most common k
signers (similar to BitGo-style 2-of-3 where the keys involved are
alice_hot, alice_cold, and bob_hot and almost all transactions are
expected to be signed by {alice_hot, bob_hot}; that common case can
be the key-path spend and the alternatives {alice_hot, alice_cold}
and {alice_cold, bob_hot} can be script-path spends) - contract
protocols that can sometimes result in all parties agreeing on an
outcome (similar to LN mutual closes, cross-chain atomic swaps, and
same-chain coinswaps) *

Is the same if Schnorr + Merkle Branch without Taproot optimization, unless
I'm missing something in one of the cases? I guess there's a distinction on
"can" v.s. "are likely"?

Jonas,

That's a really interesting point about K-N systems making the most likely
K-K the taproot key. (For the uninitiated, MuSig can do N-of-N aggregation
non-interactively, but K-of-N requires interaction). I think this works
with small (N choose K), but as (N choose K) increases it seems the
probability of picking the correct one goes down?

I guess the critical question is if cases where there's not some timelock
will be mandatory across all signing paths.

cheers,

jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Mon, Feb 10, 2020 at 9:16 AM Jonas Nick via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I agree with most of the comments so far, but the group brings up an often
> overlooked point with respect to the privacy benefits of taproot. In the
> extreme
> case, if there would be no policies that have both a key and a script spend
> path, then taproot does not improve anonymity sets compared to the "Taproot
> Public NUMS Optimization" proposal (which saves 8 vbytes in a
> script-spend). (*)
>
> In fact, the cases where scripts would have to be used given usage of
> Bitcoin
> today are be rare because threshold policies, their conjunctions and
> disjunctions can be expressed with a single public key. Even if we
> disregard
> speculation that timelocks, ANYPREVOUT/NOINPUT and other interesting
> scripts
> will be used in the future (which can be added through the leaf or key
> versions
> without affecting key-spend anonymity sets), not all of today's
> applications are
> able to be represented single public keys because there are applications
> that
> can not deal with interactive key setups or interactive signing. For
> applications where this is possible it will be a gradual change because of
> the
> engineering challenges involved. For example, k-of-n threshold policies
> could
> have the most likely k-of-k in the taproot output key and other k-of-k in
> the
> leaves, instead of going for a k-of-n taproot output key immediately.
>
> Given that anonymity sets in Bitcoin are permanent and software tends to be
> deployed longer than anyone would expect at the time of deployment,
> realistically Taproot is superior to the "Public NUMS Optimization" and "An
> Alternative Deployment Path".
>
> (*) One could argue that the little plausible deniability gained by a very
> small
> probability of the change of a script-spend being a key-spend and vice
> versa is
> significantly better than no probability at all.
>
> On 2/9/20 8:47 PM, Bryan Bishop via bitcoin-dev wrote:
> > Apologies for my previous attempt at relaying the message- it looks like
> > the emails got mangled on the archive. I am re-sending them in this
> > combined email with what I hope will be better formatting. Again this is
> > from some nym that had trouble posting to this mailing list; I didn't see
> > any emails in the queue so I couldn't help to publish this sooner.
> >
> > SUBJECT: Taproot (and Graftroot) Complexity
> >
> > This email is the first of a collection of sentiments from a group of
> > developers who in aggregate prefer to remain anonymous. These emails have
> > been sent under a pseudonym so as to keep the focus of discussion on the
> > merits of the technical issues, rather than miring the discussion in
> > personal politics. Our goal isn't to cause a schism, but rather to help
> > figure out what the path forward is with Taproot. To that end, we:
> >
> > 1) Discuss the merits of Taproot's design versus simpler alternatives
> (see
> > thread subject, "Taproot (and Graftroot) Complexity").
> >
> > 2) Propose an alternative path to deploying the technologies described in
> > BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
> > Deployment Path for Taproot Technologies").
> >
> > 3) Suggest a modification to Taproot to reduce some of the overhead (see
> > thread subject, "Taproot Public NUMS Optimization").
> >
> > Now that the BIP has moved to draft we felt that now was the time to
> > prioritize review to make sure it was an acceptable change for our
> > activities. As a group, we're excited about the totality of what Taproot
> > has to offer. However, after our review, we're left perplexed about the
> > development of Taproot (and Graftroot, to a lesser extent).
> >
> > We also want to convey that we have nothing but respect for the
> developers
> > and community who have poured their heart and soul into preparing
> Taproot.
> > Self evidently, it is an impressive synthesis of ideas. We believe that
> the
> > highest form of respect to pay such a synthesis of ideas is a detailed
> and
> > critical review, as it's pertinent to closely consider changes to
> Bitcoin.
> >
> >
> > In essence, Taproot is fundamentally the same as doing
> > https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki and
> Schnorr
> > signatures separately.
> >
> > The main reason for putting them together -- as mentioned in the BIP --
> is
> > a gain in efficiency. But this efficiency pre-supposes a specific use
> case
> > and probability distribution of use cases.
> >
> > Compare:
> >
> > Suppose a MAST for {a,b,c,d,e,f,g,h} spending conditions it looks
> something
> > like this:
> >
> >
> > /\
> > / \
> > / \
> > / \
> > /\ /\
> > / \ / \
> > /\ /\ /\ /\
> > a b c d e f g h
> >
> > If we want this to be functionally equivalent to Taproot, we add a new
> path:
> >
> > /\
> > /\ {<pk> schnorr_checksig}
> > / \
> > / \
> > / \
> > /\ /\
> > / \ / \
> > /\ /\ /\ /\
> > a b c d e f g h
> >
> > Now, to spend from this MBV you have to reveal 32 bytes on the stack for
> > the not taken branch, and 35 bytes for the <pk> schnorr_checksig (1 byte
> > push, 33 bytes PK, 1 byte checksig).
> >
> > This is 67 bytes more than Taproot would require for the same spending
> > condition.
> >
> > However, suppose we wanted to use one of the script paths instead. We
> still
> > need to have one extra hash for the {<pk> schnorr_checksig} (depending on
> > if we put the key in this position or not--see below). But now we can
> spend
> > with just a logarithmic control program path.
> >
> > However, if we do the same script via taproot, we now need to provide the
> > base public key (33 bytes) as well as the root hash (32 bytes) and path
> and
> > then the actual scripts. With the need for 2 push bytes, this ends up
> being
> > back at 67 bytes extra.
> >
> > Is Taproot just a probability assumption about the frequency and
> likelihood
> > of the signature case over the script case? Is this a good assumption?
> The
> > BIP only goes as far as to claim that the advantage is apparent if the
> > outputs *could be spent* as an N of N, but doesn't make representations
> > about how likely that N of N case would be in practice compared to the
> > script paths. Perhaps among use cases, more than half of the ones we
> expect
> > people to be doing could be spent as an N of N. But how frequently would
> > that path get used? Further, while the *use cases* might skew toward
> things
> > with N of N opt-out, we might end up in a power law case where it's the
> one
> > case that doesn't use an N of N opt out at all (or at a de minimis level)
> > that becomes very popular, thereby making Taproot more costly then
> > beneficial.
> >
> > Further, if you don't want to use a Taproot top-level key (e.g., you need
> > to be able to audit that no one can spend outside of one of the script
> > conditions), then you need to use a NUMS (nothing up my sleeve) point.
> This
> > forces users who don't want Taproot to pay the expense, when if they just
> > had a MAST based witness type they would be cheaper. So if this use case
> is
> > at all common, Taproot leaves them worse off in terms of fees. Given that
> > script paths are usually done in the case where there is some contested
> > close, it's actually in the interest of protocol developers that the
> > contested script path be as efficient as possible so that the fees paid
> > maximally increase the feerate. We think this can be fixed simply in
> > Taproot though, as noted below.
> >
> >
> >
> > On privacy, we're also a bit confused as to the goal of Taproot over MAST
> > and Schnorr. Earlier, we presented a design with MAST which is very close
> > to Taproot. However, it'd also be possible to just add {<pk>
> > schnorr_checksig} to the set {a,b,c,d,e,f,g,h}, shuffle them, and compute
> > some MAST structure (perhaps probability encoded) on them. This has the
> > effect of not having much additional fees for adding the extra Schnorr
> path
> > at redeem time (only 1 extra branch on 2/8 script paths), e.g.
> >
> >
> > /\
> > / \
> > / \
> > / \
> > /\ /\
> > / \ / \
> > /\ /\ /\ /\
> > a b c d e f/\ {<pk> schnorr_checksig}
> > g h
> >
> > We could argue that this is more private than Taproot, because we don't
> > distinguish between the Schnorr key case and other cases by default, so
> > chain analyzers can't tell if the signature came from the Taproot case or
> > from one of the Script paths. There's also no NUMS point required, which
> > means chain analyzers can't tell when you spend that there was no top
> level
> > key if the NUMS point is not per-output indistinguishable. By using a
> > semi-randomized MAST structure, chain analyzers also can't tell exactly
> how
> > big your spend condition MAST was. In particular, you care more about
> > privacy when you are contesting a close of a channel or other script path
> > because then the miners could be more likely to extract a rent from you
> as
> > "ransom" for properly closing your channel (or in other words, in a
> > contested close the value of the closing transaction is larger than
> usual).
> >
> > It would also be possible to do something really simple which is to allow
> > the witness type to be either a MAST hash OR a schnorr key (but not a
> > Taproot). This allows you to not completely fracture the anonymity set
> > between people who want plain Schnorr and people who want MAST (at least
> > until they go to spend). This fix can also be used in Taproot in place
> of a
> > NUMS point, to decrease extra fees. It's unclear if this plays negatively
> > with any future batch validation mechanism though, but the contextual
> > checks to exclude a witness program from the batch are relatively simple.
> > See thread subject, "Taproot Public NUMS Optimization".
> >
> > The considerations around Graftroot, a proposed delegation mechanism, is
> a
> > bit similar. Delegation is a mechanism by which a UTXO with script S can
> > sign a script R which can then be executed in addition to S without
> > requiring a transaction. This allows an output to monotonically and
> > dynamically increase the number of conditions under which it can be
> spent.
> > As noted by Pieter Wiulle here:
> >
> https://github.com/kanzure/diyhpluswiki/commit/a03f6567d714f8733b578de263a4b149441cd058
> > delegation was originally possible in Bitcoin, but got broken during an
> > emergency fork to split the scriptSig and scriptpubkey separation. Rather
> > than adding some fancy delegation mechanism in Bitcoin, why not just
> have a
> > P2SH-like semantic which allows a delegated script to be evaluated? See
> > BIP-117 https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki.
> > This way we aren't special casing where delegation can occur, and we can
> > allow taproot nested spending conditions (i.e., with timelocks) to
> generate
> > their own delegations. As I've seen Graftroot discussed thus far, it is
> as
> > a top-level witness program version like Taproot and non-recursive.
> Similar
> > to the above discussion, top-level is more efficient if you suspect that
> > delegation will be most likely occurring at the top level, but it's not
> > clear that's a good assumption as it may be common to want to allow
> > different scripts to delegate.
> >
> >
> > Overall, we are left with concerns both about the merit of doing Taproot
> > versus alternatives, as well as the process through which we got to be
> here.
> >
> > 1) Is Taproot actually more private than bare MAST and Schnorr
> separately?
> > What are the actual anonymity set benefits compared to doing the
> separately?
> >
> > 2) Is Taproot actually cheaper than bare MAST and Schnorr separately?
> What
> > evidence do we have that the assumption it will be more common to use
> > Taproot with a key will outweigh Script cases?
> >
> > 3) Is Taproot riskier than bare MAST and Schnorr separately given the new
> > crypto? How well reviewed is the actual crypto parts? None of us
> personally
> > feel comfortable reviewing the crypto in Schnorr -- what's the set of
> > people who have thoroughly reviewed the crypto and aren't just ACKing
> > because they trust other developers to have looked at it close enough?
> >
> > 4) Design wise, couldn't we forego the NUMS point requirement and be able
> > to check if it's a hash root directly? This would encumber users who
> don't
> > need the key path a cheaper spend path. See thread subject, "Taproot
> Public
> > NUMS Optimization".
> >
> > 5) Is the development model of trying to jam a bunch of features into
> > Bitcoin all at once good for Bitcoin development? Would we be better off
> if
> > we embraced incremental improvements that can work together (e.g., MAST
> and
> > then Schnorr)? Although the BIP raises some points about anonymity sets
> > being why to do them all at once, it's not clear to me this argument
> holds
> > water (same goes for businesses not upgrading). If we can take things as
> > smaller steps, we are not only more secure, but we also have more time to
> > dedicate review to each change independently. We also end up co-mingling
> > changes that people end up accepting only because they want one and
> they're
> > bundled (e.g., MAST and Schnorr, MAST seems like a much less risky
> addition
> > versus Schnorr). See thread subject, "An Alternative Deployment Path for
> > Taproot Technologies".
> >
> >
> >
> >
> > Our provocation with this email is primarily that we think we should more
> > carefully consider the benefits of Taproot over simpler primitives that
> are
> > not only easier to review, but could have been made available much sooner
> > rather than waiting on putting everything all together for an unclear
> > aggregate benefit.
> >
> > We do think that most of the developers have been honest about the
> benefits
> > of Taproot, but that on closer look we feel the general ecosystem has
> > oversold Taproot as being the key enabler for a collection of techniques
> > that we could do with much simpler building blocks.
> >
> >
> > At the end of the day, we do not strongly advocate not deploying Taproot
> at
> > this point in the review cycle. We think the Taproot Public NUMS
> > Optimization may be a good idea, worth considering if it's not insecure,
> as
> > it cuts through the case where you would otherwise need a NUMS point.
> > Things like TapScript and its MAST mechanisms are well designed and offer
> > exciting new deployment paths, and would be something we would use even
> if
> > we opted for MAST instead of Taproot. However, we also believe it is our
> > duty to raise these concerns and suggestions, and we look forward to
> > listening to the responses of the community.
> >
> > Great thanks,
> >
> > The Group
> >
> > ----
> >
> > SUBJECT: An Alternative Deployment Path for Taproot Technologies
> >
> > This email is the second of a collection of sentiments from a group of
> > developers who in aggregate prefer to remain anonymous. These emails have
> > been sent under a pseudonym so as to keep the focus of discussion on the
> > merits of the technical issues, rather than miring the discussion in
> > personal politics. Our goal isn't to cause a schism, but rather to help
> > figure out what the path forward is with Taproot. To that end, we: [clip
> > repeat]
> >
> > As a follow up to our prior message, we propose a different path forward
> > for the Taproot family of changes:
> >
> > 1) A separate soft-fork for Merkle Branch Witnesses based on Taproot;
> >
> > 2) A separate soft-fork for Schnorr Signatures
> >
> > 3) A separate follow up soft-fork which enables Taproot and Graftroot
> >
> > We think that the first 2 forks can be offered at the same time or one
> at a
> > time.
> >
> > Taproot, as a follow up to changes 1 and 2, can be enabled as a soft-fork
> > on the existing semantics, but requiring a new witness version. With the
> > Public NUMS Optimization, wallets could upgrade by just changing one
> > version byte to be in the same anonymity set as Taproot.
> >
> > It's not clear to us that the time to prepare a BIP and implementation
> for
> > 1 and 2 at this point would be any less than the time to do Taproot as
> > currently proposed. However, we believe that such a deployment plan is a
> > reasonable option as it is more conservative, as Merkle Branch witnesses
> > are relatively simple and users only have to use Schnorr signing if they
> > want to, and can otherwise continue to use ECDSA. A further benefit of
> > waiting on 3 is that we get to collect real world protocol engineering
> > experience to see how frequently the Taproot frequency of use assumption
> > holds, and if it is worth doing or not.
> >
> >
> > Great thanks,
> >
> > The Group
> >
> >
> > ----
> >
> > SUBJECT: Taproot Public NUMS Optimization
> >
> > This email is the third of a collection of sentiments from a group of
> > developers who in aggregate prefer to remain anonymous. These emails have
> > been sent under a pseudonym so as to keep the focus of discussion on the
> > merits of the technical issues, rather than miring the discussion in
> > personal politics. Our goal isn't to cause a schism, but rather to help
> > figure out what the path forward is with Taproot. To that end, we:
> [clipped
> > again]
> >
> > We propose to modify Taproot's specification in BIP-341 by adding the
> rule:
> >
> > If there is one element on the witness stack:
> >
> > 1) Attempt hashing it to see if it's equal to the witness program. The
> > first byte is the control byte for leaf versioning.
> >
> > 2) If it's not the witness program, and it's 65 bytes, try signature
> > validation
> >
> > If there is more than one element on the witness stack:
> >
> > If the control block is even, treat it as a non-Taproot MAST and get the
> > leaf version as the last byte of the script (so you can pop it off before
> > hashing).
> >
> >
> > If greater anonymity is required, a NUMS point can still be used in
> > Taproot, at the expense of the additional data. However, if NUMS points
> are
> > just a couple well known constants this could actually decrease privacy
> as
> > then the NUMS points could differ from application to application
> > fingerprinting wallets. Instead, the NUMS point should only be used
> when a
> > single use nonce can be sent, so that NUMS cannot be distinguished from a
> > normal Taproot to a third party who doesn't know the setup (e.g., that
> the
> > NUMS is H(X) for known X).
> >
> >
> > Great thanks,
> >
> > The Group
> >
> >
> > _______________________________________________
> > 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/20200214/5b6e9b27/attachment-0001.html>;

📅 Original date posted:2019-10-27 📝 Original message:Johan, ...

2023-06-07T20:21:25+02:00

In reply to nevent1q…3z0d
_________________________

📅 Original date posted:2019-10-27
📝 Original message:Johan,

The issues with mempool limits for OP_SECURETHEBAG are related, but have
distinct solutions.

There are two main categories of mempool issues at stake. One is relay
cost, the other is mempool walking.

In terms of relay cost, if an ancestor can be replaced, it will invalidate
all it's children, meaning that no one paid for that broadcasting. This can
be fixed by appropriately assessing Replace By Fee update fees to
encapsulate all descendants, but there are some tricky edge cases that make
this non-obvious to do.

The other issue is walking the mempool -- many of the algorithms we use in
the mempool can be N log N or N^2 in the number of descendants. (simple
example: an input chain of length N to a fan out of N outputs that are all
spent, is O(N^2) to look up ancestors per-child, unless we're caching).

The other sort of walking issue is where the indegree or outdegree for a
transaction is high. Then when we are computing descendants or ancestors we
will need to visit it multiple times. To avoid re-expanding a node, we
currently cache it with a set. This uses O(N) extra memory and makes O(N
Log N) (we use std::set not unordered_set) comparisons.

I just opened a PR which should help with some of the walking issues by
allowing us to cheaply cache which nodes we've visited on a run. It makes a
lot of previously O(N log N) stuff O(N) and doesn't allocate as much new
memory. See: https://github.com/bitcoin/bitcoin/pull/17268.

Now, for OP_SECURETHEBAG we want a particular property that is very
different from with lightning htlcs (as is). We want that an unlimited
number of child OP_SECURETHEBAG txns may extend from a confirmed
OP_SECURETHEBAG, and then at the leaf nodes, we want the same rule as
lightning (one dangling unconfirmed to permit channels).

OP_SECURETHEBAG can help with the LN issue by putting all HTLCS into a tree
where they are individualized leaf nodes with a preceding CSV. Then, the
above fix would ensure each HTLC always has time to close properly as they
would have individualized lockpoints. This is desirable for some additional
reasons and not for others, but it should "work".

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Fri, Oct 25, 2019 at 10:31 AM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> I don’te see how? Let’s imagine Party A has two spendable outputs, now
> they stuff the package size on one of their spendable outlets until it is
> right at the limit, add one more on their other output (to meet the
> Carve-Out), and now Party B can’t do anything.
>
> On Oct 24, 2019, at 21:05, Johan Torås Halseth <johanth at gmail.com> wrote:
>
>
> It essentially changes the rule to always allow CPFP-ing the commitment as
> long as there is an output available without any descendants. It changes
> the commitment from "you always need at least, and exactly, one non-CSV
> output per party. " to "you always need at least one non-CSV output per
> party. "
>
> I realize these limits are there for a reason though, but I'm wondering if
> could relax them. Also now that jeremyrubin has expressed problems with the
> current mempool limits.
>
> On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> I may be missing something, but I'm not sure how this changes anything?
>>
>> If you have a commitment transaction, you always need at least, and
>> exactly, one non-CSV output per party. The fact that there is a size
>> limitation on the transaction that spends for carve-out purposes only
>> effects how many other inputs/outputs you can add, but somehow I doubt
>> its ever going to be a large enough number to matter.
>>
>> Matt
>>
>> On 10/24/19 1:49 PM, Johan Torås Halseth wrote:
>> > Reviving this old thread now that the recently released RC for bitcoind
>> > 0.19 includes the above mentioned carve-out rule.
>> >
>> > In an attempt to pave the way for more robust CPFP of on-chain contracts
>> > (Lightning commitment transactions), the carve-out rule was added in
>> > https://github.com/bitcoin/bitcoin/pull/15681. However, having worked
>> on
>> > an implementation of a new commitment format for utilizing the Bring
>> > Your Own Fees strategy using CPFP, I’m wondering if the special case
>> > rule should have been relaxed a bit, to avoid the need for adding a 1
>> > CSV to all outputs (in case of Lightning this means HTLC scripts would
>> > need to be changed to add the CSV delay).
>> >
>> > Instead, what about letting the rule be
>> >
>> > The last transaction which is added to a package of dependent
>> > transactions in the mempool must:
>> > * Have no more than one unconfirmed parent.
>> >
>> > This would of course allow adding a large transaction to each output of
>> > the unconfirmed parent, which in effect would allow an attacker to
>> > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is
>> > this a problem with the current mempool acceptance code in bitcoind? I
>> > would imagine evicting transactions based on feerate when the max
>> > mempool size is met handles this, but I’m asking since it seems like
>> > there has been several changes to the acceptance code and eviction
>> > policy since the limit was first introduced.
>> >
>> > - Johan
>> >
>> >
>> > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty at rustcorp.com.au
>> > <mailto:rusty at rustcorp.com.au>> wrote:
>> >
>> > Matt Corallo <lf-lists at mattcorallo.com
>> > <mailto:lf-lists at mattcorallo.com>> writes:
>> > >>> Thus, even if you imagine a steady-state mempool growth, unless
>> the
>> > >>> "near the top of the mempool" criteria is "near the top of the
>> next
>> > >>> block" (which is obviously *not* incentive-compatible)
>> > >>
>> > >> I was defining "top of mempool" as "in the first 4 MSipa", ie.
>> next
>> > >> block, and assumed you'd only allow RBF if the old package wasn't
>> > in the
>> > >> top and the replacement would be. That seems incentive
>> > compatible; more
>> > >> than the current scheme?
>> > >
>> > > My point was, because of block time variance, even that criteria
>> > doesn't hold up. If you assume a steady flow of new transactions and
>> > one or two blocks come in "late", suddenly "top 4MWeight" isn't
>> > likely to get confirmed until a few blocks come in "early". Given
>> > block variance within a 12 block window, this is a relatively likely
>> > scenario.
>> >
>> > [ Digging through old mail. ]
>> >
>> > Doesn't really matter. Lightning close algorithm would be:
>> >
>> > 1. Give bitcoind unileratal close.
>> > 2. Ask bitcoind what current expidited fee is (or survey your
>> mempool).
>> > 3. Give bitcoind child "push" tx at that total feerate.
>> > 4. If next block doesn't contain unilateral close tx, goto 2.
>> >
>> > In this case, if you allow a simpified RBF where 'you can replace if
>> > 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3.
>> > old tx isnt',
>> > it works.
>> >
>> > It allows someone 100k of free tx spam, sure. But it's simple.
>> >
>> > We could further restrict it by marking the unilateral close
>> somehow to
>> > say "gonna be pushed" and further limiting the child tx weight (say,
>> > 5kSipa?) in that case.
>> >
>> > Cheers,
>> > Rusty.
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > <mailto:Lightning-dev at lists.linuxfoundation.org>
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> >
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191027/184af597/attachment.html>;

📅 Original date posted:2019-10-04 📝 Original ...

2023-06-07T20:20:56+02:00

In reply to nevent1q…yl6n
_________________________

📅 Original date posted:2019-10-04
📝 Original message:Interesting point.

The script is under your control, so you should be able to ensure that you
are always using a correctly constructed midstate, e.g., something like:

scriptPubKey: <-1> OP_SHA256STREAM DEPTH OP_SHA256STREAM <-2>
OP_SHA256STREAM
<hash> OP_EQUALVERIFY

would hash all the elements on the stack and compare to a known hash.
How is that sort of thing weak to midstateattacks?

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Fri, Oct 4, 2019 at 4:16 AM Peter Todd <pete at petertodd.org> wrote:

> On Thu, Oct 03, 2019 at 10:02:14PM -0700, Jeremy via bitcoin-dev wrote:
> > Awhile back, Ethan and I discussed having, rather than OP_CAT, an
> > OP_SHA256STREAM that uses the streaming properties of a SHA256 hash
> > function to allow concatenation of an unlimited amount of data, provided
> > the only use is to hash it.
> >
> > You can then use it perhaps as follows:
> >
> > // start a new hash with item
> > OP_SHA256STREAM (-1) -> [state]
> > // Add item to the hash in state
> > OP_SHA256STREAM n [item] [state] -> [state]
> > // Finalize
> > OP_SHA256STREAM (-2) [state] -> [Hash]
> >
> > <-1> OP_SHA256STREAM <tag> <subnode 2> <subnode 3> <3> OP_SHA256STREAM
> <-2>
> > OP_SHA256STREAM
>
> One issue with this is the simplest implementation where the state is just
> raw
> bytes would expose raw SHA256 midstates, allowing people to use them
> directly;
> preventing that would require adding types to the stack. Specifically I
> could
> write a script that rather than initializing the state correctly from the
> official IV, instead takes an untrusted state as input.
>
> SHA256 isn't designed to be used in situations where adversaries control
> the
> initialization vector. I personally don't know one way or the other if
> anyone
> has analyzed this in detail, but I'd be surprised if that's secure. I
> considered adding midstate support to OpenTimestamps but decided against
> it for
> exactly that reason.
>
> I don't have the link handy but there's even an example of an experienced
> cryptographer on this very list (bitcoin-dev) proposing a design that falls
> victim to this attack. It's a subtle issue and we probably don't want to
> encourage it.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191004/bda6e24c/attachment-0001.html>;

📅 Original date posted:2019-06-23 📝 Original message:This ...

2023-06-07T20:18:27+02:00

In reply to nevent1q…5z7r
_________________________

📅 Original date posted:2019-06-23
📝 Original message:This is insufficient: sequences must be committed to because they affect
TXID. As with scriptsigs (witness data fine to ignore). NUM_IN too.

Any malleability makes this much less useful.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote:
> > So with regards to OP_SECURETHEBAG, I am also "not really seeing any
> reason to
> > complicate the spec to ensure the digest is precommitted as part of the
> > opcode."
>
> Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT
> (NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if
> it's been spelled out anywhere); ie instead of constructing
>
> X = Hash_BagHash( version, locktime, [outputs], [sequences], num_in )
>
> and having the script be "<X> OP_SECURETHEBAG" you calculate an
> ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:
>
> Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
> amount, sequence)
>
> and calculate a signature sig = Schnorr(P,m) for some pubkey P, and
> make your script be "<sig> <P> CHECKSIG".
>
> That loses the ability to commit to the number of inputs or restrict
> the nsequence of other inputs, and requires a bigger script (sig and P
> are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much the
> same as far as I can tell. Both scripts are automatically satisfied when
> revealed (with the correct set of outputs), and don't need any additional
> witness data.
>
> If you wanted to construct "X" via script instead of hardcoding a value
> because it got you generalised covenants or whatever; I think you could
> get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much
> the same way you construct X, but you'd then need to turn that into a
> signature. You could do so by using pubkey P=G and nonce R=G, which
> means you need to calculate s=1+hash(G,G,Y)*1 -- calculating the hash
> part is easy, multiplying it by 1 is easy, and to add 1 you can probably
> do something along the lines of:
>
> OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT
>
> (ie, take the last 4 bytes, increment it using 4-byte arithmetic,
> then cat the first 28 bytes and the result. There's overflow issues,
> but I think they can be worked around either by allowing you to choose
> different locktimes, or by more complicated script)
>
> Cheers,
> aj
>
> _______________________________________________
> 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/20190622/df90c3c4/attachment-0001.html>;

📅 Original date posted:2019-06-02 📝 Original message:Hi ...

2023-06-07T20:18:26+02:00

In reply to nevent1q…gus8
_________________________

📅 Original date posted:2019-06-02
📝 Original message:Hi Russell,

Thanks for the response. I double checked my work in drafting my response
and realized I didn't address all the malleability concerns, I believe I
have now (fingers crossed) addressed all points of malleability.

*The malleability concerns are as follows:*

A TXID is computed as:

def txid(self):
r = b""
r += struct.pack("<i", self.nVersion)
r += ser_vector(self.vin)
r += ser_vector(self.vout)
r += struct.pack("<I", self.nLockTime)
return sha256(r)

if the bag hash is just:

def get_bag_hash(self):
r = b""
r += ser_vector(self.vout)
return TaggedHash("BagHash", r)

We allow changing a few things: nVersion, nLockTime, scriptSig (per input),
number of inputs, nSequence (per input) which can change the TXID/what the
transaction does.

changing nVersion: can disable BIP68, change TXID
changing nLockTime: can change TXID
changing nSequence: can change TXID
changing number of inputs: half spend problem, change TXID
changing scriptsigs: change TXID if co-spent with legacy input

Instead, we can use the following digest:

def get_bag_hash(self):
r = b""
r += struct.pack("<i", self.nVersion)
r += struct.pack("<I", self.nLockTime)
r += sha256(b"".join(out.serialize() for out in self.vout))
r += sha256(b"".join(struct.pack("<I", inp.nSequence) for inp in
self.vin))
r += struct.pack("<Q", len(self.vin))
for inp in self.vin:
r += ser_string(inp.scriptSig)
return TaggedHash("BagHash", r)

which should lock in all the relevant bits. The only part left out is the
COutpoint, which can't be known ahead of time (because it depends on the
creating txn). Technically, len(vin) is redundant with
sha256(b"".join(struct.pack("<I", inp.nSequence) for inp in self.vin)),
because the length padding on the hash implied the number of inputs, but I
figured it's best to err on explicit.

A further benefit (in a CISC sense) of committing to all these values is
that we enforce CLTV and CSV semantics for free on OP_SECURETHEBAG scripts,
which helps with channels.

*Treating OP_SECURETHEBAG as a PUSHDATA:*

I agree in theory it's nicer, and am 100% open to implementing it that way.
The only concern I have with doing it this way is that it means that a
flags must be added to GetOp (or GetOp must be modularized to be per-script
version) because it affects script parsing, as opposed to using a multibyte
opcode which contains a pushdata, which remain compatible with prior script
parsing.

I'd like to get rough consensus on the best approach for compatibility with
downstream software, hence choosing this option for the draft.

Personally, my preference is to *not* do flags and just have a separate
parser version which cleans up some of our past sins. We can experiment
with a fancier parser (as you've shown in Haskell/Rust/Coq), perhaps even
bitwise huffman encoding opcodes to save space on scripts (i.e. the 7 most
common opcodes could fit within 3 bits) or whatever else we like. I just
didn't want to have the scope creep too far on this particular BIP, but I'm
with you that lookahead is a hack compared to an actual parametrized
argument.

I think you'd also appreciate the template script expansion approach
mentioned in the BIP -- it gets around some of these concerns, but requires
changes to Taproot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190602/dfb4e5a2/attachment-0001.html>;

📅 Original date posted:2017-01-03 📝 Original message:It is ...

2023-06-07T19:55:17+02:00

In reply to nevent1q…shl5
_________________________

📅 Original date posted:2017-01-03
📝 Original message:It is an unfortunate script, but can't actually
do
that much
it seems
. The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes.
Thus, it would seem the worst you could do with this would be to
(10000-520*2)*520*2
bytes ~=~ 10 MB.

Much more concerning would be the op_dup/op_cat style bug, which under a
similar script would certainly cause out of memory errors :)

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi all,
>
> Suppose someone were to use the following pk_script:
>
> [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
> op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
>
> This still seems to be valid AFAICS, and may be a potential attack vector?
>
> Thanks.
>
>
> _______________________________________________
> 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/20170102/91e5e8d8/attachment.html>;

📅 Original date posted:2016-10-09 📝 Original message:Hi ...

2023-06-07T19:53:50+02:00

In reply to nevent1q…2ytr
_________________________

📅 Original date posted:2016-10-09
📝 Original message:Hi bitcoin-dev,

I'm well aware that discussion of moderation on bitcoin-dev is
discouraged*. However, I think that we should, as a year of moderation
approaches, discuss openly as a community what the impact of such policy
has been. Making such a post now is timely given that people will have the
opportunity to discuss in-person as well as online as Scaling Bitcoin is
currently underway. On the suggestion of others, I've also CC'd
bitcoin-discuss on this message.

Below, I'll share some of my own personal thoughts as a starter, but would
love to hear others feelings as well.

For me, the bitcoin-dev mailing list was a place where I started
frequenting to learn a lot about bitcoin and the development process and
interact with the community. Since moderation has begun, it seems that the
messages/day has dropped drastically. This may be a nice outcome overall
for our sanity, but I think that it has on the whole made the community
less accessible. I've heard from people (a > 1 number, myself included)
that they now self-censor because they think they will put a lot of work
into their email only for it to get moderated away as trolling/spam. Thus,
while we may not observe a high rate of moderated posts, it does mean the
"chilling effect" of moderation still manifests -- I think that people not
writing emails because they think it may be moderated reduces the rate of
people writing emails which is a generally valuable thing as it offers
people a vehicle through which they try to think through and communicate
their ideas in detail.

Overall, I think that at the time that moderation was added to the list, it
was probably the right thing to do. We're in a different place as a
community now, so I feel we should attempt to open up this valuable
communication channel once again. My sentiment is that we enacted
moderation to protect a resource that we all felt was valuable, but in the
process, the value of the list was damaged, but not irreparably so.

Best,

Jeremy

* From the email introducing the bitcoin-dev moderation policy, "Generally
discouraged: shower thoughts, wild speculation, jokes, +1s, non-technical
bitcoin issues, rehashing settled topics without new data, moderation
concerns."

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161009/ea20481e/attachment.html>;