Jeremy [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-07-16 to 2022-02-20
💬 Posted a total of 260 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, Lightning-dev, was BIP OP_CHECKTEMPLATEVERIFY, Pre-BIP, was CheckSigFromStack for Arithmetic Values, Bitcoin Advent Calendar, dlc-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta

Profile Code

nprofile1qqsqraf6x9nt8v338yspwcmh0crslnld24266a247l5sz9xqe8sw3dqu7khl9

Author Public Key

npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta

Show more details

Last Notes

2023-06-09 13:05:01

- reply

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

2023-06-09 13:04:59

- reply

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

2023-06-09 13:04:58

- reply

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

2023-06-09 13:04:57

- reply

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

2023-06-09 13:03:19

- reply

📅 Original date posted:2021-08-20
📝 Original message:
one interesting point that came up at the bitdevs in austin today that
favors remove that i believe is new to this discussion (it was new to me):
the argument can be reduced to:
- dust limit is a per-node relay policy.
- it is rational for miners to mine dust outputs given their cost of
maintenance (storing the output potentially forever) is lower than their
immediate reward in fees.
- if txn relaying nodes censor something that a miner would mine, users
will seek a private/direct relay to the miner and vice versa.
- if direct relay to miner becomes popular, it is both bad for privacy and
decentralization.
- therefore the dust limit, should there be demand to create dust at
prevailing mempool feerates, causes an incentive to increase network
centralization (immediately)
the tradeoff is if a short term immediate incentive to promote network
centralization is better or worse than a long term node operator overhead.
///////////////////
my take is that:
1) having a dust limit is worse since we'd rather not have an incentive to
produce or roll out centralizing software, whereas not having a dust limit
creates an mild incentive for node operators to improve utreexo
decentralizing software.
2) it's hard to quantify the magnitude of the incentives, which does matter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210819/831b9608/attachment.html>

2023-06-09 13:03:14

- reply

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

2023-06-09 13:03:13

- reply

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

2023-06-09 13:03:09

- reply

📅 Original date posted:2021-07-12
📝 Original message:
Another option would be to somehow encrypt this data in, say, an OP_RETURN
for any update transaction for each participant (perhaps worth breaking
update symmetry for efficiency on this...) that way if an update ever
happens on a state you don't have you can use your static key to decrypt
the relevant data for what PK_si signed off on.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Jul 12, 2021 at 3:16 PM Jeremy <jlrubin at mit.edu> wrote:
> Without an exact implementation, one thing you could do to fix the lost
> state issue would be to make the scripts something like:
>
> [`<N+1> CLTV DROP PKu CHECKSIGVERIFY GETLOCKTIME <PK_root>
> BIP32DERIVE CHECKTRANSACTIONSIGNEDFROMSTACK`, `2016 CSV DROP PK_si
> CHECKSIG`]
>
> In order to upgrade to state M>= N+1 you'd have to publish a transaction
> signed with the BIP32 derived key for that update in the future.
>
> The downside is that you end up double publishing the txdata on the chain,
> but it at least ensure data availability.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210712/54e583d7/attachment.html>

2023-06-09 13:03:08

- reply

📅 Original date posted:2021-07-12
📝 Original message:
Without an exact implementation, one thing you could do to fix the lost
state issue would be to make the scripts something like:
[`<N+1> CLTV DROP PKu CHECKSIGVERIFY GETLOCKTIME <PK_root>
BIP32DERIVE CHECKTRANSACTIONSIGNEDFROMSTACK`, `2016 CSV DROP PK_si
CHECKSIG`]
In order to upgrade to state M>= N+1 you'd have to publish a transaction
signed with the BIP32 derived key for that update in the future.
The downside is that you end up double publishing the txdata on the chain,
but it at least ensure data availability.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210712/dabb3aed/attachment.html>

2023-06-09 13:02:21

- reply

📅 Original date posted:2021-04-23
📝 Original message:
I'd be excited to join. Recommend bumping the date to mid June, if that's
ok, as many Americans will be at Bitcoin 2021.
I was thinking about reviving the sponsors proposal with a 100 block lock
on spending a sponsoring tx which would hopefully make less controversial,
this would be a great place to discuss those tradeoffs.
On Fri, Apr 23, 2021, 8:17 AM Antoine Riard <antoine.riard at gmail.com> wrote:
> Hi,
>
> During the lastest years, tx-relay and mempool acceptances rules of the
> base layer have been sources of major security and operational concerns for
> Lightning and other Bitcoin second-layers [0]. I think those areas require
> significant improvements to ease design and deployment of higher Bitcoin
> layers and I believe this opinion is shared among the L2 dev community. In
> order to make advancements, it has been discussed a few times in the last
> months to organize in-person workshops to discuss those issues with the
> presence of both L1/L2 devs to make exchange fruitful.
>
> Unfortunately, I don't think we'll be able to organize such in-person
> workshops this year (because you know travel is hard those days...) As a
> substitution, I'm proposing a series of one or more irc meetings. That
> said, this substitution has the happy benefit to gather far more folks
> interested by those issues that you can fit in a room.
>
> # Scope
>
> I would like to propose the following 4 items as topics of discussion.
>
> 1) Package relay design or another generic L2 fee-bumping primitive like
> sponsorship [0]. IMHO, this primitive should at least solve mempools spikes
> making obsolete propagation of transactions with pre-signed feerate, solve
> pinning attacks compromising Lightning/multi-party contract protocol
> safety, offer an usable and stable API to L2 software stack, stay
> compatible with miner and full-node operators incentives and obviously
> minimize CPU/memory DoS vectors.
>
> 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it trivial
> for an attacker to partition network mempools in divergent subsets and from
> then launch advanced security or privacy attacks against a Lightning node.
> Note, it might also be a concern for bandwidth bleeding attacks against L1
> nodes.
>
> 3) Guidelines about coordinated cross-layers security disclosures.
> Mitigating a security issue around tx-relay or the mempool in Core might
> have harmful implications for downstream projects. Ideally, L2 projects
> maintainers should be ready to upgrade their protocols in emergency in
> coordination with base layers developers.
>
> 4) Guidelines about L2 protocols onchain security design. Currently
> deployed like Lightning are making a bunch of assumptions on tx-relay and
> mempool acceptances rules. Those rules are non-normative, non-reliable and
> lack documentation. Further, they're devoid of tooling to enforce them at
> runtime [2]. IMHO, it could be preferable to identify a subset of them on
> which second-layers protocols can do assumptions without encroaching too
> much on nodes's policy realm or making the base layer development in those
> areas too cumbersome.
>
> I'm aware that some folks are interested in other topics such as extension
> of Core's mempools package limits or better pricing of RBF replacement. So
> l propose a 2-week concertation period to submit other topics related to
> tx-relay or mempools improvements towards L2s before to propose a finalized
> scope and agenda.
>
> # Goals
>
> 1) Reaching technical consensus.
> 2) Reaching technical consensus, before seeking community consensus as it
> likely has ecosystem-wide implications.
> 3) Establishing a security incident response policy which can be applied
> by dev teams in the future.
> 4) Establishing a philosophy design and associated documentations (BIPs,
> best practices, ...)
>
> # Timeline
>
> 2021-04-23: Start of concertation period
> 2021-05-07: End of concertation period
> 2021-05-10: Proposition of workshop agenda and schedule
> late 2021-05/2021-06: IRC meetings
>
> As the problem space is savagely wide, I've started a collection of
> documents to assist this workshop : https://github.com/ariard/L2-zoology
> Still wip, but I'll have them in a good shape at agenda publication, with
> reading suggestions and open questions to structure discussions.
> Also working on transaction pinning and mempool partitions attacks
> simulations.
>
> If L2s security/p2p/mempool is your jam, feel free to get involved :)
>
> Cheers,
> Antoine
>
> [0] For e.g see optech section on transaction pinning attacks :
> https://bitcoinops.org/en/topics/transaction-pinning/
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> [2] Lack of reference tooling make it easier to have bug slip in like
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html
> _______________________________________________
> 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/20210423/4e8df87e/attachment.html>

2023-06-09 13:00:27

- reply

📅 Original date posted:2020-06-22
📝 Original message:
Yes -- to be clear, most of the feature-wise benefits of CTV for Lightning
are only in the initial channel setup phase, lessening interactivity
requirements.
Everything else can be emulated via multisig layers, but that can add
substantial latency in doing either 2pECDSA for each layer or on chain &
storage overhead in the signature space. CTV helps here because it can be
both deterministic & compact, but is not adding a new feature to already
interactive protocols. This does end up helping in terms of the feasibility
of some of the HTLC indirection tree techniques though :).
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sun, Jun 21, 2020 at 6:20 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> Hi Jeremy,
>
> The up-front costs can be further mitigated even without something like CTV
> (which makes things more efficient) by adding a layer of in-direction
> w.r.t how
> HTLCs are manifested within the commitment transactions. To do this, we
> add a
> new 2-of-2 multi-sig output (an HTLC indirect block) to the commitment
> transactions. This is then spent by a new transaction (the HTLC block) that
> actually manifests (creates the HTLC outputs) the HTLCs.
>
> With this change, the cost to have a commitment be mined in the chain is
> now
> _independent of the number of HTLCs in the channel_. In the past I've
> called
> this construction "coupe commitments" (lol).
>
> Other flavors of this technique are possible as well, allowing both sides
> to
> craft varying HTLC indirection trees (double layers of indirection are
> possible, etc) which may factor in traits like HTLC expiration time (HTLCs
> that
> expire later are further down in the tree).
>
> Something like CTV does indeed make this technique more powerful+efficient
> as
> it allows one to succinctly commit to all the relevant desirable
> combinations
> of HTLC indirect blocks, and HTLC fan-out transactions.
>
> -- Laolu
>
>
> On Sat, Jun 20, 2020 at 4:14 PM Jeremy <jlrubin at mit.edu> wrote:
>
>> 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
>>>
>> _______________________________________________
>> 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/20200622/96c3bf3b/attachment.html>

2023-06-09 13:00:25

- reply

📅 Original date posted:2020-06-21
📝 Original message:
Hi ZmnSCPxj,
My understanding is that you can use the CTV deferral to also get
independent HTLC relative timelocks start points per output. This would
help with this sort of issue right?
And you're correct that there's overhead of indirection, but it's not super
large (minimally complicated something like an extra 100 bytes per output,
if you were to have a flat array where each entry is a CTV output so that
each out gets its own clock).
Essentially something like this:
Chan
|
---------------------------------------------
| | | | |
CTV(A) CTV(B) CTV(C) CTV(D) (Optional CPFP Anchor?)
| | | |
1 block 1 block 1 block 1 block
| | | |
A B C D
Where A B C and D are all HTLCs.
Now because of the one-hop indirection, A B C and D can all expand
independently. It's also possible for the Channel Operator to do something
like:
Chan
|
---------------------------------------------
| | | | |
CTV(A) CTV(B) CTV(C) CTV(D) (Optional CPFP Anchor?)
| | | |
1 block 1 block 1 block 10 blocks
| | | |
A B C D
To make D have a further out resolution time to prevent the
simultaneous-ness issue (trees or a linear-chain rather than total fan-out
can also be used but I think it's a bit more confusing for a basic
example). The benefit of trees is that I can do something like:
Chan
|
--------------------------------------------------------
| | | | |
CTV(A) CTV(B) CTV(C) CTV(400 HTLC) (Optional CPFP Anchor?)
| | | | |
1 block 1 block 1 block 10 blocks (Optional CPFP Anchor?)
| | | |
| | | / ....\
A B C | ..... |
Which makes it so that the low-value new HTLCs can be deprioritized fee
wise. So that the attack, which occurs during a fee spike, doesn't end up
*requiring* substantial fees to be added to the channel to support a burst
of HTLCS.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sat, Jun 20, 2020 at 8:34 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Jeremy,
>
> > 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.
>
> If the attacker stops responding, then all HTLC rules need to be published
> onchain for enforcement of the HTLC rules.
> And that publication onchain is the problem: every HTLC published requires
> onchain space, which must be paid for.
>
> The most compact way to expose the HTLCs is as a flat array, i.e. outputs
> of a single transaction.
> Every tree structure is going to take up more space than a flat array.
>
> What CTV buys is to be able to defer *when* you reveal scripts, possibly
> to a later time when blockchain space is cheaper.
> But in case the victim owns the timelock branch of an outgoing HTLC, it is
> unsafe for the victim to defer: it has to enforce the locktime soon or it
> could end up losing both incoming and outgoing HTLC amounts.
> And to enforce the locktime it has to publish the HTLC.
>
> Now of course with CTV you could publish only the HTLC you have to enforce
> *now*, and keep the rest in an CTV output.
> The attacker can counter this by pushing 483 HTLCs with the same timelock
> at the victim, so that the victim has to publish all HTLCs simultaneously.
> And a flat array of outputs is cheaper than a tree.
>
> What *can* be done would be to bin by timelock rather than amount; tree
> leaves are a transaction that exposes all HTLCs with a particular timelock
> as a flat array of outputs, but different timelocks go to different tree
> branches.
> But the attacker can still do the same-timelock trick, and the tree
> structure is likely to take up more space in the end than just a non-treed
> flat array of outputs.
>
> Regards,
> ZmnSCPxj
>
>
> > --
> > @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/20200621/8e0db1ae/attachment-0001.html>

2023-06-09 12:59:51

- reply

📅 Original date posted:2020-04-22
📝 Original message:
Hi everyone,
Sorry to just be getting to a response here. Hadn't noticed it till now.
*(Plug: If anyone or their organizations would like to assist in funding
the work described below for a group of developers, I've been working to
put resources together for funding the above for a few months now, and I
think it would be high leverage towards seeing this through. There are a
lot of unsexy tasks to do that aren't coming up with a solution
(e.g.,writing a myriad of Mempool stress test scenarios) that can be a well
defined full-time job for someone to do.)*
I've been working on exactly this problem in the mempool for months now.
I'm deeply familiar with the issues here and the types of pinning possible.
I think everyone can recognize that with my work on OP_CTV I want nothing
more than the mempool to be able to accept whatever long chains we can
throw at it, but I'm pretty well steeped at this point in the obstacles to
doing that.
I don't think that we should be entertaining further carve outs at the
moment, unless it is really trivial. Every new carve out rule added to the
way that the mempool operates is removing complexity invariants we aim to
preserve in the mempool in order to keep nodes operational. Many of these
invariants are well documented, some are not. I'm happy to go off list for
a more thorough discussion with anyone qualified to have it; this isn't the
best venue for that discussion.
>From my point of view the path forward here is to dedicate more development
resources towards finishing the mempool project I began. You can see the
outstanding work here: https://github.com/bitcoin/bitcoin/projects/14,
contributing review towards moving those PRs forward will greatly improve
our ability to consider a stopgap carve out measure.
The current focus of this work is primarily on:
1) Testing Construction to better test & catch regressions or
vulnerabilities introduced or extant in mempool
2) Refactoring algorithms in mempool to reduce constant factors &
asymptotics
3) Package Relay
None of these fix the exact problem at hand though, but here's part of how
they can help us:
If we finish up the algorithmic refactors I've been working on it seems
plausible to do a one-off increase of descendants limits to say, 100
descendants with no restriction. However, we could use the opportunity to
use the 75 descendant increase exclusively for a new carve out, and apply
some new stricter rules in that extra space. There are a few anti-pinning
countermeasures that you can apply in that space that you would not
generally want in the mempool. An example of one is that any new
transaction must pay more feerate and absolute fee than every child in that
space. Or that only the highest fee paying branch of the excess
transactions are mineable, no others. Another would be disabling RBF past
that watermark. In all likelihood, different subsystems interacting with
the mempool will require a different set of restrictions each with the
current architecture, I don't think there's a magic bullet.
Package relay is a promising approach for a future pinning solution as
there are opportunities to attach to packages compact proofs of improved
fee efficiency for pinned transactions. But the ground work for package
relay needs to come first. This is theoretically possible with our current
architecture of the mempool and can probably address much of the pinning
concerns by replacing pinning with more rational eviction policies.
Longer term I've been working on plans and designs to completely re-do the
mempool's architecture to make it behave for arbitrary cases. It's possible
to one day lift all preemptively enforced (e.g., before acceptance)
descendants limits, which can solve this problem for good. There is more
than one potentially good solution here, and a conjunction of them can be
used as they affect independent sub systems. But this work will probably
take years to complete to the point where restrictions can realistically be
lifted.
If developers would like to coordinate resources around completing this
work and making more regular progress on it I'm happy to help point people
to specific tasks that need to be done in order to accelerate this and help
serialize the work so that we can not get into rebase hell.
Originally I had the plug at the top as a closing note, but I figured
people might miss it.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/a1e156ab/attachment.html>

2023-06-09 12:56:47

- reply

📅 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/lightning-dev/attachments/20191027/184af597/attachment.html>

2023-06-09 12:56:31

- reply

📅 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/lightning-dev/attachments/20191004/bda6e24c/attachment.html>

- reply

- reply

- reply

- reply

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

2023-06-07 23:02:35

- reply

📅 Original date posted:2022-01-18
📝 Original message:Thanks for the detailed review.
I'll withhold comment around activation logic and leave that for others to
discuss.
w.r.t. the language cleanups I'll make a PR that (I hope) clears up the
small nits later today or tomorrow. Some of it's kind of annoying because
the legal definition of covenant is "A formal agreement or promise, usually
included in a contract or deed, to do or not do a particular act; a compact
or stipulation made in writing or by parol." so I do think things like
CLTV/CSV are covenants since it's a binding promise to not spend before a
certain time... it might be out of scope for the BIP to fully define these
terms because it doesn't really matter what a covenant could be as much as
it matters what CTV is specifically.
On the topic of drafting BIPs for specific use cases, I agree that would be
valuable and can consider it.
However, I'm a bit skeptical of that approach overall as I don't
necessarily think that the applications *must be* standard, and I view BIPs
as primarily for standardization whereas part of the flexibility of
CTV/Sapio allows users to figure out how they want to use it.
E.g., we do not yet have a BIP for MuSig or even Multisig in Taproot,
although there are some papers and example implementations but nothing
formal yet
https://bitcoin.stackexchange.com/questions/111666/support-for-taproot-multisig-descriptors).
Perhaps this is an opportunity for CTV to lead on the amount of formal
application designs available before 'release'.
As a starting point, maybe you could review some of the application focused
posts in rubin.io/advent21 and let me know where they seem deficient?
Also a BIP describing how to build something like Sapio (and less so Sapio
itself, since it's still early days for that) might help for folks to be
able to think through how to compile to CTV contracts? But again, I'm
skeptical of the value of a BIP v.s. the documentation and examples
available in the code and https://learn.sapio-lang.org.
I think it's an interesting discussion too because as we've just seen the
LN ecosystem start the BLIP standards, would an example of non-interactive
channels be best written up as a BIP, a BLIP, or a descriptive blog/mailing
list post?
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Tue, Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> tl;dr: I don't think CTV is ready yet (but probably close), and in any
> case
> definitely not worth reviving BIP 9 with its known flaws and vulnerability.
>
> My review here is based solely on the BIP, with no outside context (aside
> from
> current consensus rules, of course). In particular, I have _not_ looked at
> the CTV code proposed for Bitcoin Core yet.
>
> >Covenants are restrictions on how a coin may be spent beyond key
> ownership.
>
> nit: Poorly phrased. Even simple scripts can do that already.
>
> >A few examples are described below, which should be the subject of future
> non-consensus standardization efforts.
>
> I would ideally like to see fully implemented BIPs for at least one of
> these
> (preferably the claimed CoinJoin improvements) before we move toward
> activation.
>
> >Congestion Controlled Transactions
>
> I think this use case hasn't been fully thought through yet. It seems like
> it
> would be desirable for this purpose, to allow any of the recipients to
> claim
> their portion of the payment without footing the fee for every other
> payment
> included in the batch. This is still a covenant-type solution, but one
> that
> BIP 119 cannot support as-is.
>
> (I realise this may be a known and accepted limitation, but I think it
> should
> be addressed in the BIP)
>
> >Payment Channels
>
> Why batch mere channel creation? Seems like the spending transaction
> should
> really be the channel closing.
>
> >CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins
> than
> previously because participants agree on a single output which pays all
> participants, which will be lower fee than before.
>
> I don't see how. They still have to agree in advance on the outputs, and
> the
> total fees will logically be higher than not using CTV...?
>
> >Further Each participant doesn't need to know the totality of the outputs
> committed to by that output, they only have to verify their own sub-tree
> will
> pay them.
>
> I don't see any way to do this with the provided implementation.
>
> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
> Trial.
>
> Hard NACK on this. BIP 9 at this point represents developers attempting to
> disregard and impose their will over community consensus, as well as an
> attempt to force a miner veto backdoor/vulnerability on deployment. It
> should
> never be used again.
>
> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
> compromise between LOT=True and LOT=False (which could be deployed prior
> to
> or in parallel), but using BIP 9 would destroy this.
>
> As with Taproot, any future deployments should use BIP 8 again, until a
> better
> solution is developed. Reverting back to a known flawed and vulnerable
> activation method should not be done, and it would be better not to deploy
> CTV at all at such an expense.
>
> The fact that certain developers attempted to deploy a BIP 9 alternative
> activation for Taproot against community consensus, and that even managed
> to
> get released as "Bitcoin Core", makes it all the more important that the
> community firmly rejects any further action to force this regression.
>
> * it is my opinion a BIP 8 ST would be an okay compromise under those
> circumstances; others do disagree that ST is acceptable at all
>
> > This ensures that for a given known input, the TXIDs can also be known
> ahead
> of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched
> Channel Creation constructions as the redemption TXID could be malleated
> and
> pre-signed transactions invalidated, unless the channels are built using
> an
> Eltoo-like protocol.
>
> Why is it a problem for them to use an Eltoo-like protocol?
>
> Why not just commit to the txid itself if that's the goal?
>
> >P2SH is incompatible with CHECKTEMPLATEVERIFY
>
> Maybe the CTV opcode should only be defined/enforced within witness
> scripts?
>
> >nLockTime should generally be fixed to 0 (in the case of a payment tree,
> only
> the *first* lock time is needed to prevent fee-sniping the root)
>
> Your "Congestion Controlled Transactions" example would only make sense
> with
> the spending transaction much later than the "root", and so could benefit
> from fee sniping malleability. (In fact, in that example, it would be
> better
> not to commit to locktime at all.)
>
> >In the CHECKTEMPLATEVERIFY approach, the covenants are severely
> restricted to
> simple templates. The structure of CHECKTEMPLATEVERIFY template is such
> that
> the outputs must be known exactly at the time of construction. Based on a
> destructuring argument, it is only possible to create templates which
> expand
> in a finite number of steps.
>
> It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get
> added.
>
> >For example, a exchange's hot wallet might use an address which can
> automatically be moved to a cold storage address after a relative timeout.
>
> Wouldn't it make more sense to just have a UTXO both cold+hot can spend,
> then
> throw away the hot key?
>
> >In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make
> scripts
> valid for policy until the new rule is active.
>
> Policy isn't validity, and cannot be dictated by BIPs (or anyone/anything,
> for
> that matter).
>
> 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/20220118/84498a7e/attachment-0001.html>

2023-06-07 23:02:23

- reply

📅 Original date posted:2022-01-17
📝 Original message:This is a good point, but can be addressed by having a non-void whitespace
character (e.g., win x estate).
changing BIP39 would be hard since software expects a standard list; it
would also be possible to rejection sample for seeds that do not contain
these pairs, unclear how much entropy would be lost from that.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Jan 17, 2022 at 2:26 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> really don't like that art, work, and artwork are 3 different words
>
> would be nice to clean up adjacent ambiguity
>
> it's not a big deal, but it can lead to confusion when writing things down
>
>
> dup: ('canal', 'arm') ('can', 'alarm')
> dup: ('canal', 'one') ('can', 'alone')
> dup: ('canal', 'ready') ('can', 'already')
> dup: ('card', 'anger') ('car', 'danger')
> dup: ('card', 'ice') ('car', 'dice')
> dup: ('card', 'inner') ('car', 'dinner')
> dup: ('card', 'raw') ('car', 'draw')
> dup: ('cart', 'able') ('car', 'table')
> dup: ('cart', 'ask') ('car', 'task')
> dup: ('cart', 'hat') ('car', 'that')
> dup: ('cart', 'hen') ('car', 'then')
> dup: ('cart', 'issue') ('car', 'tissue')
> dup: ('cart', 'one') ('car', 'tone')
> dup: ('cart', 'own') ('car', 'town')
> dup: ('cart', 'rack') ('car', 'track')
> dup: ('cart', 'rain') ('car', 'train')
> dup: ('cart', 'win') ('car', 'twin')
> dup: ('catch', 'air') ('cat', 'chair')
> dup: ('erase', 'arch') ('era', 'search')
> dup: ('fatal', 'arm') ('fat', 'alarm')
> dup: ('fatal', 'one') ('fat', 'alone')
> dup: ('fatal', 'ready') ('fat', 'already')
> dup: ('feed', 'anger') ('fee', 'danger')
> dup: ('feed', 'ice') ('fee', 'dice')
> dup: ('feed', 'inner') ('fee', 'dinner')
> dup: ('feed', 'raw') ('fee', 'draw')
> dup: ('feel', 'earn') ('fee', 'learn')
> dup: ('feel', 'end') ('fee', 'lend')
> dup: ('gasp', 'act') ('gas', 'pact')
> dup: ('gasp', 'age') ('gas', 'page')
> dup: ('gasp', 'air') ('gas', 'pair')
> dup: ('gasp', 'ill') ('gas', 'pill')
> dup: ('gasp', 'raise') ('gas', 'praise')
> dup: ('gasp', 'rice') ('gas', 'price')
> dup: ('gasp', 'ride') ('gas', 'pride')
> dup: ('gasp', 'roof') ('gas', 'proof')
> dup: ('kite', 'merge') ('kit', 'emerge')
> dup: ('kite', 'motion') ('kit', 'emotion')
> dup: ('kite', 'state') ('kit', 'estate')
> dup: ('lawn', 'arrow') ('law', 'narrow')
> dup: ('lawn', 'either') ('law', 'neither')
> dup: ('lawn', 'ice') ('law', 'nice')
> dup: ('legal', 'arm') ('leg', 'alarm')
> dup: ('legal', 'one') ('leg', 'alone')
> dup: ('legal', 'ready') ('leg', 'already')
> dup: ('seat', 'able') ('sea', 'table')
> dup: ('seat', 'ask') ('sea', 'task')
> dup: ('seat', 'hat') ('sea', 'that')
> dup: ('seat', 'hen') ('sea', 'then')
> dup: ('seat', 'issue') ('sea', 'tissue')
> dup: ('seat', 'one') ('sea', 'tone')
> dup: ('seat', 'own') ('sea', 'town')
> dup: ('seat', 'rack') ('sea', 'track')
> dup: ('seat', 'rain') ('sea', 'train')
> dup: ('seat', 'win') ('sea', 'twin')
> dup: ('skin', 'arrow') ('ski', 'narrow')
> dup: ('skin', 'either') ('ski', 'neither')
> dup: ('skin', 'ice') ('ski', 'nice')
> dup: ('tent', 'able') ('ten', 'table')
> dup: ('tent', 'ask') ('ten', 'task')
> dup: ('tent', 'hat') ('ten', 'that')
> dup: ('tent', 'hen') ('ten', 'then')
> dup: ('tent', 'issue') ('ten', 'tissue')
> dup: ('tent', 'one') ('ten', 'tone')
> dup: ('tent', 'own') ('ten', 'town')
> dup: ('tent', 'rack') ('ten', 'track')
> dup: ('tent', 'rain') ('ten', 'train')
> dup: ('tent', 'win') ('ten', 'twin')
> dup: ('used', 'anger') ('use', 'danger')
> dup: ('used', 'ice') ('use', 'dice')
> dup: ('used', 'inner') ('use', 'dinner')
> dup: ('used', 'raw') ('use', 'draw')
> dup: ('wine', 'merge') ('win', 'emerge')
> dup: ('wine', 'motion') ('win', 'emotion')
> dup: ('wine', 'state') ('win', 'estate')
> dup: ('wing', 'host') ('win', 'ghost')
> dup: ('wing', 'love') ('win', 'glove')
> dup: ('wing', 'old') ('win', 'gold')
> dup: ('wing', 'own') ('win', 'gown')
> dup: ('wing', 'race') ('win', 'grace')
> dup: ('wing', 'rain') ('win', 'grain')
> dup: ('wink', 'now') ('win', 'know')
> dup: ('youth', 'under') ('you', 'thunder')
> _______________________________________________
> 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/20220117/2bbe5f2e/attachment.html>

2023-06-07 23:02:12

- reply

📅 Original date posted:2022-01-14
📝 Original message:If I understand the intent of your message correctly, that's unfortunately
not how the law works.
If there is a case that is precedent setting, whether it directly involves
bitcoin or not, a bitcoin focused legal fund might want to either offer
representation or file an amicus brief to guide the court to making a
decision beneficial to Bitcoin Developers.
More than likely, some of these cases would involve developers of
alternative projects (as they might be "ahead of the curve" on legal
problems) and heading off a strong precedent for other communities would be
protective for Bitcoiners in general. As an example, were the developers
building Rollups on Ethereum to face a legal threat, since we might one day
want similar software for Bitcoin, ensuring a good outcome for them helps
Bitcoin.
That said, all organizations must at some point have a defined scope, and
it seems the BLDF is primarily focused for now on things impacting the
developers of Bitcoin or software for bitcoin specifically. I "trust" the
legal team behind BLDF will form a coherent strategy around what is
relevant to Bitcoin defense, even if the particulars of a case are not
directly about Bitcoin.
cheers,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Fri, Jan 14, 2022 at 10:25 AM qmccormick13 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I very much hope the fund will not finance lawsuits irrelevant to bitcoin.
>
> On Fri, Jan 14, 2022 at 5:23 PM Aymeric Vitte via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> (P2P?) Electronic Cash (Defense?) Fund or Electronic Cash Foundation ?
>> More neutral, potentially covering others than Bitcoin, mimicking a bit
>> EFF (even if as stated US is not the only target), referring to
>> Satoshi's paper where everything started
>>
>> Maybe I am not up to date but it would be good to know what are the
>> current procedures with the Tulip thing
>>
>> Aymeric
>>
>>
>> Le 13/01/2022 à 19:20, jack via bitcoin-dev a écrit :
>> > Hi Prayank,
>> >
>> >> On 13 Jan 2022, at 10:13, Prayank <prayank at tutanota.de> wrote:
>> >> I had few suggestions and feel free to ignore them if they do not make
>> sense:
>> >>
>> >> 1.Name of this fund could be anything and 'The Bitcoin Legal Defense
>> Fund' can be confusing or misleading for newbies. There is nothing official
>> in Bitcoin however people believe things written in news articles and some
>> of them might consider it as an official bitcoin legal fund.
>> > Excellent point. Will come up with a better name.
>> >
>> >> 2.It would be better if people involved in such important funds do not
>> comment/influence soft fork related discussions. Example: Alex Morcos had
>> some opinions about activation mechanism during Taproot soft fork IIRC.
>> > Yes. Will think through this and board operating principles we can
>> share publicly, which would probably include criteria for how cases are
>> chosen, to protect against this board and fund influencing direction.
>> >
>> > Open to ideas and suggestions on all.
>> >
>> > jack
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220114/bbca9866/attachment-0001.html>

2023-06-07 23:01:54

- reply

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

2023-06-07 23:01:51

- reply

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

2023-06-07 23:01:50

- reply

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

2023-06-07 23:01:49

- reply

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

2023-06-07 23:01:34

- reply

📅 Original date posted:2021-12-17
📝 Original message:An interesting concept occurred to me today while chatting with Nic Carter.
If we set Bitcoin Core up to gossip headers for work shares (e.g., expected
500 headers per block would have 20kb overhead, assuming we don't need to
send the prev hash) we'd be able to have more accurate finality estimates
and warnings if we see hashrate abandoning our chain tip. This is
observable regardless of if dishonest miners choose not to publish their
work on non tip shares, since you can notice the missing work.
In the GUI, we could give users an additional warning if they are
accepting a payment during a sudden hashrate decrease that they might wait
longer.
Has this been discussed before?
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/20211217/fbca153e/attachment.html>

2023-06-07 23:01:26

- reply

📅 Original date posted:2021-12-23
📝 Original message:> If you introduce signing into mining, then you will have cases, where
> someone is powerful enough to produce blocks, but cannot, because signing
> is needed. Then, your consensus is no longer "the heaviest chain", but "the
> heaviest signed chain". That means, your computing power is no longer
> enough by itself (as today), because to make a block, you also need some
> kind of "permission to mine", because first you sign things (like in
> signet) and then you mine them. That kind of being "reliably unreliable"
> may be ok for testing, but not for the main network.
this is a really great point worth underscoring. this is the 'key
ingredient' for DCFMP, which is that there is no signing or other network
system that is 'in the way' of normal bitcoin mining, just an opt-in set of
rules for sharing the bounties of your block in exchange for future shares.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211223/9dd4e268/attachment.html>

2023-06-07 23:01:23

- reply

📅 Original date posted:2021-12-16
📝 Original message:high level response:
including a small number of block headers (10?) directly as op_return
metadata (or something) doesn't have that high overhead necessarily, but
could be super effective at helping miners participate with lower hashrate.
the reason to include this as on-chain data is so that the mining pool
doesn't require any external network software.
this would balance out the issues if the data is somewhat bounded (e.g., 10
headers). what's nice is this data has no consensus meaning as it's client
side validated by the DCFMP block filter.
interestingly, the participating pools could 'vote' on how difficult shares
should be as a metaparameter to the pool over blocks... but analysis gets
more complex with that.
cheers,
jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211216/b0d4f253/attachment.html>

2023-06-07 23:01:20

- reply

📅 Original date posted:2021-12-15
📝 Original message:Hi Billy!
Thanks for your response. Some replies inline:
On Wed, Dec 15, 2021 at 10:01 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Looks like an interesting proposal, but it doesn't seem to quite match the
> goals you mentioned. As you do mention, this mining pool coordination
> doesn't get rid of the need for mining pools in the first place. So it
> doesn't satisfy item 1 on your goal list afaict.
>
It does, actually :) Point 1 was
1. Funds should not be centrally custodied, ever, if at all
And for top-level pool participants there is never any central custody.
What the windows are there (100 blocks, 2016, 4032, etc) is up to the
specific implementation which sets limits on how small you can be to
participate.
Further, for the entities that are too small:
from the article:
*> **The blocks that they mine should use a taproot address/key which is a
multisig of some portion of the workshares, that gets included in the
top-level pool as a part of Payment Pool.*
The micro-pools embed a multisig of top-contributors, 'reputable' members,
or on a rotating basis, as a leaf node to the parent. They then opt-out of
having their leaf channel-ized, as noted.
This would be fully non-custodial if we always included all miners. The
issue is that opens up DoS if one miner goes away, so you do want to anchor
around a few.
In this mode, you can set the protocol up such that immediately after
getting a reward in a block, you should see the chosen nodes for multi-sigs
distribute the spoils according to the schedule that is agreed on in the
block causing the share to be granted.
the main issue is data availability, without extra in-band storage local
mining pools have to track the work shares (which can be committed to in a
block) locally for auditing.
This is not fully non-custodial, but it doesn't have to be centrally
custodied by one party. We can multisig immediately after every block (and
nodes should quit their pool if they don't get sigs quickly perhaps).
Further, nodes can hash into multiple pools dividing their risk (modulo
sybil attack) across many pools.
If we had stronger covenants (CAT, AMOUNT, DIVIDE/MUL), we could make every
leaf node commit to payment pools that operate on percents instead of fixed
amounts and we'd be able to handle this in a manner that the payment pools
work no matter what amount is assigned to them.
The primary benefits over what we have today that I can see are:
> 1. increased payout regularity, which lowers the viable size of mining
> pools, and
> 2. Lower on chain footprint through combining pay outs from multiple pools.
>
> Am I missing some?
>
> These are interesting benefits, but it would be nice if your post was
> clearer on that, since the goals list is not the same as the list of
> potential benefits of this kind of design.
>
I think I hit all the benefits mentioned:
1. Funds should not be centrally custodied, ever, if at all.
see above -- we can do better for smaller miners, but we hit this for
miners above the threshold.
2. No KYC/AML.
see above, payouts are done 'decentralized' by every miner mining to the
payout
3. No “Extra network” software required.
you need the WASM, but do not need any networked software to participate,
so there are no DoS concerns from participating.
You do need extra software to e.g. use channels or cut-through multiple
pools, but only after the fact of minding.
4. No blockchain bloat.
Very little, if cut-through + LN works.
5. No extra infrastructure.
Not much needed, if anything. I don't really know what 'infrastructure'
means, but I kind of imagined it to mean 'big expensive things' that would
make it hard to partake.
6. The size of a viable pool should be smaller. Remember our singer – if
you just pool with one other songwriter it doesn’t make your expected time
till payout in your lifetime. So bigger the pools, more regular the
payouts. We want the smallest possible “units of control” with the most
regular payouts possible.
I think this works, roughly?
> As far as enabling solo mining, what if this concept were used off chain?
> Have a public network of solo miners who publish "weak blocks" to that
> network, and the next 100 (or 1000 etc) nice miners pay you out as long as
> you're also being nice by following the protocol? All the nice
> optimizations you mentioned about eg combined taproot payouts would apply i
> think. The only goals this wouldn't satisfy are 3 and 5 since an extra
> network is needed, but to be fair, your proposal requires pools which all
> need their own extra network anyways.
>
> The missing piece here would be an ordering of weak blocks to make the
> window possible. Or at least a way to determine what blocks should
> definitely be part of a particular block's pay out. I could see this being
> done by a separate ephemeral blockchain (which starts fresh after each
> Bitcoin block) that keeps track of which weak blocks have been submitted,
> potentially using the pow already in each block to secure it. Granted that
> piece is a bit half baked, but it seems quite solvable. Wdyt?
>
>
Yeah, it's worth thinking more about 100%. This post wasn't a deployable
thing, more an exposition of a technique. I'd love to see a weak-block
based pool, the main issue as noted is the extra software component + data
availability, but perhaps that's solvable!
> One thing that jumped out at me as not safe is throwing block rewards into
> a channel and being able to spend them immediately. There's a reason block
> rewards aren't spendable for a while, and channels don't solve that
> problem, do they? Why not simply reduce the on chain wait time for spending
> block rewards at that point? Seems like the consequences would be the same.
>
Miners could already do this if they mine to e.g. a multisig (trustlessly
if they form blocks with their counterparty and pre-sign before hashing).
Also in lightning we don't generally have to check that our routes channels
exist, we don't care as long as they are happy. Thus it doesn't "hurt"
anyone except for the miners who are taking the not fully locked in funds
risk, a risk they already take. But that risk can't infect the rest of
Bitcoin's users.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211215/ebd6b6af/attachment-0001.html>

2023-06-07 23:01:18

- reply

📅 Original date posted:2021-12-14
📝 Original message:I've received some confused messages that whatever I was replying to didn't
come through, I've reproduced Bob's e-mail below that I was responding to
for context:
*This, quite simply, is not a "pool". A pool is by definition a tool to
reduceprofit variance by miners by collecting "weak blocks" that do not
meet thedifficulty target, so as to get a better statistical measure of
each miner'shashrate, which is used to subdivide profits. These are called
"shares" and areentirely absent here.The only available information here to
decide payouts is the blocks themselves,I do not have any higher statistics
measurement to subdivide payments. If Iexpect to earn 3 blocks within the
window, sometimes I will earn 2 and sometimesI will earn 4. Whether I keep
the entire coinbase in those 2-4 blocks, or I have100 other miners paying
me 1/100 as much 100 times, my payment is the same andmust be proportional
to the number of blocks I mine in the window. My varianceis not
reduced.Further, by making miners pay other miners within the window N,
this results inN^2 payments to miners which otherwise would have had N
coinbase payments. So,this is extremely block-space inefficient for no good
reason. P2Pool had thesame problem and generated giant coinbases which
competed with fee revenue."Congestion control" makes this somewhat worse
since is it is an absoluteincrease in the block space consumed for these
N^2 payments.The only thing this proposal does do is smooth out fee
revenue. While hedging onfee revenue is valuable, this is an extremely
complicated and expensive way togo about it, that simultaneously *reduces*
fee revenue due to all the extrablock space used for miner payouts.*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211214/9be6323e/attachment.html>

2023-06-07 23:01:17

- reply

📅 Original date posted:2021-12-14
📝 Original message:Bitcoin didn't invent the concept of pooling:
https://en.wikipedia.org/wiki/Pooling_(resource_management). This is a
Bitcoin Mining Pool, although it may not be your favorite kind, which is
fixated on specific properties of computing contributions before finding a
block. Pooling is just a general technique for aggregating resources to
accomplish something. If you have another name like pooling that is in
common use for this type of activity I would be more than happy to adopt it.
This sort of pool can hedge not only against fee rates but also against
increases in hashrate since your historical rate 'carries' into the future
as a function of the window. Further, windows and reward functions can be
defined in a myriad of ways that could, e.g., pay less to blocks found in
more rapid succession, contributing to the smoothing functionality.
With respect to sub-block pooling, as described in the article, this sort
of design also helps with micro-pools being able to split resources
non-custodially in every block as a part of the higher order DCFMP. The
point is not, as noted, to enable solo mining an S9, but to decrease the
size of the minimum viable pool. It's also possible to add, without much
validation or data, some 'uncle block' type mechanism in an incentive
compatible way (e.g., add 10 pow-heavy headers on the last block for cost
48 bytes header + 32 bytes payout key) such that there's an incentive to
include the heaviest ones you've seen, not just your own, that are worth
further study and consideration (particularly because it's non-consensus,
only for opt-in participation in the pool).
With respect to space usage, it seems you wholly reject the viability of a
payment pool mechanism to cut-through chain space. Is this a critique that
holds for all Payment Pools, or just in the context of mining? Is there a
particular reason why you think it infeasible that "strongly online"
counterparties would be able to coordinate more efficiently? Is it
preferable for miners, the nexus of decentralization for Bitcoin, to prefer
to use custodial services for pooling (which may require KYC/AM) over
bearing a cost of some extra potential chainload?
Lastly, with respect to complexity, the proposal is actually incredibly
simple when you take it in a broader context. Non Interactive Channels and
Payment Pools are useful by themselves, so are the operations to merge them
and swap balance across them. Therefore most of the complexity in this
proposal is relying on tools we'll likely see in everyday use in any case,
DCFMP or no.
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211214/8d63da6e/attachment.html>

2023-06-07 23:01:17

- reply

📅 Original date posted:2021-12-12
📝 Original message:Hey there!
Thanks for your response!
One of the reasons to pick a longer window of, say, a couple difficulty
periods would be that you can make participation in the pool hedge you
against hashrate changes.
You're absolutely spot on to think about the impact of pooling w.r.t.
variance when fees > subsidy. That's not really in the analysis I had in
the (old) post, but when the block revenues swing, dcfmp over longer
periods can really smooth out the revenues for miners in a great way. This can
also help with the "mind the gap" problem when there isn't a backlog of
transactions, since producing an empty block still has some value (in order
to incentivize mining transaction at all and not cheating, we need to
reward txn inclusion as I think you're trying to point out.
Sadly, I've read the rest of your email a couple times and I don't really
get what you're proposing at all. It jumps right into "things you could
compute". Can you maybe try stating the goals of your payout function, and
then demonstrate how what you're proposing meets that? E.g., we want to pay
more to miners that do x?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211212/092788f5/attachment.html>

2023-06-07 23:01:16

- reply

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

2023-06-07 22:58:47

- reply

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

2023-06-07 22:58:40

- reply

📅 Original date posted:2021-09-06
📝 Original message:BIP 68 says >= 2:
*This specification defines the meaning of sequence numbers for
transactions with an nVersion greater than or equal to 2 for which the rest
of this specification relies on.*
BIP-112 says not < 2
// Fail if the transaction's version number is not set high
// enough to trigger BIP 68 rules.
if (static_cast<uint32_t>(txTo->nVersion) < 2) return false;
A further proof that this needs fix: the flawed upgradable semantic exists
in script as well as in the transaction nSeqeunce. we can't really control
the transaction version an output will be spent with in the future, so it
would be weird/bad to change the semantic in transaction version 3.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sun, Sep 5, 2021 at 7:36 PM David A. Harding <dave at dtrt.org> wrote:
> On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:
> > Hi Bitcoin Devs,
> >
> > I recently noticed a flaw in the Sequence lock implementation with
> respect
> > to upgradability. It might be the case that this is protected against by
> > some transaction level policy (didn't see any in policy.cpp, but if not,
> > I've put up a blogpost explaining the defect and patching it
> > https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/
>
> Isn't this why BIP68 requires using tx.version=2? Wouldn't we just
> deploy any new nSequence rules with tx.version>2?
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210905/036b421e/attachment.html>

2023-06-07 22:58:15

- reply

📅 Original date posted:2021-08-26
📝 Original message:This has actually never been true (Sapio assumes extensions).
If the extensions are not present, you can stub them out with a signing
federation instead, configurable as flags, and you can also write many
contracts that do not use the ctv based components at all.
The protocol for emulation is a bit clever (if I do say so myself) since it
ensures that contract compilation is completely offline and the oracles are
completely stateless.
Relevant links:
https://learn.sapio-lang.org/ch05-01-ctv-emulator.html
https://learn.sapio-lang.org/ch03-02-finish.html
Cheers,
Jeremy
On Tue, Aug 24, 2021, 6:19 AM Andrew Poelstra via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Simplicity does not compile to Bitcoin Script, and Sapio assumes extensions
> to Bitcoin Script that are not currently part of the consensus code.
>
>
> On Tue, Aug 24, 2021 at 03:36:29PM +0800, Gijs van Dam via bitcoin-dev
> wrote:
> > Hi,
> >
> >
> > Bitcoin does not have a virtual machine. But you do have [Miniscript][1],
> > [Min.sc][2], [Simplicity][3] and [Sapio][4]. These are all higher level
> > languages that compile to Bitcoin Script. Sapio is "just" Rust, so that
> > might fit your setting best.
> >
> > By the way, this question also has an answer on [Bitcoin
> Stackexchange][5]
> > which is a great resource for questions like this.
> >
> > [1]: http://bitcoin.sipa.be/miniscript/
> > [2]: https://min.sc/
> > [3]: https://github.com/ElementsProject/simplicity
> > [4]: https://learn.sapio-lang.org/
> > [5]:
> >
> https://bitcoin.stackexchange.com/questions/108261/is-there-a-tool-like-ethereum-evm-at-present-for-bitcoin-script
> >
> > On Tue, Aug 24, 2021 at 2:55 PM Null Null via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > Hi all,
> > >
> > > Is there a tool like Ethereum EVM at present? Users can write bitcoin
> > > scripts in a syntax just like python(or like other programming
> language);
> > > through this tool, they can be translated into bitcoin original
> scripts; it
> > > sounds like a new programming language has been invented.
> > >
> > > In my opinion， Bitcoin script programming is based on reverse Polish
> > > expression; this is not friendly to programmers;
> > >
> > > In fact, Bitcoin's opcode expression ability is very rich, and it may
> be
> > > unfriendly, which has affected the promotion of Bitcoin in the
> technical
> > > community.
> > >
> > > Hope for hearing some voice about this.
> > >
> > > Best wish.
> > >
> > > _______________________________________________
> > > 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
>
>
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
> _______________________________________________
> 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/20210826/90095c1d/attachment.html>

2023-06-07 22:57:55

- reply

📅 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/bitcoin-dev/attachments/20210809/b93d8107/attachment.html>

2023-06-07 22:57:53

- reply

📅 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/bitcoin-dev/attachments/20210808/b39f4a28/attachment-0001.html>

2023-06-07 22:57:50

- reply

📅 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/bitcoin-dev/attachments/20210808/c022237a/attachment.html>

2023-06-07 22:57:15

- reply

📅 Original date posted:2021-07-28
📝 Original message:High level feedback:
you should spec out the opcodes as separate pieces of functionality as it
sounds like OP_CD is really 3 or 4 opcodes in one (e.g., amounts to
outputs, output addresses, something with fees).
One major drawback of your approach is that all transactions are twice as
large as they might otherwise need to be for simple things like congestion
control trees, since you have to repeat all of the output data twice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210728/327b67b8/attachment.html>

2023-06-07 22:56:30

- reply

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

2023-06-07 22:56:19

- reply

📅 Original date posted:2021-07-06
📝 Original message:I don't think Elements engineering decisions or management timelines should
have any bearing on what Bitcoin adopts, beyond learning what
works/doesn't. Same as litecoin, dogecoin, or bitcoin cash :)
With my understanding of elements it makes sense that you wouldn't want to
break compatibility script version to script version, although that seems
inevitable that you will need to either hard fork or break compatibility if
you want to fix the CHECKSIGFROMSTACK has verify semantics bug. But perhaps
that's a smaller change than the # of stack elements popped? It makes sense
having CAT that adding a split CSFS wouldn't be a priority. However, I'd
suggest that as far as elements is concerned, if the bitcoin community
decides on something that is incompatible, elements can use up some
addition opcodes or a keytype to add CSFS_BITCOIN_COMPAT ops.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/8660390f/attachment-0001.html>

2023-06-07 22:54:47

- reply

📅 Original date posted:2021-06-26
📝 Original message:If the parties trust each other, rbf is still opt-in. Just don't do it?
On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > services providers are offering zero-conf channels, where you can start
> to spend instantly [0]. I believe that's an interesting usage
>
> I agree those are interesting and useful cases. I suppose I should clarify
> that when I asked if bitcoin should continue supporting 0-conf
> transactions, I meant: should we make design decisions based on whether it
> makes raw 0-conf transactions more or less difficult to double spend on? I
> do think 0-conf transactions can be useful in situations where there is
> some level of trust (either direct trust between the interacting parties,
> or disperse trust that most people won't try to double spend, perhaps
> because the transaction is small or their identity is tied to it). Fidelity
> bonds sound like an interesting way to mitigate sybil attacks in a
> reputation system.
>
> On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> > Do we as a community want to support 0-conf payments in any way at this
>> > point? It seems rather silly to make software design decisions to
>> > accommodate 0-conf payments when there are better mechanisms for fast
>> > payments (ie lightning).
>>
>> Well, we have zero-conf LN channels ? Actually, Lightning channel funding
>> transactions should be buried under a few blocks, though few services
>> providers are offering zero-conf channels, where you can start to spend
>> instantly [0]. I believe that's an interesting usage, though IMHO as
>> mentioned we can explore different security models to make 0-conf safe
>> (reputation/fidelity-bond).
>>
>> > One question I have is: how does software generally inform the user
>> about
>> 0-conf payment detection?
>>
>> Yes generally it's something like an "Unconfirmed" annotation on incoming
>> txn, though at least this is what Blockstream Green or Electrum are doing.
>>
>> > But I
>> suppose it would depend on how often 0-conf is used in the bitcoin
>> ecosystem at this point, which I don't have any data on.
>>
>> There are few Bitcoin services well-known to rely on 0-conf. Beyond how
>> much of the Bitcoin traffic is tied to a 0-conf is a hard question, a lot
>> of 0-confs service providers are going to be reluctant to share the
>> information, for a really good reason you will learn a subset of their
>> business volumes.
>>
>> I'll see if I can come up with some Fermi estimation on this front.
>>
>> [0] https://www.bitrefill.com/thor-turbo-channels/
>>
>> Le mer. 16 juin 2021 à 20:58, Billy Tetrud <billy.tetrud at gmail.com> a
>> écrit :
>>
>>> Russel O'Connor recently opined
>>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019061.html>
>>> that RBF should be standard treatment of all transactions, rather than as a
>>> transaction opt-in/out. I agree with that. Any configuration in a
>>> transaction that has not been committed into a block yet simply can't be
>>> relied upon. Miners also have a clear incentive to ignore RBF rules and
>>> mine anything that passes consensus. At best opting out of RBF is a weak
>>> defense, and at worst it's simply a false sense of security that is likely
>>> to actively lead to theft events.
>>>
>>> Do we as a community want to support 0-conf payments in any way at this
>>> point? It seems rather silly to make software design decisions to
>>> accommodate 0-conf payments when there are better mechanisms for fast
>>> payments (ie lightning).
>>>
>>> One question I have is: how does software generally inform the user
>>> about 0-conf payment detection? Does software generally tell the user
>>> something along the lines of "This payment has not been finalized yet. All
>>> recipients should wait until the transaction has at least 1 confirmation,
>>> and most recipients should wait for 6 confirmations" ? I think unless we
>>> pressure software to be very explicit about what counts as finality, users
>>> will simply continue to do what they've always done. Rolling out this
>>> policy change over the course of a year or two seems fine, no need to rush.
>>> But I suppose it would depend on how often 0-conf is used in the bitcoin
>>> ecosystem at this point, which I don't have any data on.
>>>
>>> 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
>>>>
>>> _______________________________________________
> 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/20210626/80352cab/attachment-0001.html>

2023-06-07 22:54:30

- reply

📅 Original date posted:2021-06-13
📝 Original message:The API of a sponsor-like mechanism is close to ideal in my opinion:
- compatible with non malleable transactions
- 0 overhead if fees accurately estimated
- watchtower friendly
- post hoc, requires minimal 'protocol awareness'
- friendly with most mempool eviction policies, not much new required
- can work to atomically bump multiple txns
- can be bumped cooperatively by multiple sponsors w/o coordination
- 0 'rebroadcast overhead' (e.g., for a large batch) leasing to cascading
retransmission fees for replacement
- can be piggy backed with other future transactions or protocols (e.g.
coinjoin)
- compatible with change being in cold storage
The main drawback is it is chain space - wise less efficient, as an
additional transaction gets made. However, I think the API benefits
'product market fit' over alternative solutions outweigh other concerns,
and if the 'sponsorship efficiency hypothesis' holds true, then most
transactions will not require sponsors and therefore the savings of not
needing to preplan a few bumping mechanism will be more efficient overall
(efficient market will drive accuracy in estimating fees rather than
needing to sponsor).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210613/fe1f02f3/attachment.html>

2023-06-07 22:52:38

- reply

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

2023-06-07 22:52:03

- reply

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

2023-06-07 22:52:01

- reply

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

2023-06-07 22:51:55

- reply

📅 Original date posted:2021-04-20
📝 Original message:Hi All,
Introducing the notion that we might want to have an address type defined
for OP_RETURN.
I came across this when writing some code that wanted to handle common
classes of user transactions generically, it's kind of annoying that you
have to write code that's effectively:
```
try {
print(script.address());
} catch {
try {
print(script.op_return());
} catch {
print("unknown thing");
}
}
```
I think that OP_RETURN, being relatively well defined, could have an
address type.
This would aid in simplifying types for programs. E.g., in Rust I want to
have:
```
struct Coin(Address, Amount)
impl Coin {
fn get_coin(o: Outpoint) -> Result<Coin, Error>{/**/}
}
enum Error {
UnknownType,
CoinDoesNotExist,
}
```
and without Address defining OP_RETURN I can't read a Coin containing an
OP_RETURN. It would be possible to define Coin to store script, but then
everywhere I want an address I would have to perform a conversion and
Script is technically "too wide" a type as what I really want is to only
return coins with known output types.
More concretely this is a challenge for me as I'm building the Sapio
compiler and I want to make it so that all contract compilations result in
an Address, but I need to support OP_RETURN for various reasons, so I
cannot make Sapio only output addresses.
As far as I understand the counterargument against this, it is (thanks to
Luke Jr):
1) We should only have addresses or descriptors for things we know exactly
what they are, and also for things that represent something that is not
only payable but also potentially spendable.
2) OP_RETURN, being unspendable and usually proprietary in purpose, should
not have an address.
3) Further, most uses of OP_RETURN are proprietary (e.g., we don't know
what it represents) so therefore it would be lying to the user to pretend
we know how to interpret it.
My counterargument is that:
1) Addresses should represent things that people commonly create outputs
for -- perhaps regrettably, OP_RETURN is such a thing so software (e.g.,
https://citp.github.io/BlockSci/reference/addresses/address.html) already
does treat OP_RETURN as an address type, just without a standard
representation.
2) Many things are unspendable. E.g., a 0 value payment to an address, a
payment to P2SH(OP_RETURN <data>), etc. We can't know spendability based on
address type.
3) All scripts can have proprietary interpretations, the job of the address
is to do our best job of interpreting standard types to the best of our
ability. An example where this has been (ab)used previously is P2SH wrapped
SegWit, where one cannot distinguish if the underlying is to be evaluated
as P2SH or SegWit. Further, future OP_RETURN address types could take
precedence if they are well specified.
Do folks agree with the motivations for defining an address type? Are there
any design constraints?
Some starter thoughts
1) Should it be human readable & checksummed or encoded?
2) Should it have a fixed length of max 40-80 bytes or should we support
arbitrary length strings?
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)
(my answers are 1. human readable + checksum, 2. arbitrary to support
nonstandard ones which miners create 3. non payable in standard software)
Cheers,
Jeremy
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/20210420/1e9b21d5/attachment.html>

2023-06-07 22:51:55

- reply

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

2023-06-07 22:51:46

- reply

📅 Original date posted:2021-04-16
📝 Original message:For every workaround, someone may have a long lost stash that you'd be
confiscating :)
https://bitcoin.stackexchange.com/questions/90127/why-does-this-coinbase-transaction-have-two-op-return-outputs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/cb1a5535/attachment.html>

2023-06-07 22:51:45

- reply

📅 Original date posted:2021-04-16
📝 Original message:NACK -- I happen to have a vault where I made emergency backup pre-signed
transactions containing two OP_RETURN outputs and have subsequently lost
the private key in an unfortunate boating incident.
This proposed rule change would serve to confiscate my funds.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Fri, Apr 16, 2021 at 6:32 AM Christopher Gilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have created a BIP which can be found here:
> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>
> I'm sending this email to start the discussion regarding this proposal. If
> there are any comments/suggestions, please let me know.
>
> Regards,
> Chris
> _______________________________________________
> 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/c25d7fb1/attachment.html>

2023-06-07 22:51:40

- reply

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

2023-06-07 22:51:37

- reply

📅 Original date posted:2021-04-09
📝 Original message:You could accomplish your rough goal by having:
tx A: desired expiry at H
tx B: nlocktime H, use same inputs as A, create outputs equivalent to
inputs (have to be sure no relative timelocks)
Thus after a timeout the participants in A can cancel the action using TX B.
The difference is the coins have to move, without knowing your use case
this may or may not help you.
On Fri, Apr 9, 2021, 4:40 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119:
>
> We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg
>> after a segmentation, transactions need to be able to get into the chain in
>> a later block. The OP_BLOCKNUMBER transaction and all its dependants would
>> become invalid. This wouldn't be fair to later owners of the coins who
>> weren't involved in the time limited transaction.
>>
>> nTimeLock does the reverse. It's an open transaction that can be
>> replaced with new versions until the deadline. It can't be recorded until
>> it locks. The highest version when the deadline hits gets recorded. It
>> could be used, for example, to write an escrow transaction that will
>> automatically permanently lock and go through unless it is revoked before
>> the deadline. The feature isn't enabled or used yet, but the support is
>> there so it could be implemented later.
>>
>
> Unfortunately, limiting the maximum block height for a specific
> transaction would have exactly the same problem as cited above for
> OP_BLOCKNUMBER.
>
> On Fri, Apr 9, 2021 at 7:21 AM Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> is there any way to specify a maximum block height on a transaction?
>>
>> ie: this tx is only valid if included in a block with a certain height or
>> less
>>
>> i feel like this would be useful
>> _______________________________________________
>> 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/20210409/a49670f6/attachment.html>

2023-06-07 22:51:10

- reply

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

2023-06-07 22:51:08

- reply

📅 Original date posted:2021-04-04
📝 Original message:We'll be having another meeting this Tuesday, as per
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html.
If you can't make it feel free to leave a comment on any agenda item below,
or if you think there are other things to be discussed.
Agenda:
1. AJ's update to MTP time.
Please review https://github.com/bitcoin/bitcoin/pull/21377 as AJ updated
it substantially.
The PR is now purely MTP based, and the state machine has been simplified.
This approach is intended to be compatible with a mandatory signaling
period (via a LAST_CHANCE change) and makes it easier to deploy ST on
signets (irrelevant for Taproot, because it is already active on all
signets).
2. Selecting between MTP and Height
In the previous meeting, there was no substantial publicly discussed
benefit to using MTPs over height. Since agenda item 1, there is now a
tangible benefit to using MTP.
The changes AJ promulgated for MTP neutralizes the argument, mostly, that
MTP was easier to review. 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.
3. Timeline Discussion
In all hope, we will reach consensus around item 2. Should that occur, we
can use this time to discuss a final selection on parameters, mindful of
Core's process.
If the meeting doesn't reach rough consensus around item 2, it seems that
we may fall short on the proposed schedule from last time. In this section,
we can discuss realities around scheduling.
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/20210403/89834233/attachment.html>

2023-06-07 18:31:07

- reply

2023-06-07 18:30:51

- reply

📅 Original date posted:2021-03-15
📝 Original message:I think Luke is pointing out that with the Signature and the Message you
should be able to recover the key.
if your address is H(P) and the message is H(H(P) || txn), then the you can
use the public H(P) and the signature to recover the PK and verify that
H(P) == P (I think you then don't even have to check the signature after
doing that).
Therefore there is no storage benefit.
For the script path case, you might have to pay a little bit extra though
as you'd have to reveal P I think? But perhaps that can be avoided another
way...
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There have been many threads on this before, I'm not sure anything new has
> been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> > I do not personally see this as a reason to NACK Taproot, but it has
> become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware
> of
> > it and can make their own judgements.
>
> Note that this is most definitely *not* news to this list, eg, Anthony
> brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy
> preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse
> corpse.
>
> >
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause"
> while a
> > full quantum-safe fix is developed, and then resume transacting. With
> Taproot
> > as-is, it could very well become an unrecoverable situation if QC go
> online
> > prior to having a full quantum-safe solution.
>
> This has been discussed ad nauseam, and it all seems to fall apart once
> its noted just how much Bitcoin could be stolen
> by any QC-wielding attacker due to address reuse. Ultimately, no "pause"
> can solve this issue, and, if we learned about
> a QC attacker overnight (instead of slowly over time), there isn't
> anything that a non-Taproot Bitcoin could do that a
> Taproot Bitcoin couldn't.
>
> > Also, what I didn't know myself until today, is that we do not actually
> gain
> > anything from this: the features proposed to make use of the raw keys
> being
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for
> anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at
> worst, it
> > would create an incentive for more people to use their own full node,
> which
> > is a good thing!
>
> This is untrue. The storage space required for Taproot transactions is
> materially reduced by avoiding the hash indirection.
>
> > Despite this, I still don't think it's a reason to NACK Taproot: it
> should be
> > fairly trivial to add a hash on top in an additional softfork and fix
> this.
>
> For the reason stated above, i think such a fork is unlikely.
>
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> >
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> efforts
> > discouraging address use. If the standard loses the hash, the situation
> > cannot be improved, and will indeed only get worse.
>
> I truly wish this were the case, but we've been beating that drum for at
> least nine years and still haven't solved it.
> Worse, there's a lot of old coins that are unlikely to move any time soon
> that are exposed whether we like it or not.
>
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it
> can be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> supply
> > minable by QCs is really no different than 37% minable by ASICs. (We've
> seen
> > far higher %s available for mining obviously.)
>
> Except its not? One entity would be able to steal that entire block of
> supply rather quickly (presumably over the course
> of a few days, at maximum), instead of a slow process with significant
> upfront real-world cost in the form of electricity.
> _______________________________________________
> 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/20210315/7b7aea3f/attachment-0001.html>

2023-06-07 18:29:19

- reply

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

2023-06-07 18:28:59

- reply

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

2023-06-07 18:28:01

- reply

📅 Original date posted:2021-01-02
📝 Original message:One thing I think should be added in V2 is the ability to specify sighash
flags per-key as opposed to per-input.
The per-key restriction is unfitting given that there are circumstances
where multisig signers may validate heterogenous logic.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Wed, Dec 23, 2020 at 1:37 PM Andrew Chow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> On 12/22/20 10:30 PM, fiatjaf wrote:
> > Hi Andrew.
> >
> > I'm just a lurker here and I have not much experience with PSBTs, but
> still let me pose this very obvious question and concern: isn't this change
> going to create a compatibility nightmare, with some software supporting
> version 1, others supporting version 2, and the ones that care enough about
> UX and are still maintained being forced to support both versions -- and
> for no very important reason except some improvements in the way data is
> structured?
> No, it is not just "improvements in the way data is structured."
>
> The primary reason for these changes is to allow PSBT to properly
> support adding inputs and outputs. This is a feature that many people
> have requested, and the ways that people have been doing it are honestly
> just hacks and not really the right way to be doing that. These changes
> allow for that feature to be supported well.
>
> Furthermore, it is possible to downgrade and upgrade PSBTs between the
> two versions, once all inputs and outputs have been decided. Since
> PSBTv2 is essentially just taking all of the normal transaction fields
> and grouping them all with the rest of the data for those inputs and
> outputs, it is easy to reconstruct a global unsigned transaction and
> turn a PSBTv2 into a PSBTv0. It is likewise just as easy to go the other
> way and break apart the global unsigned tx to turn a PSBTv0 into a
> PSBTv2. Originally, I had considered requiring that once a transaction
> was fully constructed it must be downgraded to a PSBTv0, but the
> structure changes that were made do make it easier to work with PSBT so
> I decided not to add this requirement.
>
> Perhaps to maintain compatibility PSBT_GLOBAL_UNSIGNED_TX shouldn't be
> disallowed in PSBTv2 once the transaction is constructed? It would make
> things much more confusing though as it would no longer be a clean break.
>
>
> Andrew Chow
>
> > Ultimately I don't think it should matter if some data is structured in
> not-the-best-possible way, as long as it is clear enough for the computer
> and for the libraries already written to deal with it.
> Backwards-compatibility and general interoperability is worth much more
> than anything else in these cases.
> >
> > Also let me leave this article here, which I find very important (even
> if for some reason it ends up not being relevant to this specific case):
> http://scripting.com/2017/05/09/rulesForStandardsmakers.html
> >
> > ---- On Tue, 22 Dec 2020 17:12:22 -0300 Andrew Chow via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote ----
> > > Hi All,
> > >
> > > I have some updates on this after speaking with some people off-list.
> > >
> > > Firstly, the version number will be set to 2. In most discussions,
> this
> > > proposal was being referred to as PSBT version 2, so it'll be easier
> and
> > > clearer to set the version number to 2.
> > >
> > > For lock times, instead of a single PSBT_IN_REQUIRED_LOCKTIME field,
> > > there will be 2 of them, one for a time based lock time, and the
> other
> > > for height based. These will be:
> > > * PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x10
> > > * Key: empty
> > > * Value: 32 bit unsigned little endian integer greater than or
> equal
> > > to 500000000 representing the minimum Unix timestamp that this input
> > > requires to be set as the transaction's lock time. Must be omitted in
> > > PSBTv0, and may be omitted in PSBTv2
> > > * PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x11
> > > * Key: empty
> > > * Value: 32 bit unsigned little endian integer less than 500000000
> > > representing the minimum block height that this input requires to be
> set
> > > as the transaction's lock time. Must be omitted in PSBTv0, and may be
> > > omitted in PSBTv2.
> > >
> > > Having two lock time fields is necessary due to the behavior where
> all
> > > inputs must use the same type of lock time (height or time). Thus if
> an
> > > input requires a particular type of lock time, it must set the
> requisite
> > > field. Any new inputs being added must be able to accommodate all
> > > existing inputs' lock time type. This means they either must not
> have a
> > > lock time specified (i.e. no OP_CLTV involved), or have branches that
> > > allow the acceptance of either type. If an input has a lock time type
> > > that is incompatible with the rest of the transaction, it must not
> be added.
> > >
> > > PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely be the fallback
> > > option if no input lock time fields are present. If there are input
> lock
> > > times, all lock time calculations must ignore it.
> > >
> > > Any role which does lock time calculation will first check if there
> are
> > > input lock time fields. If there are not, it must then check for a
> > > PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists, its value is
> the
> > > transaction's lock time. If it does not, the lock time is 0. If there
> > > are input lock time fields, it must choose the type which does not
> > > invalidate any inputs. The lock time is then determined to be the
> > > maximum value of all of the lock time fields for the chosen type.
> > >
> > >
> > > Additionally, I would like to add a new global field:
> > > * PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05
> > > * Key: empty
> > > * Value: A single byte as a boolean. 0 for False, 1 for True. All
> > > other values ore prohibited. Must be omitted for PSBTv0, may be
> omitted
> > > in PSBTv2.
> > >
> > > PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and
> > > outputs can be added to the PSBT. This flag may be set to True when
> > > inputs and outputs are being updated, signed, and finalized. However
> > > care must be taken when there are existing signatures. If this field
> is
> > > omitted or set to False, no further inputs and outputs may be added
> to
> > > the PSBT.
> > >
> > > Several rules must be followed to ensure that adding additional
> inputs
> > > and outputs will not invalidate existing signatures. First, an input
> or
> > > output adder must check for any existing signatures in all of the
> other
> > > inputs. If there are none, the input or output may be added in any
> > > position. If there are one or more signatures, each signature's
> sighash
> > > type must be examined. Inputs may only be added if all existing
> > > signatures use SIGHASH_ANYONECANPAY. Outputs may only be added if all
> > > existing signatures use SIGHASH_NONE. If an input has a signature
> using
> > > SIGHASH_SINGLE, the same number of inputs and outputs must be added
> > > before that input and it's corresponding output. For all other
> sighash
> > > types (i.e. SIGHASH_ALL and any future sighash types), no inputs or
> > > outputs may be added to the PSBT. Specific exceptions can be made in
> the
> > > future for additional sighash types.
> > >
> > > Furthermore, these newly added inputs must follow additional lock
> time
> > > rules. Because all signatures, regardless of sighash type, sign the
> > > transaction lock time, newly added inputs when there are existing
> > > signatures must have the same type of lock time used in the
> transaction,
> > > and must be less than or equal to the transaction lock time. It must
> not
> > > cause the transaction lock time to change, otherwise the signatures
> will
> > > be invalidated.
> > >
> > >
> > > Lastly, to uniquely identify transactions for combiners, a txid can
> be
> > > computed from the information present in the PSBT. Internally,
> combiners
> > > can create an unsigned transaction given the transaction version, the
> > > input prevouts, the outputs, and the computed locktime. This can
> then be
> > > used to calculate a txid and thus used as a way to identify PSBTs.
> > > Combiners will need to do this for all version 2 PSBTs in order to
> avoid
> > > combining distinct transactions.
> > >
> > >
> > > Andrew Chow
> > >
> > > On 12/9/20 5:25 PM, Andrew Chow wrote:
> > > > Hi All,
> > > >
> > > > I would like to propose a new PSBT version that addresses a few
> > > > deficiencies in the current PSBT v0. As this will be backwards
> > > > incompatible, a new PSBT version will be used, v1.
> > > >
> > > > The primary change is to truly have all input and output data for
> each
> > > > in their respective maps. Instead of having to parse an unsigned
> > > > transaction and lookup some data from there, and other data from
> the
> > > > correct map, all of the data for an input will be contained in its
> map.
> > > > Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX in this new
> version.
> > > > Thus I propose that the following fields be added:
> > > >
> > > > Global:
> > > > * PSBT_GLOBAL_TX_VERSION = 0x02
> > > > * Key: empty
> > > > * Value: 32-bit little endian unsigned integer for the
> transaction
> > > > version number. Must be provided in PSBT v1 and omitted in v0.
> > > > * PSBT_GLOBAL_PREFERRED_LOCKTIME = 0x03
> > > > * Key: empty
> > > > * Value: 32 bit little endian unsigned integer for the
> preferred
> > > > transaction lock time. Must be omitted in PSBT v0. May be provided
> in
> > > > PSBT v1, assumed to be 0 if not provided.
> > > > * PSBT_GLOBAL_INPUT_COUNT = 0x04
> > > > * Key: empty
> > > > * Value: Compact size unsigned integer. Number of inputs in
> this
> > > > PSBT. Must be provided in PSBT v1 and omitted in v0.
> > > > * PSBT_GLOBAL_OUTPUT_COUNT = 0x05
> > > > * Key: empty
> > > > * Value: Compact size unsigned integer. Number of outputs in
> this
> > > > PSBT. Must be provided in PSBT v1 and omitted in v0.
> > > >
> > > > Input:
> > > > * PSBT_IN_PREVIOUS_TXID = 0x0e
> > > > * Key: empty
> > > > * Value: 32 byte txid of the previous transaction whose output
> at
> > > > PSBT_IN_OUTPUT_INDEX is being spent. Must be provided in PSBT v1
> and
> > > > omitted in v0.
> > > > * PSBT_IN_OUTPUT_INDEX = 0x0f
> > > > * Key: empty
> > > > * Value: 32 bit little endian integer for the index of the
> output
> > > > being spent. Must be provided in PSBT v1 and omitted in v0.
> > > > * PSBT_IN_SEQUENCE = 0x0f
> > > > * Key: empty
> > > > * Value: 32 bit unsigned little endian integer for the sequence
> > > > number. Must be omitted in PSBT v0. May be provided in PSBT v1
> assumed
> > > > to be max sequence (0xffffffff) if not provided.
> > > > * PSBT_IN_REQUIRED_LOCKTIME = 0x10
> > > > * Key: empty
> > > > * Value: 32 bit unsigned little endian integer for the lock
> time that
> > > > this input requires. Must be omitted in PSBT v0. May be provided
> in PSBT
> > > > v1, assumed to be 0 if not provided.
> > > >
> > > > Output:
> > > > * PSBT_OUT_VALUE = 0x03
> > > > * Key: empty
> > > > * Value: 64-bit unsigned little endian integer for the output's
> > > > amount in satoshis. Must be provided in PSBT v1 and omitted in v0.
> > > > * PSBT_OUT_OUTPUT_SCRIPT = 0x04
> > > > * Key: empty
> > > > * Value: The script for this output. Otherwise known as the
> > > > scriptPubKey. Must be provided in PSBT v1 and omitted in v0.
> > > >
> > > > This change allows for PSBT to be used in the construction of
> > > > transactions. With these new fields, inputs and outputs can be
> added as
> > > > needed. One caveat is that there is no longer a unique transaction
> > > > identifier so more care must be taken when combining PSBTs.
> > > > Additionally, adding new inputs and outputs must be done such that
> > > > signatures are not invalidated. This may be harder to specify.
> > > >
> > > > An important thing to note in this proposal are the fields
> > > > PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUIRED_LOCKTIME. A
> Bitcoin
> > > > transaction only has a single locktime yet a PSBT may have multiple
> > > > locktimes. To choose the locktime for the transaction, finalizers
> must
> > > > choose the maximum of all of the *_LOCKTIME fields.
> > > > PSBT_IN_REQUIRED_LOCKTIME is added because some inputs, such as
> those
> > > > involving OP_CHECKLOCKTIMEVERIFY, require a specific minimum
> locktime to
> > > > be set. This field allows finalizers to choose a locktime that is
> high
> > > > enough for all inputs without needing to understand the scripts
> > > > involved. The PSBT_GLOBAL_PREFERRED_LOCKTIME is the locktime to
> use if
> > > > no inputs require a particular locktime.
> > > >
> > > > As these changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT
> v1
> > > > needs the version number bump to enforce backwards incompatibility.
> > > > However once the inputs and outputs of a PSBT are decided, a PSBT
> could
> > > > be "downgraded" back to v0 by creating the unsigned transaction
> from the
> > > > above fields, and then dropping these new fields.
> > > >
> > > > If the list finds that these changes are reasonable, I will write
> a PR
> > > > to modify BIP 174 to incorporate them.
> > > >
> > > > Thanks,
> > > > Andrew Chow
> > >
> > >
> > > _______________________________________________
> > > 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/20210101/98abd4fd/attachment-0001.html>

2023-06-07 18:27:05

- reply

📅 Original date posted:2020-09-25
📝 Original message:If I understand correctly, this is purely a policy level decision to accept
first-seen or a secondary deterministic test, but the most-work chain is
still always better than a "more fit" but less work chain.
In any case, I'm skeptical of the properties of this change. First-seen has
a nice property that once you receive a block, you have a substantially
reduced incentive to try to orphan it because the rest of the network is
going to work on building on that block. With fitness, I have a 50% shot if
I mine a block of mine being accepted, so floating point would have the
effect of destabilizing consensus convergence at the tip.
I could see using a fitness rule like this be useful if you see both blocks
within some very small window, e.g., 10 seconds, as it could decrease
partition risk if it's likely the orphan was mined within close range of
the other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200925/ca799f49/attachment.html>

2023-06-07 18:26:59

- reply

📅 Original date posted:2020-09-23
📝 Original message:Hi Suhas,
Thanks for your thoughtful response!
Overall I'll boil down my thoughts to the following:
If we can eventually come up with something clever at the user+policy layer
to emulate a sponsor like mechanism, I would still greatly prefer to expose
that sort of functionality directly and in a fully-abstracted usable way
for the minimum amount of mempool attack risk in 2nd layer protocols, even
at the expense of some base layer complexity. It's better to pay a security
sensitive engineering cost once, than to have to pay it repeatedly and
perhaps insufficiently.
Specific responses inline below:
Best,
Jeremy
>> The Sponsor Vector TXIDs must also be in the block the transaction is
validated in, with no restriction on order or on specifying a TXID more
than once.
> That means that if a transaction is confirmed in a block without its
sponsor, the sponsor is no longer valid. This breaks a design principle
that has been discussed many times over the years, which is that once a
valid transaction is created, it should not become invalid later on unless
the inputs are double-spent. This principle has some logical consequences
that we've come to accept, such as transaction chains being valid across
small reorgs in the absence of malicious (double-spend) behavior.
*Certainly, this property is strictly broken by this proposal. It does not
break the weaker property that the transactions can be reorged onto another
chain, however (like OP_GETBLOCKHASH or similar would), which is important
to note. It's also important to note this property is not preserved against
reorgs longer than 100 blocks.*
> I think that this principle is a useful one and that there should be a
high bar for doing away with it. And it seems to me that this proposal
doesn't clear that bar -- the fee bumping improvement that this proposal
aims at is really coming from the policy change, rather than the consensus
change.
*I think this is possibly correct.*
*IMO the ability to implement the policy changes is purely derived from the
consensus changes. The consensus changes add a way of third parties to a
transaction to specify economic interest in the resolution of a
transaction. This requires a consensus change to work generically and
without forethought.*
*It's possible that with specific planning or opt-in, you can make
something roughly equivalent. But such a design might also consume more
bandwidth on-chain as you would likely have to e.g. always include a CPFP
hook output.*
> But if policy changes are the direction we're going to solve these
problems, we could instead just propose new policy rules for the existing
types of transaction chaining that we have, rather than couple them to a
new transaction type.
>
> My understanding of the main benefit of this approach is that this allows
3rd parties to participate in fee bumping. But that behavior strikes me as
also problematic, because it introduces the possibility of 3rd party
griefing, to the extent that sponsor transactions in any way limit chains
of transactions that would be otherwise permitted. If Alice sends Bob some
coins, and Alice and Bob are both honest and cooperating, Mallory shouldn't
be able to interfere with their low-feerate transaction by (eg) pinning it
with a large transaction that "sponsors" it (ie a large transaction that is
just above the feerate of the parent, which prevents additional child
transactions and makes it more expensive to RBF).
*It's possible to modify my implementation of the policy such that there is
no ability to interfere with the otherwise permitted limits, it just
requires a little bit more work to always discount sponsors on the
descendant counting.*
*W.r.t. griefing, the proposed amendment to limit sponsors to 1000 bytes
minimizes this concern. Further, pinning in this context is mainly an issue
if Alice and Bob are intending to RBF a transaction, at a policy level we
could make Sponsoring require that the transaction be RBF opted-out (or
sponsor opted in). *
> This last issue of pinning could be improved in this proposal by
requiring that a sponsor transaction bring the effective feerate of its
package up to something which should be confirmed soon (rather than just
being a higher feerate than the tx it is sponsoring). However, we could
also carve out a policy rule just like that today, without any consensus
changes needed, to help with pinning (which is probably a good idea! I
think this would be useful work). So I don't think that approaches in that
direction would be unique to this proposal.
*I agree this is useful work and something that Ranked indexes would help
with if I understand them correctly, and can be worked on independently of
Sponsors. Overall I am skeptical that we want to accept any child if it
puts something into an upper percentile as we still need to mind our DoS
budgets (which the sponsors implementation keeps a tight bound on). *
>> We allow one Sponsor to replace another subject to normal replacement
policies, they are treated as conflicts.
> This policy rule of allowing sponsor transactions to RBF each other also
seems problematic; that means that if Alice is paying Bob in a transaction
that is also sponsoring some other transaction (perhaps from Alice to
someone else), then Mallory can cause the transaction going to Bob to
become invalid by RBF bumping it and sponsoring the parent transaction
herself? Allowing 3rd parties to interfere with transactions between
others seems like a complex and undesirable design to introduce.
*If you'll note in the BIP draft text and implementation recursive
sponsoring is not permitted by policy for this reason. Sponsors may not
sponsor a transaction that is sponsoring another transaction, and a further
restriction that sponsors may not have any children.*
> In summary: this proposal seems like a CPFP replacement, requiring many
policy rules along with a consensus change to be worked out to get right; I
think we could achieve largely the same effect by improving the current
policy rules to make CPFP work better without a consensus change. And
while what is unique about this proposal is that it allows for 3rd parties
to attach themselves to the transaction graph of other parties, I think
that is a complex interaction to introduce and has negative side effects as
well.
*This is where I most significantly disagree. Some thoughts below on why a
consensus change is likely required for this and why the sponsors mechanism
may not be that invasive (if done right) on the way we currently understand
the transaction graph.*
*1)*
*The main issue with CPFP like mechanisms is that they require an
omniscient like behavior around how to coordinate.*
*Given the complexity of CPFP, it's not possible to ever abstract its use
from the contract protocol you are implementing. It always requires deep
integration into any protocol as a mechanism, and many bespoke protocols
for game theoretically ensuring you can pay fees is much more brittle than
one higher-order composable mechanism (which is what sponsors aims to
achieve, but may fall short on in current incarnation).*
*Further, CPFP based protocols can be wasteful, requiring at least one CPFP
hook/anchor output per participant always. These CPFP hooks need a mempool
CPFP exemption (so that you don't get pinned by a sibling), which will have
to apply recursively in case your payment protocol is not at the base of a
transaction chain (as can happen within a multiparty channel factory). Thus
CPFP as a mechanism inherently suffers from chain bloat issues and it
composes poorly when used recursively.*
*I think it will be essentially impossible to generically handle CPFP based
on transaction graph anchors both from a protocol implementers side and
from a mempool policy side. And in the event that a new attack is
discovered, a mechanism that works with fewer assumptions about the setup
of your protocol should be more robust, or at least fixable. Whereas with a
pure CPFP transaction graph based design, once you are pinned, it may be
impossible to externally correct the incentives. *
*2)*
*Third parties can already -- trustfully -- insert themselves into
another's transaction chain by bribing mining pools to escalate priority of
a transaction. These out-of-band fees are somewhat inevitable, so if your
protocol is not robust against 3rd party feerate boosting you may have
larger issues.*
*3)*
*Because we already do not handle 100 block reorgs with the replayability
property, one fine change to the BIP would be to enforce a 100 block
maturing period on sponsor transactions outputs after confirmation. This
might make usage a little bit more unwieldy, but then it would not have the
issue on small reorg validity.* *I believe this could be safely done* *only
via policy and not consensus, as if someone wants to double spend a
transaction in a reorg they can, but it's fine either way.*
*4)*
*It's not particularly important that a transaction be in the same block
once sponsored, it could also be in the last 100 blocks (the opposite of
proposed change 3). The main benefit to having same-block resolution is
that you never pay for something that would have gone in anyways, but this
mechanism could actually be generically useful if you are operating a
business and need to make reorg safe payments contingent on funds received
into cold-storage. This implies a new rolling index of txids, which has
some overhead, but combined with appropriate mempool policy (e.g., a 200
block txid index in consensus and only a 100 block index available by
mempool policy) would ensure that most reorgs could be handled cleanly.*
*5)*
*The behavior of sponsors is already emulable in a transaction graph. A
more complicated construction is possible that's a more accurate emulation,
but a simple version is as follows:*
*if you were to require:*
*A) All non-sponsor transactions include a single CPFP anchor output/CPFP
hook with an OP_TRUE as the last output*
*B) Miners sweep all OP_TRUE outputs at the end of the block to an
OP_RETURN.*
*Then it would be possible for third parties to be a sponsor by spending
that OP_TRUE output.*
*With a couple modifications (happy to discuss off-list, they end up being
aggregately more complicated than the sponsors mechanism) this can also
permit multiple sponsors in the same block.*
*Because it's possible to convert sponsors mechanism into this transaction
graph (and back again), I don't see a sponsors mechanism as breaking any
strong inherent property of the transaction graph, it's merely an
optimization of a pattern that could be implemented without breaking the
property.*
*Therefore I am unconcerned with the impact that a sponsors-like mechanism
has on the properties of the transaction graph itself.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200923/0546c978/attachment-0001.html>

2023-06-07 18:26:57

- reply

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

2023-06-07 18:26:55

- reply

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

2023-06-07 18:26:54

- reply

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

2023-06-07 18:25:17

- reply

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

2023-06-07 18:23:53

- reply

📅 Original date posted:2020-04-22
📝 Original message:Hi everyone,
Sorry to just be getting to a response here. Hadn't noticed it till now.
*(Plug: If anyone or their organizations would like to assist in funding
the work described below for a group of developers, I've been working to
put resources together for funding the above for a few months now, and I
think it would be high leverage towards seeing this through. There are a
lot of unsexy tasks to do that aren't coming up with a solution
(e.g.,writing a myriad of Mempool stress test scenarios) that can be a well
defined full-time job for someone to do.)*
I've been working on exactly this problem in the mempool for months now.
I'm deeply familiar with the issues here and the types of pinning possible.
I think everyone can recognize that with my work on OP_CTV I want nothing
more than the mempool to be able to accept whatever long chains we can
throw at it, but I'm pretty well steeped at this point in the obstacles to
doing that.
I don't think that we should be entertaining further carve outs at the
moment, unless it is really trivial. Every new carve out rule added to the
way that the mempool operates is removing complexity invariants we aim to
preserve in the mempool in order to keep nodes operational. Many of these
invariants are well documented, some are not. I'm happy to go off list for
a more thorough discussion with anyone qualified to have it; this isn't the
best venue for that discussion.
>From my point of view the path forward here is to dedicate more development
resources towards finishing the mempool project I began. You can see the
outstanding work here: https://github.com/bitcoin/bitcoin/projects/14,
contributing review towards moving those PRs forward will greatly improve
our ability to consider a stopgap carve out measure.
The current focus of this work is primarily on:
1) Testing Construction to better test & catch regressions or
vulnerabilities introduced or extant in mempool
2) Refactoring algorithms in mempool to reduce constant factors &
asymptotics
3) Package Relay
None of these fix the exact problem at hand though, but here's part of how
they can help us:
If we finish up the algorithmic refactors I've been working on it seems
plausible to do a one-off increase of descendants limits to say, 100
descendants with no restriction. However, we could use the opportunity to
use the 75 descendant increase exclusively for a new carve out, and apply
some new stricter rules in that extra space. There are a few anti-pinning
countermeasures that you can apply in that space that you would not
generally want in the mempool. An example of one is that any new
transaction must pay more feerate and absolute fee than every child in that
space. Or that only the highest fee paying branch of the excess
transactions are mineable, no others. Another would be disabling RBF past
that watermark. In all likelihood, different subsystems interacting with
the mempool will require a different set of restrictions each with the
current architecture, I don't think there's a magic bullet.
Package relay is a promising approach for a future pinning solution as
there are opportunities to attach to packages compact proofs of improved
fee efficiency for pinned transactions. But the ground work for package
relay needs to come first. This is theoretically possible with our current
architecture of the mempool and can probably address much of the pinning
concerns by replacing pinning with more rational eviction policies.
Longer term I've been working on plans and designs to completely re-do the
mempool's architecture to make it behave for arbitrary cases. It's possible
to one day lift all preemptively enforced (e.g., before acceptance)
descendants limits, which can solve this problem for good. There is more
than one potentially good solution here, and a conjunction of them can be
used as they affect independent sub systems. But this work will probably
take years to complete to the point where restrictions can realistically be
lifted.
If developers would like to coordinate resources around completing this
work and making more regular progress on it I'm happy to help point people
to specific tasks that need to be done in order to accelerate this and help
serialize the work so that we can not get into rebase hell.
Originally I had the plug at the top as a closing note, but I figured
people might miss it.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200422/a1e156ab/attachment-0001.html>

2023-06-07 18:23:06

- reply

📅 Original date posted:2020-02-26
📝 Original message:As a replacement for paper, something like this makes sense v.s. what you
do with a ledger presently.
However, shamir's shares notoriously have the issue that the key does exist
plaintext on a device at some point.
Non-interactive multisig has the benefit of being able to sign transactions
without having keys in the same room/place/device ever.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Wed, Feb 26, 2020 at 9:14 AM Contact Team via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Everyone,
> Seed phrase security has been a subject of discussion for a long time now.
> Though there are varying opinions on the subject but the conflict usually
> arises due to different security models used by different individuals. The
> general practice in the space has been to use paper or metal engraving
> options to secure seed phrase but those too act as a single point of
> failure when secure storage is concerned. The hardware wallets, no matter
> whether use a secure element or not can be hacked either through basic
> glitching or through bigger schemes state enforced backdoors in the closed
> soured SE used.
>
> The option that Cypherock (Cypherock X1 Wallet) is working on removes a
> single point of failure when it comes to storage of seed phrases. It uses 2
> of 4 (with the option of setting up custom threshold limit) Shamir Secret
> Sharing to split the seed phrase into 4 different shares. Each share gets
> stored in a PIN ( hardware enforced ) Card with an EAL 6+ secure element.
> The user would need any 2 of these 4 cyCards to recover the seed or make a
> transaction. Ideally they should all be stored at different locations and
> this added security through distribution makes losing seed phrase highly
> improbable. We have decoupled storage and computation aspect of a hardware
> wallet. More information can be obtained from cypherock.com. The purpose
> of this mail is to get feedback from the community. Let us know if there is
> any feedback, we would love it.
>
> 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/20200226/5c9f93c7/attachment-0001.html>

2023-06-07 18:22:53

- reply

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

2023-06-07 18:21:25

- reply

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

2023-06-07 18:20:56

- reply

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

2023-06-07 18:20:55

- reply

📅 Original date posted:2019-10-04
📝 Original message:Good point -- in our discussion, we called it OP_FFS -- Fold Functional
Stream, and it could be initialized with a different integer to select for
different functions. Therefore the stream processing opcodes would be
generic, but extensible.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Fri, Oct 4, 2019 at 12:00 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Jeremy,
>
> > 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
> >
> > Or it coul
> >
>
> This seems a good idea.
>
> Though it brings up the age-old tension between:
>
> * Generically-useable components, but due to generalization are less
> efficient.
> * Specific-use components, which are efficient, but which may end up not
> being useable in the future.
>
> In particular, `OP_SHA256STREAM` would no longer be useable if SHA256
> eventually is broken, while the `OP_CAT` will still be useable in the
> indefinite future.
> In the future a new hash function can simply be defined and the same
> technique with `OP_CAT` would still be useable.
>
>
> Regards,
> ZmnSCPxj
>
> > --
> > @JeremyRubin
> >
> > On Thu, Oct 3, 2019 at 8:04 PM Ethan Heilman <eth3rs at gmail.com> wrote:
> >
> > > I hope you are having an great afternoon ZmnSCPxj,
> > >
> > > You make an excellent point!
> > >
> > > I had thought about doing the following to tag nodes
> > >
> > > || means OP_CAT
> > >
> > > `node = SHA256(type||SHA256(data))`
> > > so a subnode would be
> > > `subnode1 = SHA256(1||SHA256(subnode2||subnode3))`
> > > and a leaf node would be
> > > `leafnode = SHA256(0||SHA256(leafdata))`
> > >
> > > Yet, I like your idea better. Increasing the size of the two inputs to
> > > OP_CAT to be 260 Bytes each where 520 Bytes is the maximum allowable
> > > size of object on the stack seems sensible and also doesn't special
> > > case the logic of OP_CAT.
> > >
> > > It would also increase performance. SHA256(tag||subnode2||subnode3)
> > > requires 2 compression function calls whereas
> > > SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3 compression
> > > function calls (due to padding).
> > >
> > > >Or we could implement tagged SHA256 as a new opcode...
> > >
> > > I agree that tagged SHA256 as an op code that would certainty be
> > > useful, but OP_CAT provides far more utility and is a simpler change.
> > >
> > > Thanks,
> > > Ethan
> > >
> > > On Thu, Oct 3, 2019 at 7:42 PM ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> > > >
> > > > Good morning Ethan,
> > > >
> > > >
> > > > > To avoid derailing the NO_INPUT conversation, I have changed the
> > > > > subject to OP_CAT.
> > > > >
> > > > > Responding to:
> > > > > """
> > > > >
> > > > > - `SIGHASH` flags attached to signatures are a misdesign, sadly
> > > > > retained from the original BitCoin 0.1.0 Alpha for Windows
> design, on
> > > > > par with:
> > > > > [..]
> > > > >
> > > > > - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > > > > [..]
> > > > > """
> > > > >
> > > > > OP_CAT is an extremely valuable op code. I understand why it
> was
> > > > > removed as the situation at the time with scripts was dire.
> However
> > > > > most of the protocols I've wanted to build on Bitcoin run into
> the
> > > > > limitation that stack values can not be concatenated. For
> instance
> > > > > TumbleBit would have far smaller transaction sizes if OP_CAT
> was
> > > > > supported in Bitcoin. If it happens to me as a researcher it is
> > > > > probably holding other people back as well. If I could wave a
> magic
> > > > > wand and turn on one of the disabled op codes it would be
> OP_CAT. Of
> > > > > course with the change that size of each concatenated value
> must be 64
> > > > > Bytes or less.
> > > >
> > > > Why 64 bytes in particular?
> > > >
> > > > It seems obvious to me that this 64 bytes is most suited for
> building Merkle trees, being the size of two SHA256 hashes.
> > > >
> > > > However we have had issues with the use of Merkle trees in Bitcoin
> blocks.
> > > > Specifically, it is difficult to determine if a hash on a Merkle
> node is the hash of a Merkle subnode, or a leaf transaction.
> > > > My understanding is that this is the reason for now requiring
> transactions to be at least 80 bytes.
> > > >
> > > > The obvious fix would be to prepend the type of the hashed object,
> i.e. add at least one byte to determine this type.
> > > > Taproot for example uses tagged hash functions, with a different tag
> for leaves, and tagged hashes are just
> prepend-this-32-byte-constant-twice-before-you-SHA256.
> > > >
> > > > This seems to indicate that to check merkle tree proofs, an `OP_CAT`
> with only 64 bytes max output size would not be sufficient.
> > > >
> > > > Or we could implement tagged SHA256 as a new opcode...
> > > >
> > > > Regards,
> > > > ZmnSCPxj
> > > >
> > > >
> > > > >
> > > > > On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
> > > > > bitcoin-dev at lists.linuxfoundation.org wrote:
> > > > >
> > > > >
> > > > > > Good morning lists,
> > > > > > Let me propose the below radical idea:
> > > > > >
> > > > > > - `SIGHASH` flags attached to signatures are a misdesign,
> sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on
> par with:
> > > > > > - 1 RETURN
> > > > > > - higher-`nSequence` replacement
> > > > > > - DER-encoded pubkeys
> > > > > > - unrestricted `scriptPubKey`
> > > > > > - Payee-security-paid-by-payer (i.e. lack of P2SH)
> > > > > > - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > > > > > - transaction malleability
> > > > > > - probably many more
> > > > > >
> > > > > > So let me propose the more radical excision, starting with
> SegWit v1:
> > > > > >
> > > > > > - Remove `SIGHASH` from signatures.
> > > > > > - Put `SIGHASH` on public keys.
> > > > > >
> > > > > > Public keys are now encoded as either 33-bytes (implicit
> `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type,
> followed by pubkey coordinate).
> > > > > > `OP_CHECKSIG` and friends then look at the public key to
> determine sighash algorithm rather than the signature.
> > > > > > As we expect public keys to be indirectly committed to on every
> output `scriptPubKey`, this is automatically output tagging to allow
> particular `SIGHASH`.
> > > > > > However, we can then utilize the many many ways to hide public
> keys away until they are needed, exemplified in MAST-inside-Taproot.
> > > > > > I propose also the addition of the opcode:
> > > > > >
> > > > > > <sighash> <pubkey> OP_SETPUBKEYSIGHASH
> > > > > >
> > > > > >
> > > > > > - `sighash` must be one byte.
> > > > > > - `pubkey` may be the special byte `0x1`, meaning "just use
> the Taproot internal pubkey".
> > > > > > - `pubkey` may be 33-byte public key, in which case the
> `sighash` byte is just prepended to it.
> > > > > > - `pubkey` may be 34-byte public key with sighash, in which
> case the first byte is replaced with `sighash` byte.
> > > > > > - If `sighash` is `0x00` then the result is a 33-byte public
> key (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit.
> > > > > >
> > > > > > This retains the old feature where the sighash is selected at
> time-of-spending rather than time-of-payment.
> > > > > > This is done by using the script:
> > > > > >
> > > > > > <pubkey> OP_SETPUBKEYSIGHASH OP_CHECKSIG
> > > > > >
> > > > > >
> > > > > > Then the sighash can be put in the witness stack after the
> signature, letting the `SIGHASH` flag be selected at time-of-signing, but
> only if the SCRIPT specifically is formed to do so.
> > > > > > This is malleability-safe as the signature still commits to the
> `SIGHASH` it was created for.
> > > > > > However, by default, public keys will not have an attached
> `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default
> non-`SIGHASH_ALL`).
> > > > > > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`,
> as they are allowed only if the output specifically says they are allowed.
> > > > > > Would this not be a superior solution?
> > > > > > Regards,
> > > > > > ZmnSCPxj
> > > > > >
> > > > > > bitcoin-dev mailing list
> > > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > >
> > > > > 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
>
>
> _______________________________________________
> 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/709217b1/attachment.html>

2023-06-07 18:20:54

- reply

📅 Original date posted:2019-10-04
📝 Original message: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
Or it coul
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Thu, Oct 3, 2019 at 8:04 PM Ethan Heilman <eth3rs at gmail.com> wrote:
> I hope you are having an great afternoon ZmnSCPxj,
>
> You make an excellent point!
>
> I had thought about doing the following to tag nodes
>
> || means OP_CAT
>
> `node = SHA256(type||SHA256(data))`
> so a subnode would be
> `subnode1 = SHA256(1||SHA256(subnode2||subnode3))`
> and a leaf node would be
> `leafnode = SHA256(0||SHA256(leafdata))`
>
> Yet, I like your idea better. Increasing the size of the two inputs to
> OP_CAT to be 260 Bytes each where 520 Bytes is the maximum allowable
> size of object on the stack seems sensible and also doesn't special
> case the logic of OP_CAT.
>
> It would also increase performance. SHA256(tag||subnode2||subnode3)
> requires 2 compression function calls whereas
> SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3 compression
> function calls (due to padding).
>
> >Or we could implement tagged SHA256 as a new opcode...
>
> I agree that tagged SHA256 as an op code that would certainty be
> useful, but OP_CAT provides far more utility and is a simpler change.
>
> Thanks,
> Ethan
>
> On Thu, Oct 3, 2019 at 7:42 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> >
> > Good morning Ethan,
> >
> >
> > > To avoid derailing the NO_INPUT conversation, I have changed the
> > > subject to OP_CAT.
> > >
> > > Responding to:
> > > """
> > >
> > > - `SIGHASH` flags attached to signatures are a misdesign, sadly
> > > retained from the original BitCoin 0.1.0 Alpha for Windows design,
> on
> > > par with:
> > > [..]
> > >
> > > - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > > [..]
> > > """
> > >
> > > OP_CAT is an extremely valuable op code. I understand why it was
> > > removed as the situation at the time with scripts was dire. However
> > > most of the protocols I've wanted to build on Bitcoin run into the
> > > limitation that stack values can not be concatenated. For instance
> > > TumbleBit would have far smaller transaction sizes if OP_CAT was
> > > supported in Bitcoin. If it happens to me as a researcher it is
> > > probably holding other people back as well. If I could wave a magic
> > > wand and turn on one of the disabled op codes it would be OP_CAT.
> Of
> > > course with the change that size of each concatenated value must
> be 64
> > > Bytes or less.
> >
> > Why 64 bytes in particular?
> >
> > It seems obvious to me that this 64 bytes is most suited for building
> Merkle trees, being the size of two SHA256 hashes.
> >
> > However we have had issues with the use of Merkle trees in Bitcoin
> blocks.
> > Specifically, it is difficult to determine if a hash on a Merkle node is
> the hash of a Merkle subnode, or a leaf transaction.
> > My understanding is that this is the reason for now requiring
> transactions to be at least 80 bytes.
> >
> > The obvious fix would be to prepend the type of the hashed object, i.e.
> add at least one byte to determine this type.
> > Taproot for example uses tagged hash functions, with a different tag for
> leaves, and tagged hashes are just
> prepend-this-32-byte-constant-twice-before-you-SHA256.
> >
> > This seems to indicate that to check merkle tree proofs, an `OP_CAT`
> with only 64 bytes max output size would not be sufficient.
> >
> > Or we could implement tagged SHA256 as a new opcode...
> >
> > Regards,
> > ZmnSCPxj
> >
> >
> > >
> > > On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
> > > bitcoin-dev at lists.linuxfoundation.org wrote:
> > >
> > >
> > > > Good morning lists,
> > > > Let me propose the below radical idea:
> > > >
> > > > - `SIGHASH` flags attached to signatures are a misdesign, sadly
> retained from the original BitCoin 0.1.0 Alpha for Windows design, on par
> with:
> > > > - 1 RETURN
> > > > - higher-`nSequence` replacement
> > > > - DER-encoded pubkeys
> > > > - unrestricted `scriptPubKey`
> > > > - Payee-security-paid-by-payer (i.e. lack of P2SH)
> > > > - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > > > - transaction malleability
> > > > - probably many more
> > > >
> > > > So let me propose the more radical excision, starting with SegWit v1:
> > > >
> > > > - Remove `SIGHASH` from signatures.
> > > > - Put `SIGHASH` on public keys.
> > > >
> > > > Public keys are now encoded as either 33-bytes (implicit
> `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type,
> followed by pubkey coordinate).
> > > > `OP_CHECKSIG` and friends then look at the public key to determine
> sighash algorithm rather than the signature.
> > > > As we expect public keys to be indirectly committed to on every
> output `scriptPubKey`, this is automatically output tagging to allow
> particular `SIGHASH`.
> > > > However, we can then utilize the many many ways to hide public keys
> away until they are needed, exemplified in MAST-inside-Taproot.
> > > > I propose also the addition of the opcode:
> > > >
> > > > <sighash> <pubkey> OP_SETPUBKEYSIGHASH
> > > >
> > > >
> > > > - `sighash` must be one byte.
> > > > - `pubkey` may be the special byte `0x1`, meaning "just use the
> Taproot internal pubkey".
> > > > - `pubkey` may be 33-byte public key, in which case the `sighash`
> byte is just prepended to it.
> > > > - `pubkey` may be 34-byte public key with sighash, in which case
> the first byte is replaced with `sighash` byte.
> > > > - If `sighash` is `0x00` then the result is a 33-byte public key
> (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit.
> > > >
> > > > This retains the old feature where the sighash is selected at
> time-of-spending rather than time-of-payment.
> > > > This is done by using the script:
> > > >
> > > > <pubkey> OP_SETPUBKEYSIGHASH OP_CHECKSIG
> > > >
> > > >
> > > > Then the sighash can be put in the witness stack after the
> signature, letting the `SIGHASH` flag be selected at time-of-signing, but
> only if the SCRIPT specifically is formed to do so.
> > > > This is malleability-safe as the signature still commits to the
> `SIGHASH` it was created for.
> > > > However, by default, public keys will not have an attached `SIGHASH`
> byte, implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).
> > > > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as
> they are allowed only if the output specifically says they are allowed.
> > > > Would this not be a superior solution?
> > > > Regards,
> > > > ZmnSCPxj
> > > >
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev at lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > > 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/bitcoin-dev/attachments/20191003/e3a709c9/attachment.html>

2023-06-07 18:10:30

- reply

📅 Original date posted:2018-02-09
📝 Original message:I'm also highly interested in the case where you sign a delegate
conditional on another delegate being signed, e.g. a bilateral agreement.
In order for this to work nicely you also need internally something like
segwit so that you can refer to one side's delegation by a signature-stable
identity.
I don't have a suggestion of a nice way to do this at this time, but will
stew on it.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Thu, Feb 8, 2018 at 11:29 PM, Jeremy <jlrubin at mit.edu> wrote:
> This might be unpopular because of bad re-org behavior, but I believe the
> utility of this construction can be improved if we introduce functionality
> that makes a script invalid after a certain time (correct me if I'm
> wrong, I believe all current timelocks are valid after a certain time and
> invalid before, this is the inverse).
>
> Then you can exclude old delegates by timing/block height arguments, or
> even pre-sign delegates for different periods of time (e.g., if this
> happens in the next 100 blocks require y, before the next 1000 blocks but
> after the first 100 require z, etc).
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev at rgrant.org>
>> wrote:
>> > Am I reading correctly that this allows unilateral key rotation (to a
>> > previously unknown key), without invalidating the interests of other
>> > parties in the existing multisig (or even requiring any on-chain
>> > transaction), at the cost of storing the signed delegation?
>>
>> Yes, though I'd avoid the word rotation because as you note it doesn't
>> invalidate the interests of any key, the original setup remains able
>> to sign. You could allow a new key of yours (plus everyone else) to
>> sign, assuming the other parties agree... but the old one could also
>> still sign.
>> _______________________________________________
>> 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/20180208/75f279de/attachment-0001.html>

2023-06-07 18:10:29

- reply

📅 Original date posted:2018-02-09
📝 Original message:This might be unpopular because of bad re-org behavior, but I believe the
utility of this construction can be improved if we introduce functionality
that makes a script invalid after a certain time (correct me if I'm wrong,
I believe all current timelocks are valid after a certain time and invalid
before, this is the inverse).
Then you can exclude old delegates by timing/block height arguments, or
even pre-sign delegates for different periods of time (e.g., if this
happens in the next 100 blocks require y, before the next 1000 blocks but
after the first 100 require z, etc).
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev at rgrant.org> wrote:
> > Am I reading correctly that this allows unilateral key rotation (to a
> > previously unknown key), without invalidating the interests of other
> > parties in the existing multisig (or even requiring any on-chain
> > transaction), at the cost of storing the signed delegation?
>
> Yes, though I'd avoid the word rotation because as you note it doesn't
> invalidate the interests of any key, the original setup remains able
> to sign. You could allow a new key of yours (plus everyone else) to
> sign, assuming the other parties agree... but the old one could also
> still sign.
> _______________________________________________
> 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/20180208/916acbdb/attachment.html>

2023-06-07 17:53:50

- reply

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

2023-06-07 17:50:55

- reply

📅 Original date posted:2016-05-22
📝 Original message:nack -- not secure.
OP_PRANDOM also adds extra validation overhead on a block potentially
composed of transactions all spending an OP_PRANDOM output from all
different blocks.
I do agree that random numbers are highly desirable though.
I think it would be much better for these use cases to add OP_XOR back and
then use something like Blum's fair coin-flipping over the phone. OP_XOR
may have other uses too.
I have a write-up from a while back which does Blum's without OP_XOR using
OP_SIZE for off-chain probabilistic payments if anyone is interested. No
fork needed, but of course it is more limited and broken in a number of
ways.
(sorry to those of you seeing this twice, my first email bounced the list)
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Matthew,
>
> You should take a look at OP_DETERMINISTICRANDOM [1] from the Elements
> Project. It aims to achieve a similar goal.
>
> Code is in the `alpha` branch [2].
>
> [1]: https://www.elementsproject.org/elements/opcodes/
> [2]:
> https://github.com/ElementsProject/elements/blob/alpha/src/script/interpreter.cpp#L1252-L1305
>
> On Fri, May 20, 2016 at 8:29 AM Matthew Roberts via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good point, to be honest. Maybe there's a better way to combine the block
>> hashes like taking the first N bits from each block hash to produce a
>> single number but the direction that this is going in doesn't seem ideal.
>>
>> I just asked a friend about this problem and he mentioned using the hash
>> of the proof of work hash as part of the number so you have to throw away a
>> valid POW if it doesn't give you the hash you want. I suppose its possible
>> to make it infinitely expensive to manipulate the number but I can't think
>> of anything better than that for now.
>>
>> I need to sleep on this for now but let me know if anyone has any better
>> ideas.
>>
>>
>>
>> On Fri, May 20, 2016 at 6:34 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
>>
>>> Using the hash of multiple blocks does not make it any safer. The miner
>>> of the last block always determines the results, by knowing the hashes of
>>> all previous blocks.
>>>
>>>
>>> == Security
>>>
>>> Pay-to-script-hash can be used to protect the details of contracts that
>>> use OP_PRANDOM from the prying eyes of miners. However, since there is also
>>> a non-zero risk that a participant in a contract may attempt to bribe a
>>> miner the inclusion of multiple block hashes as a source of randomness is a
>>> must. Every miner would effectively need to be bribed to ensure control
>>> over the results of the random numbers, which is already very unlikely. The
>>> risk approaches zero as N goes up.
>>>
>>>
>>>
>> _______________________________________________
>> 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/20160522/22a4184e/attachment.html>

2023-06-07 17:44:12

- reply

📅 Original date posted:2015-11-05
📝 Original message:I'd also like to see some more formal analysis of the notion that "$10 in
the hand of 10 people is more than $50 in the hand of two, or $100 in the
hand of one". I think this encapsulates the security assumption on why we
want decentralization at all.
This is a very critical property bitcoin exploits for being able to
transact large amounts, among other things. (Closely related is the notion
that defecting will destroy all the value...)
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Thu, Nov 5, 2015 at 6:33 PM, Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
> > ...
> > Validators: Economically dependent full nodes are an important part of
> > Bitcoin's security model because they assure Bitcoin security by
> > enforcing consensus rules. While full nodes do not have orphan
> > risk, we also dont want maliciously crafted blocks with pathological
> > validation cost to erode security by knocking reasonable spec full
> > nodes off the network on CPU (or bandwidth grounds).
> > ...
> > Validators vs Miner decentralisation balance:
> >
> > There is a tradeoff where we can tolerate weak miner decentralisation
> > if we can rely on good validator decentralisation or vice versa. But
> > both being weak is risky. Currently given mining centralisation
> > itself is weak, that makes validator decentralisation a critical
> > remaining defence - ie security depends more on validator
> > decentralisation than it would if mining decentralisation was in a
> > better shape.
>
> This side of the security model seems underappreciated, if not poorly
> understood. Weakening is not just occurring because of the proliferation
> of non-validating wallet software and centralized (web) wallets, but
> also centralized Bitcoin APIs.
>
> Over time developers tend to settle on a couple of API providers for a
> given problem. Bing and Google for search and mapping, for example. All
> applications and users of them, depending on an API service, reduce to a
> single validator. Imagine most Bitcoin applications built on the
> equivalent of Bing and Google.
>
> e
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151105/fcb5bbd4/attachment.html>

2023-06-07 15:24:00

- reply

📅 Original date posted:2014-07-16
📝 Original message:Hey all,
I had an idea for a new transaction type. The base idea is that it is
matching on script hashes much like pay to script hash, but checks for one
of N scripts.
A motivating case is for "permission groups". Let's say I want to have a
single "root user" script, a 2 of 3 group, and a 2 of 2 group able to spend
a utxo. This would allow for any one of these permission groups to spend.
Right now, this could be expressed multiple ways (ie, using an op_dup if
then else chain) , but all would incur additional costs in terms of
complicated control flows. Instead, I would propose:
OP_HASH160 [20-byte-hash-value 1]...[20-byte-hash-value N] OP_N
OP_MULTISCRIPTHASHVERIFY
could be spent with
...signatures... {serialized script}
And the alternative formulation: (more complex!)
OP_HASH160 OP_DUP [20-byte-hash-value 1]
OP_IF OP_EQUAL
OP_VERIFY OP_ELSE <OP_DUP [20-byte-hash-value 2] OP_IF......>
OP_ENDIF
Of course, the permission group example is just one use case, there could
be other interesting combinations as well
.
There is an implication in terms of increased utxo pool bloat, but also an
implication in terms of increased txn complexity (each 20 byte hash allows
for a 500 byte script, only one of the 500 byte scripts has to be
permanently stored on blockchain).
Looking forward to your feedback -- the idea is a bit preliminary, but I
think it could be exciting.
Best,
Jeremy
--
Jeremy Rubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140716/a960cd3a/attachment.html>