Billy Tetrud [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-08-22 to 2023-01-31
💬 Posted a total of 195 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, Bitcoin Advent Calendar, Pre-BIP
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns

Profile Code

nprofile1qqsrqv8v94czt87a2kagup3hgrqnns764fsclphrlt35e67tw0r59wslqyh07

Author Public Key

npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns

Show more details

Last Notes

2023-06-09 13:05:26

- reply

📅 Original date posted:2022-02-26
📝 Original message:
> m is how much people want to kill a sidechain, 0 = everybody would be sad
if it died and would rather burn all their BTC forever than continue living
Math is brutal
On Sat, Feb 26, 2022, 01:39 ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good morning Paul,
>
>
> > I don't think I can stop people from being ignorant about Drivechain.
> But I can at least allow the Drivechain-knowledgable to identify each other.
> >
> > So here below, I present a little "quiz". If you can answer all of these
> questions, then you basically understand Drivechain:
> >
> > 0. We could change DC to make miner-theft impossible, by making it a
> layer1 consensus rule that miners never steal. Why is this cure worse than
> the disease?
>
> Now miners are forced to look at all sideblocks, not optionally do so if
> it is profitable for them.
>
> > 1. If 100% hashrate wanted to steal coins from a DC sidechain *as
> quickly as possible*, how long would this take (in blocks)?
>
> 13,150 (I think this is how you changed it after feedback from this list,
> I think I remember it was ~3000 before or thereabouts.)
>
> > 2. Per sidechain per year (ie, per 52560 blocks), how many DC
> withdrawals can take place (maximum)? How many can be attempted?
> > (Ie, how does the 'train track metaphor' work, from ~1h5m in the
> "Overview and Misconceptions" video)?
>
> I hate watching videos, I can read faster than anyone can talk (except
> maybe Laolu, he speaks faster than I can process, never mind read).
>
> ~4 times (assuming 52560 block per year, which may vary due to new miners,
> hashrate drops, etc)
>
> > 3. Only two types of people should ever be using the DC withdrawal
> system at all.
> > 3a. Which two?
>
> a. Miners destroying the sidechain because the sidechain is no longer
> viable.
> b. Aggregators of sidechain-to-minechain transfers and large whales.
>
> > 3b. How is everyone else, expected to move their coins from chain to
> chain?
>
> Cross-system atomic swaps.
> (I use "System" here since the same mechanism works for Lightning
> channels, and channels are not blockchains.)
>
> > 3c. (Obviously, this improves UX.) But why does it also improve
> security?
>
> Drivechain-based pegged transfers are aggregates of many smaller transfers
> and thus every transfer out from the sidechain contributes its "fee" to the
> security of the peg.
>
> > --
> > 4. What do the parameters b and m stand for (in the DC security model)?
>
> m is how much people want to kill a sidechain, 0 = everybody would be sad
> if it died and would rather burn all their BTC forever than continue
> living, 1 = do not care, > 1 people want to actively kill the sidechain.
>
> b is how much profit a mainchain miner expects from supporting a sidechain
> (do not remember the unit though).
> Something like u = a + b where a is the mainchain, b is the sidechain, u
> is the total profit.
> Or fees? Something like that.
>
> > 5. How can m possibly be above 1? Give an example of a
> sidechain-attribute which may cause this situation to arise.
>
> The sidechain is a total scam.
> A bug may be found in the sidechain that completely negates any security
> it might have, thus removing any desire to protect the sidechain and
> potentially make users want to destroy it completely rather than let it
> continue.
> People end up hating sidechains completely.
>
> > 6. For which range of m, is DC designed to deter sc-theft?
>
> m <= 1
>
> > 7. If DC could be changed to magically deter theft across all ranges of
> m, why would that be bad for sidechain users in general?
>
> Because the sidechain would already be part of mainchain consensus.
>
> > --
> > 8. If imminent victims of a DC-based theft, used a mainchain UASF to
> prohibit the future theft-withdrawal, then how would this affect non-DC
> users?
>
> If the non-DC users do not care, then they are unaffected.
> If the non-DC users want to actively kill the sidechain, they will
> counterattack with an opposite UASF and we have a chainsplit and sadness
> and mutual destruction and death and a new subreddit.
>
> > 9. In what ways might the BTC network one day become uncompetitive? And
> how is this different from caring about a sidechain's m and b?
>
> If it does not enable scaling technology fast enough to actually be able
> to enable hyperbitcoinization.
>
> Sidechains are not a scaling solution, so caring about m and b is
> different because your focus is not on scaling.
>
> > --
> > 10. If DC were successful, Altcoin-investors would be harmed. Two
> Maximalist-groups would also be slightly harmed -- who are these?
>
> Dunno!
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220226/cf55492c/attachment.html>

2023-06-09 13:05:01

- reply

📅 Original date posted:2022-01-20
📝 Original message:
Thanks for the info.
> you could "sponsor yourself" directly or through a cycle involving > 1
txn.
Ah I see, because the sighash flags aren't used to create the TXID. I don't
really see the problem with cycles tho. Could a cycle cause problems for
anyone? Seems like it would be a harmless waste of bytes. The
fee-sponsoring OP_VER looks good too tho.
On Wed, Jan 19, 2022 at 2:08 PM Jeremy <jlrubin at mit.edu> wrote:
> 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/1724e2e9/attachment-0001.html>

2023-06-09 13:05:00

- reply

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

2023-06-09 13:04:59

- reply

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

2023-06-09 13:04:57

- reply

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

2023-06-09 13:04:56

- reply

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

2023-06-09 13:03:20

- reply

📅 Original date posted:2021-08-26
📝 Original message:
One interesting thing I thought of: the cost of maintenance of the dust
creates a (very) small incentive to mine transactions that *use* dust
outputs with a slightly lower fee that contain dust, in order to reduce the
future maintenance cost for themselves. However, the rational discount
would likely be vanishingly small. It would be interesting to add
something to the consensus rules to decrease the vbytes for a transaction
that consumes dust outputs such that the value of removing them from the
system (saving the future cost of maintenance) is approximately equal to
the amount that the fee could be made lower for such transactions. Even
measuring this as a value over the whole (future) bitcoin network, I'm not
sure how to evaluate the magnitude of this future cost.
On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Jeremy,
>
> > 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.
>
> Against the above, we should note that in the Lightning spec, when an
> output *would have been* created that is less than the dust limit, the
> output is instead put into fees.
>
> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs
>
> Thus, the existence of a dust limit encourages L2 protocols to have
> similar rules, where outputs below the dust limit are just given over as
> fees to miners, so the existence of a dust limit might very well be
> incentivize-compatible for miners, regardless of centralization effects or
> not.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210826/952bece6/attachment.html>

2023-06-09 13:03:18

- reply

📅 Original date posted:2021-08-10
📝 Original message:
For sure, CT can be done with computational soundness. The advantage of
unhidden amounts (as with current bitcoin) is that you get unconditional
soundness. My understanding is that there is a fundamental tradeoff between
unconditional soundness and unconditional privacy. I believe Monero has
taken this alternate tradeoff path with unconditional privacy but only
computational soundness
<https://www.reddit.com/r/Monero/comments/8erg8e/what_should_monero_do_about_the_soundness_problem/dxy59ad?utm_source=share&utm_medium=web2x&context=3>
.
> old things that never move more or less naturally "fall leftward"
Ah yes, something like that would definitely be interesting to basically
make dust a moot point. Sounds like the tradeoff mentioned is that proofs
would be twice as big? Except newer UTXOs would have substantially shorter
proofs. It sounds like the kind of thing where there's some point where
there would be so many old UTXOs that proofs would be smaller on average in
the swap tree version vs the dead-leaf version. Maybe someone smarter than
me could estimate where that point is.
On Mon, Aug 9, 2021 at 10:04 PM Jeremy <jlrubin at mit.edu> wrote:
> You might be interested in https://eprint.iacr.org/2017/1066.pdf which
> claims that you can make CT computationally hiding and binding, see section
> 4.6.
>
> with respect to utreexo, you might review
> https://github.com/mit-dci/utreexo/discussions/249?sort=new which
> discusses tradeoffs between different accumulator designs. With a swap
> tree, old things that never move more or less naturally "fall leftward",
> although there are reasons to prefer alternative designs.
>
>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210809/c4607f2b/attachment.html>

2023-06-09 13:03:17

- reply

📅 Original date posted:2021-08-09
📝 Original message:
> 5) should we ever do confidential transactions we can't prevent it without compromising
privacy / allowed transfers
I wanted to mention the dubiousness of adding confidential transactions to
bitcoin. Because adding CT would eliminate the ability for users to audit
the supply of Bitcoin, I think its incredibly unlikely to ever happen. I'm
in the camp that we shouldn't do anything that prevents people from
auditing the supply. I think that camp is probably pretty large. Regardless
of what I think should happen there, and even if CT were to eventually
happen in bitcoin, I don't think that future possibility is a good reason
to change the dust limit today.
It seems like dust is a scalability problem regardless of whether we use
Utreexo eventually or not, tho an accumulator would help a ton. One idea
would be to destroy/delete dust at some point in the future. However, even
if we were to plan to do this, I still don't think the dust limit should be
removed. But the dust limit should probably be lowered a bit, given that
the 546 sats limit is about 7 cents and its very doable to send 1 sat/vbyte
transactions, so lowering it to 200 sats seems reasonable.
On Mon, Aug 9, 2021 at 6:24 AM Antoine Riard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm pretty conservative about increasing the standard dust limit in any
> way. This would convert a higher percentage of LN channels capacity into
> dust, which is coming with a lowering of funds safety [0]. Of course, we
> can adjust the LN security model around dust handling to mitigate the
> safety risk in case of adversarial settings, but ultimately the standard
> dust limit creates a "hard" bound, and as such it introduces a trust
> vector in the reliability of your peer to not goes
> onchain with a commitment heavily-loaded with dust-HTLC you own.
>
> LN node operators might be willingly to compensate this "dust" trust
> vector by relying on side-trust model, such as PKI to authenticate their
> peers or API tokens (LSATs, PoW tokens), probably not free from
> consequences for the "openness" of the LN topology...
>
> Further, I think any authoritative setting of the dust limit presents the
> risk of becoming ill-adjusted w.r.t to market realities after a few months
> or years, and would need periodic reevaluations. Those reevaluations, if
> not automated, would become a vector of endless dramas and bikeshedding as
> the L2s ecosystems grow bigger...
>
> Note, this would also constrain the design space of newer fee schemes.
> Such as negotiated-with-mining-pool and discounted consolidation during low
> feerate periods deployed by such producers of low-value outputs.
> `
> Moreover as an operational point, if we proceed to such an increase on the
> base-layer, e.g to 20 sat/vb, we're going to severely damage the
> propagation of any LN transaction, where a commitment transaction is built
> with less than 20 sat/vb outputs. Of course, core's policy deployment on
> the base layer is gradual, but we should first give a time window for the
> LN ecosystem to upgrade and as of today we're still devoid of the mechanism
> to do it cleanly and asynchronously (e.g dynamic upgrade or quiescence
> protocol [1]).
>
> That said, as raised by other commentators, I don't deny we have a
> long-term tension between L2 nodes and full-nodes operators about the UTXO
> set growth, but for now I would rather solve this with smarter engineering
> such as utreexo on the base-layer side or multi-party shared-utxo or
> compressed colored coins/authentication smart contracts (e.g
> opentimestamp's merkle tree in OP_RETURN) on the upper layers rather than
> altering the current equilibrium.
>
> I think the status quo is good enough for now, and I believe we would be
> better off to learn from another development cycle before tweaking the dust
> limit in any sense.
>
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html
> [1] https://github.com/lightningnetwork/lightning-rfc/pull/869
>
> Le dim. 8 août 2021 à 14:53, Jeremy <jlrubin at mit.edu> a écrit :
>
>> 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>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-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/lightning-dev/attachments/20210809/84b13e96/attachment-0001.html>

2023-06-09 12:47:33

- reply

📅 Original date posted:2017-09-04
📝 Original message:
Johan,
" I suspect that if you keep every node within 3 hops in your local
topology"
Not every node would store 3 hops. Maybe for some nodes 2 hops is the right
number. Or if you're connected directly with a huge hub, maybe you would
only be able to store your direct connections and the 2nd hops for only
*some* of your connections. Or maybe the algorithm could aim for a certain
amount of topology data for each connection (eg 10MB per connection) so
that you'll only store a small percentage of 2nd hops for a large hub,
while still be able to store 5th or 6th hops for long chains of nodes with
few connections.
~BT
> ---------- Forwarded message ----------
> From: "Johan Torås Halseth" <johanth at gmail.com>
> To: Billy Tetrud <billy.tetrud at gmail.com>
> Cc: lightning-dev at lists.linuxfoundation.org
> Bcc:
> Date: Mon, 04 Sep 2017 11:13:15 +0200
> Subject: Re: [Lightning-dev] Route finding and route generation
> I haven’t looked too closely at your proposal, but the first thing that
> hit me (2 weeks ago, sorry for not answering right away), is that instead
> of the basic flood-the-network-about-channels algorithm that currently is
> being used, this makes each route discovery request behave more or less
> like flooding (ask everybody within your local topology)?
>
> Also it will be interesting to see when the network starts developing, I
> suspect that if you keep every node within 3 hops in your local topology,
> you end up storing most of the network anyway. So I think the routing
> algorithms will be far easier to optimize and analyze after some real world
> data :)
>
> That being said, interesting idea, I’m not dismissing it :D
>
> On Tue, Aug 22, 2017 at 3:08, Billy Tetrud <billy.tetrud at gmail.com> wrote:
>
> Hey Guys,
>
> I'm testing this mailing list out for the first time, so I'm probably
> gonna be doing it wrong.
>
> I want to talk about route discovery and route generation in the lightning
> network. It seems there's a couple types of things going on with routing:
>
> - Super basic flood-the-network style routing to get things up and
> running, as I believe is implicitly proposed here: https://github.com/
> lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
> <https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md>
> - More involved research projects that may not reach fruition any time
> soon. Eg this: http://bitfury.com/content/5-white-papers-research/
> whitepaper_flare_an_approach_to_routing_in_lightning_
> network_7_7_2016.pdf
> <http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf>
>
> I'd like to discuss a near-term approach that can replace the basic
> flood-the-network style route discovery, but isn't so complicated that it
> needs a ton of study and work. This won't be the end-all solution to route
> discovery, but should take us a lot further than flood-the-network.
>
> I propose a protocol where each node knows about its own local network
> topology, and to find a final route, a transaction originator queries a
> number of its connections for routes to the intended destination. By doing
> this, it means that nodes are *not* receiving or storing the entire network
> topology, which makes route discovery a lot less taxing on the network (in
> terms of bandwidth and storage space).
>
> To go into more detail...
>
> When a node joins the network:
> 1. it broadcasts its information to all its channels (pretty much as
> proposed here
> <https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md>)
> announcing its relevant channel information
> 2. it requests local network topology information from all its channels
> for information about channels 1 hop beyond its direct connection (ie it
> will receive information about which addresses those channels are connected
> to, and their related fee info / etc)
> 3. it then requests topology information for channels 2 hops beyond, etc
> until it has filled its cache to its satisfaction (the user can choose some
> amount of megabytes as its limit of network topology data to store)
> 4. it also subscribes to topology changes for nodes at those distances (eg
> if a node has requested information from 3 hops away, it will receive info
> about any new channels or removed channels that fall within that distance)
>
> When a node receives an announcement message from a node joining the
> network:
> 1. it will store that node's info in its cache
> 2. it will also forward that info to any node that's subscribed to
> topology changes that fall within the relevant distance
>
> When a node wants to construct a route for a transaction:
> 1. It checks to see if it has a path to that node in its cache. If it
> does, it finds the cost of the cheapest path it has.
> 2. It asks all the channels on the edge of its cached local view for their
> cheapest path (however you want to define cheapest), specifying that it
> only care about paths with a maximum cost of the cheapest path it has
> already found in its cache. For example, if the node has nodes up to 3 hops
> away in its cache, it will *only* ask the nodes 3 hops away (it will not
> ask its direct connections, nor nodes 2 hops away, since it already has
> enough information to ignore them)
> 3. When it gets all its responses, it constructs a path
>
> When a node receives a path request from a node:
> 1. It checks its cache for its cheapest cache-only path
> 2. It asks nodes on the edge of its cached local view for their cheapest
> path, specifying that it only cares about paths with a maximum cost of
> either its cheapest cache-only path or the max-cost specified by the
> requesting node minus the channel cost between it and the requesting node
> (whichever is cheaper). A node on the edge of its cached local view is
> *not* asked for route information if the cost to that node exceeds the
> max-cost this relay node would specify.
> 3. It reports the results that satisfy the max-cost requirements of the
> requesting node
>
> And that's it. All the route information can be encrypted and signed so
> relaying nodes can't read the information inside, and so the requesting
> source node can verify which nodes sent that information.
>
> This protocol should keep both node-announcement messages *and* route
> request messages highly localized.
>
> Thoughts?
>
> ~BT
>
>
>
>
> _______________________________________________
> 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/20170904/db2b4551/attachment.html>

2023-06-09 12:47:32

- reply

📅 Original date posted:2017-09-04
📝 Original message:
Thanks for the information Laolu! I'm glad people smarter than me are
working on this : ) . Do you have any idea when Flare might be ready for
real-world use?
~BT
On Mon, Sep 4, 2017 at 1:02 PM, Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> Hi,
>
> Welcome to the mailing list!
>
> Replying here rather than the issue you filed on the lighting-rfc repo as
> I'd say this is a better venue to discuss matters such as this. The
> structure of the mailing list may be a bit strange initially, but once you
> get over that hump, I think you'll find it's rather pleasant to use. Also,
> if you stick around, you'll find that most members of the Bitcoin
> development community use technical mailing lists such as this one to
> share ideas, propose new solutions, analyze existing schemes, etc.
>
> This list has been a bit lower traffic recently than compared to the past
> as many of us have locked ourselves in dungeons coding without pants as
> we're rapidly approaching the first mainnet release of our various
> lightning node software. As a result, replies may have a bit of delay, but
> that's nothing to fret about!
>
> > I propose a protocol where each node knows about its own local network
> > topology, and to find a final route, a transaction originator queries a
> > number of its connections for routes to the intended destination.
>
> For color, I'm one of the co-authors of the Flare paper. What you've
> described in this email is close to the approach, but it utilizes a blind
> all-the-links flood towards the destination, rather than a DFS search
> guided by the distance metric proposed in the paper. One thing to note is
> that Flare utilizes HORNET to allow senders to query their beacon nodes,
> and also nodes beyond the horizon of their beacon nodes in a private
> manner. By using the bi-directional communication circuit, we maintain
> requester anonymity, and don't force those performing search to reveal
> their identity nor intent. Also note that Flare itself also uses an
> initial routing cache for a neighborhood of N nodes.
>
> What you've described here is essentially Dynamic Source Routing (DSR)[1],
> with a mix of components from Fisheye State Routing (FSR) making it a
> hybrid protocol that combines reactive and proactive elements in order to
> achieve its goals.
>
> Our current stop-gap is a pure proactive protocol, meaning that nodes
> gather all link state data and then make forwarding and
> routing decisions based off of that. The clear trade off (as you point
> out), is the increase in table state and bandwidth incurred due to keeping
> up with the announcements. The upside is that the latency observed when
> attempting payments to random sections of the graphs are minimized.
> Additionally, as we have complete information, we can make more
> intelligent path finding decisions, and also ensure that we collect a
> redundant set of routes for each payment. By ensuring that we collect a
> set of routes with high path diversity, we have many options to fall back
> to in the case of a routing failure with one of the earlier routes in our
> set.
>
> However, protocols that have a reactive element for each circuit
> establishment may not necessarily scale better. This is due to the
> computational overhead of circuit establishment. Particularly in your
> DSR+FSR combo as the flood proceeds in all directions. As a result,
> circuit establishment may have latency in the seconds as each random
> payment may potentially need to flood out in the graph in search of the
> destination. Without a sort of distance metric to guide the search, it
> may wastefully explore non-relevant sections, further increasing payment
> latency and overhead for all other nodes. Finally, one aspect to consider
> is how DoS-able schemes like this that require flooding for each circuit
> establishment are.
>
> > When a node wants to construct a route for a transaction:
> > 2. It asks all the channels on the edge of its cached local view for
> > their cheapest path
>
> Simply _asking_ nodes for a path to a destination defeats the point of
> using onion routing at all. If one is prepared to make that tradeoff, then
> far more scalable routing protocols can be explored as at that point, one
> would move to distance vector based algorithms.
>
> Very happy to see that more folks are exploring alternative
> routing/discovery solutions! In the future we'll definitely need to scale
> up the network.
>
> One beauty of the way the system is laid out is that multiple
> heterogeneous routing protocols can be used within the network just as
> within the Internet (eBGP vs iBGP), so different sub-graphs can chose
> protocols that achieve their goals in light of the various tradeoffs. I
> think I'll follow up this post with a general survey of potential
> approaches I've come up with and come across in the literature along with
> their various tradeoffs, and possible paths forward for the network as a
> whole.
>
>
> -- Laolu
>
>
> [1]: https://arxiv.org/pdf/1507.05724.pdf
> [2]: http://www.utdallas.edu/~ksarac/Papers/DSR.pdf
> [3]: http://nrlweb.cs.ucla.edu/publication/download/203/05_
> 75_fisheye-state-routing-in.pdf
>
>
> On Mon, Aug 21, 2017 at 6:09 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> Hey Guys,
>>
>> I'm testing this mailing list out for the first time, so I'm probably
>> gonna be doing it wrong.
>>
>> I want to talk about route discovery and route generation in the
>> lightning network. It seems there's a couple types of things going on with
>> routing:
>>
>> - Super basic flood-the-network style routing to get things up and
>> running, as I believe is implicitly proposed here: https://github.com/
>> lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
>> <https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md>
>> - More involved research projects that may not reach fruition any
>> time soon. Eg this: http://bitfury.com/content/5-white-papers-
>> research/whitepaper_flare_an_approach_to_routing_in_
>> lightning_network_7_7_2016.pdf
>> <http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf>
>>
>> I'd like to discuss a near-term approach that can replace the basic
>> flood-the-network style route discovery, but isn't so complicated that it
>> needs a ton of study and work. This won't be the end-all solution to route
>> discovery, but should take us a lot further than flood-the-network.
>>
>> I propose a protocol where each node knows about its own local network
>> topology, and to find a final route, a transaction originator queries a
>> number of its connections for routes to the intended destination. By doing
>> this, it means that nodes are *not* receiving or storing the entire network
>> topology, which makes route discovery a lot less taxing on the network (in
>> terms of bandwidth and storage space).
>>
>> To go into more detail...
>>
>> When a node joins the network:
>> 1. it broadcasts its information to all its channels (pretty much as
>> proposed here
>> <https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md>)
>> announcing its relevant channel information
>> 2. it requests local network topology information from all its channels
>> for information about channels 1 hop beyond its direct connection (ie it
>> will receive information about which addresses those channels are connected
>> to, and their related fee info / etc)
>> 3. it then requests topology information for channels 2 hops beyond, etc
>> until it has filled its cache to its satisfaction (the user can choose some
>> amount of megabytes as its limit of network topology data to store)
>> 4. it also subscribes to topology changes for nodes at those distances
>> (eg if a node has requested information from 3 hops away, it will receive
>> info about any new channels or removed channels that fall within that
>> distance)
>>
>> When a node receives an announcement message from a node joining the
>> network:
>> 1. it will store that node's info in its cache
>> 2. it will also forward that info to any node that's subscribed to
>> topology changes that fall within the relevant distance
>>
>> When a node wants to construct a route for a transaction:
>> 1. It checks to see if it has a path to that node in its cache. If it
>> does, it finds the cost of the cheapest path it has.
>> 2. It asks all the channels on the edge of its cached local view for
>> their cheapest path (however you want to define cheapest), specifying that
>> it only care about paths with a maximum cost of the cheapest path it has
>> already found in its cache. For example, if the node has nodes up to 3 hops
>> away in its cache, it will *only* ask the nodes 3 hops away (it will not
>> ask its direct connections, nor nodes 2 hops away, since it already has
>> enough information to ignore them)
>> 3. When it gets all its responses, it constructs a path
>>
>> When a node receives a path request from a node:
>> 1. It checks its cache for its cheapest cache-only path
>> 2. It asks nodes on the edge of its cached local view for their cheapest
>> path, specifying that it only cares about paths with a maximum cost of
>> either its cheapest cache-only path or the max-cost specified by the
>> requesting node minus the channel cost between it and the requesting node
>> (whichever is cheaper). A node on the edge of its cached local view is
>> *not* asked for route information if the cost to that node exceeds the
>> max-cost this relay node would specify.
>> 3. It reports the results that satisfy the max-cost requirements of the
>> requesting node
>>
>> And that's it. All the route information can be encrypted and signed so
>> relaying nodes can't read the information inside, and so the requesting
>> source node can verify which nodes sent that information.
>>
>> This protocol should keep both node-announcement messages *and* route
>> request messages highly localized.
>>
>> Thoughts?
>>
>> ~BT
>>
>>
>>
>> _______________________________________________
>> 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/20170904/46ed51f1/attachment.html>

2023-06-09 12:47:28

- reply

📅 Original date posted:2017-08-21
📝 Original message:
Hey Guys,
I'm testing this mailing list out for the first time, so I'm probably gonna
be doing it wrong.
I want to talk about route discovery and route generation in the lightning
network. It seems there's a couple types of things going on with routing:
- Super basic flood-the-network style routing to get things up and
running, as I believe is implicitly proposed here:
https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
- More involved research projects that may not reach fruition any time
soon. Eg this:
http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf
I'd like to discuss a near-term approach that can replace the basic
flood-the-network style route discovery, but isn't so complicated that it
needs a ton of study and work. This won't be the end-all solution to route
discovery, but should take us a lot further than flood-the-network.
I propose a protocol where each node knows about its own local network
topology, and to find a final route, a transaction originator queries a
number of its connections for routes to the intended destination. By doing
this, it means that nodes are *not* receiving or storing the entire network
topology, which makes route discovery a lot less taxing on the network (in
terms of bandwidth and storage space).
To go into more detail...
When a node joins the network:
1. it broadcasts its information to all its channels (pretty much as
proposed here
<https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md>)
announcing its relevant channel information
2. it requests local network topology information from all its channels for
information about channels 1 hop beyond its direct connection (ie it will
receive information about which addresses those channels are connected to,
and their related fee info / etc)
3. it then requests topology information for channels 2 hops beyond, etc
until it has filled its cache to its satisfaction (the user can choose some
amount of megabytes as its limit of network topology data to store)
4. it also subscribes to topology changes for nodes at those distances (eg
if a node has requested information from 3 hops away, it will receive info
about any new channels or removed channels that fall within that distance)
When a node receives an announcement message from a node joining the
network:
1. it will store that node's info in its cache
2. it will also forward that info to any node that's subscribed to topology
changes that fall within the relevant distance
When a node wants to construct a route for a transaction:
1. It checks to see if it has a path to that node in its cache. If it does,
it finds the cost of the cheapest path it has.
2. It asks all the channels on the edge of its cached local view for their
cheapest path (however you want to define cheapest), specifying that it
only care about paths with a maximum cost of the cheapest path it has
already found in its cache. For example, if the node has nodes up to 3 hops
away in its cache, it will *only* ask the nodes 3 hops away (it will not
ask its direct connections, nor nodes 2 hops away, since it already has
enough information to ignore them)
3. When it gets all its responses, it constructs a path
When a node receives a path request from a node:
1. It checks its cache for its cheapest cache-only path
2. It asks nodes on the edge of its cached local view for their cheapest
path, specifying that it only cares about paths with a maximum cost of
either its cheapest cache-only path or the max-cost specified by the
requesting node minus the channel cost between it and the requesting node
(whichever is cheaper). A node on the edge of its cached local view is
*not* asked for route information if the cost to that node exceeds the
max-cost this relay node would specify.
3. It reports the results that satisfy the max-cost requirements of the
requesting node
And that's it. All the route information can be encrypted and signed so
relaying nodes can't read the information inside, and so the requesting
source node can verify which nodes sent that information.
This protocol should keep both node-announcement messages *and* route
request messages highly localized.
Thoughts?
~BT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170821/c3f18091/attachment-0001.html>

- reply

- reply

- reply

- reply

📅 Original date posted:2023-01-31
🗒️ Summary of this message: A proposal for a wallet vault without requiring key deletion involves creating an N-of-N multisig address and pre-signing transactions with N-1 keys to an address with timelocked spend paths.
📝 Original message:Ah good to know someone's put work into this kind of idea. Thanks for the
reference!
On Thu, Jan 26, 2023 at 8:31 AM darosior <darosior at protonmail.com> wrote:
> Hello Billy,
>
> Yes it's basically a (simple) instantiation of Revault. You can find more
> at https://github.com/revault (you most likely want the
> `practical-revault` repo). There is a description of the concept, the
> specification of a communication protocol between the participants as well
> as the implementation of the whole.
>
> Such a design presents some advantages, but it has two major issues:
>
> - You need to make sure all your watchtowers received the Cancel
> signature before you sign the Unvault transaction. But how can you get this
> guarantee in the usual (and reasonable) model of an untrusted laptop?
> - You can only have policies on the Unvault transaction (eg "You can
> only Unvault up to X BTC during working hours"), not on the Spend
> transaction (eg "You can only send coins to a Script with pubkey Y required
> in all spending paths"). Revault allows to use cosigning servers that act
> as anti-replay oracles to have policies on the spend, but this is obviously
> *very* suboptimal.
>
>
> Both issues are solvable with covenants.
>
> Antoine Poinsot
> ------- Original Message -------
> Le lundi 23 janvier 2023 à 6:39 PM, Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
> In the discussion around James' OP_VAULT proposal, it was implied that
> precomputed vaults must use ephemeral keys that must be deleted as part of
> the vaulting protocol, like Bryan Bishop's proposal
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html>.
> Looking around, I haven't been able to find any wallet vault proposal that
> doesn't require ephemeral keys, so at the risk of posting something that's
> obvious to everyone, I wanted to share a simple way to do a wallet vault
> without requiring any key deletion.
>
> The basic idea is to create an N-of-N multisig address, and pre-sign some
> transactions from it with N-1 keys to an address with several timelocked
> spend paths. This has the fallback that funds can always be spent
> immediately if you use all the keys, just like a normal N-of-N multisig
> address (since that's what it is at its core), but the usage of any of the
> pre-signed transactions leads to an address that guarantees a clawback
> within a time window. Here's a 3-of-3 example:
>
> *Vault Initialization*:
> 1. Create 3 of 3 Vault Address
> 2. Create an Interim Address that can send with:
> * 1 of 3 keys after a timelock of 1 month
> * 2 of 3 keys after a timelock of 1 week
> * 3 of 3 keys with no timelock
>
> *Vaulting*:
> 1. Create a transaction sending an output to the Vault Address
> 2. Create a transaction spending that Vault Address output to the Interim
> Address
> 3. Presign one copy of the step-2 transaction for each of the three
> combinations of two keys.
> 4. Store seeds separately, store the wallet config as well as the three
> presigned transactions with each seed.
>
> *Unvaulting*:
> 1. Sign one of the pre-signed transactions with the missing signature.
> 2. Broadcast
> 3. Wait the appropriate timelock for the number of keys you want to sign
> with.
> 4. Create a transaction sending from the Interim Address.
> 5. Broadcast
>
> *Recovering *(after unvaulting step 2 after the broadcasted transaction
> to the Interim Address has been mined):
> 1. Sign the utxo with all three keys to any destination. Alternatively
> sign with two keys, wait 1 week.
> 2. Broadcast it
>
> This has the usual downsides of pre-signed vaults that you need to backup
> these transactions for each vaulting, complications involving the
> flexibility (or lack thereof) of fees, and inflexibility in how much to
> unvault (must be the whole utxo, no change). This could of course be
> augmented with various techniques to make fee handling more flexible
> (anchor outputs, multiple versions of the presigned transactions with
> different fees, etc). More complicated presigning schemes could allow for
> some flexibility in unvaulting amount (eg by sending change back into the
> vault, and creating additional pre-signed transactions for that new output).
>
> It also has the same downside that OP_CTV vaults have, where a stolen key
> can steal funds from the interim address by racing the owner with their own
> transaction once the necessary delay has passed. Note that James' OP_VAULT
> opcode wouldn't have this problem.
>
> But not requiring any toxic waste keys seems like a pretty good benefit
> over Bryan Bishop's original proposal.
>
> Anyways sorry if this was already on people's radar and just too obvious
> to post about.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/3f850526/attachment.html>

2023-06-07 23:18:41

- reply

📅 Original date posted:2023-01-23
🗒️ Summary of this message: A simple way to create a wallet vault without requiring key deletion is to create an N-of-N multisig address and pre-sign transactions from it with N-1 keys.
📝 Original message:In the discussion around James' OP_VAULT proposal, it was implied that
precomputed vaults must use ephemeral keys that must be deleted as part of
the vaulting protocol, like Bryan Bishop's proposal
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html>.
Looking around, I haven't been able to find any wallet vault proposal that
doesn't require ephemeral keys, so at the risk of posting something that's
obvious to everyone, I wanted to share a simple way to do a wallet vault
without requiring any key deletion.
The basic idea is to create an N-of-N multisig address, and pre-sign some
transactions from it with N-1 keys to an address with several timelocked
spend paths. This has the fallback that funds can always be spent
immediately if you use all the keys, just like a normal N-of-N multisig
address (since that's what it is at its core), but the usage of any of the
pre-signed transactions leads to an address that guarantees a clawback
within a time window. Here's a 3-of-3 example:
*Vault Initialization*:
1. Create 3 of 3 Vault Address
2. Create an Interim Address that can send with:
* 1 of 3 keys after a timelock of 1 month
* 2 of 3 keys after a timelock of 1 week
* 3 of 3 keys with no timelock
*Vaulting*:
1. Create a transaction sending an output to the Vault Address
2. Create a transaction spending that Vault Address output to the Interim
Address
3. Presign one copy of the step-2 transaction for each of the three
combinations of two keys.
4. Store seeds separately, store the wallet config as well as the three
presigned transactions with each seed.
*Unvaulting*:
1. Sign one of the pre-signed transactions with the missing signature.
2. Broadcast
3. Wait the appropriate timelock for the number of keys you want to sign
with.
4. Create a transaction sending from the Interim Address.
5. Broadcast
*Recovering *(after unvaulting step 2 after the broadcasted transaction to
the Interim Address has been mined):
1. Sign the utxo with all three keys to any destination. Alternatively sign
with two keys, wait 1 week.
2. Broadcast it
This has the usual downsides of pre-signed vaults that you need to backup
these transactions for each vaulting, complications involving the
flexibility (or lack thereof) of fees, and inflexibility in how much to
unvault (must be the whole utxo, no change). This could of course be
augmented with various techniques to make fee handling more flexible
(anchor outputs, multiple versions of the presigned transactions with
different fees, etc). More complicated presigning schemes could allow for
some flexibility in unvaulting amount (eg by sending change back into the
vault, and creating additional pre-signed transactions for that new output).
It also has the same downside that OP_CTV vaults have, where a stolen key
can steal funds from the interim address by racing the owner with their own
transaction once the necessary delay has passed. Note that James' OP_VAULT
opcode wouldn't have this problem.
But not requiring any toxic waste keys seems like a pretty good benefit
over Bryan Bishop's original proposal.
Anyways sorry if this was already on people's radar and just too obvious to
post about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230123/eb519e3d/attachment.html>

2023-06-07 23:18:34

- reply

📅 Original date posted:2023-01-19
🗒️ Summary of this message: OP_UNVAULT can be used as a not-so-simple covenant with arbitrary conditions set on spending the utxo to the "recovery address," making it a general CTV-like covenant.
📝 Original message:That's an interesting mechanism. Since the goal of OP_VAULT was to avoid
being another general covenant proposal, that avenue could be blocked by
requiring that for a transaction spending a utxo with a script using
OP_UNVAULT, the script (or taproot tree) must *only* contain that one
opcode call (perhaps with an escape hatch that OP_UNVAULT turns into a NOOP
if that constraint isn't satisfied). If no other conditions can be placed
on the utxo, then the only relevant condition is the delay (and the
prescribed output targets).
Even with this restriction, it could be used for Jeremy Rubin's congestion
control transactions, which just commits to a list of future outputs, to be
sent when the fee environment is cheaper.
However, James mentioned adding <recovery-params> that includes a
scriptPubKey for authorizing recovery. With that addition, OP_UNVAULT can
be used to do more general covenants by making `unvault-target-hash`
unsatisfiable (set to some random number that isn't derived from a hash)
the delay wouldn't matter, but arbitrary conditions can be set on spending
the utxo to the "recovery address" which could be another OP_UNVAULT. It
seems like that could be used as a general CTV-like covenant.
On Fri, Jan 13, 2023 at 2:04 PM Ben Carman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi list,
>
> After reading through James's OP_VAULT proposal this week, I had a realization that this can be used for more than a deep cold storage wallet.
>
> Instead of vaulting and unvaulting, we can just send to a OP_UNVAULT output.
> When using OP_UNVAULT if we set the `recovery-spk-hash` to a burn address (ie OP_RETURN `<random value>`)
> and the `delay-period` to `0` we can use it as a not-so simple covenant with the `unvault-target-hash` being
> set to whatever output restrictions you want to create.
>
> Given this we can recreate a lot of what CTV promises, one of my favorites being
> [Lloyd's improvement to DLCs](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html)
> (I recommend reading that first)
>
> A similiar construction could be done by creating a taproot tree similiar to LLoyd's construction with each leaf looking like:
>
> `<hash-of-burn-spk> 0 <CET-hash_i> OP_UNVAULT <CET_i> CHECKSIG`
>
> In the same as Lloyd's proposal: when the oracle(s) reveals their attestations either party can combine them to get the secret key corresponding to `CET_i` and spend the coins to the CET (whose `unvault-target-hash`
> hash is `CET-hash`) which distributes the funds according to the contract.
>
> ## Comparison
>
> Compared to the original CTV proposal, this *should *get all the same computational savings. However, it would use more blockchain space.
>
> The main downside I see is our final spending script will be slightly larger.
> Instead of just having `<hash> OP_CTV` it will be replaced with `<hash> 0 <hash> OP_UNVAULT` (34 bytes extra, not including the witness discount).
> However, this may be negligible in the case of a DLC with many outcomes as a lot of the input size will be coming from the control block.
> This also can always be skipped by doing a cooperative close of the DLC if the internal-key of the taproot tree can be spent using something like MuSig.
>
> I imagine a lot of the other applications for CTV can be recreated with OP_VAULT using this same trick.
>
> # Credits
>
> - Lloyd Fournier for the original proposal
> - James O'Beirne for the OP_VAULT proposal and giving me the idea to skip the intial OP_VAULT and just use OP_UNVAULT
>
>
>
> Best,
>
> benthecarman
>
> _______________________________________________
> 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/20230119/ca21c32f/attachment-0001.html>

2023-06-07 23:18:24

- reply

📅 Original date posted:2023-01-19
🗒️ Summary of this message: OP_VAULT can be gated by a scriptPubKey, making it a general covenant. Combining otherwise-spendable utxos adds complexity to downstream code and usability. Consideration needed for complexity vs. reasonably bound fees.
📝 Original message:>> It would usually be prudent to store this recovery address with every key
to the vault, ...
> Worth noting now that in OP_VAULT the recovery path can be optionally
gated by an arbitrary scriptPubKey.
Gating by a scriptPubKey solves the problem I was talking about there.
However, thinking about it more, I realized doing this basically turns
OP_VAULT into something able to do general covenants. By making
`unvault-target-hash`
unsatisfiable (set to some random number that isn't derived from a hash)
the delay wouldn't matter, but arbitrary conditions can be set on spending
the utxo to the "recovery address" which could be another OP_UNVAULT
destination. It seems like that could be used as a general CTV-like
covenant.
>> Wouldn't it be reasonably possible to allow recovery outputs with any
>> recovery address to be batched, and the amount sums sent to each to be
>> added up and verified?
> I think the space savings from this is pretty negligible
Besides space savings, there's the consideration of the usability of the
vault and downstream code complexity. One of the criteria I designed the
"efficient wallet vaults" opcodes for is that the vault spend should be
spendable in situations where a normal output is spendable as much as
possible. Having a constraint that prevents one type of otherwise spendable
output from being combined with another type would add complexity to all
downstream code which now has to have special cases - either a simple error
and recovery if they just want to disallow that type of opcode being
combined with other types (which may degrade the user experience by asking
them to provide a different utxo or do an unvaulting first), or some kind
of special case handling to make it work. Any kind of hybrid wallet
incorporating a vault (eg a wallet that combines a vault and a hot address
or lightning channel, kind of like Phoenix combines a lightning channel and
a normal onchain wallet) would need to deal with this kind of extra
complexity during utxo selection.
Are there currently any situations where one otherwise-spendable utxo can't
be mixed with another? If not, this added edge case deserves some extra
consideration I think.
> I can imagine there might be a mechanism where you include a payout
output to some third party in a drafted unvault trigger transaction, and
they provide a spend of the ephemeral output.
I agree that's doable. I just think it merits some consideration as to
whether that complexity (both for downstream code and for users) is a
favorable trade off vs having a solution to reasonably bound fees spendable
from the vault.
Consider the case where a self-custodying user would have a small set of
keys (2? 3?) and use all those keys to secure their vault, and just 1 of
them to secure their hot wallet. It doesn't seem an implausible case and I
could imagine that kind of set up becoming quite common. In such a case, if
the hot wallet key is stolen, it means one vault key is also stolen and the
hot wallets funds could be stolen at the same time as an unvaulting is
triggered. The need to figure out how to coordinate a 3rd party's help to
recover is at best an added difficulty and delay.
An alternative would be to keep a completely separate hot wallet key that
isn't use as part of the vault. But because key storage is by far the most
difficult and costly part of self-custody, every additional key that needs
to be stored is a significant additional burden (that's one of the benefits
of wallet vaults - fewer seeds needed for a given amount of
security/redundancy).
Another alternative would be to have a hot wallet that for its primary
spend-path uses a memory-only passphrase on one of the vault seeds (so
compromise of a vault seed won't compromise the hot wallet) and has a
recovery spend path that uses multiple (or all) vault seeds to recover if
you forget the passphrase. It certainly seems like something can be worked
out here to make the end user experience reasonable, but the additional
operational complexity this would entail still deserves consideration.
>> OP_BEFOREBLOCKVERIFY
> I think this breaks fundamental reorgability of transactions.
I discuss this in the Reorg Safety section here
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#reorg-safety>
.
>> This is done by using a static intermediate address that has no values
>> that are unique to the particular wallet vault address.
> Does mean .. that (ii) .. in order to be batch unvaulted [with dynamic
unvaulting
targets], vaulted
> coins need to first be spent into this intermediate output?
It does support dynamic unvaulting using OP_PUSHOUTPUTSTACK
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>,
which adds data to an output that carries over to the execution when
spending the output created by a utxo that uses OP_PUSHOUTPUTSTACK. So the
design is done such that once the intermediate output has been confirmed
and the unvaulting delay has passed, it is then fully owned by the
recipient without a second transaction (because of the use of
OP_BEFOREBLOCKVERIFY). If OP_BEFOREBLOCKVERIFY is deemed to be
unacceptable, then the intermediate output is fully intermediate and a 2nd
transaction would be required to get it to its committed recipient.
> it'd be valuable to see a full implementation
While OP_BEFOREBLOCKVERIFY can be dropped with only somewhat minor degraded
usability, OP_PUSHOUTPUTSTACK is necessary for the proposal to work as
intended. I would want to see some support for the high-level concepts it
introduces before spending significant time on an implementation. It does
something fundamentally new that other opcodes haven't done: add "hidden"
data onto the output that allows for committing to destination addresses.
Maybe something along the line of Greg Sanders' suggestion for your
proposal could replace the need for this, but I'm not sure its possible
with how OP_CD is designed.
On Wed, Jan 18, 2023 at 5:38 PM James O'Beirne <james.obeirne at gmail.com>
wrote:
> > I don't see in the write up how a node verifies that the destination
> > of a spend using an OP_VAULT output uses an appropriate OP_UNVAULT
> > script.
>
> It's probably quicker for you to just read through the
> implementation that I reference in the last section of the paper.
>
>
> https://github.com/bitcoin/bitcoin/blob/fdfd5e93f96856fbb41243441177a40ebbac6085/src/script/interpreter.cpp#L1419-L1456
>
> > It would usually be prudent to store this recovery address with every
> > key to the vault, ...
>
> I'm not sure I really follow here. Worth noting now that in OP_VAULT the
> recovery path can be optionally gated by an arbitrary scriptPubKey.
>
> > This is rather limiting isn't it? Losing the key required to sign
> > loses your recovery option.
>
> This functionality is optional in OP_VAULT as of today. You can specify
> OP_TRUE (or maybe I should allow empty?) in the <recovery-params> to
> disable any signing necessary for recovery.
>
> > Wouldn't it be reasonably possible to allow recovery outputs with any
> > recovery address to be batched, and the amount sums sent to each to be
> > added up and verified?
>
> I think the space savings from this is pretty negligible, since you're
> just saving on the transaction overhead, and it makes the implementation
> decently more complicated. One benefit might be sharing a common
> fee-management output (e.g. ephemeral anchor) across the separate vaults
> being recovered.
>
> > If someday wallet vaults are the standard wallet construct, people
> > might not even want to have a non-vault wallet just for use in
> > unvaulting.
>
> If you truly lacked any non-vaulted UTXOs and couldn't get any at a
> reasonable price (?), I can imagine there might be a mechanism where you
> include a payout output to some third party in a drafted unvault trigger
> transaction, and they provide a spend of the ephemeral output.
>
> Though you do raise a good point that this construction as written may
> not be compatible with SIGHASH_GROUP... I'd have to think about that
> one.
>
> > Hmm, it seems inaccurate to say that step is "skipped". While there
> > isn't a warm wallet step, its replaced with an OP_UNVAULT script step.
>
> It is "skipped" in the sense that your bitcoin can't be stolen by having
> to pass through some intermediate wallet during an authorized withdrawal
> to a given target, in the way that they could if you had to prespecify
> an unvault target when creating the vault.
>
>
> ---
>
>
> > My proposal for efficient wallet vaults was designed to meet all of
> > those criteria, and allows batching as well.
>
> Probably a discussion of your proposal merits a different thread, but
> some thoughts that occur:
>
>
> > [from the README]
> >
> > OP_BEFOREBLOCKVERIFY - Verifies that the block the transaction is
> > within has a block height below a particular number. This allows a
> > spend-path to expire.
>
> I think this breaks fundamental reorgability of transactions. I think
> some of the other opcodes, e.g the one that limits fee contribution on
> the basis of historical feerate, are going to be similarly
> controversial.
>
> > This is done by using a static intermediate address that has no values
> > that are unique to the particular wallet vault address.
>
> Does mean either that (i) this proposal doesn't have dynamic unvaulting
> targets or, (ii) if you do, in order to be batch unvaulted, vaulted
> coins need to first be spent into this intermediate output?
>
> It sounds like (ii) is the case, given that your unvault target
> specification lives in (I think?) the witness for the spend creating the
> intermediate output.
>
> If the intermediate address doesn't have any values which are unique to
> a particular vault, how do you authorize recoveries from it?
>
> ---
>
> Personally I think if you'd like to pursue your proposal, it'd be
> valuable to see a full implementation. Might also make it easier to
> assess the viability of the proposal.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230119/acfb7455/attachment-0001.html>

2023-06-07 23:18:22

- reply

📅 Original date posted:2023-01-18
🗒️ Summary of this message: Proposal for efficient wallet vaults using a targeted wallet vault opcode, allowing batching and single transaction sending, but with potential issues regarding recovery path security.
📝 Original message:I like the proposal of a targeted wallet vault opcode. It keeps things
constrained, limiting objections to those of the form "but if we had X it
would do all this and more so why add this complexity when it will be
obsoleted in the future?"
> An idealized vault
> no existing vault design meets this set of features.
My proposal for efficient wallet vaults
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> was designed
to meet all of those criteria, and allows batching as well. It also allows
sending in a single transaction vs the two it would take with OP_VAULT and
several other benefits. However, it uses a general covenant opcode to do
it, along with several other new opcodes specified in that write up.
> it must first be spent into an OP_UNVAULT output
I don't see in the write up how a node verifies that the destination of a
spend using an OP_VAULT output uses an appropriate OP_UNVAULT script. I see
you mentioned above (but not in the write up) that the script pub key needs
to be bare. But it would be very helpful if you detailed exactly how this
is intended to be done in that document.
It seems that Greg Sanders noticed the same thing. I like his suggestion as
you reworded it above, makes a lot of sense.
> I think the fix is just requiring a single additional witness data item
during OP_VAULT spend (for unvault path), mandating the
<target-outputs-hash> to be included in the witness stack as an input to
OP_VAULT opcode, and transaction introspection then checks to make sure the
witness item and the corresponding output script template matches the
expected.
> If it becomes necessary to make use of the recovery path, the recovery
scriptPubKey will be revealed, which means that any other vaults with that
recovery path may be swept there by an unauthenticated party.
Another issue is that the recovery path becomes the easiest mechanism of
attack. It would usually be prudent to store this recovery address with
every key to the vault, and potentially in other places as well, so as to
minimize the possibility that the funds are lost or stolen. In such a
situation, this means that an attacker that finds any key can grief the
vault by spending it to its recovery address. My "efficient wallet vault"
design I mentioned above doesn't have this issue, nor the associated
batching DoS attack.
> if the recovery path should be committed with a signature
> This would enable a "sign-to-recover" flow at the option of the user,
specified during vault creation.
This is rather limiting isn't it? Losing the key required to sign loses
your recovery option. Seems brittle. It seems better to me to include a
<recovery-initiation-spk-hash> that operates similarly to
<recovery-spk-hash> - where some arbitrary script must be fulfilled to
allow the recovery path to be spent. For a recovery path, you'd probably
often want one of the keys required to spend from the recovery address,
since without access to one of those keys, you can't spend from the
recovery address anyway (and the spend path is an effective burn). Having
some ability to allow an n-of-m situation for triggering the recovery path
seems desirable.
> What do you think about the idea of making the recovery-path
authorization behavior variable on a single byte flag preceding the 32 byte
data push, as I mentioned in another post?
A more arbitrary construct here that allows you to use any kind of recovery
script would be much more flexible and preclude the need for any kind of
switching like this. It seems like it would also solve the issue Andrew
Chow mentioned where recovery transactions can only be batched if they all
share the same recovery output, since each output can simply include the
appropriate witness matching its recovery scriptPubkey.
Tho I don't think I quite understand why you mention the constraint
requiring recovery batching to only be done with vault outputs that have
matching recovery destinations. Wouldn't it be reasonably possible to allow
recovery outputs with any recovery address to be batched, and the amount
sums sent to each to be added up and verified?
> 1. script validation rules could require some allowable “range” of
amount discounts
> seems like a bad design
> 2. script validation rules could require that the unvault/recovery
outputs preserve the full value
> seems like the preferable approach
Both have tradeoffs. I would not call #1 an inherently bad design. I would
point out that for 2, disallowing the spending of vault funds without
access to already-unvaulted bitcoin seems like a very inconvenient design,
since it would require you in the best of cases to create more complex
transactions (or cpfp transaction chains) involving a 2nd wallet that you
involve in the unvaulting process, and in the worst case (if you have no
other bitcoin or other money on hand) you have to go asking a 3rd party for
their bitcoin to use in the unvaulting process. If someday wallet vaults
are the standard wallet construct, people might not even want to have a
non-vault wallet just for use in unvaulting.
#1 is the approach I used to design OP_LIMITFEECONTRIBUTION
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/lfc/bip-limit-fee-contribution.md>,
which allows for a fee-range specification that depends on recent median
fees included in blocks. This allows rather flexibly limiting fees to a
particular range of "priorities" regardless of fee environment.
For #2, it seems like Jeremy Rubin's Sponsor transactions would be ideal
for facilitation of adding a fee to an unvaulting transaction.
> In the case of a withdrawal, unvaulted funds can skip the “warm” wallet
step that precomputed vault funds must pass through on their way to
destinations only known at unvault time.
Hmm, it seems inaccurate to say that step is "skipped". While there isn't a
warm wallet step, its replaced with an OP_UNVAULT script step. So its not
skipped as much as modified I think, right?
It looks like the way the OP_UNVAULT is specified prevents any use where
you don't know the full set of outputs, which might happen in cases where
certain sighash flags might be useful (signing some outputs you know, but
allowing outputs that you don't know to be added later). This is another
thing my "efficient wallet vault" design should allow.
On Tue, Jan 17, 2023 at 1:47 AM Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Jan 16, 2023 at 11:47:09PM +0000, Andrew Chow via bitcoin-dev
> wrote:
> > It seems like this proposal will encourage address reuse for vaults,
>
> (That is listed as an explicit goal: "A single vault scriptPubKey should
> be able to "receive" multiple deposits")
>
> > However the current construction makes it impossible to spend these
> > vaults together. Since OP_VAULT requires the recovery script of the
> > unvault output to match what's provided in the input,
>
> I don't think this part is a big problem -- the recovery path requires
> revealing a secret, but if you separate that secret from the recovery
> path sPK, you could vary the secret. ie:
>
> unvault1 delay recovery1 VAULT
> unvault2 delay recovery2 VAULT
>
> where recovery1 = SHA256(SHA256(secret1), rSPK) and recovery2 =
> SHA256(SHA256(secret2), rSPK), and both are spendable when the top stack
> element is secretN and the first output pays at least the sum of all
> the OP_VAULT using inputs to rSPK. So batched recovery could work fine,
> I think.
>
> (If you're using the same "recovery" parameter to each VAULT, then
> you're revealing which txs are in your vault at spend time, rather than
> at receive time, which doesn't seem all that much better to me)
>
> But the problem with this is it prevents you from combining vaults when
> spending normally: so if you've got a bunch of vaults with 1 BTC each,
> and want to spend 10 BTC on a house, you'll need to make 11 separate
> transactions:
>
> * 10 txs each spending a single vault utxo, satisfying
> <uN> <delay> <rN> OP_VAULT
> via the uN path, creating an output of
> <outhash> <delay> <rN> OP_UNVAULT
>
> * 1 tx spending all the OP_UNVAULT outputs to a common set of outputs
> <uN>, with nSequence set to a relative timelock of at least <delay>
>
> Whereas if you use an identical OP_VAULT script for all the utxos in
> your vault, that can look like:
>
> * 1 tx, spending all the vault utxos, to a single OP_UNVAULT output,
> with the same <delay> <rN> that all the inputs share.
>
> * 1 tx spending the OP_UNVAULT output after a delay
>
> But maybe you can get the best of both worlds just by having the unvault
> path for OP_VAULT require you to put the vout number for its corresponding
> OP_UNVAULT output on the stack? Then if you're doing address reuse, you
> use a single vout for multiple inputs; and if you're avoiding address
> reuse, you use multiple outputs, and provide the mapping between inputs
> and outputs explicitly.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230118/17d1061b/attachment.html>

2023-06-07 23:18:04

- reply

📅 Original date posted:2023-01-04
🗒️ Summary of this message: tionary Bitcoin relies heavily on coinbase rewards for security, with fees making up only a small portion. The cost of a 50% attack is currently less than $7 billion, but if Bitcoin's security needs increase to $2 trillion, a price of $4.3 million/bitcoin would be required. The fee market may grow superlinearly as Bitcoin adoption increases, making high levels of security more realistic.
📝 Original message:> In Bitcoin "the show must go on" and someone must pay for it. Active
[and/or] passive users
I certainly agree.
> or more precisely: tiny inflation
👍
> Right now security comes from almost fully from ~1.8% inflation.
Best I could find, fees make up about 13% of miner revenue
<https://decrypt.co/57740/bitcoin-miners-now-earn-1-btc-in-fees-per-block>.
So yes, the vast majority of security comes from coinbase rewards. I assume
you're implying that ~13% of today's security is not enough? I would love
to see any quantitative thoughts you have on how one might determine that.
Have there been any thoughts put out in the community as to what size of
threat is unlikely enough to arise that we don't need to worry about it?
Maybe 1% of the yearly government budgets
<https://en.wikipedia.org/wiki/List_of_countries_by_government_budget> of
the world would be an upper bound on how much anyone would expect could
realistically be brought to bear? Today that would be maybe around $350
billion.
Or perhaps a better way to estimate would be calculating the size of the
motivation of an attacker. For example, this paper
<https://files.stlouisfed.org/files/htdocs/publications/review/92/03/Seigniorage_Mar_Apr1992.pdf>
seems
to conclude that the US government was extracting a maximum of ~$20
billion/year in 1982 dollars (so maybe $60 billion/year in 2022 dollars if
you go by CPI). If we scale this up to the entire world of governments,
this seems like it would place an upper bound of $180 billion/year of
seigniorage extraction that would be at risk if bitcoin might put the
currencies they gain seigniorage from out of business. Over 10 years (about
as far as we can expect any government to think), that's almost $2
trillion.
Whereas it would currently cost probably less than $7 billion to purchase a
50% share of bitcoin miners. To eventually reach a level of $350 billion,
bitcoin's price would need to reach about $800,000 / bitcoin. That seems
within the realm of possibility. To reach a level of $2 trillion, you'd
need a price of $4.3 million/bitcoin. That's still probably within the
realm of possibility, but certainly not as likely. If you then assume we
won't have significant coinbase rewards by that point, and only 13% of the
equivalent revenue (from fees) would be earned, then a price of ~$6 million
would be needed to support a $350 billion and $34 million to support a $2
trillion security. I think that second one is getting up towards the realm
of impossibility, so if we think that much security is necessary, we might
have to rethink things. Its also quite possible, as the network of people
who accept and use bitcoin as payment grows, that the fee market will grow
superlinearly in comparison to market cap, which would make these kind of
high levels of security more realistic.
Anyways if it turns out that fees alone don't look like they're supporting
enough security, we have a good amount of time to come to that conclusion
and do something about it.
> Deflation in Bitcoin is not 1:1 matter like in gold, for example...
Deflation in Bitcoin is more complex issue
It's helpful to keep our language precise here. Price inflation and
deflation act identically in bitcoin and gold and anything else. What you
seem to be talking about at this point is monetary inflation (specifically,
a reduction in it) which of course operates differently on the machinery of
bitcoin than it does in the machinery of gold or other things. Whereas my
comment about you mentioning Gresham's law was specifically talking about
price inflation, not the effects of the coin emission machinery in bitcoin.
On Mon, Jan 2, 2023 at 5:02 PM <jk_14 at op.pl> wrote:
>
>
> Right now security comes from almost fully from ~1.8% inflation.
> In November mempool was inflated to ~150MB and people were rather waiting
> for cheap transactions back.
> Instead of being happy that system is closer for a while to default
> working area.
>
> Deflation in Bitcoin is not 1:1 matter like in gold, for example.
> If all plain gold available to mine would be finished - gold mines as
> unprofitable enterprices are immediately closed.
> And it doesn't affect security of gold already in circulation.
> In Bitcoin "the show must go on" and someone must pay for it.
> Active and passive users together (balanced by market play) or: only
> active users (in current scenario, long-term).
>
> Deflation (or more precisely: tiny inflation) in Bitcoin is more complex
> issue with more repercussions than in gold.
> In case of drop of network security - the tax will be paid anyway, in
> Bitcoin price.
> So, there is an self-regulating mechanism here. The harsh one, but still.
>
>
>
> W dniu 2023-01-02 05:53:57 użytkownik Billy Tetrud <billy.tetrud at gmail.com>
> napisał:
> > is surely better than not delaying it.
>
> I might agree, but I don't think it really solves the problem well enough
> to be worth it. Any solution that would solve the problem better would make
> delaying halvings unnecessary.
>
> > there is non-zero risk that people will hoard it more and more,
> according to old Gresham's law
>
>
> Gresham's law doesn't apply here. Gresham's law is about the interaction
> between two currencies with a fixed, usually government-enforced exchange
> rate. You seem to be saying that Bitcoin will be hoarded because Bitcoin
> inflation reduces every halving. But even with 0 inflation, it certainly
> won't cause all Bitcoin to be hoarded. Also, "hoarding" is also known as
> "saving", and there's nothing wrong with saving. The spectre of deflation
> comes from a misunderstanding of deflation and why it happens during bad
> economic times. It is an effect, not a cause.
>
>
> On Sun, Jan 1, 2023, 15:23 <jk_14 at op.pl> wrote:
>
> Yes, the idea is:
> if mining activity is growing - let's execute consecutive halvings
> but if miner exodus has happened - let's delay next halving until mining
> activity is recovered to previous levels
>
> If it gets to the point where a sudden drop in mining difficulty happens -
> delaying the next halving may be not sufficient to correct, but is surely
> better than not delaying it.
>
> While Bitcoin is better and better money with every halving in comparision
> to other types of money - there is non-zero risk that people will hoard it
> more and more, according to old Gresham's law ("HODL"). And this way
> decreasing liquidity / transactions volume. The positive feedback loop - is
> my real concern here.
>
> Regarding the relationship between difficulty and security - I fully agree.
> But ASIC technology is already matured. And also any technology
> breakthrough is a short event within 4 years period.
> So growth of difficulty could be gained by technology breakthrough, but
> any sudden drop of difficulty would be always an issue, while there is no
> such thing as: ASIC technology regression.
>
> Obviously, not complicated solution would be better than complicated one.
>
>
>
>
> W dniu 2022-12-30 19:21:10 użytkownik Billy Tetrud <billy.tetrud at gmail.com>
> napisał:
> If the idea is to ensure that a catastrophic miner exodus doesn't happen,
> the "difference" you're calculating should only care about downward
> differences. Upward differences indicate more mining activity and so
> shouldn't cause a halving skip.
>
>
> But I don't think any scheme like this that only acts on the basis of
> difficulty will be sufficient. If it gets to the point where a sudden drop
> in mining difficulty happens, it is very likely that simply delaying the
> next halving or even ending halving all together will not be sufficient to
> correct for whatever is causing hashrate to tank. There is also the danger
> of simple difficulty stagnation, which this mechanism wouldn't detect.
>
>
> The relationship between difficulty and security becomes less and less
> predictable the longer you want to look ahead. There's no long term
> relation between difficulty and any reasonable security target. A security
> target might be something like "no colluding group with less than $1
> trillion dollars at their disposal could successfully 51% attack the
> network (with a probability of blah blah)". There is no way to today
> program in any code that detects based on difficult alone when that
> criteria is violated. You would have to program in assumptions about the
> cost of hashrate projected into the future.
>
>
> I can't think of any robust automatic way to do this. I think to a certain
> degree, it will have to be a change that happens in a fork of some kind
> (soft or hard) periodically (every 10 years? 30 years?). The basic
> relations needed is really the cost in Bitcoin of the security target (ie
> the minimum number of Bitcoin it should take to 51% attack the system) and
> the cost in Bitcoin of acquiring a unit of hashrate. This could be simply
> input into the code, or could use some complicated oracle system. But with
> that relation, the system could be programmed to calculate the difficulty
> necessary to keep the system secure.
>
>
> Once that is in place, the system could automatically adjust the subsidy
> up or down to attract more or less miners, or it could adjust the block
> size up or down to change the fee market such that more or less total fees
> are collected each block to attract more or less miners.
>
>
> On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> It seems like the more elegant solution could be by using a chainwork
> parameter instead.
> i.e. comparison just before halving - if the last 210,000 block interval
> has a higher chainwork difference between the begining and the end of
> interval
> than any other such inter-halving interval before.
>
> LIttle digression yet:
> A system in which all users participate in ensuring its security looks
> better than one in which only some (i.e. active) of them participate (and
> passive stakeholders are de facto free riders)
> In my opinion this concept above is only the complement of currently
> missing mechanism: achieving equilibrium regarding costs of security
> between two parties with opposing interests.
> It's easy to understand and - most important - it has no hardcoded value
> of tail emission - what is the clear proof it is based on a free market.
> And last but not least, if someone is 100% sure that income from
> transactions will takeover security support from block subsidy - accepting
> such proposal is like putting the money where the mouth is: this safety
> measure will never be triggered, then (no risk of fork)
>
>
> Best Regards
> Jaroslaw
>
>
>
> W dniu 2022-12-23 20:29:20 użytkownik Jaroslaw via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> napisał:
> >
> Necessary or not - it doesn't hurt to plan the robust model, just in case.
> The proposal is:
>
> Let every 210,000 the code calculate the average difficulty of 100 last
> retargets (100 fit well in 210,000 / 2016 = 104.166)
> and compare with the maximum of all such values calculated before, every
> 210,000 blocks:
>
>
> if average_diff_of_last_100_retargets >
> maximum_of_all_previous_average_diffs
> do halving
> else
> do nothing
>
>
> This way:
>
> 1. system cannot be played
> 2. only in case of destructive halving: system waits for the recovery of
> network security
>
>
> Best Regards
> Jaroslaw
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230104/dfb173d9/attachment-0001.html>

2023-06-07 23:18:01

- reply

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

2023-06-07 23:17:58

- reply

📅 Original date posted:2022-12-30
📝 Original message:If the idea is to ensure that a catastrophic miner exodus doesn't happen,
the "difference" you're calculating should only care about downward
differences. Upward differences indicate more mining activity and so
shouldn't cause a halving skip.
But I don't think any scheme like this that only acts on the basis of
difficulty will be sufficient. If it gets to the point where a sudden drop
in mining difficulty happens, it is very likely that simply delaying the
next halving or even ending halving all together will not be sufficient to
correct for whatever is causing hashrate to tank. There is also the danger
of simple difficulty stagnation, which this mechanism wouldn't detect.
The relationship between difficulty and security becomes less and less
predictable the longer you want to look ahead. There's no long term
relation between difficulty and any reasonable security target. A security
target might be something like "no colluding group with less than $1
trillion dollars at their disposal could successfully 51% attack the
network (with a probability of blah blah)". There is no way to today
program in any code that detects based on difficult alone when that
criteria is violated. You would have to program in assumptions about the
cost of hashrate projected into the future.
I can't think of any robust automatic way to do this. I think to a certain
degree, it will have to be a change that happens in a fork of some kind
(soft or hard) periodically (every 10 years? 30 years?). The basic
relations needed is really the cost in Bitcoin of the security target (ie
the minimum number of Bitcoin it should take to 51% attack the system) and
the cost in Bitcoin of acquiring a unit of hashrate. This could be simply
input into the code, or could use some complicated oracle system. But with
that relation, the system could be programmed to calculate the difficulty
necessary to keep the system secure.
Once that is in place, the system could automatically adjust the subsidy up
or down to attract more or less miners, or it could adjust the block size
up or down to change the fee market such that more or less total fees are
collected each block to attract more or less miners.
On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> It seems like the more elegant solution could be by using a chainwork
> parameter instead.
> i.e. comparison just before halving - if the last 210,000 block interval
> has a higher chainwork difference between the begining and the end of
> interval
> than any other such inter-halving interval before.
>
> LIttle digression yet:
> A system in which all users participate in ensuring its security looks
> better than one in which only some (i.e. active) of them participate (and
> passive stakeholders are de facto free riders)
> In my opinion this concept above is only the complement of currently
> missing mechanism: achieving equilibrium regarding costs of security
> between two parties with opposing interests.
> It's easy to understand and - most important - it has no hardcoded value
> of tail emission - what is the clear proof it is based on a free market.
> And last but not least, if someone is 100% sure that income from
> transactions will takeover security support from block subsidy - accepting
> such proposal is like putting the money where the mouth is: this safety
> measure will never be triggered, then (no risk of fork)
>
>
> Best Regards
> Jaroslaw
>
>
>
> W dniu 2022-12-23 20:29:20 użytkownik Jaroslaw via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> napisał:
> >
> Necessary or not - it doesn't hurt to plan the robust model, just in case.
> The proposal is:
>
> Let every 210,000 the code calculate the average difficulty of 100 last
> retargets (100 fit well in 210,000 / 2016 = 104.166)
> and compare with the maximum of all such values calculated before, every
> 210,000 blocks:
>
>
> if average_diff_of_last_100_retargets >
> maximum_of_all_previous_average_diffs
> do halving
> else
> do nothing
>
>
> This way:
>
> 1. system cannot be played
> 2. only in case of destructive halving: system waits for the recovery of
> network security
>
>
> Best Regards
> Jaroslaw
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221230/1890b675/attachment.html>

2023-06-07 23:17:08

- reply

📅 Original date posted:2022-12-13
📝 Original message:Re Verkle trees, that's a very interesting construction that would be super
useful as a tool for something like Utreexo. A potentially substantial
downside is that it seems the cryptography used to get those nice
properties of Verkle trees isn't quantum safe
<https://vitalik.ca/general/2021/06/18/verkle.html>. While a lot of things
in Bitcoin seems to be going down the path of quantum-unsafe (I'm looking
at you, taproot), there are still a lot of people who think quantum
safety is important in a lot of contexts.
On Thu, Dec 1, 2022 at 5:52 AM Salvatore Ingala via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Rijndael,
>
>
>
> On Wed, 30 Nov 2022 at 23:09, Rijndael <rot13maxi at protonmail.com> wrote:
>
>> Hello Salvatore,
>>
>> I found my answer re-reading your original post:
>> > During the arbitration phase (say at the i-th leaf node of M_T), any
>> party can win the challenge by providing correct values for tr_i = (st_i,
>> op_i, st_{i + 1}). Crucially, only one party is able to provide correct
>> values, and Script can verify that indeed the state moves from st_i to
>> st_{i + 1} by executing op_i. The challenge is over.
>>
> You are correct, the computation step encoded in a leaf needs to be simple
> enough for Script to verify it.
>
> For the academic purpose of proving completeness (that is, any computation
> can be successfully "proved" by the availability of the corresponding fraud
> proof), one can imagine reducing the computation all the way down to a
> circuit, where each step (leaf) is as simple as what can be checked with
> {OP_NOT, OP_BOOLAND, OP_BOOLOR, OP_EQUAL}.
>
> In practice, you would want to utilize Script to its fullest, so for
> example you wouldn't compile a SHA256 computation to something else – you'd
> rather use OP_SHA256 directly.
>
>
>> That raises leads to a different question: Alice initially posts a
>> commitment to an execution trace of `f(x) = y`, `x`, and `y`. Bob Disagrees
>> with `y` so starts the challenge protocol. Is there a commitment to `f`? In
>> other words, the dispute protocol (as I read it) finds the leftmost step in
>> Alice and Bob's execution traces that differ, and then rewards the coins to
>> the participant who's "after-value" is computed by the step's operation
>> applied to the "before value". But if the participants each present valid
>> steps but with different operations, who wins? In other words, Alice could
>> present [64, DECREMENT, 63] and Bob could present [64, INCREMENT, 65].
>> Those steps don't match, but both are valid. Is there something to ensure
>> that before the challenge protocol starts, that the execution trace that
>> Alice posts is for the right computation and not a different computation
>> that yields a favorable result for her (and for which she can generate a
>> valid merkle tree)?
>>
>
> The function f is already hard-coded in the contract itself, by means of
> the tree of scripts − that already commits to the possible futures.
> Therefore, once you are at state S14, you know that you are verifying the
> 6th step of the computation; and the operation in the 6th step of the
> computation depends solely on f, not its inputs. In fact, you made me
> realize that I could drop op_i from the i-th leaf commitment, and just
> embed the information in the Script of that corresponding state.
>
> Note that the states S0 to S14 of the 256x game are not _all_ the possible
> states, but only the ones that occurred in that execution of the contract
> (corresponding to a path from the root to the leaf of the Merkle tree of
> the computation trace), and therefore the ones that materialized in a UTXO.
> Different choices made by the parties (by providing different data, and
> therefore choosing different branches) would lead to a different leaf, and
> therefore to different (but in a certain sense "symmetric") states.
>
> ========
>
> Since we are talking about the fact that f is committed to in the
> contract, I'll take the chance to extend on this a bit with a fun
> construction on top.
> It is well-known in the academic literature of state channels that you can
> create contracts where even the function ("program", or "contract") is not
> decided when the channel is created.
>
> Since f is generic, we can choose f itself to be a universal Turing
> machine. That is, we can imagine a function f(code, data) that executes a
> program ("code") on the "data" given to it as input.
> Since we can do fraud proofs on statements "f(code, data) == output", we
> could build contracts where the "code" itself is chosen later.
>
> For example, one could build a universal state channel, where parties can
> enter any contract among themselves (e.g.: start playing a chess game)
> entirely inside the channel. The state of this universal channel would
> contain all the states of the individual contracts that are currently open
> in the channel, and even starting/closing contracts can happen entirely
> off-chain.
>
> I believe these constructions are practical (the code of universal Turing
> machines is not really complicated), so it might be worth exploring further
> to figure out useful applications of this approach (supercharging
> lightning?).
>
> We should probably start by implementing testnet rock-paper-scissors in
> MATT, though :)
>
> Best,
> Salvatore Ingala
> _______________________________________________
> 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/20221213/21e4f924/attachment-0001.html>

2023-06-07 23:13:10

- reply

📅 Original date posted:2022-08-27
📝 Original message:@Ali Thats some good well thought through and well articulated feedback. I
have one point of contention
> it's important that unnecessary types are kept out of the format. People
are known to leave files lying around on their computer that they don't
need anymore, so these files can find their way via telemetry to
surveillence entities. While we can't specify what users can do with their
exports, we can control the information leak by preventing certain types of
items that we know most users will never use from being exported in the
first place.
This seems to run contrary with your point about letting users be in
control of how they store this. Given that you can always connect together
an output and its address or find the outputs at any address, it doesn't
seem like it would actually leak any more information than just including
addresses. Am I missing something?
On Wed, Aug 24, 2022, 14:44 Ali Sherief via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Craig,
>
> This a really good proposal. I studied your BIP and I have some feedback
> on some parts of it.
>
> > The first line in the file is a header, and should be ignored on import.
>
> From past experience and lessons, most notably BIP39, it is important that
> a version byte is defined somewhere in case someone wants to extend it in
> the future, currently there is no version byte which someone can increment
> if somebody wants to extend it. In the unique case of CSV files, you should
> make the header line mandatory (I see you have already implied this, but
> you should make it explicit in the BIP), but instead of a line with columns
> in it, I suggest instead of Reference,Label, you make the format like this:
>
> BIP-wallet-labels,<version>
>
> Since there are two columns per record, this works out nicely. The first
> column can be the name of the BIP - BIPxxxx where the x's are numbers, and
> the second column can be an unsigned 32-bit integer (most significant 8
> bits reserved for version, the remaining for flags, or perhaps the entirety
> for version - but I recommend leaving at least some bits for flags, even if
> they all end up being just "reserved").
>
> You should make importing fail if the header line is not exactly as
> specified - or appropriate, should you decide a different format for the
> header.
>
> > Files exported should use the <tt>.csv</tt> file extension.
> Don't mandate the file extension (read below for why):
>
> > In order to reduce file size while retaining wide accessibility, the CSV
> > file may be compressed using the ZIP file format, using the <tt>.zip</tt>
> > file extension.
> I see three problems with this. The first is more important than the later
> two because it makes them moot points, but I'll mention them anyway so you
> get a background of the situation:
> - The BIP is trying to specify in what file format the export format can
> be written in onto the filesystem. There is no way to enforce this on a BIP
> level (besides, Unix operating systems don't even consider the file
> extension, they use its mimetype). Also specifying this in the BIP will
> prevent modular "Layer 2" protocols and schemes from encoding the Export
> labels into another format - for example Base64 or with their own
> compression algorithm.
>
> Now for the two "moot problems":
> - ZIP does not have good performance or compression ratio, there are
> better algorithms out there like gzip (which also happens to be more
> ubiquitous; nearly all websites are serving HTML compressed with gzip
> compression).
> - ZIP is an archiving format, that happens to have its own compression
> format. Archiving format parsers can have serious vulnerabilities in their
> implementation that can allow malware to swipe private keys and passwords,
> since the primary target for this BIP is wallets. For example, there was
> Zip Slip[1] in 2018, which allows for remote code execution. So the malware
> can even hide in memory until private keys or passwords are written to
> memory, then send them accros the network. Assuming it's targeting a
> specific wallet software it's not hard to carry out at all.
>
> There's two solutions for all this:
> 1. The duck-tape solution: Use some compression algorithm like gzip
> instead of ZIP archive format.
> 2. The "throw it out and buy a new one" solution: Get rid of the optional
> compression specs altogether, because users are responsible for supplying
> the export labels in the first place, so all the compression stuff is
> redundant and should be left up to the user use if they desire to.
>
> I prefer the second solution because it hits the nail at the problem
> directly instead of putting duck tape on it like the first one.
>
> > This <tt>.zip</tt> file may optionally be encrypted using either AES-128
> or
> > AES-256 encryption, which is supported by numerous applications including
> > Winzip and 7-zip.
> > The textual representation of the wallet's extended public key (as
> defined
> > by BIP32, with an <tt>xpub</tt> header) should be used as the password.
> Not specific to AES, but I don't see the benefit of encrypting addresses
> and labels together. Can you please elaborate why this would be desireable?
>
> Like I said though, it's better to leave it up to users to decide how to
> store their exports, since BIPs can't enforce that anyway (additionally,
> the password you propose is insecure - anybody with access to the wallet
> can unlock it, which is not desireable to some users who want their own
> security).
>
> > * Transaction ID (<tt>txid</tt>)
> > * Address
> > * Input (rendered as <tt>txid<index</tt>)
> > * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
> Why the need for input and output formats? There is no difference between
> them on the wallet level, because they are always identified with a txid
> and output index. To distinguish between them and hence write them with the
> correct format would require a UTXO set and thus access to a full node,
> otherwise the CSV cannot be verified to be completely well-formed.
>
> Another important point is that practically nobody labels inputs or
> outputs because most people do not know that those things even exist, and
> the rest don't bother to label them.
>
> But the biggest downside to including them is related to the problem of
> information leaking which you make reference to here:
> > In both cases, care must be taken when spending to avoid undesirable
> leaks
> > of private information.
> A CSV dump that has inputs/outputs and addresses mixed together can infer
> the owner of all those items. In fact, A CVS label dump is basically a
> personal information store so everything in it can be correlated as coming
> from the same wallet, so it's important that unnecessary types are kept out
> of the format. People are known to leave files lying around on their
> computer that they don't need anymore, so these files can find their way
> via telemetry to surveillence entities. While we can't specify what users
> can do with their exports, we can control the information leak by
> preventing certain types of items that we know most users will never use
> from being exported in the first place.
>
> > The order in which these records appear is not defined.
> Again, since the primary use case for this BIP is wallets, which likely
> use heirarchical derivation schemes like BIP44, there is a net benefit for
> the addresses to be exported in ascending order of their `address_type`. It
> means that wallets can import them in O(n) time as opposed to O(n^2) time
> spent serially checking in which index the address appears at. Of course,
> this implies that all addresses up to a certain index have to be exported
> into the CSV as well, but most wallets I know of like Core, Electrum
> already store addresses like that.
>
> Also if you do this, you will need to group all the transaction records
> before the address records or vice versa - you can use lexigraphical
> sorting if you want (ie. Addresses before Transactions). The benefit of
> this separation of parts is that wallets can split the imported address
> records from the transaction records internally, and feed them to separate
> functions which set these labels internally.
>
> If you decide on doing it this way, then you need a 3rd column to identify
> the item type, and also you should quote the label (see below). I strongly
> recommend using numbers for identification as opposed to character strings,
> so you don't have to worry about localization or character case issues.
> There is always one unique number, but there could be multiple strings that
> reference the same type. This will complicate importing functions.
>
> If you insist on include Input and Output types then they can both be
> specified as <txid>:<index> if you do this change. They won't be used to
> determine the type anyway.
>
> > The fields may be quoted, but this is unnecessary, as the first comma in
> > the line will always be the delimiter.
> Don't implement it like that, because that will break CSV parsers which
> expect a fixed amount of rows in each record (2 in the header, and some
> rows have >2 rows). It's better to mandate that they should always be
> double-quoted, since only wallets will generate label exports anyway. If
> you plan to use headers then the 3rd column can be blank for it (or you can
> split the version and flags from each other).
>
> > ==Importing==
> >
> > When importing, a naive algorithm may simply match against any reference,
> > but it is possible to disambiguate between transactions, addresses,
> inputs
> > and outputs.
> > For example in the following pseudocode:
> > <pre>
> > if reference length < 64
> > Set address label
> > else if reference length == 64
> > Set transaction label
> > else if reference contains '<'
> > Set input label
> > else
> > Set output label
> > </pre>
> The importing code is too naive and in its current form will prevent the
> BIP from getting a number. It is perhaps the single most important part of
> a BIP. When implementing an importer, it should utilize a dedicate item
> type field that unambiguously identifies the item. So the naive importer is
> not good, you need use a 3rd column for that like I explained above, so
> that the importer becomes robust.
>
> In summary (exclamation marks indicate severity - one means low, two means
> medium, and three means high):
>
> 1. Convert the header into a version line with optional flags, otherwise
> nobody can extend this format without compatibility issues (!)
> 2. Get rid of the specs related to file compression (!!!)
> 3. Add a 3rd column for item type (address, transaction etc.) preferably
> as numeric constants and grouping items of one type after items of another
> type, or if you insist on strings, then only recognize their Titlecase
> ASCII versions <spreadsheet software like Excel always tries to titlecase
> the words> (!!)
> 4. Require double quotes around the label (or single quotes if you prefer,
> as long as spreadsheet software doesn't choke on them) (!!)
> 5. Require sorting the records according to the order they are stored in
> the wallet implementation. (!)
> 6. Consider getting rid of Input and Output item types. (!)
> 7. And last and most importantly, please write a more robust importer
> algorithm in the example given by the BIP, because code in BIPs are
> frequently used as references for software. (!!!)
>
> I hope you will consider these points in future revisions of your BIP.
>
> - Ali
>
> [1] https://github.com/snyk/zip-slip-vulnerability
>
> On Wed, 24 Aug 2022 11:18:43 +0200, craigraw at gmail.com wrote:
> > Hi all,
> >
> > I would like to propose a BIP that specifies a format for the export and
> > import of labels from a wallet. While transferring access to funds across
> > wallet applications has been made simple through standards such as BIP39,
> > wallet labels remain siloed and difficult to extract despite their value,
> > particularly in a privacy context.
> >
> > The proposed format is a simple two column CSV file, with the reference
> to
> > a transaction, address, input or output in the first column, and the
> label
> > in the second column. CSV was chosen for its wide accessibility,
> especially
> > to users without specific technical expertise. Similarly, the CSV file
> may
> > be compressed using the ZIP format, and optionally encrypted using AES.
> >
> > The full text of the BIP can be found at
> > https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki
> > and also copied below.
> >
> > Feedback is appreciated.
> >
> > Thanks,
> > Craig Raw
> >
> > ---
> >
> > <pre>
> > BIP: wallet-labels
> > Layer: Applications
> > Title: Wallet Labels Export Format
> > Author: Craig Raw <craig at sparrowwallet.com>
> > Comments-Summary: No comments yet.
> > Comments-URI:
> > https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels
> > Status: Draft
> > Type: Informational
> > Created: 2022-08-23
> > License: BSD-2-Clause
> > </pre>
> >
> > ==Abstract==
> >
> > This document specifies a format for the export of labels that may be
> > attached to the transactions, addresses, input and outputs in a wallet.
> >
> > ==Copyright==
> >
> > This BIP is licensed under the BSD 2-clause license.
> >
> > ==Motivation==
> >
> > The export and import of funds across different Bitcoin wallet
> applications
> > is well defined through standards such as BIP39, BIP32, BIP44 etc.
> > These standards are well supported and allow users to move easily between
> > different wallets.
> > There is, however, no defined standard to transfer any labels the user
> may
> > have applied to the transactions, addresses, inputs or outputs in their
> > wallet.
> > The UTXO model that Bitcoin uses makes these labels particularly valuable
> > as they may indicate the source of funds, whether received externally or
> as
> > a result of change from a prior transaction.
> > In both cases, care must be taken when spending to avoid undesirable
> leaks
> > of private information.
> > Labels provide valuable guidance in this regard, and have even become
> > mandatory when spending in several Bitcoin wallets.
> > Allowing users to export their labels in a standardized way ensures that
> > they do not experience lock-in to a particular wallet application.
> > In addition, by using common formats, this BIP seeks to make manual or
> bulk
> > management of labels accessible to users without specific technical
> > expertise.
> >
> > ==Specification==
> >
> > In order to make the import and export of labels as widely accessible as
> > possible, this BIP uses the comma separated values (CSV) format, which is
> > widely supported by consumer, business, and scientific applications.
> > Although the technical specification of CSV in RFC4180 is not always
> > followed, the application of the format in this BIP is simple enough that
> > compatibility should not present a problem.
> > Moreover, the simplicity and forgiving nature of CSV (over for example
> > JSON) lends itself well to bulk label editing using spreadsheet and text
> > editing tools.
> >
> > A CSV export of labels from a wallet must be a UTF-8 encoded text file,
> > containing one record per line, with records containing two fields
> > delimited by a comma.
> > The fields may be quoted, but this is unnecessary, as the first comma in
> > the line will always be the delimiter.
> > The first line in the file is a header, and should be ignored on import.
> > Thereafter, each line represents a record that refers to a label applied
> in
> > the wallet.
> > The order in which these records appear is not defined.
> >
> > The first field in the record contains a reference to the transaction,
> > address, input or output in the wallet.
> > This is specified as one of the following:
> > * Transaction ID (<tt>txid</tt>)
> > * Address
> > * Input (rendered as <tt>txid<index</tt>)
> > * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
> >
> > The second field contains the label applied to the reference.
> > Exporting applications may omit records with no labels or labels of zero
> > length.
> > Files exported should use the <tt>.csv</tt> file extension.
> >
> > In order to reduce file size while retaining wide accessibility, the CSV
> > file may be compressed using the ZIP file format, using the <tt>.zip</tt>
> > file extension.
> > This <tt>.zip</tt> file may optionally be encrypted using either AES-128
> or
> > AES-256 encryption, which is supported by numerous applications including
> > Winzip and 7-zip.
> > In order to ensure that weak encryption does not proliferate, importers
> > following this standard must refuse to import <tt>.zip</tt> files
> encrypted
> > with the weaker Zip 2.0 standard.
> > The textual representation of the wallet's extended public key (as
> defined
> > by BIP32, with an <tt>xpub</tt> header) should be used as the password.
> >
> > ==Importing==
> >
> > When importing, a naive algorithm may simply match against any reference,
> > but it is possible to disambiguate between transactions, addresses,
> inputs
> > and outputs.
> > For example in the following pseudocode:
> > <pre>
> > if reference length < 64
> > Set address label
> > else if reference length == 64
> > Set transaction label
> > else if reference contains '<'
> > Set input label
> > else
> > Set output label
> > </pre>
> >
> > Importing applications may truncate labels if necessary.
> >
> > ==Test Vectors==
> >
> > The following fragment represents a wallet label export:
> > <pre>
> > Reference,Label
> >
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?,Transaction
> > 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
> > c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?<0,Input
> >
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?>0,Output
> >
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?:0,Output
> > (alternative)
> > </pre>
> >
> > ==Reference Implementation==
> >
> > TBD
>
> _______________________________________________
> 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/20220827/656c893a/attachment-0001.html>

2023-06-07 23:13:08

- reply

📅 Original date posted:2022-08-27
📝 Original message:I think it might be a good idea to record something that can directly
connect the list of labels with the correct wallet. Imagine someone backs
up a bunch of label files and then forgets which wallet they apply to. Sure
you could probably look through the list of transactions, addresses, etc
and compare against those contained in the actual wallet, but this would be
sort of messy and potentially inefficient. It might be useful to include a
hash of the wallet descriptor (hash for privacy) that can be compared
against potential matching wallet descriptors.
On Fri, Aug 26, 2022 at 2:46 AM Clark Moody via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Having previously developed an export format[1] for general cryptocurrency
> transaction information, I can attest to the value of the human-readable
> CSV. I was careful to mention the RFC 4180 spec so that implementations
> could avoid the pitfalls of incorrect CSV encoding.
>
> [1]: https://github.com/harmony-csv/harmony
>
> Clark
>
> ------- Original Message -------
> On Thursday, August 25th, 2022 at 3:59 AM, Craig Raw via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Thanks for your thoughts Ryan.
>
> Without reference to the quality feedback on this proposal, I was aware
> when submitting it for review that it provides an excellent opportunity for
> bike shedding. As developers, we have all experienced frustration with data
> formats. One thing that I did not perhaps make clear enough is that this
> format is not solely intended for developers, but general users who are
> probably not well represented on this list.
>
> While doing research for this proposal I spoke to several professional
> users of Sparrow Wallet (who are not developers). They all expressed a
> desire for the format to integrate with their business processes, which are
> driven by business tools such as Excel. Labelling provides an important
> function in UTXO and address management in these scenarios, and needs to be
> accessible and manageable outside of wallet software.
>
> If this is to be achieved, it immediately rules out JSON as a data format.
> Not only is JSON limited to editing only through specific software or text
> editors, but (in the latter case) it is fragile enough that a single
> missing character can cause an entire file to fail parsing. CSV is more
> forgiving in this regard. With respect to your comments on escaping, my
> expectation would be that developers will be using a mature CSV library
> rather than handling character escaping themselves. I would rather propose
> a format that is generally usable, even if occasionally a label is escaped
> incorrectly.
>
> Finally, I'll note that CSV files are already common and uncontroversial
> in Bitcoin wallet software. Bitcoin Core, Electrum, Sparrow (and no doubt
> many others) already export addresses and/or transactions with their labels
> as CSV files. This proposal simply attempts to create a standard for
> importing and exporting all the labels in a wallet.
>
> Craig
>
> On Wed, Aug 24, 2022 at 9:01 PM <rhavar at protonmail.com> wrote:
>
>> I'd strongly suggest not using CSV. Especially for a standard. I've
>> worked with it as an interchange format many a times, and it's always been
>> a clusterfuck.
>>
>> Right off the bat, you have stuff like "The fields may be quoted, but
>> this is unnecessary as the first comma in the line will always be the
>> delimiter" which invariably leads to some implementations doing it, some
>> implementations not doing it, and others that are intolerant of the other
>> way.
>>
>> And you have also made the classic mistake of not strictly defining
>> escape rules. So everyone will pick their own (e.g. some will \, escape
>> commas, others will not cause it's quoted and escape quotes, and others
>> will assume no escaping is required since its the last column in a csv).
>>
>> Over time it morphs into its own mini-monster that introduces so much
>> pain.
>>
>> On a similar note, allowing alternatives (like: txid>index vs
>> txid:index) provides no benefit, but creates additional work for
>> implementations (who quite likely only test formats they produce) and
>> future incompatibilities.
>>
>> I know everyone loves to hate on it, but really (line-separated?) json is
>> the way to go.
>>
>> { "tx": "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎",
>> "label": "wow, such label" }
>> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b",
>> "txout": 4, "label": "omg this is so easy to parse" }
>> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b",
>> "txin": 0, "label": "wow this is going to be extensible as well" }
>>
>>
>>
>>
>> -Ryan
>>
>> ------- Original Message -------
>> On Wednesday, August 24th, 2022 at 2:18 AM, Craig Raw via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi all,
>>
>> I would like to propose a BIP that specifies a format for the export and
>> import of labels from a wallet. While transferring access to funds across
>> wallet applications has been made simple through standards such as BIP39,
>> wallet labels remain siloed and difficult to extract despite their value,
>> particularly in a privacy context.
>>
>> The proposed format is a simple two column CSV file, with the reference
>> to a transaction, address, input or output in the first column, and the
>> label in the second column. CSV was chosen for its wide accessibility,
>> especially to users without specific technical expertise. Similarly, the
>> CSV file may be compressed using the ZIP format, and optionally encrypted
>> using AES.
>>
>> The full text of the BIP can be found at
>> https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki
>> and also copied below.
>>
>> Feedback is appreciated.
>>
>> Thanks,
>> Craig Raw
>>
>> ---
>>
>> <pre>
>> BIP: wallet-labels
>> Layer: Applications
>> Title: Wallet Labels Export Format
>> Author: Craig Raw <craig at sparrowwallet.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels
>> Status: Draft
>> Type: Informational
>> Created: 2022-08-23
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies a format for the export of labels that may be
>> attached to the transactions, addresses, input and outputs in a wallet.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> The export and import of funds across different Bitcoin wallet
>> applications is well defined through standards such as BIP39, BIP32, BIP44
>> etc.
>> These standards are well supported and allow users to move easily between
>> different wallets.
>> There is, however, no defined standard to transfer any labels the user
>> may have applied to the transactions, addresses, inputs or outputs in their
>> wallet.
>> The UTXO model that Bitcoin uses makes these labels particularly valuable
>> as they may indicate the source of funds, whether received externally or as
>> a result of change from a prior transaction.
>> In both cases, care must be taken when spending to avoid undesirable
>> leaks of private information.
>> Labels provide valuable guidance in this regard, and have even become
>> mandatory when spending in several Bitcoin wallets.
>> Allowing users to export their labels in a standardized way ensures that
>> they do not experience lock-in to a particular wallet application.
>> In addition, by using common formats, this BIP seeks to make manual or
>> bulk management of labels accessible to users without specific technical
>> expertise.
>>
>> ==Specification==
>>
>> In order to make the import and export of labels as widely accessible as
>> possible, this BIP uses the comma separated values (CSV) format, which is
>> widely supported by consumer, business, and scientific applications.
>> Although the technical specification of CSV in RFC4180 is not always
>> followed, the application of the format in this BIP is simple enough that
>> compatibility should not present a problem.
>> Moreover, the simplicity and forgiving nature of CSV (over for example
>> JSON) lends itself well to bulk label editing using spreadsheet and text
>> editing tools.
>>
>> A CSV export of labels from a wallet must be a UTF-8 encoded text file,
>> containing one record per line, with records containing two fields
>> delimited by a comma.
>> The fields may be quoted, but this is unnecessary, as the first comma in
>> the line will always be the delimiter.
>> The first line in the file is a header, and should be ignored on import.
>> Thereafter, each line represents a record that refers to a label applied
>> in the wallet.
>> The order in which these records appear is not defined.
>>
>> The first field in the record contains a reference to the transaction,
>> address, input or output in the wallet.
>> This is specified as one of the following:
>> * Transaction ID (<tt>txid</tt>)
>> * Address
>> * Input (rendered as <tt>txid<index</tt>)
>> * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
>>
>> The second field contains the label applied to the reference.
>> Exporting applications may omit records with no labels or labels of zero
>> length.
>> Files exported should use the <tt>.csv</tt> file extension.
>>
>> In order to reduce file size while retaining wide accessibility, the CSV
>> file may be compressed using the ZIP file format, using the <tt>.zip</tt>
>> file extension.
>> This <tt>.zip</tt> file may optionally be encrypted using either AES-128
>> or AES-256 encryption, which is supported by numerous applications
>> including Winzip and 7-zip.
>> In order to ensure that weak encryption does not proliferate, importers
>> following this standard must refuse to import <tt>.zip</tt> files encrypted
>> with the weaker Zip 2.0 standard.
>> The textual representation of the wallet's extended public key (as
>> defined by BIP32, with an <tt>xpub</tt> header) should be used as the
>> password.
>>
>> ==Importing==
>>
>> When importing, a naive algorithm may simply match against any reference,
>> but it is possible to disambiguate between transactions, addresses, inputs
>> and outputs.
>> For example in the following pseudocode:
>> <pre>
>> if reference length < 64
>> Set address label
>> else if reference length == 64
>> Set transaction label
>> else if reference contains '<'
>> Set input label
>> else
>> Set output label
>> </pre>
>>
>> Importing applications may truncate labels if necessary.
>>
>> ==Test Vectors==
>>
>> The following fragment represents a wallet label export:
>> <pre>
>> Reference,Label
>>
>> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction
>> 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
>> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎<0,Input
>> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎>0,Output
>> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output
>> (alternative)
>> </pre>
>>
>> ==Reference Implementation==
>>
>> TBD
>>
>>
>>
>>
> _______________________________________________
> 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/20220827/d9a86c1b/attachment-0001.html>

2023-06-07 23:12:48

- reply

📅 Original date posted:2022-08-18
📝 Original message:While constant tail emission does in fact converge to 0 inflation over time
(which bitcoin's halvings do as well mind you), tail emission does *not*
solve the potential problem of mining rewards, it only delays it. A tail
emission of 200,000 btc/year (~1% of the current supply) would be
equivalent to halvings every ~50 years rather than every 4 years. Were we
to implement this kind of thing right after the last non-" destructive"
halving, it would buy us 46 years of extra time. Nothing more, nothing less.
While its mildly interesting to know that tail emission converges to a
stable point, while no inflation implies monetary deflation at the rate of
loss, this feels very likely to be an insignificant problem. I think 1%
loss rate per year is an absurdly high estimate these days, and the loss
rate is likely to decrease as methods of storing bitcoin mature. Imagine
bitcoin was worth $1 trillion (not so hard, since it was not too long ago),
then try imagining people losing $10 billion of bitcoin every year. Highly
unlikely IMO. A rate of loss of 0.01%/year might be more realistic for a
near-future mature bitcoin. That's not going to be enough to make a
significant difference even over 100s of years.
If we actually wanted to solve the potential problem of not-enough-fees to
upkeep mining security, there are less temporary ways to solve that. For
example, if fees end up not being able to support sufficient mining, we
could add emission based on a constant fraction of fees in the block. For
example, every block could emit new bitcoin amounting to 10% of the fees
collected in that block. This would tie coinbase rewards to the real world
(since the fee market is tied to the real economy) and ensure higher block
revenue indefinitely - ie not just for another 50 years.
But its also worth saying that blockchain security (which mining revenue
correlates with) does *not* need to increase indefinitely. There is some
amount of security (and therefore some amount of mining revenue) that is
sufficient, beyond which additional security is simply unnecessary,
unwarranted, and wasteful (you wouldn't buy a $1000 safe to store $1000 of
valuables). Do we, as the bitcoin community, have some good idea how much
security we need? Do we have some idea how costly a 51% attack must be
where we can be comfortable it will never happen? I'm curious to hear what
people think about that. Because without having some kind of estimates of
what "enough security" is, there's absolutely no way of evaluating whether
or not its likely that bitcoin fees alone will be able to sustain enough
security.
On Wed, Aug 17, 2022 at 9:31 AM Jaroslaw via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On one scale you puts the Trust to the large stakeholders (why we avoid
> plenty of small stakeholders, btw),
> and on the other side I put game theory and well defined Prisoner's
> Dilemma.
>
> Again: large stakeholders WILL NOT incentivised to mine, they will have
> the hundreds excuses why not to switch-on Antminers back.
> That's how it simply works. Bitcoin would fail miserably if Satoshi was
> based his concept mainly on existence of idealists.
>
> If we will observe lack of hashrate recovery four years after some halving
> and still unprepared like today
> - means the trust in large stakeholders was a very costly mistake.
>
>
> Superiority of Proof of Work against Proof of Stake has been discussed
> enough either
> The overall conclusion with what I fully agree is: swapping PoW to PoS -
> would be a degradation.
> You can stop talking about degradation to proof of stake, but just:
> degradation.
>
> Degradation of Bitcoin, due to human greed.
>
> Now you mine and you have an INSTANT gratification.
> Then you will mine and it will cost you real money, but simple switch -
> and you have a DELAYED, maybe some day in the future, maybe only a tiny -
> punishment.
> And The Punishment Won't Be Tiny.
>
>
> "If the pain after hitting the hand with a hammer would appear after a
> month - people would notoriously walk with swollen fingers"
> 100% (^2)
>
> Regards
> Jaroslaw
>
>
>
> W dniu 2022-08-17 13:10:38 użytkownik Erik Aronesty <erik at q32.com>
> napisał:
>
> > you can stop talking about the "security of the system" as meaningful
> > this has been discussed enough
> > if fees are not sufficient, clearance times increase and large
> stakeholders are incentivised to mine
> > in the best case, fees are sufficient
> > in the worst case, it degrades to proof of stake
> > i'm sure you can see how that's fine either way
>
>
>
> _______________________________________________
> 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/20220818/bc7a359b/attachment.html>

2023-06-07 23:12:44

- reply

📅 Original date posted:2022-08-20
📝 Original message:@vjudeu
> Miners can game this system by moving their own coins in 100% fees
transactions, just to produce more coins. You have one million BTC? No
problem, just move them as fees, and you just created 100k BTC out of thin
air, just because you are a wealthy miner.
Hmm, I believe you're right about that. If a miner can make 1 BTC of fees
by honestly mining + 0.1 BTC of inflation, they could instead make 2 BTC by
mining their own transactions with 20 BTC of fees. That does sound very
gameable. I rescind my suggestion.
One could imagine modifications to that suggestion that attempts to make it
more difficult to game directly. For example, if an average sum of
fees/block was calculated over a window (eg 2 weeks, 2 months, etc) and 10%
of that was released in coinbase rewards, you would eliminate the
possibility for individual miners to game the system. However, you would
then have to consider the group of miners as a whole - since they all have
an interest in increasing their revenues, it certainly seems like a
dangerous incentive that could lead to runaway inflation. So perhaps even
extensions of my suggestion are too gameable to be safe.
But my point still stands that tail emission is not a permanent solution.
One permanent solution would be some constant inflation *rate *(eg
0.1%/year). Given that the necessary security is a function of the total
value of the currency, perhaps that would be a reasonable natural way to
scale security as needed.
Again tho, I haven't seen any convincing evidence that any solution like
this will likely be necessary at all. Total collected fees will also scale
up as bitcoin grows, probably quadratically (since the value of the network
grows quadratically). I'm rather more inclined to think collected fees will
get far *too* high - ie substantially higher than needed to pay for
sufficient blockchain security.
On Fri, Aug 19, 2022 at 1:48 PM aliashraf.btc At protonmail via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Peter, everyone
> This issue has been discussed thoroughly in bitcointalk, general
> discussions are more suited to forums, I believe, still ....
>
> First and foremost, it is more than obvious that bitcoin block subsidy
> algorithm is a total disaster, not just for the zero subsidy security
> consequences, but also for the overly rewarding scheme that favors (few)
> first-runners against (masses of) people who join later, a policy that
> looks to be a cheap marketing trick rather than a decent strategic
> monetary, system design, no matter how natural it is presumed nowadays,
> after being implemented by Bitcoin.
>
> For now, the brilliance of the idea behind Bitcoin and the enthusiasm have
> compensated for its bizzar, upside-down inflation policy, in practice as
> newcomers have been paying the price to lucky first-runners and adopting
> anyway.
> Is it happening for low block subsidy? Is it going to be solved somehow? I
> don't think so.
>
> With subsidy still being the major (like 90%) portion of the block reward,
> there is an equalizer factor pushing equilibrium by paying security costs
> on behalf of current coin owners.Note that every single new bitcoin paid as
> subsidy is actually paid by the rest of the wallets proportional to their
> balance.
> Other than its direct contribution to security, once understood as a
> ballance-based taxing scheme, it is a crucial mechanism for re-distribution
> of wealth because to compensate for their costs, unlike speculators (who
> are among the worst adopters of Bitcoin, and unfortunately the most
> influencers), miners are used to dumping their coins, providing more fair
> opportunities for people to join.
> So, halving and the hard cap, put both adoption and security as risk, It
> is why, unlike "believers", I'm deeply concerned about a future with low
> block subsidy because it puts both security and adoption in an awkward
> situation.
>
> Additionally, It is not considered an engineering practice by any measure
> to speculate about the security of a system that we abundantly recommend to
> friends, family for joining.
> We need proofs, security proof, ease of adaptation proof, etc.,
> Fantasies are not proofs, having faith in a magical incentive mechanism
> that fixes everything is not an argument, let alone being a proof.
> Incentives are irrelevant, rules, schemes, projects, and so fort, matter.
> There are always incentives in games, but rules are in charge of
> determining the fate.
> Without rules, there is no game, flawed schemes and rules move the game
> behind its equilibrium to fail eventually.
>
> I've not to mention the unfeasibility of tempering Bitcoin's basic
> consensus rules, Bitcoin rules are not subject to change specially when it
> comes to something that is widely considered a basic characteristic, a
> Schelling point, and so forth.
>
> So, it is the paradoxical situation: we are exposed to, on one hand, it is
> a deficiency and on the other hand it is inevitable because is critically
> hard-code to Bitcoin, advertised more than any feature as its identity.
> But it is our job, isn't it? Dealing with the impossible and taking care
> of it, but I think before reaching to that point we have to settle the
> basics.:
>
>
> 1. There is a problem with long term security and adoption
> consequences.
> 2. It is built deeply to bitcoin consensus rules, and considered a
> critical
> 3. It is not going to disappear magically, neither it will be
> addressed by whales, etc.
> 4. The 21M cap, halving, and generally, Bitcoin consensus, is not
> subject to change.
>
>
> Don't panic, it is not exactly a catch-22 situation. Tip:
> It is always possible to help a system without aggressive intervention,
> either by smart tweaks or by supporting it using other system(s).
>
> Cheers, Ali Ashraf
>
>
>
> ------- Original Message -------
> On Tuesday, August 16th, 2022 at 8:35 PM, Peter via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Jaroslaw,
>
>
>
> In the Prisoner's Dilemma the prisoners cannot communicate. In Bitcoin
> large holders are able to communicate with each other. Also, prisoners need
> not make an all or nothing decision in Bitcoin. Miners can join and leave
> the network freely over time. You can change your decision based on the
> decision of others.
>
>
> The Bitcoin design is such that security is volatile but the issuance of
> blocks is timely and evened out to a 10 minutes average even after the
> reward is exhausted.
>
>
> The existing incentive that miners earn money for including transactions
> is enough to motivate human nature. Transaction initiators have an
> incentive to mine and run full nodes for personal interest.
>
>
> >Noone will waste his renewable energy on unprofitable Antminer while
> he/she can sell this energy for the market price.
>
>
> The law in most jurisdictions prevents the resale of spare electricity
> unless an expensive license is obtained (and in most cases no license is
> available as the government maintains a monopoly). Mining with waste
> electricity is reducing losses. Another incentive to motivate human nature.
>
>
> Bitcoin holders can be enfranchised into any new system. So, no need for
> bike shedding the original design which is a Schelling Point.
>
>
> Regards
>
> Peter Kroll
>
> pointbiz/ BTCCuracao
>
>
>
> _______________________________________________
> 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/20220820/84699ddb/attachment-0001.html>

2023-06-07 23:12:28

- reply

📅 Original date posted:2022-08-03
📝 Original message:@Dmitry
> various software might start to use extra indexes in a tuple for their
own non-standard purposes
This will be true regardless of whether the spec allows or doesn't allow
tuples of length more than 2. In fact, any other tuple other than <1;2>
will be nonstandard. We can't prevent people from using standards in
use-case-specific ways, and we can't prevent people from creating
non-standard extensions of standards.
> Wallet software that wishes to utilize non-standard extra indexes beyond
'receive' and 'change' should use separate descriptors instead for these
extra indexes.
What benefit would that gain? The wallets would still be doing something
non-standard and interpreting those indexes however they want. A descriptor
format is simply defining a space of address derivation paths. It is not
describing in any way what each path is intended for - those are
conventions outside the scope of this BIP IMO. Defining the conventions of
derivation path indexes should be a separate BIP. Single responsibility
principle.
On Thu, Jul 28, 2022 at 5:15 AM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The issue with tuples of lenth more than two is that the purpose for
> indexes beyond 'receive' and 'change' are not established, and
> therefore various software might start to use extra indexes in a tuple
> for their own non-standard purposes. This is bound to create
> incompatibilities where different wallet software that import the same
> descriptor would use those addresses for different purposes.
>
> Even if some auxiliary standard emerges for the meanings of extra
> indexes, since the indexes in the tuple are listed without omissions (no
> "<0;1;;;3>" allowed), all software will need to be aware of the
> existence of these purposes and define indexes for them: if one wishes
> to utilize position 3 in such a tuple, they will need to define an index
> for position 2 as well.
>
> I'd expect that emergence of new widely-used purposes for indexes would
> be a very rare event, and a separate BIP for each purpose wouldn't be
> excessive.
>
> I'd say that bip-multipath-descs should say that extra indexes are OK
> for address discovery (for scanning of the addresses of a wallet), but
> it should say that any interpretation of the purpose of such indexes
> and deriving new addresses at these indexes are strongly discouraged.
>
> Wallet software that wishes to utilize non-standard extra indexes beyond
> 'receive' and 'change' should use separate descriptors instead for
> these extra indexes.
>
> And when a new established purpose emerges for the next position in the
> index tuple, a new BIP should be made that defines such position.
>
> The BIP for position 3 would naturally come after the BIP for position
> 2, and thus software that implemnents BIP for position 3 would be aware
> of the previous BIP and will at least know to choose some index for
> position 2.
>
> В Wed, 27 Jul 2022 14:58:28 +0000
> Andrew Chow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> wrote:
>
> > I've updated the BIP text to allow arbitrary length tuples.
> >
> > On 07/27/2022 04:44 AM, Pavol Rusnak wrote:
> >
> > > On Wed, 27 Jul 2022 at 00:28, Andrew Chow
> > > <achow101-lists at achow101.com> wrote:
> > >> However I don't see why this couldn't generalize to any sized
> > >> tuples. As long as the tuples are all the same length, and the
> > >> limit is one tuple per key expression, then we don't get any
> > >> combinatorial blowup issues.
> > >
> > > I think it's worthwhile to generalize for any sized tuples. I don't
> > > have any existing particular use case in mind, because BIP-44,
> > > BIP-84, etc. are fine with just using <0;1>, but there might be
> > > some upcoming standards in the future that will want to introduce
> > > more sub-paths.
> > >
> > > --
> > >
> > > Best Regards / S pozdravom,
> > >
> > > Pavol "stick" Rusnak
> > > Co-Founder, SatoshiLab
>
> _______________________________________________
> 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/20220803/bc75c220/attachment-0001.html>

2023-06-07 23:12:25

- reply

📅 Original date posted:2022-08-27
📝 Original message:> I would like to note it's real work for the organizers in terms of time
and energy: finding a common date making consensus, an acceptable host
country (i.e respecting the travel policy of the widest...
I was actually not thinking one large central in-person meeting, but many
smaller decentralized in-person meetings where no one has to travel far.
The meetings can be used to foster communication that can then be
summarized and/or brought online and discussed with the larger group. Would
certainly make all those date/visa/etc issues a lot easier.
> I would be even cautious about something restrained like "group
consensus" in Bitcoin FOSS. At best, it's just a snapshot of people's
understanding of the technical issues in state X at time T
Fair enough. But I think part of the point here would be to use such a
snapshot as an indicator that helps convince others that a particular idea
has been discussed, thought through, and has actual well-reasoned support.
Whatever you call it, it would be a useful set of data points.
> I believe the covenant problem space might be solved in an evolutionary
way, layer by layer akin to how LN moves forward.
Definitely.
On Tue, Aug 9, 2022 at 3:15 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi Billy,
>
> Thanks for your interest in a covenant working group.
>
> > place for this kind of thing to happen. I also agree with Ryan Grant's
> > comment about in-person cut-through (ie cut through the BS and resolve
> > misunderstandings). Perhaps every 3 IRC meetings or so, an in-person
> meetup
> > can be organized in various locations to facilitate that kind of cut
> > through.
>
> I really appreciate in-person cut-through to resolve misunderstandings and
> accelerate the information synchronization across the stakeholders of a
> problem space. However, I would like to note it's real work for the
> organizers in terms of time and energy: finding a common date making
> consensus, an acceptable host country (i.e respecting the travel policy of
> the widest, e.g organizing Scaling in Israel in 2019 was an issue for some
> passport holders), a standard meeting location, seeking event sponsors,
> communicating all those infos well ahead to ease everyone travels, ensuring
> coffees & foods suiting many different diets, collecting topics of
> discussions, etc. Further, even assuming travel support, it can still be a
> prohibitive cost for a lot of participants, e.g if you have to request
> months ahead to the host country authorities a dedicated visa for the
> opportunity. I did a bit of in-person meetings organizing in the past, I'm
> clearly not interested in doing it anymore, though it would be cool if
> someone would like to do it for covenants in the future.
>
> > I would imagine the phases the group could go through is:
> > 1. Define the phases (these phases). This list of 6 phases could be a
> > starting point, but its probably best to open the floor to whether this
> > feels like a reasonable approach and if more phases are needed or if some
> > aren't.
> > 2. Define and prioritize the motivations (ie the various features and
> > functionality we want out of covenants, like the ones you listed). By
> > prioritize, I mostly mean figure out which motivations are most
> motivating
> > to people and rate them by strength of motivation (rather than a ranked
> > list).
> > 3. Define and prioritize the relevant constraints. These are things to
> > avoid in any covenant implementation. Constraints that have been brought
> up
> > in the past are things like preventing the possibility of infinite
> covenant
> > recursion, full enumeration, preventing dynamic state, etc. By prioritize
> > here, it might be useful to categorize them into categories like "no
> > tolerance", "some tolerance", "no reservations". Eg it might turn out
> most
> > people don't have any tolerance for infinite recursion, but don't mind
> > non-full enumeration.
> > 4. Other criteria? These are other criteria we might want to evaluate
> > proposals according to. And some kind of way to prioritize them /
> evaluate
> > them against each other as trade offs.
> > 5. Evaluate the proposals based on motivations, constraints, and other
> > criteria. This phase shouldn't involve comparing them to each other.
> > 6. Produce a set of conclusions/opinions on which proposals are worth
> > pursuing further. This would be the phase where proposals are compared.
>
> Yes, I think overall a lot is making sense. Though it's good to keep
> things as loose and see how it evaluates with time and new information
> showing up.
>
> About 2., I think one more thing to define is the list of use-cases, I
> would abstract out features and functionality from use-cases. E.g, I think
> with the TLUV proposal, the taproot output editing feature enables both
> "dynamic-amount" vault and scaling payment pools.
>
> About 3., I think this is going to be the hard part. Collecting all the
> constraints and evaluating the risk tolerance of as-much-as-we-can
> community stakeholders in face of known and plausible risks. E.g, again
> with TLUV, I think it would make from now on the taproot internal pubkey
> and tree of alternative scripts a kind of "dynamic state".
>
> About 4. I've quickly come to mind as additional criterias economic
> simulations of any feature, privacy advantages, toolchain implementations
> complexity, evolvability and composability with future features.
>
> About 6. I agree I think it's good to withhold comparison further down in
> the pipe we can, even if there is I would say some criteria-learning
> heuristics by mirroring features against another.
>
> > Each phase would probably span over more than one meeting. I imagine each
> > phase basically consisting of discussing each individual nominated item
> (ie
> > motivations, constraints, other criteria, or proposals) sequentially. The
> > consensus reached at the end of each phase would be considered of course
> a
> > group consensus of those who participated, not a global consensus, not a
> > "bitcoin community consensus". After each phase, the results of that
> phase
> > would be published more widely to get broader community feedback. These
> > results would include what the major opinions are, what level of
> consensus
> > each major opinion has, what the reasons/justifications behind each
> opinion
> > are, and various detailed opinions from individuals. It would be
> especially
> > great to have detailed evaluations of each proposal published by various
> > people so anyone can go back and understand their thought process (as
> > opposed to a list of names attached to basically a thumbs up or thumbs
> > down). Think like a supreme court decision kind of thing.
>
> Yeah, again I don't see meetings as bounded in time rather happening
> regularly as we have with LN ones. I guess it's going to take at least a
> good year for working group participants to take habits and familiarity
> with the problem space and reach consensus on the process itself. Further,
> I would be even cautious about something restrained like "group consensus"
> in Bitcoin FOSS. At best, it's just a snapshot of people's understanding of
> the technical issues in state X at time T, and that can evaluate quickly in
> function of new findings or issues arising. I think it's more interesting
> to seek a lack of consensus in the sense of opposite opinions or blocking
> arguments. I wouldn't disqualify thumbs up or thumbs down per se, there are
> marks of interest in a specific proposal, though I lean to agree that I
> find more interesting too laid-out evaluations and thought processes.
>
> > The process doesn't need to be complete after phase 6. Any previous phase
> > could be revisited, but after a phase is revisited, the phases after it
> > should probably be also revisited in order - or at least until its
> decided
> > a previous phase needs to be revisited again. Each iteration would
> solidify
> > consensus more about each phase. I would imagine the group might loop
> > through phases 2, 3, and 4 a couple times (since constraints might
> conflict
> > with motivating features). It might be likely that in phase 5 while
> > evaluating proposals, people realize that there are additional criteria
> > that should be added and can propose going back to step 4 to do that.
> > Hopefully we would get to the point where the motivations and constraints
> > and relatively solid consensuses and iterations can loop through phases 5
> > and 6 until the set of proposals the group thinks is worth pursuing is
> > narrowed down (ideally to 1 or 2).
>
> For sure, in the function of new feedback arising it's good to constantly
> reevaluate proposals. Hopefully, I think any looping should make proposals
> more formalized and accurate. We might also have the "easy" covenants
> moving faster than the "hard" ones across the phases. I believe the
> covenant problem space might be solved in an evolutionary way, layer by
> layer akin to how LN moves forward.
>
> Le mer. 3 août 2022 à 11:37, Billy Tetrud <billy.tetrud at gmail.com> a
> écrit :
>
>> @Antoine
>> I very much like your proposal of an open decentralized process for
>> investigating the problem and solution spaces. IRC sounds like a reasonable
>> place for this kind of thing to happen. I also agree with Ryan Grant's
>> comment about in-person cut-through (ie cut through the BS and resolve
>> misunderstandings). Perhaps every 3 IRC meetings or so, an in-person meetup
>> can be organized in various locations to facilitate that kind of cut
>> through.
>>
>> I would imagine the phases the group could go through is:
>> 1. Define the phases (these phases). This list of 6 phases could be a
>> starting point, but its probably best to open the floor to whether this
>> feels like a reasonable approach and if more phases are needed or if some
>> aren't.
>> 2. Define and prioritize the motivations (ie the various features and
>> functionality we want out of covenants, like the ones you listed). By
>> prioritize, I mostly mean figure out which motivations are most motivating
>> to people and rate them by strength of motivation (rather than a ranked
>> list).
>> 3. Define and prioritize the relevant constraints. These are things to
>> avoid in any covenant implementation. Constraints that have been brought up
>> in the past are things like preventing the possibility of infinite covenant
>> recursion, full enumeration, preventing dynamic state, etc. By prioritize
>> here, it might be useful to categorize them into categories like "no
>> tolerance", "some tolerance", "no reservations". Eg it might turn out most
>> people don't have any tolerance for infinite recursion, but don't mind
>> non-full enumeration.
>> 4. Other criteria? These are other criteria we might want to evaluate
>> proposals according to. And some kind of way to prioritize them / evaluate
>> them against each other as trade offs.
>> 5. Evaluate the proposals based on motivations, constraints, and other
>> criteria. This phase shouldn't involve comparing them to each other.
>> 6. Produce a set of conclusions/opinions on which proposals are worth
>> pursuing further. This would be the phase where proposals are compared.
>>
>> Each phase would probably span over more than one meeting. I imagine each
>> phase basically consisting of discussing each individual nominated item (ie
>> motivations, constraints, other criteria, or proposals) sequentially. The
>> consensus reached at the end of each phase would be considered of course a
>> group consensus of those who participated, not a global consensus, not a
>> "bitcoin community consensus". After each phase, the results of that phase
>> would be published more widely to get broader community feedback. These
>> results would include what the major opinions are, what level of consensus
>> each major opinion has, what the reasons/justifications behind each opinion
>> are, and various detailed opinions from individuals. It would be especially
>> great to have detailed evaluations of each proposal published by various
>> people so anyone can go back and understand their thought process (as
>> opposed to a list of names attached to basically a thumbs up or thumbs
>> down). Think like a supreme court decision kind of thing.
>>
>> The process doesn't need to be complete after phase 6. Any previous phase
>> could be revisited, but after a phase is revisited, the phases after it
>> should probably be also revisited in order - or at least until its decided
>> a previous phase needs to be revisited again. Each iteration would solidify
>> consensus more about each phase. I would imagine the group might loop
>> through phases 2, 3, and 4 a couple times (since constraints might conflict
>> with motivating features). It might be likely that in phase 5 while
>> evaluating proposals, people realize that there are additional criteria
>> that should be added and can propose going back to step 4 to do that.
>> Hopefully we would get to the point where the motivations and constraints
>> and relatively solid consensuses and iterations can loop through phases 5
>> and 6 until the set of proposals the group thinks is worth pursuing is
>> narrowed down (ideally to 1 or 2).
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 26, 2022 at 11:47 AM Bram Cohen via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard <antoine.riard at gmail.com>
>>> wrote:
>>>
>>>> What would be the canonical definition and examples of capabilities in
>>>> the Bitcoin context ?
>>>>
>>>
>>> Payments into vaults which can only be accepted by that vault and are
>>> guaranteed to be subject to the vault's restrictions (the vault has a
>>> capability)
>>>
>>> Oracles whose validity can be verified on chain (so transactions can
>>> depend on what they say. The oracle has a capability)
>>>
>>> Colored coins whose validity can be verified on chain (the colored coins
>>> have a capability)
>>>
>>> _______________________________________________
>>> 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/20220827/651cda91/attachment-0001.html>

2023-06-07 23:12:24

- reply

📅 Original date posted:2022-08-03
📝 Original message:@Antoine
I very much like your proposal of an open decentralized process for
investigating the problem and solution spaces. IRC sounds like a reasonable
place for this kind of thing to happen. I also agree with Ryan Grant's
comment about in-person cut-through (ie cut through the BS and resolve
misunderstandings). Perhaps every 3 IRC meetings or so, an in-person meetup
can be organized in various locations to facilitate that kind of cut
through.
I would imagine the phases the group could go through is:
1. Define the phases (these phases). This list of 6 phases could be a
starting point, but its probably best to open the floor to whether this
feels like a reasonable approach and if more phases are needed or if some
aren't.
2. Define and prioritize the motivations (ie the various features and
functionality we want out of covenants, like the ones you listed). By
prioritize, I mostly mean figure out which motivations are most motivating
to people and rate them by strength of motivation (rather than a ranked
list).
3. Define and prioritize the relevant constraints. These are things to
avoid in any covenant implementation. Constraints that have been brought up
in the past are things like preventing the possibility of infinite covenant
recursion, full enumeration, preventing dynamic state, etc. By prioritize
here, it might be useful to categorize them into categories like "no
tolerance", "some tolerance", "no reservations". Eg it might turn out most
people don't have any tolerance for infinite recursion, but don't mind
non-full enumeration.
4. Other criteria? These are other criteria we might want to evaluate
proposals according to. And some kind of way to prioritize them / evaluate
them against each other as trade offs.
5. Evaluate the proposals based on motivations, constraints, and other
criteria. This phase shouldn't involve comparing them to each other.
6. Produce a set of conclusions/opinions on which proposals are worth
pursuing further. This would be the phase where proposals are compared.
Each phase would probably span over more than one meeting. I imagine each
phase basically consisting of discussing each individual nominated item (ie
motivations, constraints, other criteria, or proposals) sequentially. The
consensus reached at the end of each phase would be considered of course a
group consensus of those who participated, not a global consensus, not a
"bitcoin community consensus". After each phase, the results of that phase
would be published more widely to get broader community feedback. These
results would include what the major opinions are, what level of consensus
each major opinion has, what the reasons/justifications behind each opinion
are, and various detailed opinions from individuals. It would be especially
great to have detailed evaluations of each proposal published by various
people so anyone can go back and understand their thought process (as
opposed to a list of names attached to basically a thumbs up or thumbs
down). Think like a supreme court decision kind of thing.
The process doesn't need to be complete after phase 6. Any previous phase
could be revisited, but after a phase is revisited, the phases after it
should probably be also revisited in order - or at least until its decided
a previous phase needs to be revisited again. Each iteration would solidify
consensus more about each phase. I would imagine the group might loop
through phases 2, 3, and 4 a couple times (since constraints might conflict
with motivating features). It might be likely that in phase 5 while
evaluating proposals, people realize that there are additional criteria
that should be added and can propose going back to step 4 to do that.
Hopefully we would get to the point where the motivations and constraints
and relatively solid consensuses and iterations can loop through phases 5
and 6 until the set of proposals the group thinks is worth pursuing is
narrowed down (ideally to 1 or 2).
On Tue, Jul 26, 2022 at 11:47 AM Bram Cohen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> What would be the canonical definition and examples of capabilities in
>> the Bitcoin context ?
>>
>
> Payments into vaults which can only be accepted by that vault and are
> guaranteed to be subject to the vault's restrictions (the vault has a
> capability)
>
> Oracles whose validity can be verified on chain (so transactions can
> depend on what they say. The oracle has a capability)
>
> Colored coins whose validity can be verified on chain (the colored coins
> have a capability)
>
> _______________________________________________
> 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/20220803/101b8a4d/attachment.html>

2023-06-07 23:12:23

- reply

📅 Original date posted:2022-08-03
📝 Original message:I agree with Peter, it seems like we don't need a dust limit with full
blocks. And we should expect blocks to remain full indefinitely.
However, if we were to still have a dust limit, it shouldn't be a simple
constant. It should be determined by the mempool environment. Eg one could
define the dust limit to be the 5th percentile lowest fee in the last 100
blocks. Or the 1st percentile. Etc. This way, as the value of bitcoin
fluctuates (inevitably affecting the fees people are willing to pay), the
dust limit would automatically adjust to compensate. One might worry that
in high fee environments, the dust limit calculated this way might make for
too-high dust limits. But I don't think you could really say it would be
"too high" because it would match the actual mempool. We could have a
maximum dust limit set if that's a worry tho.
On Wed, Aug 3, 2022 at 5:35 PM Aaradhya Chauhan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thank you for answering. I'll check out the link you provided, while also
> playing around with the fee settings for my own full node, at my home
> server.
>
> On Wed, 3 Aug 2022 at 23:02, vjudeu via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> It is possible, because you can find nodes that accept low-fee
>> transactions. And on some statistics, for example
>> https://jochen-hoenicke.de/queue/#BTC,24h,weight,0 you can see that zero
>> to one satoshi per virtual byte transactions could take more space than
>> other transactions. You can be convinced that those charts are not fake by
>> running a full node and reaching some nodes with different fee settings. If
>> miners don't want to accept them, well, it is their choice to leave that
>> money on the table. As long as the basic block reward is sufficient, they
>> don't have to accept such low fee transactions, because they can wait
>> instead, to receive them in some batched form.
>>
>> Also, some miners could accept only 10 sats/vB or higher, because why
>> not. As long as your transaction will reach enough nodes to be confirmed,
>> you can safely pick lower fees. For now, de-facto standard is one satoshi
>> per virtual byte, but:
>>
>> 1) it is only declared, so you can rely only on declarations, not on hard
>> consensus rules
>> 2) there is no way to make sure if some transaction was truly rejected by
>> some miner, or maybe it was saved somewhere
>> 3) you can never be sure if some node is a miner and can enforce those
>> different fee rules or not
>>
>> So, you can really judge only by how nodes behave, you cannot make sure
>> in any way if anyone is running some additional rules. And fees are not a
>> part of the consensus, so they can be freely adjusted by each node, and
>> there is no way to make sure, what rules are really executed, you can only
>> assume that, based on what transactions are included in blocks.
>>
>>
>>
>> On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> So, can we conclude by something, whether or not it would be possible and
>> feasible in the future?
>>
>>
>> On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail
>> wrote:
>> > > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev
>> wrote:
>> > > like a hashcash-based alternative broadcast scheme.
>> > Hi Peter,
>> > I've been mulling the idea of attaching work to low fee txns, both as a
>> compensation (e.g., in a sidechain, or an alt), and/or as a spam proof.
>> Unfortunately, both suffer from ASICs:
>> > For spam proof case, the adversary can easily buy a used/obsolete
>> device to produce lots of spam txns very cheaply, unless you put the bar
>> very high, making it almost impossible for average users to even try.
>> > The compensation scenario is pretty off-topic, still, interesting
>> enough for 1 min read:
>> > Wallets commit to the latest blockchain state in the transaction AND
>> attach work.
>> > It is considered contribution to the security (illegitimate chains
>> can't include the txn), hence isrewarded by fee discount/exemption
>> depending on the offset of the state they've committed to (the closer, the
>> better) and the amount of work attached.
>> > For this to work, block difficulty is calculated inclusive with the
>> work embedded in the txns, it contains. Sophisticated and consequential,
>> yet not infeasible per se.
>> >
>> > Unfortunately, this scheme is hard to balance with ASICs in the scene
>> too, for instance, you can't subsidize wallets for their work like with a
>> leverge, because miners can easily do it locally, seizing the subsidies for
>> themselves, long story, not relevant just ignore it.
>>
>> We're not talking about a consensus system here. Just a way to rate-limit
>> access to a broadcast network used by a small minority of nodes. It's
>> completely ok to simply change the PoW algorithm in the _highly_ unlikely
>> event
>> someone bothers to build an ASIC for it. Since this isn't a consensu
>> system,
>> it's totally ok if multiple versions of the scheme run in parallel.
>> _______________________________________________
>> 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/20220803/8badd1b8/attachment-0001.html>

2023-06-07 23:11:08

- reply

📅 Original date posted:2022-07-14
📝 Original message:@Peter Todd
> The fact of the matter is that the present amount of security is about
1.7% of
the total coin supply/year
That's on the order of what I calculated
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#analysis-of-various-consensus-algorithms>:
~0.5%. I'm curious where the 1.7% number comes from. Perhaps much of the
difference in our two numbers likely comes from me incorporating what I
call the "Economic Mining Monopoly Attack"
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#economic-mining-monopoly-attack>
which effectively cuts the security in half.
> There's zero reason to stress about finding an "optimal" amount. An
amount low enough to be easily affordable, but non-zero, is fine.
That's fair. What I mean is that we should estimate an optimal value to
some degree of accuracy. It doesn't have to be super accurate. But too low
and we could have a bad time. Too high and its a deadweight cost forever
(which increases fees, slows adoption, and causes an inflation-like
devaluation force on bitcoin, which has all the familiar market distorting
effects, albeit to a much smaller degree than we're used to). In any case,
we need to come to an accurate enough estimate of how much is enough
security so that we ensure we're above that amount.
> These are all amounts that are likely to be dwarfed by economic shifts.
Perhaps you're right. Regardless, its certainly an improvement to what
we've had the last 100 years.
@Erik Voskuil
> You cannot support the blanket statement (and absent any assumption) that
lower confirmation rates produce “much higher fees” or “better security”.
I can in fact support it. The theory of supply and demand supports it.
Well, depending on what you mean by "fees". Reducing the block size will
certainly increase average fees/vbyte. Whether it increases total fees
collected by miners (and thus lead to "better security") is another story -
a story that depends on the demand dynamics in the market. It could very
well be that reducing the blocksize reduces the number of transactions by a
higher proportion than fees go up. As we have seen in past periods of high
traffic tho, total fees go up *quite* a lot. So it seems pretty clear to me
that constraining the block size would very likely increase total fees
collected by miners, at least for the near future.
@Carvalho
> I will reiterate. Proof of work and the difficulty adjustment scheme
already solve all of these issues
You haven't addressed any of the comments that disagree with you above. You
didn't address any of my comments originally. You are simply claiming
things without any logical support. If you want to be a respectable part of
this conversation, I'd recommend explaining yourself much more thoroughly.
> That restaurant is too popular, nobody goes there anymore.
If you could feed 100,000 people with 1 entire from a restaurant, your
restaurant might not make enough money to survive despite feeding the
entire country. That's what the lightning network does for/to bitcoin. We
need to make sure the restaurant can afford to staff itself despite massive
increases in food-use efficiency.
On Fri, Jul 8, 2022 at 12:32 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil <eric at voskuil.org> wrote:
>
>> Value is subjective, though a constraint of 1tx per 10 minutes seems
>> unlikey to create a fee of 5000x that of 5000tx. This is of course why I
>> stated my assumption. Yet this simple example should make clear that at
>> some point a reduction in confirmation rate reduces reward. Otherwise a
>> rate of zero implies infinite reward.
>>
>
> Like i said, it's not linear. So no, a rate of 0 does not imply an
> infinite reward. A number of papers on the Nash equilibrium of mining
> rewards and block size have been written. There are block sizes that
> are optimal for fees, and they obviously not zero, where the system
> collapses, and they are obviously not infinite... where all bidders pay 1
> sat/byte.
>
>
>>
>> You cannot support the blanket statement (and absent any assumption) that
>> lower confirmation rates produce “much higher fees” or “better security”.
>>
>
> You can look at the research and the history of zero-size block impact on
> fees and see that this is true.
>
>
>
>>
>> What you call a “bidding war” is merely market pricing, as it occurs with
>> any good. People *always* will pay as much as they will pay. This is
>> tautological. What you cannot say is how much more someone will pay at any
>> given time for any given good, until they have done it. And I’m pretty sure
>> Bitcoin hasn’t done it.
>>
>
> If there is infinite supply, then there is zero value. Infinite blocks
> have lower fees. This is impossible to argue against.
>
>
>> You cannot prove what the price of anything will be, nor can any
>> “papers”. The absurdity of S2F should have clearly demonstrated that by
>> now. Value is an individual human preference.
>>
>
> A trivial example: block sizeof 10, and 10 people want to transact, all
> can bid 1 SAT/byte, 2 tx are moving 100 mil sats, the other 8 are moving 10
> mil sats. Block size of 2. Now the two transactions moving 100 mil sats
> will bid, they can easily pay 400 sats/byte.
>
> You can show, from history, that when block sizes are more constrained,
> due to the mining of zero byte blocks, total fees were higher. People
> will always pay for "next confirm" if the cost of that is very reasonable
> (less than 0.1%).
>
>>
>> If everyone pays 1 sat, then either miners are profitable at 1 sat, or
>> these people are not getting confirmed (economic rationality always
>> assumed).
>>
>
> Yes, and if miners are not profitable at 1 sat, then they will not mine,
> and the hash rate will drop. And this reduces the security of the coin.
> Hashrate is an index of security.
>
> But there is of course no real issue here. Simply fork off an inflation
>> coin and test your theory. I mean, that’s the only way it can happen anyway.
>>
>
> I would argue inflation is not a good solution. Instead, being cautious
> about block-compressing tech, like mweb, and being more aggressive about
> fee-driving tech, makes more sense .
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220713/ee9b842f/attachment-0001.html>

2023-06-07 23:10:58

- reply

📅 Original date posted:2022-07-08
📝 Original message:@vjudeu
> better to allow transaction joining.. to make fees more smoothly
I'm not familiar with RSK transaction joining. However, I don't think this
addresses the issues Corey brought up - which is that the
appropriate amount of security (ie miner revenue) isn't linked with any
bitcoin market behavior. It sounds like you're suggesting something that
could smooth out the fee market and potentially lower fees, however it
doesn't sound like a mechanism that could be used to target a particular
security level.
> I think the market should adjust fees, and finding the right balance
between on-chain and off-chain should be left to the users, just by
providing them options like transaction joining
The market has an incentive to minimize fees. So I don't see how this would
be sufficient if it ends up that miner revenue from fees is too low.
@Erik
> I think perhaps you're underestimating the degree to which utility can
be added to the main chain to encourage fees.
It seems you've misinterpreted me to be saying that fees will be too low. I
have no idea if fees will be too low or not. And you might be right that
fees are likely to remain high enough. However, fees might also remain *too
high* which itself could be a problem. As I noted above, since market
forces all incentivize driving fees down, what do we do if that force
drives it below a sufficient level? How will we know when that happens
until we know what the sufficient level of security is (eg in terms of
total miner revenue).
@Guiseppe
> If it only takes a few million dollars to attack BTC and make it
completely unusable for one day
It would take much more than a few million to 51% attack bitcoin. Bitcoin's
blockchain security is primarily based on the capital cost of buying up a
massive amount of hashpower. The ongoing maintenance and electricity costs
of mining are actually not very relevant to security because all those
ongoing costs are directly offset by mining revenues. Its the upfront costs
that serve as the primary barrier an attacker must surpass. Acquiring the
mining hardware, finding places where energy costs are low enough, setting
up the equipment, etc. To do that costs billions of dollars, not millions.
On Thu, Jul 7, 2022 at 9:44 AM Giuseppe B via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> It's the first time I read about the security budget and it definitely
> sounds scary to me.
> If it only takes a few million dollars to attack BTC and make it
> completely unusable for one day, I suppose it's only a matter of time
> before some hedge fund actually does it, using a short position to profit
> from the huge panic sell wave and global loss of confidence that would
> result from it.
> It seems even cheaper to do than the recent attack to Terra, unless I'm
> missing something.
>
>
> On Wed, Jul 6, 2022, 1:10 PM <vjudeu at gazeta.pl> wrote:
>
>> > If the only realistic (fair, efficient & proportionate) way to pay for
>> Bitcoin's security was by having some inflation scheme that violated the 21
>> million cap, then agreeing to break the limit would probably be what makes
>> sense, and in the economic interest of its users and holders.
>>
>> So, Paul Sztorc was right again, there are three options: Enormous Block
>> Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come
>> From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png.
>> And I think using Merged Mining is the best option. More about that:
>> https://www.truthcoin.info/blog/security-budget-ii-mm/
>>
>> > Another option, if we were to decide we are over-secured in the short
>> term, would be to soft-fork in a reduction in the current and near-future
>> mining rewards, by somehow locking the coins in a contract that deprived
>> the miner of the full reward, and then using that contract to pay the
>> rewards out far in the future, should at some point we feel the security
>> budget was insufficient.
>>
>> Yes, that's also possible, RSK uses that. And making some kind of
>> soft-fork for that is also possible, but I don't know if miners will agree
>> to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY
>> OP_DROP OP_TRUE".
>>
>> On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >Bitcoin's finite supply is the main argument for people investing in it,
>> the whole narrative around bitcoin is based on its finite supply. While it
>> has its flaws and basically condemns bitcoin to be only used as a store >of
>> value (and not as a currency), I don't think it's worth questioning it at
>> this point.
>> >
>> >Just my 2 sats.
>> >
>> >Giuseppe.
>>
>>
>> A finite supply alone is not enough to give something value, as it must
>> also be useful in some way. In the case of Bitcoin, various forms of
>> cryptographic security must all work - and work together - to make Bitcoin
>> useful. If the only realistic (fair, efficient & proportionate) way to pay
>> for Bitcoin's security was by having some inflation scheme that violated
>> the 21 million cap, then agreeing to break the limit would probably be what
>> makes sense, and in the economic interest of its users and holders.
>>
>> There will always be competitive pressures with respect to efficiency,
>> and both being over-secured and under-secured would be economically
>> inefficient for a crypto currency, and thereby laving room for a more
>> optimally-secured competitor to gain ground. Currently there is zero
>> feedback in the Bitcoin system between what we might think is the optimum
>> amount of security and what actually exists. There is also zero agreement
>> on how much security would constitute such an optimum. Figuring out how
>> much security is needed, or even better, figuring out a way to have a
>> market mechanism to answer that question, will be an important project.
>>
>> Another option, if we were to decide we are over-secured in the short
>> term, would be to soft-fork in a reduction in the current and near-future
>> mining rewards, by somehow locking the coins in a contract that deprived
>> the miner of the full reward, and then using that contract to pay the
>> rewards out far in the future, should at some point we feel the security
>> budget was insufficient. Anthony Towns presented a form of this concept in
>> greater detail at a Scaling Bitcoin conference some years ago. While this
>> solution, if employed, would only work for some finite amount of time, it
>> is possible that could give additional decades before the accumulated
>> security budget was exhausted.
>>
>>
>> Corey
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220708/fd7b41a1/attachment-0001.html>

2023-06-07 23:10:55

- reply

📅 Original date posted:2022-07-06
📝 Original message:@Corey
> Currently there is zero feedback in the Bitcoin system between what we
might think is the optimum amount of security and what actually exists.
I basically agree with this. The pedantic part of my mind does want to
point out that the link between block subsidy and bitcoin's price does
actually give somewhat of a feedback loop, in that the higher the price,
the more valuable bitcoin is as a whole (at least as viewed by the active
market), and therefore the more investment in security is appropriate.
However, in the long run when the subsidy reduces to insignificance, we
basically lose this link. And even with this link, it's not very direct.
Fees retain only a little bit of this behavior, because presumably a more
valuable bitcoin is more valuable to spend, but the link to security is
very tenuous there.
> There is also zero agreement on how much security would constitute such
an optimum.
This is really step 1. We need to generate consensus on this long before
the block subsidy becomes too small. Probably in the next 10-15 years. I
wrote a paper
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity>
that uses a framework for thinking about how much security bitcoin might
need. The concept is that we should figure out what bitcoin's bottlenecks
are, and figure out the minimum requirements we want to place on running a
node based on how many (public) nodes we think we need and what percentage
of machines out there are likely to run a node. The goals I chose to
explore in that paper are totally up for debate, and I think its an
important debate to have. But they are basically a first stab at setting up
what we would need to determine optimum security. I would very much
appreciate your review of that part of the paper, Corey.
> Figuring out how much security is needed, or even better, figuring out a
way to have a market mechanism to answer that question, will be an
important project.
My thoughts on this are that we will need to periodically make some
software change to adjust a *target amount of investment in security*,
because the components of bitcoin's blockchain security are not all
predictable. Many unpredictable things factor into bitcoin's security (eg
miner behavior, pools, how many people generally run public nodes on their
own, what features require running public nodes, value of bitcoin, etc.
The primary mechanism we have to change how much security we have is to
change the block size, which changes how much fees miners can collect each
block. This isn't a linear thing. Its probably a parabola with a peak,
where at that peak, making the block either smaller and larger would both
reduce total fees paid. This is because when blocksize is higher, more
transactions (and thus more fees) can be collected, but at the same time
average fees will be lower. The pull of those two forces should define that
parabola.
So my suggestion here would be that we should target a certain amount of
security and have programmatic adjustments to the block size in order to
stay near enough to the parabolic maximum so that we pay miners enough to
give us sufficient blockchain security. Conversely, it should also attempt
to minimize how much "extra" security we pay for. It would be wasteful to
pay 3 times as much for 3 times the security we actually need. Such a thing
is a very real form of devaluation that basically represents a tax on
bitcoin and users of bitcoin. And its very possible for the position of
this parabola to change over time. We could never say with certainty
whether we're on one side of the parabola's maximum or the other. This
would make it rather complex to track well.
Additionally, there's no clear trustless way to determine the market value
of bitcoin at any given time, which makes it difficult to maintain this
target over time. As the market value of bitcoin changes, that target could
become quite inaccurate. This implies that we would need to do periodic
adjustments to the target, either through periodic forks or through some
other mechanism for changing the target.
If there were a good trustless way to determine the market value of
bitcoin, we would have to "manually" change this target potentially much
less often. Transaction fees kind of have an association with market value.
Perhaps some kind of analysis can be done on that to make a reasonable
prediction of what market value is based on fees. Or maybe blocks can
commit to a market price similarly to how they commit to a timestamp (which
is also only verifiable to an approximation and can only be verified close
to when it was mined but not eg years later).
On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > If the only realistic (fair, efficient & proportionate) way to pay for
> Bitcoin's security was by having some inflation scheme that violated the 21
> million cap, then agreeing to break the limit would probably be what makes
> sense, and in the economic interest of its users and holders.
>
> So, Paul Sztorc was right again, there are three options: Enormous Block
> Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come
> From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png.
> And I think using Merged Mining is the best option. More about that:
> https://www.truthcoin.info/blog/security-budget-ii-mm/
>
> > Another option, if we were to decide we are over-secured in the short
> term, would be to soft-fork in a reduction in the current and near-future
> mining rewards, by somehow locking the coins in a contract that deprived
> the miner of the full reward, and then using that contract to pay the
> rewards out far in the future, should at some point we feel the security
> budget was insufficient.
>
> Yes, that's also possible, RSK uses that. And making some kind of
> soft-fork for that is also possible, but I don't know if miners will agree
> to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY
> OP_DROP OP_TRUE".
>
> On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >Bitcoin's finite supply is the main argument for people investing in it,
> the whole narrative around bitcoin is based on its finite supply. While it
> has its flaws and basically condemns bitcoin to be only used as a store >of
> value (and not as a currency), I don't think it's worth questioning it at
> this point.
> >
> >Just my 2 sats.
> >
> >Giuseppe.
>
>
> A finite supply alone is not enough to give something value, as it must
> also be useful in some way. In the case of Bitcoin, various forms of
> cryptographic security must all work - and work together - to make Bitcoin
> useful. If the only realistic (fair, efficient & proportionate) way to pay
> for Bitcoin's security was by having some inflation scheme that violated
> the 21 million cap, then agreeing to break the limit would probably be what
> makes sense, and in the economic interest of its users and holders.
>
> There will always be competitive pressures with respect to efficiency, and
> both being over-secured and under-secured would be economically inefficient
> for a crypto currency, and thereby laving room for a more optimally-secured
> competitor to gain ground. Currently there is zero feedback in the Bitcoin
> system between what we might think is the optimum amount of security and
> what actually exists. There is also zero agreement on how much security
> would constitute such an optimum. Figuring out how much security is needed,
> or even better, figuring out a way to have a market mechanism to answer
> that question, will be an important project.
>
> Another option, if we were to decide we are over-secured in the short
> term, would be to soft-fork in a reduction in the current and near-future
> mining rewards, by somehow locking the coins in a contract that deprived
> the miner of the full reward, and then using that contract to pay the
> rewards out far in the future, should at some point we feel the security
> budget was insufficient. Anthony Towns presented a form of this concept in
> greater detail at a Scaling Bitcoin conference some years ago. While this
> solution, if employed, would only work for some finite amount of time, it
> is possible that could give additional decades before the accumulated
> security budget was exhausted.
>
>
> Corey
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220706/d5a48a69/attachment.html>

2023-06-07 23:10:17

- reply

📅 Original date posted:2022-06-15
📝 Original message:> two aspects to consensus
Well, consensus isn't just one thing with two aspects. There are many
things one might ask for consensus about, and many groups you might ask for
it from. There's miner consensus about transaction ordering, miner
consensus about soft fork signaling, developer consensus about the
desirability and readiness of a particular change (to the code / miner
consensus rules), there's consensus about these changes from various sub
communities within and related to bitcoin, and the broader consensus of the
whole bitcoin community. And probably many others. Most of these types of
consensus involve trust to various degrees. I think that's what you mean
by there being more than one aspect of consensus, yes?
> the live advogato system .. remained 100% spam-free of off-topic articles
throughout its entire life.
Very impressive!
> if those pseudo-identities are not linked to anyone .. they .. remain
isolated.
I see. Because anyone measuring consensus is only measuring it with respect
to their own trust network, anyone not transitively trusted by the person
measuring consensus is simply ignored.
> i made some modifications that required a *minimum number* of incoming
Trust Declarations before Flow was permitted to cross outwards.
I wouldn't think this is sufficient, since an attacker could put in effort
to achieve whatever minimum you come up with. For example, an attacker
could pose as someone with a particular popular point of view, put in
effort to produce actual helpful content that's interesting to their target
audience, and therefore get plenty of trust from people, but then they
could mark themselves as trusting of various sock puppets. The only way I
can think of solving that problem is for people in the community to be able
to investigate and somehow recognize something's weird about who that
outwardly helpful person trusts and detrust them because of it. Are there
other mechanisms to deal with this kind of thing, maybe as part of Keynote?
> hilariously, such isolated networks, being easy to identify, and also
entirely public, allow the existence of attackers to come to public
awareness.
I suppose this is related to my thought above.
> negative Certs were discussed but never implemented because they could do
more harm than good.
How so?
> the other weakess is: *it takes discipline to maintain*. you cannot
incentivise people to do this kind of thing without risking invitation of
bribery.
What do you mean by "discipline"? Discipline amongst who? The whole
network? The operator of something like Avogato? An individual who wants to
measure consensus?
> a zero-value transaction gets the entry into the chain.
> who on earth wants to pay BTC to make some "stupid" declaration of whom
they "trust"?
I don't see a reason to commit any of this data to the blockchain. Why not
just have a network where nodes collect and/or query for the data they
need? Such a thing would be far less expensive (could potentially even be
free). Since declarations of trust are always signed, they're all
verifiable. There's no double spending problem here because any "double
spend" (ie two signed conflicting declarations) only serves to dilute or
nullify that person's contribution to consensus (which is basically only
bad for the "double spender"). If one wanted to connect a signed
declaration to a block, they could simply include the block hash in the
signature, which would verify that the declaration was signed after that
block happened, and it could mean that the declaration is valid from that
block until a new declaration is signed with a newer block's hash. If one
wanted to but some financial barriers in place to limit sybil attacks, you
could require a zero-value transaction that records the public key (or a
hash of the public key) like you mentioned. However, rather than charging a
fee to register a public key, you could instead simply require that the
public key be associated with UTXOs. This works best when it makes sense to
weight any declaration by the value contained in the associated UTXOs, like
I suggest doing with coin-weighted polling here
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>
.
On Thu, Jun 9, 2022 at 6:34 AM lkcl <luke.leighton at gmail.com> wrote:
> ------------------------------
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Wed, Jun 8, 2022 at 5:05 AM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
> >
> > That sounds like an interesting mechanism to help measure consensus -
>
> it is related to consensus but is not consensus as bitcoin sees it.
>
> there are two aspects to consensus:
>
> 1) the public declarations of "trust" (or other declarations)
> 2) the programmatic evaluation of the same resulting in automated
> decisions.
>
> conflating these two or assuming them to be inextricably intertwined
> results in severe limitations of the possible applications of bitcoin.
>
> > and a good way to do that would help bitcoin significantly I think. I
> don't quite see what the similarity is between Trust Metric and bitcoin
> tho.
>
> the mining is a "public declaration" where the "trust" may be
> computationally verified. it is... slightly different but similar enough to
> be able to fit
>
> >How would you propose "building it into" bitcoin?
>
> without requiring going through a BEP for that, use of the comment field
> would suffice. a zero-value transaction gets the entry into the chain.
>
> the comments can include a URL or a hash of a URL (if the conversation is
> supposed to be private), and must include a hash of an identity which can
> be verified (GPG Key, a BTC Wallet known to be linked to a user). yes, the
> end-result here is that the blockchain subsumes the role of a web-of-trust
> as part of the Operational Requirements [you can't have trust unless the
> pseudonym is provably-linkable to a user in a verifiable way. Monero
> protocol springs to mind here, as does Debian's GPG Key-signing protocols]
>
>
> from there it becomes a matter of writing programs that parse the chain,
> extracting the comments, parse them, and perform a "trust evaluation".
>
>
> note that these programs *do not* rely on any centralised party. any user
> may decide the "top-level seeds" (whom they implicitly trust 100%) which
> may only be themselves.
>
> > From my limited searching, it looks like trust metric is basically a
> graph of who trusts who, allowing you to quantify who's trusted among a
> particular set or subset of people. Is that right?
>
> using Transitive Relationships, yes. A trusts B, B trusts C, therefore it
> is reasonable for A to trust C (to some extent). If A trusts B *and* D, and
> both B *and* D trust C, thenA has a much higher level of confidence that
> they can trust C than in the first scenario.
>
> the use of the Ford-Fulkersson Max Flow Algorithm allows for an unordered
> graph of such "Trust Declarations" to be turned into a Directed Acyclic
> Graph, with weighting in order to deliberately "peter out" the possibility
> of long-distance Transitive Chains from being "faulty".
>
> [btw in pymmetry i did *not* use depth-first, as in Ford-Fulkersson, i
> used breadth-first. the cost of depth-first will be insane in a network as
> large as BTC]
>
> What is nice about the Max Flow Algorithm is that should there be a large
> genuine cluster of Declarations into a node that is a large number of
> degrees away from the "seeds", that node can still potentially receive a
> positive evaluation. Likewise, Nodes that have a limited number of
> Declarations get quickly filtered out.
>
> > I would think such a thing can be done completely separately from
> bitcoin, but used to answer questions about bitcoin.
>
> indeed. and many other uses.
>
> > I'm curious to know specifically how the metric works and how its
> resistant to adversaries, specifically how its sybil resistant.
>
> had to look that up
> https://en.m.wikipedia.org/wiki/Sybil_attack
>
> ok, so if those pseudo-identities are not linked to anyone that is linked
> to the "seeds", they can create as many Trust Declarations in between
> themselves as they damn well like: they get f***-all flow and consequently
> remain isolated.
>
> this was exactly what happened on the live advogato system and it remained
> 100% spam-free of off-topic articles throughout its entire life.
>
> > In particular I'm curious what weaknesses it has that could be gamed.
>
> rright. the problem comes if someone who *does* have Transitive Flow of
> Trust is fooled by the puppets into making a Declaration, "I trust one of
> these puppets because what they said looked reasonable to me at the time".
>
> and this was a weakness of the *original* advogato algorithm, because the
> application of the Ford Fulkersson algorithm was naive "flow in from edge
> equals flow out".
>
> i made some modifications that required a *minimum number* of incoming
> Trust Declarations before Flow was permitted to cross outwards.
>
> this led me to investigate Keynote (RFC2704) because i realised that there
> may be circumstances for which much more sophisticated Gating would be
> needed, and Keynote is perfect for that.
>
> (you could in theory use bitcoin scripts, but they're not really up to the
> task, as designed)
>
> revocation is needed, here, which will be interesting on top of a
> blockchain, for when people realise they've been duped.
>
>
> > It seems sybil resistance might be there for a while, but I can imagine
> that it might be possible for a colluding set of users to farm aliases with
> higher and higher reputation until they could take over the network.
>
> they can try but as i said above, if no Transitive Relationship exists to
> them, they can basically do whatever they like.
>
> hilariously, such isolated networks, being easy to identify, and also
> entirely public, allow the existence of attackers to come to public
> awareness.
>
> the only reason why such attackers can f*** with Facebook etc. is
> precisely because the attacks are behind the secretive closed doors of
> proprietary systems.
>
> if the entire database is public they have nowhere to hide.
>
>
> the other weakness of the original system was that there was neither
> expiry, revocation, nor "negative" Certs. people abandoned their account,
> someone misbehaved, and the Certs flowing to the misbehaving person
> remained.
>
> negative Certs were discussed but never implemented because they could do
> more harm than good.
>
> i wrote over a hundred articles on advogato, and Raph received MULTIPLE
> DEMANDS from really quite prominent Open Source Developers who had
> absolutely no business at all demanding Censorship and the removal of those
> articles. Raph pointed them at the *150* "Master" Level Certs i had
> received (which was a lot), and informed them that only when all 150 of
> those Certs were removed by each of those individuals, many of whom were
> also respected Community Members, would my "Master" Level drop and their
> demands that i no longer be permitted to post Articles would automatically
> and inherently be met.
>
> there's nothing that can be done about defamation or social abuse, in
> other words. just because technology exists doesn't make people become more
> humane.
>
>
> the other weakess is: *it takes discipline to maintain*. you cannot
> incentivise people to do this kind of thing without risking invitation of
> bribery. there were enough people begging "please Cert me" on underground
> forums as it was.
>
>
> > In bitcoin, there are good ways of bolstering such sybil resistance, eg
> by charging fees for identities in some way, or by requiring proof of funds.
>
> through requiring that the Trust Declarations be actual bitcoin
> transactions, that helps as well.
>
> the only problem then becomes a practical social one: who on earth wants
> to pay BTC to make some "stupid" declaration of whom they "trust"? and,
> more than that: are the *developers themselves* being actually paid enough
> in BTC such that they can *afford* to make a Declaration?
>
> or, sorry, crictical, critical correction: separating the Declaration from
> the payment threshold is important! anyone should be able to enter a
> zero-value Transaction with a Declaration of Trust, but whether their
> Declaration is *included in the Graph Processing* would be (a la Keynote)
> down to the independent post-processing.
>
> for example, if a Developer has five hundred incoming Declarations of
> Trust and they are only one degree away from the "seeds", it should be
> blindingly obvious that charging them for making Declarations is
> unnecessary. this "rule" would be expressed a la Keynote
>
> these things can be solved in other words.
>
> l.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220614/4276a352/attachment-0001.html>

2023-06-07 23:10:16

- reply

📅 Original date posted:2022-06-08
📝 Original message:That sounds like an interesting mechanism to help measure consensus - and a
good way to do that would help bitcoin significantly I think. I don't quite
see what the similarity is between Trust Metric and bitcoin tho. How
would you propose "building it into" bitcoin?
>From my limited searching, it looks like trust metric is basically a graph
of who trusts who, allowing you to quantify who's trusted among a
particular set or subset of people. Is that right? I would think such a
thing can be done completely separately from bitcoin, but used to answer
questions about bitcoin.
I'm curious to know specifically how the metric works and how its resistant
to adversaries, specifically how its sybil resistant. In particular I'm
curious what weaknesses it has that could be gamed. It seems sybil
resistance might be there for a while, but I can imagine that it might be
possible for a colluding set of users to farm aliases with higher and
higher reputation until they could take over the network. In bitcoin, there
are good ways of bolstering such sybil resistance, eg by charging fees for
identities in some way, or by requiring proof of funds.
On Sun, Jun 5, 2022 at 8:19 AM Luke Kenneth Casson Leighton via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> (apologies i am subscribed digest)
>
> On Sun, Jun 5, 2022 at 1:00 PM
> <bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>
> > Date: Sun, 05 Jun 2022 04:18:04 +0000
> > From: alicexbt <alicexbt at protonmail.com>
> > To: Bitcoin Protocol Discussion
> > <bitcoin-dev at lists.linuxfoundation.org>
> > Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
> > Message-ID:
> >
> <zyE-uR_2M7vAE8jXf3wthIGQj_-dz9FoL50ERTmCb-MCv4zyMgoHAdSff539SPtROJpJdgrfBspM3IZJrNQ9V4kpDnyMB9X6mlWf0eSk1Rk=@
> protonmail.com>
> > Hi Jorge,
> >
> >
> > Misinformation is false or inaccurate information, especially that which
> is deliberately intended to deceive.
> > A combination of 'misleading' and 'information'.
>
> it's a classic technique that was refined by psy-ops well over
> 60 years ago. it should come as no surprise at all that it is
> being systematically deployed to undermine bitcoin.
> (welcome to the party, all psy-ops teams reading this: i admire your
> persistence and tenacity. you serve an extremely useful purpose
> of detecting flaws in the resilience of bitcoin and its development.)
>
> a potential solution is Trust Metrics. the most successful open
> source experiment in that regard was advogato.org by Raph Levien.
>
> i expanded it greatly so that any user could specify the "seeds"
> whom *they* trusted, rather than being forced to utilise the fixed
> hard-coded user ids in the advogato.org source code (this difference
> is extremely important for de-centralisation)
>
> public declarations of trust, and their propagation through standard
> Maximum-Flow Graph analysis, helps greatly to filter out the crap.
> advogato deflected heavy systematic and sustained spam attacks
> thanks to the simple expedient of users declaring publicly whom
> they trusted.
>
> a more advanced version of the max-flow concept came up a few
> years later called keynote (RFC2704)
>
> the similarity between trust metric evaluation and the bitcoin protocol
> is so remarkable that i am, frankly, slightly stunned that it was not
> added right from the start.
>
> it is ironic that the lack of integrated trust metric evaluation built-in
> to the bitcoin protocol is now hampering developers from being able
> to evaluate whom to trust when it comes to protocol development.
>
> l.
> _______________________________________________
> 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/20220607/917931e8/attachment.html>

2023-06-07 23:10:14

- reply

📅 Original date posted:2022-06-09
📝 Original message:@jorge
> Who do you mean by "the non technical folks"?
I mean people that don't have software engineering skills. This is the
twittersphere, reddit, most podcasters, etc etc. This is the vast majority
of the bitcoin community, and the vast majority of.. everyone.
> You don't include alicexbt or yourself as a "technical folk", do you?
I have no idea what alicexbt's skillset is. I do include myself. I have a
degree in software engineering. I work as a programmer in the bitcoin
space. I have written papers on technical aspects of bitcoin. Why would you
assume that I'm not technical as someone who participates in the bitcoin
developers mailing list? Perhaps its projection?
On Wed, Jun 8, 2022 at 3:31 PM Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Who do you mean by "the non technical folks"?
> You don't include alicexbt or yourself as a "technical folk", do you?
>
>
> On Wed, Jun 8, 2022 at 8:38 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Wholeheartedly agree with you alicexbt. There are no technical issues
>> that have been shown that I'm aware of. Once the non-technical folks have
>> time to discuss it and realize that, I'm hopeful things will move forward.
>> Perhaps we can learn from this and figure out how to better catch the
>> attention of the larger bitcoin community for important changes without
>> alarming them.
>>
>> On Sun, Jun 5, 2022 at 2:48 AM alicexbt via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Jorge,
>>>
>>>
>>> Misinformation is false or inaccurate information, especially that which
>>> is deliberately intended to deceive. A combination of 'misleading' and
>>> 'information'. Here are a few examples and I am sure I missed a lot of
>>> others but its difficult for me to keep a track of everything:
>>>
>>>
>>> 1) Sapio is open source and everything mentioned in tweet is false:
>>> https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602
>>>
>>> 2) Personal attacks on author of BIP 119 with false information:
>>> https://nitter.net/s3cp256k1/status/1521238634111770624
>>>
>>> 3) Andreas Antonopoulos shared false things about CTV and explained by
>>> Ryan in this email:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html
>>>
>>> 4) Misleading things shared in these emails by Michael Folkson:
>>>
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
>>>
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>>>
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html
>>>
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html
>>>
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>>>
>>> 5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin
>>> and L2. I replied in this email:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html
>>>
>>> 6) Social media influencers like Peter McCormack tweeted they don't
>>> understand BIP 119 but its an attack (this was even retweeted by developers
>>> like Peter Todd):
>>> https://nitter.net/PeterMcCormack/status/1521253840963653632
>>>
>>> 7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine:
>>> https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained
>>>
>>> 8) There were lies and misinformation about BIP 119 on social media
>>> according to this Bitcoin Magazine article:
>>> https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it
>>>
>>> 9) John Carvalho tweeting false things:
>>>
>>> https://nitter.net/BitcoinErrorLog/status/1468599535538745359
>>>
>>> https://nitter.net/BitcoinErrorLog/status/1522652884218822658
>>>
>>> https://nitter.net/BitcoinErrorLog/status/1442554615967354880
>>>
>>> https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog)
>>>
>>> 10) Greg Maxwell responding to misinformation related to BIP 119 but
>>> adding false things in the comments:
>>> https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/
>>>
>>>
>>> I am not surprised by your email but it would be better if the people
>>> who are interested in reviewing BIP 119 could raise the bar and not share
>>> misleading information.
>>>
>>>
>>> /dev/fd0
>>>
>>>
>>> Sent with Proton Mail secure email.
>>> ------- Original Message -------
>>> On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón <jtimon at jtimon.cc>
>>> wrote:
>>>
>>>
>>> > "Some people say CTV is contentious, but they're spreading
>>> misinformation"? Really? Seriously?Come on, guys, we can do better than
>>> nina jankovich and the "fact checkers".
>>> > Please, rise the bar.
>>> > On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >
>>> > > Note: This email is an opinion and not an attack on bitcoin
>>> > >
>>> > > Covenants on bitcoin will eventually be implemented with a soft
>>> fork. CTV is the easiest and best possible way OP_TX looks good as well.
>>> Apart from the technical merits, covenants will improve a few other things:
>>> > >
>>> > > - Developers can build interesting projects with real demand in
>>> market.
>>> > > - Students learn Sapio and not just solidity.
>>> > > - Better tooling could be available for application developers.
>>> > > - Maybe we see bitcoin developer hackathons in different countries.
>>> > > - Demand for block space might increase, it wont be just exchanges
>>> and coinjoin.
>>> > > - Funding of bitcoin developers and projects might improve. Wont
>>> need to convince a few people for grants.
>>> > >
>>> > > **Why covenants are not contentious?**
>>> > >
>>> > > Some people may write paragraphs about CTV being contentious, spread
>>> misinformation and do all types of drama, politics etc. on social media but
>>> there are zero technical NACKs for CTV. We have discussed other covenant
>>> proposals in detail on mailing list and IRC meetings with an open minded
>>> approach.
>>> > >
>>> > > All the developers that participated in the discussion are either
>>> okay with CTV or OP_TX or covenants in general.
>>> > >
>>> > > **How and when should covenants be implemented in Bitcoin?**
>>> > >
>>> > > I don't think we should wait for years anticipating a proposal that
>>> everyone will agree on or argue for years to pretend changes are hard in
>>> Bitcoin. We should improve the review process for soft fork BIPs and share
>>> honest opinions with agreement, disagreement on technical merits.
>>> > >
>>> > > I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind
>>> anything else being used if that improves Bitcoin. Covenants implemented in
>>> Bitcoin before the next cycle would provide opportunity for developers to
>>> build interesting things during the bear market. Ossification supporters
>>> also believe there is some window that will close soon, maybe doing changes
>>> considering each case individually will be a better approach. CTV is not a
>>> rushed soft fork, less people followed the research and it was not
>>> mentioned on social media repeatedly by the respected developers like other
>>> soft forks.
>>> > >
>>> > > /dev/fd0
>>> > >
>>> > >
>>> > > Sent with Proton Mail secure email.
>>> > > _______________________________________________
>>> > > bitcoin-dev mailing list
>>> > > bitcoin-dev 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
>>
> _______________________________________________
> 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/20220608/e460f937/attachment-0001.html>

2023-06-07 23:10:13

- reply

📅 Original date posted:2022-06-08
📝 Original message:Wholeheartedly agree with you alicexbt. There are no technical issues that
have been shown that I'm aware of. Once the non-technical folks have time
to discuss it and realize that, I'm hopeful things will move forward.
Perhaps we can learn from this and figure out how to better catch the
attention of the larger bitcoin community for important changes without
alarming them.
On Sun, Jun 5, 2022 at 2:48 AM alicexbt via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Jorge,
>
>
> Misinformation is false or inaccurate information, especially that which
> is deliberately intended to deceive. A combination of 'misleading' and
> 'information'. Here are a few examples and I am sure I missed a lot of
> others but its difficult for me to keep a track of everything:
>
>
> 1) Sapio is open source and everything mentioned in tweet is false:
> https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602
>
> 2) Personal attacks on author of BIP 119 with false information:
> https://nitter.net/s3cp256k1/status/1521238634111770624
>
> 3) Andreas Antonopoulos shared false things about CTV and explained by
> Ryan in this email:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html
>
> 4) Misleading things shared in these emails by Michael Folkson:
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> 5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin and
> L2. I replied in this email:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html
>
> 6) Social media influencers like Peter McCormack tweeted they don't
> understand BIP 119 but its an attack (this was even retweeted by developers
> like Peter Todd):
> https://nitter.net/PeterMcCormack/status/1521253840963653632
>
> 7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine:
> https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained
>
> 8) There were lies and misinformation about BIP 119 on social media
> according to this Bitcoin Magazine article:
> https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it
>
> 9) John Carvalho tweeting false things:
>
> https://nitter.net/BitcoinErrorLog/status/1468599535538745359
>
> https://nitter.net/BitcoinErrorLog/status/1522652884218822658
>
> https://nitter.net/BitcoinErrorLog/status/1442554615967354880
>
> https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog)
>
> 10) Greg Maxwell responding to misinformation related to BIP 119 but
> adding false things in the comments:
> https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/
>
>
> I am not surprised by your email but it would be better if the people who
> are interested in reviewing BIP 119 could raise the bar and not share
> misleading information.
>
>
> /dev/fd0
>
>
> Sent with Proton Mail secure email.
> ------- Original Message -------
> On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón <jtimon at jtimon.cc>
> wrote:
>
>
> > "Some people say CTV is contentious, but they're spreading
> misinformation"? Really? Seriously?Come on, guys, we can do better than
> nina jankovich and the "fact checkers".
> > Please, rise the bar.
> > On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > Note: This email is an opinion and not an attack on bitcoin
> > >
> > > Covenants on bitcoin will eventually be implemented with a soft fork.
> CTV is the easiest and best possible way OP_TX looks good as well. Apart
> from the technical merits, covenants will improve a few other things:
> > >
> > > - Developers can build interesting projects with real demand in market.
> > > - Students learn Sapio and not just solidity.
> > > - Better tooling could be available for application developers.
> > > - Maybe we see bitcoin developer hackathons in different countries.
> > > - Demand for block space might increase, it wont be just exchanges and
> coinjoin.
> > > - Funding of bitcoin developers and projects might improve. Wont need
> to convince a few people for grants.
> > >
> > > **Why covenants are not contentious?**
> > >
> > > Some people may write paragraphs about CTV being contentious, spread
> misinformation and do all types of drama, politics etc. on social media but
> there are zero technical NACKs for CTV. We have discussed other covenant
> proposals in detail on mailing list and IRC meetings with an open minded
> approach.
> > >
> > > All the developers that participated in the discussion are either okay
> with CTV or OP_TX or covenants in general.
> > >
> > > **How and when should covenants be implemented in Bitcoin?**
> > >
> > > I don't think we should wait for years anticipating a proposal that
> everyone will agree on or argue for years to pretend changes are hard in
> Bitcoin. We should improve the review process for soft fork BIPs and share
> honest opinions with agreement, disagreement on technical merits.
> > >
> > > I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind
> anything else being used if that improves Bitcoin. Covenants implemented in
> Bitcoin before the next cycle would provide opportunity for developers to
> build interesting things during the bear market. Ossification supporters
> also believe there is some window that will close soon, maybe doing changes
> considering each case individually will be a better approach. CTV is not a
> rushed soft fork, less people followed the research and it was not
> mentioned on social media repeatedly by the respected developers like other
> soft forks.
> > >
> > > /dev/fd0
> > >
> > >
> > > Sent with Proton Mail secure email.
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev 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/20220607/f8344db4/attachment-0001.html>

2023-06-07 23:10:11

- reply

📅 Original date posted:2022-06-30
📝 Original message:@Alex
> The person who obtained greater economic utility from their two
transactions.
That is not the case. The economic utility gained by their two transactions
is probably almost entirely related to something other than bitcoin - the
nature of the specific transactions themselves. The value they got from
using bitcoin is the value they get from the properties of bitcoin when
compared against other competing things in the market (other currencies or
payment systems). Bitcoin's ability to finalize quickly, have no
counterparty risk, reduced 3rd party middleman fees, and the willingness of
that person to transact using bitcoin vs something else, to name a few.
My example was intended to make it very clear that the person who held
bitcoin over 10 years got more value from bitcoin itself, regardless of who
received more economic utility from their chosen transactions.
> Billy appeared to be indicating that the frequent movement of coins in
itself somehow produced utility
I was actually saying the opposite of that. My point, and the point of my
example I explained above, was that holders gain quite a bit of value from
bitcoin, and so bitcoin's value to its users is not derived solely from
transacting.
@Kate
> Pool operators are free to request larger fees from older utxos
You're absolutely right that whoever creates their block template can
decide how to include transactions. However, by doing such non-standard
things, they would lose money, so they are not incentivized to do that.
Keagan's point was about who pays for bitcoin's security. Right now it is
only transactors. And yet transactors are not the only actors who gain
value from the use of bitcoin. As such, the payment for bitcoin's security
is not spread proportionally to those who get value from the use of
bitcoin. It would certainly be ideal if bitcoin's security was paid for by
each actor proportionally to how much value they get from using bitcoin.
Worth it? Questionable. But ideal, certainly. You aren't going to get to
that ideal by expecting individual miners to altruistically lose money to
enact that ideal.
On Wed, Jun 29, 2022 at 3:44 AM Kate Salazar <
mercedes.catherine.salazar at gmail.com> wrote:
> Hey
>
> On Tue, Jun 28, 2022 at 10:43 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> @Eric
>> > People who transact are realizing the benefit of money - the avoidance
>> of barter costs.
>>
>> I'm very confident you're incorrect that holders don't receive any
>> benefit and you're certainly not correct that every spend is receiving the
>> same benefit. As I'm sure you're aware, one of the primary components of a
>> currency's value and purpose is as a store of value. Storing value happens
>> while you're holding it, not while you're spending it. Consider the
>> following two scenarios: one person holds onto 10 bitcoin for 10 years and
>> then spends those 10 bitcoins in some way in 2 transactions. Another person
>> spends 4 bitcoins to buy something, then sells it for 6 bitcoins, and then
>> buys something else for that 6 bitcoins and then never acquires any bitcoin
>> for 10 years.
>>
>> Both people spent 10 bitcoins over 2 transactions. Over that 10 year
>> period, only one of those people utilized bitcoin's utility as a store of
>> value. Who benefited more from their use of bitcoin?
>>
>> > Those who never transact, never realize any benefit.
>>
>> While that's true, its not relevant and basically a red herring. You need
>> to compare those who transact often and rarely hold, to those who hold a
>> lot but rarely transact. Its not helpful to consider those who throw their
>> bitcoin into a bottomless pit and never retrieve them.
>>
>> On an idealistic level, I agree with Keagan that it would make sense to
>> have "a balance of fees to that effect". I think doing that would be
>> technically/economically optimal. However, I think there is an enormous
>> benefit to having a cultural aversion to monetary inflation and the
>> consequences of convincing the bitcoin community that inflation is ok could
>> have unintended negative consequences (not to mention how difficult
>> convincing the community would be in the first place). There's also the
>> economic distortion that inflation causes that has a negative effect which
>> should also be considered. The idea of decaying utxo value is interesting
>> to consider, but it would not solve the economic distortion that
>> monetary inflation causes, because that distortion is a result of monetary
>> devaluation (which decaying utxos would be a form of). Then again, maybe in
>> this case the distortion of inflation would actually be a correction -
>> correcting for the externality of benefit received by holders. I'm
>> stream-of-consciousnessing a bit, but anyways, I suspect its not worth the
>> trouble to perfect the distribution of bitcoin blockchain security costs to
>> include holders. Tho, if I were to go back in time and influence how
>> bitcoin was designed, I might advocate for it.
>>
>
> Pool operators are free to request larger fees from older utxos, or from
> all utxos, or from newer utxos, at their judgement, looking at the
> blockspace demand census and at what the other pool operators are doing.
> This is not consensus, it's policy. It's not a technology problem, it's
> solved above in the social layer.
>
> If this kind of problem torments anyone, maybe miner decentralization hard
> forks are worth looking at, some already exist.
>
>
>>
>> @Peter
>> > demurrage and inflation have identical economic properties.
>>
>> The distortion of incentives is identical, however there is also the
>> effect it has on a currency's property as a useful unit of account.
>> Decaying utxos would mean that it would contribute substantially less to
>> market prices needing to change. I suspect this effect would be bordering
>> on negligible tho.
>>
>> On Thu, Jun 23, 2022 at 2:17 PM Peter Todd via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Tue, Jun 21, 2022 at 01:00:07PM -0600, Keagan McClelland via
>>> bitcoin-dev wrote:
>>> > > The PoW security of Bitcoin benefits all Bitcoin users, proportional
>>> to
>>> > the
>>> > value of BTC they hold; if Bitcoin blocks aren't reliably created the
>>> value
>>> > of
>>> > *all* BTC goes down. It doesn't make sense for the entire cost of that
>>> > security
>>> > to be paid for on a per-tx basis. And there's a high chance paying for
>>> it
>>> > on a
>>> > per-tx basis won't work anyway due to lack of consistent demand.
>>> >
>>> > FWIW I prefer the demurrage route. Having something with finite supply
>>> as a
>>> > means of measuring economic activity is unprecedented and I believe
>>> deeply
>>> > important. I'm sympathetic to the argument that the security of the
>>> chain
>>> > should not be solely the responsibility of transactors. We realize the
>>> > value of money on receipt, hold *and* spend and it would be
>>> appropriate for
>>> > there to be a balance of fees to that effect. While inflation may be
>>> > simpler to implement (just chop off the last few halvings), I think it
>>> > would be superior (on the assumption that such a hodl tax was
>>> necessary) to
>>> > keep the supply fixed and have people's utxo balances decay, at least
>>> at
>>> > the level of the UX.
>>>
>>> Demurrage makes protocols like Lightning much more complex, and isn't
>>> compatible with existing implementations. While demurrage could in
>>> theory be
>>> implemented in a soft-fork by forcing txs to contain an output with the
>>> demurrage-taxed amount, spending to a pool of future mining fees, I
>>> really
>>> don't think it's practical to actually do that.
>>>
>>> Anyway, demurrage and inflation have identical economic properties.
>>> They're
>>> both a tax on savings. The only difference is the way that tax is
>>> implemented.
>>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev 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/20220630/871e84df/attachment.html>

2023-06-07 23:10:08

- reply

📅 Original date posted:2022-06-28
📝 Original message:@Eric
> People who transact are realizing the benefit of money - the avoidance
of barter costs.
I'm very confident you're incorrect that holders don't receive any benefit
and you're certainly not correct that every spend is receiving the same
benefit. As I'm sure you're aware, one of the primary components of a
currency's value and purpose is as a store of value. Storing value happens
while you're holding it, not while you're spending it. Consider the
following two scenarios: one person holds onto 10 bitcoin for 10 years and
then spends those 10 bitcoins in some way in 2 transactions. Another person
spends 4 bitcoins to buy something, then sells it for 6 bitcoins, and then
buys something else for that 6 bitcoins and then never acquires any bitcoin
for 10 years.
Both people spent 10 bitcoins over 2 transactions. Over that 10 year
period, only one of those people utilized bitcoin's utility as a store of
value. Who benefited more from their use of bitcoin?
> Those who never transact, never realize any benefit.
While that's true, its not relevant and basically a red herring. You need
to compare those who transact often and rarely hold, to those who hold a
lot but rarely transact. Its not helpful to consider those who throw their
bitcoin into a bottomless pit and never retrieve them.
On an idealistic level, I agree with Keagan that it would make sense to
have "a balance of fees to that effect". I think doing that would be
technically/economically optimal. However, I think there is an enormous
benefit to having a cultural aversion to monetary inflation and the
consequences of convincing the bitcoin community that inflation is ok could
have unintended negative consequences (not to mention how difficult
convincing the community would be in the first place). There's also the
economic distortion that inflation causes that has a negative effect which
should also be considered. The idea of decaying utxo value is interesting
to consider, but it would not solve the economic distortion that
monetary inflation causes, because that distortion is a result of monetary
devaluation (which decaying utxos would be a form of). Then again, maybe in
this case the distortion of inflation would actually be a correction -
correcting for the externality of benefit received by holders. I'm
stream-of-consciousnessing a bit, but anyways, I suspect its not worth the
trouble to perfect the distribution of bitcoin blockchain security costs to
include holders. Tho, if I were to go back in time and influence how
bitcoin was designed, I might advocate for it.
@Peter
> demurrage and inflation have identical economic properties.
The distortion of incentives is identical, however there is also the effect
it has on a currency's property as a useful unit of account. Decaying utxos
would mean that it would contribute substantially less to market prices
needing to change. I suspect this effect would be bordering on negligible
tho.
On Thu, Jun 23, 2022 at 2:17 PM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Jun 21, 2022 at 01:00:07PM -0600, Keagan McClelland via
> bitcoin-dev wrote:
> > > The PoW security of Bitcoin benefits all Bitcoin users, proportional to
> > the
> > value of BTC they hold; if Bitcoin blocks aren't reliably created the
> value
> > of
> > *all* BTC goes down. It doesn't make sense for the entire cost of that
> > security
> > to be paid for on a per-tx basis. And there's a high chance paying for it
> > on a
> > per-tx basis won't work anyway due to lack of consistent demand.
> >
> > FWIW I prefer the demurrage route. Having something with finite supply
> as a
> > means of measuring economic activity is unprecedented and I believe
> deeply
> > important. I'm sympathetic to the argument that the security of the chain
> > should not be solely the responsibility of transactors. We realize the
> > value of money on receipt, hold *and* spend and it would be appropriate
> for
> > there to be a balance of fees to that effect. While inflation may be
> > simpler to implement (just chop off the last few halvings), I think it
> > would be superior (on the assumption that such a hodl tax was necessary)
> to
> > keep the supply fixed and have people's utxo balances decay, at least at
> > the level of the UX.
>
> Demurrage makes protocols like Lightning much more complex, and isn't
> compatible with existing implementations. While demurrage could in theory
> be
> implemented in a soft-fork by forcing txs to contain an output with the
> demurrage-taxed amount, spending to a pool of future mining fees, I really
> don't think it's practical to actually do that.
>
> Anyway, demurrage and inflation have identical economic properties. They're
> both a tax on savings. The only difference is the way that tax is
> implemented.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev 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/20220627/83152ae9/attachment.html>

2023-06-07 23:09:38

- reply

📅 Original date posted:2022-05-13
📝 Original message:Hi all,
Since there's recently been a lot more interest in discussing covenants and
alternative covenant proposals because of CTV, I figured I'd bring up my
own proposed covenant opcode again while the urge is still fresh.
To be clear upfront, this opcode has a spec, but nothing else. No tests. No
implementation. No signet. No tooling. While this is a serious proposal
that I think has a lot of benefits over any other covenant opcode proposal,
I am not suggesting that this should supplant CTV. I also don't have any
plans to work on an implementation of OP_CONSTRAINDESTINATION, and I
certainly wouldn't without more interest and an equal partner on a project
like this. I think CTV is a quite useful opcode that is simple and
incremental. OP_CD on the other hand is significantly more powerful, which
would be likely to lead to even more contention than what CTV has had.
To the opcode itself, there is already plenty of exposition about it in the
spec:
https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md
So I wanted to discuss it from the perspective of what it enables, pros and
cons, and key considerations:
*OP_CONSTRAINDESTINATION alone*
- Like OP_CTV
- Is fully enumerated (not open ended)
- Unlike OP_CTV
- Enables infinitely recursive covenants
- Does not and cannot prevent malleability on its own
The wallet vaults that can be created
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md>
using this are more flexible than ones that can be created with OP_CTV:
- Spends from a wallet vault can spend arbitrary amounts, and send the
rest back to a change address, just like a normal transaction.
- Arbitrary amounts of coins can be sent directly to any of the
addresses involved in the wallet vault without any risk of loss of funds.
- Anchor outputs are not (necessarily) necessary for fee bumping. A user
can have the option of creating a transaction that includes other inputs
that can contribute to the fee. Those inputs can also send to other
outputs, allowing one to basically attach an anchor output at
transaction-creation-time if they think they want it for CPFP fee bumping.
One less-than-ideal property shared with CTV wallet vaults:
- If the hot wallet / intermediate wallet key is stolen, the attacker
can steal funds after the owner initiates a normal spend.
The opcode requires some mechanism for fee limiting:
- As currently specified, an attacker who gets access to the hot key can
fee-grief the owner of the vault by spending all the coins as fees. The
proposed solution to this is to add an addition opcode to limit the fees,
called OP_LIMITFEECONTRIBUTION
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/lfc/bip-limit-fee-contribution.md>.
Another solution would be to require 100% of the output values go to the
destinations passed to OP_CONSTRAINDESTINATION, and rely on CPFP on an
anchor output to pay the fees, which seems less than ideal. A third
solution would be to include sponsor transactions alongside the opcode and
rely on those instead of CPFP. While I think sponsor transactions would be
very useful, always relying on an external wallet to pay the fees is IMO
not super great since it allows for inconvenient scenarios if all your
money is in this secure vault, in which case you simply wouldn't be able to
get it out without either first acquiring more bitcoin in a hotter wallet,
or doing a full recovery transaction with all your wallet vault keys.
The downsides compared to CTV:
- Increased implementation complexity and complexity of the possibility
space. The opcode's main purpose of ensuring that only certain addresses
are sent to might be simpler than CTV, but the aspect of counting output
values pushes it into more complex territory. And when you consider the
solutions to fee-griefing, that adds additional implementation and
possibility-space complexity (depending on how its done).
- txid malleability
*OP_CONSTRAINDESTINATION + OP_PUSHOUTPUTSTACK*
OP_PUSHOUTPUTSTACK
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>
is
an opcode that allows a script to dynamically add local state to an output
being created.
- Unlike OP_CTV
- Also enables infinitely recursive covenants and does not prevent
malleability.
- Can be open ended (not fully enumerated)
- Can produce dynamic state.
The wallet vaults that can be created with this combination of opcodes is a
bit better than ones with just OP_CD on its own:
- Even if the hot wallet key is stolen, the attacker cannot steal funds
without compromising all the seeds that make up the wallet vault.
However, the complexity is substantially higher:
- Being able to push dynamic state onto transactions substantially
increases the possibility space of covenant chains. There may be
significant consequences of this that no one has thought of yet.
*Summary*
These opcodes would allow the creation of wallet vaults that could be
intuitively used in almost the same way that a standard wallet can be used,
including mixing in arbitrary inputs and outputs (including ones you don't
own). With one more opcode
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>,
funds could be sent directly out of a wallet vault in a single transaction
(whereas most wallet vaults require two transactions to send money out to
an arbitrary destination).
The opcodes are significantly more complex and powerful than OP_CTV, and
also substantially less developed. However, I think they demonstrate a
number of important considerations for covenants in the context of wallet
vaults. Please feel free to respond or ask questions here or as a github
issue.
I think wallet vaults in particular are a very important mechanism to
enable much more secure self-custody setups without sacrificing so much
usability as normal multisig wallets require. Wallet vaults could enable
significantly faster growth in the rate of bitcoin holders who
self-custody. CTV is the only opcode that is ready, and no other opcode is
even being developed, let alone close to being ready. I don't see APO as a
good practical covenant mechanism as currently defined. Any "next" covenant
opcode would likely be 4-6 years out. I believe centralized custody is a
huge problem in the bitcoin ecosystem, so I think making it easier for
people to securely self-custody their bitcoins is an incredibly important
area of development. I believe even *if* some other covenant opcode makes
CTV completely obsolete (which it isn't at all clear to me is a likely
scenario), a 4-6 year head start on better self-custody mechanisms could go
a long way to saving a lot of people who need bitcoin a lot of pain (from
both custodial shenanigans and self-custody mishaps).
Cheers,
BT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220513/3f91a9e9/attachment-0001.html>

2023-06-07 23:09:33

- reply

📅 Original date posted:2022-05-13
📝 Original message:@alicexbt
> I think 'support' and 'opposition' can be replaced with readiness.
Miners should not consider signaling as voting.
I agree that it isn't voting, its signaling. But whether or not you call it
'readiness' or 'support', some miners will use it to signal 'support' and
will refuse to become ready if they do not support the change. Regardless,
I'm open to calling it "readiness" instead.
@Russell
> I'm sure there are lots of design choices available better than a
MUST_SIGNAL state that does not risk potentially taking a large fraction of
mining hardware offline for a protracted period of time.
I tend to agree. The case where the fork has not locked in, but some miners
are beginning to orphan other miners' blocks, seems like a rather chaotic
state to program into an activation mechanism. I do like the idea of using
orphaning to ensure that miners are alerted to the fact that a fork has
*already* locked in, but such a thing should be done at a low level (eg
orphan <10% of their blocks) - just high enough so the drop in revenue
makes them investigate, but as minimal as possible to avoid lots of orphans
and loss of hashpower.
On Wed, May 11, 2022 at 10:15 AM alicexbt <alicexbt at protonmail.com> wrote:
> Hi Billy,
>
> Thanks for the feedback. I agree with everything
> and bip-trinary-version-signaling looks interesting.
>
> > A primary difference from both BIP8 and BIP9 is that this proposal uses
> tri-state version signaling (rather than binary version bits) that can
> encode both active support as well as active opposition to an active soft
> fork.
>
>
> I think 'support' and 'opposition' can be replaced with readiness. Miners
> should not consider signaling as voting.
>
> > The meaning for each ternary value is as follows:
>
>
> 0 - No signal
> 1 - Ready for new consensus rules
> 2 - Not ready for new consensus rules
>
> The concept of a minimum and maximum threshold sounds intriguing, and I'm
> interested to read what other developers have to say about it.
>
> Concept ACK on removing LOT, using tri-state version signaling, min/max
> threshold and required threshold calculation.
>
>
> /dev/fd0
>
> Sent with ProtonMail secure email.
> ------- Original Message -------
> On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tetrud at gmail.com
> wrote:
>
>
>
> > I think this is a useful proposal. There are certainly things about BIP9
> that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but
> a BIP spec was never produced for it afaik. A possibly unhelpful comment:
> >
> > > minimum_activation_height
> > > I think a minor improvement would be to specify this as
> minimum_activation_blocks, ie a number of blocks passed the start_height.
> Slightly easier to reason about and change when necessary. I proposed
> semantics like that here.
> > > In any case, I'll give this a concept ACK. I would very much like
> future soft forks to use a previously specified activation mechanism rather
> than rolling out a rushed unspeced thing as part of the (very orthogonal)
> soft fork implementation.
> > > On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev
> bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> > > Hi Bitcoin Developers,
> > >
> > > There were some disagreements with speedy trial activation method
> recently and BIP 8 became controversial because of LOT earlier. I have
> tried to solve these two problems after reading some arguments for/against
> different activation methods by removing LOT from BIP 8 and calculating
> MUST_SIGNAL state based on threshold reached.
> > >
> > > BIP draft with no code and some changes in BIP 8:
> https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
> > >
> > > State transitions diagram: https://i.imgur.com/dj4bFVK.png
> > >
> > > This proposal removes lockinontimeout flag, activation never fails
> although MUST_SIGNAL can be longer if miners signaling does not reach the
> threshold. Longer period for MUST_SIGNAL state is useful for coordination
> if LOCKED_IN was not reached.
> > >
> > > MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached
> and blocks that fail to signal in MUST_SIGNAL phase are invalid.
> > >
> > > Example:
> > >
> > > - This activation method is used for a soft fork
> > > - Only 60% miners signaled readiness and timeout height was reached
> > > - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> > > - LOCKED_IN and ACTIVE states remain same as BIP 8
> > > - Soft fork is activated with a delay of 2 months
> > >
> > > /dev/fd0
> > >
> > > Sent with ProtonMail secure
> email._______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220513/6fbdf8b8/attachment.html>

2023-06-07 23:09:32

- reply

📅 Original date posted:2022-05-10
📝 Original message:I think this is a useful proposal. There are certainly things about BIP9
that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but
a BIP spec was never produced for it afaik. A possibly unhelpful comment:
> minimum_activation_height
I think a minor improvement would be to specify this as
minimum_activation_blocks, ie a number of blocks passed the start_height.
Slightly easier to reason about and change when necessary. I proposed
semantics like that here
<https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/bip-trinary-version-bits.md>
.
In any case, I'll give this a concept ACK. I would very much like future
soft forks to use a previously specified activation mechanism rather than
rolling out a rushed unspeced thing as part of the (very orthogonal) soft
fork implementation.
On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Bitcoin Developers,
>
> There were some disagreements with speedy trial activation method recently
> and BIP 8 became controversial because of LOT earlier. I have tried to
> solve these two problems after reading some arguments for/against different
> activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL
> state based on threshold reached.
>
> BIP draft with no code and some changes in BIP 8:
> https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
>
> State transitions diagram: https://i.imgur.com/dj4bFVK.png
>
> This proposal removes lockinontimeout flag, activation never fails
> although MUST_SIGNAL can be longer if miners signaling does not reach the
> threshold. Longer period for MUST_SIGNAL state is useful for coordination
> if LOCKED_IN was not reached.
>
> MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and
> blocks that fail to signal in MUST_SIGNAL phase are invalid.
>
> Example:
>
> - This activation method is used for a soft fork
> - Only 60% miners signaled readiness and timeout height was reached
> - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> - LOCKED_IN and ACTIVE states remain same as BIP 8
> - Soft fork is activated with a delay of 2 months
>
>
> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/> secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220510/af6e90ce/attachment.html>

2023-06-07 23:09:27

- reply

📅 Original date posted:2022-05-12
📝 Original message:@Jorge & Zmn
> A recursive covenant guarantees that the same thing will happen in the
future.
Just a clarification: a recursive covenant does not necessarily guarantee
any particular thing will happen in the future. Both recursives and a
non-recursive covenant opcodes *can* be used to guarantee something will
happen. Neither *necessarily* guarantee anything (because of
the possibility of alternative spend paths). A covenant isn't just a
promise, its a restriction.
A "recursive covenant" opcode is one that allows loops in the progression
through covenant addresses. Here's an example of a set of transitions from
one address with a covenant in the spend path to another (or "exit" which
does not have a covenant restriction):
A -> B
A -> C
B -> C
C -> A
C -> exit
The possible combinations of changes are:
A -> B -> C -> exit
A -> C -> A -> ...
A -> B -> C -> A -> ...
This would be a recursive covenant with an exit. Remove the exit
transition, and you have a walled garden. Even with this walled garden, you
can avoid going through address B (since you can skip directly to C).
A covenant opcode that can allow for infinite recursion (often talked about
as a "recursive covenant") can be used to return to a previous state, which
allows for permanent walled gardens.
So I would instead characterize a bitcoin covenant as:
A covenant in an input script places a requirement/restriction on the
output script(s) that input sends to. Pretty much any covenant allows for a
chain or graph of covenant-laden addresses to be prescribed, while a
"recursive covenant" opcode allows previous nodes in that graph to be
returned to such that the states can be looped through forever (which may
or may not have some way to exit).
One potentially confusing thing about the way covenants are usually talked
about is that in technical discussions about the risks of covenants, what
is being talked about is not what a particular covenant opcode always does,
but rather what the boundaries are on what can be done with that opcode.
Pretty much any recursive covenant you could design would be able to be
used to create normal simple non-walled-garden situations. The question is,
since they do allow someone to create walled gardens, is that ok.
I suppose maybe an interesting possibility would be to have a covenant
limit placed into a covenant opcode. Eg, let's say that you have
OP_LIMITEDCOVENANT (OP_LC) and OP_LC specifies that the maximum covenant
chain is 100. The 100th consecutive output with an OP_LC use could simply
ignore it and be spent normally to anywhere (given that the rest of the
script allows it). This could effectively prevent the ability to create
walled gardens, without eliminating most interesting use cases. Among
people who care about covenants on this mailing list, the consensus seems
to be that infinitely recursive covenants are not something to be afraid
of. However, if maybe something like this could make more powerful
covenants acceptable to a larger group of people, it could be worth doing.
On Thu, May 12, 2022 at 7:20 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Jorge,
>
> > I fail to understand why non recursive covenants are called covenants at
> all. Probably I'm missing something, but I guess that's another topic.
>
> A covenant simply promises that something will happen in the future.
>
> A recursive covenant guarantees that the same thing will happen in the
> future.
>
> Thus, non-recursive covenants can be useful.
>
> Consider `OP_EVICT`, for example, which is designed for a very specific
> use-case, and avoids recursion.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220512/23bd0000/attachment-0001.html>

2023-06-07 23:09:25

- reply

📅 Original date posted:2022-05-10
📝 Original message:> So if you don't want to receive restricted coins, just don't generate an
address with those restrictions embedded.
This is an interesting point that I for some reason haven't thought of
before. However...
> Unless governments can mandate that you generate these addresses AND
force you to accept funds bound by them for your services**, I don't
actually see how this is a real concern.
Actually, I think only the second is necessary. For example, if there was a
law that compelled giving a good or service if payment of a publicly
advertised amount was paid, and someone pays to an address that can be
shown is spendable by the merchant's keys in a way that the government
accepts, it doesn't matter whether the recipient can or has generated the
address.
Regardless I do think its still important to note that a government could
do that today using multisig.
> This is a reason to oppose legal tender laws for Bitcoin imo.
I agree.
On Mon, May 9, 2022 at 10:23 AM Keagan McClelland <
keagan.mcclelland at gmail.com> wrote:
> > > > To me the most scary one is visacoin, specially seeing what happened
> in canada and other places lately and the general censorship in the west,
> the supposed war on "misinformation" going on (really a war against truth
> imo, but whatever) it's getting really scary. But perhaps someone else can
> be more scared about a covenant to add demurrage fees to coins or
> something, I don't know.
> > > > https://bitcointalk.org/index.php?topic=278122
>
> > > This requires *recursive* covenants.
>
> > Actually, for practical use, any walled-garden requires *dynamic*
> covenants, not recursive covenants.
>
> There's actually also a very straight forward defense for those who do not
> want to receive "tainted" coins. In every covenant design I've seen to date
> (including recursive designs) it requires that the receiver generate a
> script that is "compliant" with the covenant provisions to which the sender
> is bound. The consequence of this is that you can't receive coins that are
> bound by covenants you weren't aware of*. So if you don't want to receive
> restricted coins, just don't generate an address with those restrictions
> embedded. As long as you can specify the spend conditions upon the receipt
> of your funds, it really doesn't matter how others are structuring their
> own spend conditions. So long as the verification of those conditions can
> be predictably verified by the rest of the network, all risk incurred is
> quarantined to the receiver of the funds. Worst case scenario is that no
> one wants to agree to those conditions and the funds are effectively burned.
>
> It's not hard to make the case that any time funds are being transferred
> between organizations with incompatible interests (external to a firm),
> that they will want to be completely free to choose their own spend
> conditions and will not wish to inherit the conditions of the spender.
> Correspondingly, any well implemented covenant contract will include
> provisions for escaping the recursion loop if some sufficiently high bar is
> met by the administrators of those funds. Unless governments can mandate
> that you generate these addresses AND force you to accept funds bound by
> them for your services**, I don't actually see how this is a real concern.
>
> *This requires good wallet tooling and standards but that isn't materially
> different than wallets experimenting with non-standard recovery policies.
>
> **This is a reason to oppose legal tender laws for Bitcoin imo.
>
> Keagan
>
> On Sun, May 8, 2022 at 11:32 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > This requires *recursive* covenants.
>>
>> Actually, for practical use, any walled-garden requires *dynamic*
>> covenants, not recursive covenants. CTV can get arbitrarily close to
>> recursive covenants, because you can have an arbitrarily long string of
>> covenants. But this doesn't help someone implement visacoin because CTV
>> only allows a specific predefined iteration of transactions, meaning that
>> while "locked" into the covenant sequence, the coins can't be used in any
>> way like normal coins - you can't choose who you pay, the sequence is
>> predetermined.
>>
>> Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>)
>> don't automatically allow for practical walled gardens. Recursion
>> definitely allows creating walled gardens, but those gardens would be
>> impractically static. You could add millions of potential addresses to send
>> to, which would "only" quadruple the size of your transactions, but if
>> anyone creates a new address you want to send to, you wouldn't be able to.
>> Everyone would have to have a single address whitelisted into every
>> government-bitcoin output. If someone lost their key and needs to create a
>> new wallet, suddenly no one would be able to pay them.
>>
>> In order to really build a wallet garden, infinite recursion isn't really
>> necessary nor sufficient. You need to be able to dynamically specify
>> destination addresses. For example, if you were a government that wants to
>> make a walled garden where you (the government) could confiscate the funds
>> whenever you wanted, you'd have to have a covenant that allows the end-user
>> to specify an arbitrary public key to send money to. The covenant might
>> require that user to send to another covenant that has a government spend
>> path, but also has a spend path for that user-defined public key. That way,
>> you (the government) could allow people to send to each other arbitrarily,
>> while still ensuring that you (the government) could spend the funds no
>> matter where they may have been sent. Even without recursive covenants, you
>> could have arbitrarily long chains of these, say 1 million long, where at
>> the end of the chain the user must send your coins back to the government
>> who can then send them back with another million-long chain of covenants to
>> work with.
>>
>> OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf> can
>> do this kind of dynamicness, and OP_PUSHOUTPUTSTACK
>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md> can
>> enable it for things like OP_TLUV and OP_CD. I personally think dynamic
>> covenants are a *good* thing, as it enables more secure wallet vaults,
>> among other things. And I'm not worried about a government creating a
>> in-bitcoin visa-coin. Why? Because they can already do it today. They have
>> been able to do it for 9 years already. How?
>>
>> Replace the covenant above with a multisig wallet. The government has 2
>> keys, you have 1 key. Every time you make a transaction, you request the
>> government's signature on it. The government then only signs if you're
>> sending to a wallet they approve of. They might only sign when you're
>> sending to another multisig wallet that the government has 2 of 3 keys for.
>> Its a very similar walled garden, where the only difference is that the
>> government needs to actively sign, which I'm sure wouldn't be a huge
>> challenge for the intrepid dictator of the land. You want to add
>> demurage fees? Easy, the government just spends the fee out of everyone's
>> wallets every so often.
>>
>> On the other hand, OP_CTV *cannot* be used for such a thing. No
>> combination of future opcodes can enable either recursion or dynamicness to
>> an OP_CTV call.
>>
>>
>>
>> On Sat, May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Good morning Jorge,
>>>
>>> > I think people may be scared of potential attacks based on covenants.
>>> For example, visacoin.
>>> > But there was a thread with ideas of possible attacks based on
>>> covenants.
>>> > To me the most scary one is visacoin, specially seeing what happened
>>> in canada and other places lately and the general censorship in the west,
>>> the supposed war on "misinformation" going on (really a war against truth
>>> imo, but whatever) it's getting really scary. But perhaps someone else can
>>> be more scared about a covenant to add demurrage fees to coins or
>>> something, I don't know.
>>> > https://bitcointalk.org/index.php?topic=278122
>>>
>>> This requires *recursive* covenants.
>>>
>>> At the time the post was made, no distinction was seen between recursive
>>> and non-recursive covenants, which is why the post points out that
>>> covenants suck.
>>> The idea then was that anything powerful enough to provide covenants
>>> would also be powerful enough to provide *recursive* covenants, so there
>>> was no distinction made between recursive and non-recursive covenants (the
>>> latter was thought to be impossible).
>>>
>>> However, `OP_CTV` turns out to enable sort-of covenants, but by
>>> construction *cannot* provide recursion.
>>> It is just barely powerful enough to make a covenant, but not powerful
>>> enough to make *recursive* covenants.
>>>
>>> That is why today we distinguish between recursive and non-recursive
>>> covenant opcodes, because we now have opcode designs that provides
>>> non-recursive covenants (when previously it was thought all covenant
>>> opcodes would provide recursion).
>>>
>>> `visacoin` can only work as a recursive covenant, thus it is not
>>> possible to use `OP_CTV` to implement `visacoin`, regardless of your
>>> political views.
>>>
>>> (I was also misinformed in the past and ignored `OP_CTV` since I thought
>>> that, like all the other covenant opcodes, it would enable recursive
>>> covenants.)
>>>
>>>
>>> Regards,
>>> ZmnSCPxj
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220510/06d05ed0/attachment-0001.html>

2023-06-07 23:09:24

- reply

📅 Original date posted:2022-05-08
📝 Original message:> This requires *recursive* covenants.
Actually, for practical use, any walled-garden requires *dynamic*
covenants, not recursive covenants. CTV can get arbitrarily close to
recursive covenants, because you can have an arbitrarily long string of
covenants. But this doesn't help someone implement visacoin because CTV
only allows a specific predefined iteration of transactions, meaning that
while "locked" into the covenant sequence, the coins can't be used in any
way like normal coins - you can't choose who you pay, the sequence is
predetermined.
Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>)
don't automatically allow for practical walled gardens. Recursion
definitely allows creating walled gardens, but those gardens would be
impractically static. You could add millions of potential addresses to send
to, which would "only" quadruple the size of your transactions, but if
anyone creates a new address you want to send to, you wouldn't be able to.
Everyone would have to have a single address whitelisted into every
government-bitcoin output. If someone lost their key and needs to create a
new wallet, suddenly no one would be able to pay them.
In order to really build a wallet garden, infinite recursion isn't really
necessary nor sufficient. You need to be able to dynamically specify
destination addresses. For example, if you were a government that wants to
make a walled garden where you (the government) could confiscate the funds
whenever you wanted, you'd have to have a covenant that allows the end-user
to specify an arbitrary public key to send money to. The covenant might
require that user to send to another covenant that has a government spend
path, but also has a spend path for that user-defined public key. That way,
you (the government) could allow people to send to each other arbitrarily,
while still ensuring that you (the government) could spend the funds no
matter where they may have been sent. Even without recursive covenants, you
could have arbitrarily long chains of these, say 1 million long, where at
the end of the chain the user must send your coins back to the government
who can then send them back with another million-long chain of covenants to
work with.
OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf> can do
this kind of dynamicness, and OP_PUSHOUTPUTSTACK
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>
can
enable it for things like OP_TLUV and OP_CD. I personally think dynamic
covenants are a *good* thing, as it enables more secure wallet vaults,
among other things. And I'm not worried about a government creating a
in-bitcoin visa-coin. Why? Because they can already do it today. They have
been able to do it for 9 years already. How?
Replace the covenant above with a multisig wallet. The government has 2
keys, you have 1 key. Every time you make a transaction, you request the
government's signature on it. The government then only signs if you're
sending to a wallet they approve of. They might only sign when you're
sending to another multisig wallet that the government has 2 of 3 keys for.
Its a very similar walled garden, where the only difference is that the
government needs to actively sign, which I'm sure wouldn't be a huge
challenge for the intrepid dictator of the land. You want to add
demurage fees? Easy, the government just spends the fee out of everyone's
wallets every so often.
On the other hand, OP_CTV *cannot* be used for such a thing. No combination
of future opcodes can enable either recursion or dynamicness to an OP_CTV
call.
On Sat, May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Jorge,
>
> > I think people may be scared of potential attacks based on covenants.
> For example, visacoin.
> > But there was a thread with ideas of possible attacks based on covenants.
> > To me the most scary one is visacoin, specially seeing what happened in
> canada and other places lately and the general censorship in the west, the
> supposed war on "misinformation" going on (really a war against truth imo,
> but whatever) it's getting really scary. But perhaps someone else can be
> more scared about a covenant to add demurrage fees to coins or something, I
> don't know.
> > https://bitcointalk.org/index.php?topic=278122
>
> This requires *recursive* covenants.
>
> At the time the post was made, no distinction was seen between recursive
> and non-recursive covenants, which is why the post points out that
> covenants suck.
> The idea then was that anything powerful enough to provide covenants would
> also be powerful enough to provide *recursive* covenants, so there was no
> distinction made between recursive and non-recursive covenants (the latter
> was thought to be impossible).
>
> However, `OP_CTV` turns out to enable sort-of covenants, but by
> construction *cannot* provide recursion.
> It is just barely powerful enough to make a covenant, but not powerful
> enough to make *recursive* covenants.
>
> That is why today we distinguish between recursive and non-recursive
> covenant opcodes, because we now have opcode designs that provides
> non-recursive covenants (when previously it was thought all covenant
> opcodes would provide recursion).
>
> `visacoin` can only work as a recursive covenant, thus it is not possible
> to use `OP_CTV` to implement `visacoin`, regardless of your political views.
>
> (I was also misinformed in the past and ignored `OP_CTV` since I thought
> that, like all the other covenant opcodes, it would enable recursive
> covenants.)
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220508/6162df67/attachment.html>

2023-06-07 23:09:10

- reply

📅 Original date posted:2022-05-08
📝 Original message:I took a look at the spec for the wallet descriptor format, and I like the
concept of having placeholder variables for keys. It reduces the size of
the descriptor, makes it substantially easier for a human to
read/verify, especially in the future when we have more complex
scripts, and provides a nice format for a script template which can make it
easier to verify that you're using the same script template as something
else (ie besides using different keys). I think the `/**` syntax is an
improvement over the current descriptor format, however it is a bit awkward
and inflexible. My understanding is that some of this inflexibility comes
from the goal of reducing memory usage, and I don't think I have a good
enough handle on that part of things to usefully comment. I've put
additional comments and suggestions on the format in this github issue
<https://github.com/LedgerHQ/app-bitcoin-new/issues/35>.
I think it would be very useful to come to agreement on a more flexible
format that can support a much broader set of use cases, and can
potentially be a widely supported standard. I understand low-ram devices
might have a much harder time using more flexible (and complex) formats.
On Thu, May 5, 2022 at 9:39 AM Salvatore Ingala via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> In the implementation work to implement descriptors and miniscript support
> in hardware wallets [a][b], I encountered a number of challenges. Some of
> them are technical in nature (e.g. due to constraints of embedded
> development). Others are related to the attempts of shaping a good user
> experience; with bitcoin reaching more people who are not tech-savvy,
> self-custody is only as secure as what those newcomers can use easily
> enough.
>
> The main tool that I am using to address some of these challenges is a
> layer that sits _on top_ of descriptors/miniscript, while staying very
> close to it. Since there is nothing that is vendor-specific in the vast
> majority of the approach I'm currently using, I tried to distill it here
> for your comments, and will propose a BIP if this is deemed valuable.
>
> I called the language "wallet policies" (suggestions for a better name are
> welcome). I believe an approach based on wallet policies can benefit all
> hardware wallets (stateless or not) that want to securely support complex
> scripts; moreover, wallet policies are close enough to descriptors that
> their integration should be extremely easy for any software wallet that is
> currently using descriptors.
>
> [a]: https://blog.ledger.com/bitcoin-2 - early demo
> [b]: https://blog.ledger.com/miniscript-is-coming - miniscript example
>
>
> Salvatore Ingala
>
>
> ======================================================
>
> This document starts with a discussion on the motivation for wallet
> policies, followed by their formal definition, and some recommendations for
> implementations.
>
> == Rationale ==
>
> Output script descriptors [1] were introduced in bitcoin-core as a way to
> represent collections of output scripts. It is a very general and flexible
> language, designed to catch all the possible use-cases of bitcoin wallets
> (that is, if you know the script and you have the necessary keys, it will
> be possible to sign transactions with bitcoin-core's descriptor-based
> wallets).
>
> Unfortunately, descriptors are not a perfect match for the typical usage
> of hardware wallets. Most hardware wallets have the following limitations
> compared to a general-purpose machine running bitcoin-core:
>
> - they are embedded devices with limited RAM and computational power;
> - they might not be able to import additional private keys (all the keys
> are generated from a single seed via [BIP-32](
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki));
> - they might not have permanent storage (*stateless* hardware wallet
> design).
>
> Moreover, other limitations like the limited size of the screen might
> affect what design choices are available in practice. Therefore, minimizing
> the size of the information shown on-screen is important for a good user
> experience.
>
> A more native, compact representation of the wallet receive/change would
> also benefit the UX of software wallets using descriptors to represent
> software wallets using descriptors/miniscript for multisignature or other
> complex locking conditions.
>
> === Security and UX concerns of scripts in hardware wallets ===
>
> For a hardware wallet, allowing the usage of complex scripts presents
> challenges in terms of both security and user experience.
>
> ==== Security issues ====
>
> One of the security properties that hardware wallets strive to guarantee
> is the following: **as long as the user correctly verifies the information
> that is shown on the hardware wallet's screen before approving, no action
> can be performed without the user's consent**.
> This must hold even in scenarios where the attacker has full control of
> the machine that is connected to the hardware wallet, and can execute
> arbitrary requests or tamper with the legitimate user's requests.
>
> Therefore, it is not at all trivial to allow complex scripts, especially
> if they contain keys that belong to third parties.
> The hardware wallet must guarantee that the user knows precisely *what*
> "policy" is being used to spend the funds, and that the "unspent" funds (if
> any) will be protected by the same policy. This makes it impossible for an
> attacker to surreptitiously modify the policy, therefore stealing or
> burning user's funds.
>
> ==== UX issues ====
>
> With miniscript (and taproot trees) allowing substantially more complex
> spending policies to be used, it becomes more challenging to make sure that
> the user is able _in practice_ to verify the information on the screen.
> Therefore, there are two fundamental design goals to strive for:
> - Minimize the amount of information that is shown on screen - so that the
> user can actually validate it.
> - Minimize the number of times the user has to validate such information.
>
> Designing a secure protocol for the coordination of a descriptor wallet
> among distant parties is also a challenging problem that is out of scope in
> this document. See BIP-129 [2] for an approach designed for multisignature
> wallets.
>
> === Policy registration as a solution ===
>
> A solution to address the security concerns, and part of the UX concerns,
> is to have a *registration* flow for the wallet policy in the hardware
> wallet. The "wallet policy" must contain enough information to generate all
> the relevant addresses/scripts, and for the hardware wallet to identify the
> keys that it controls and that are needed to spend the funds sent to those
> addresses.
>
> Before a new policy is used for the first time, the user will register a
> `wallet policy` into the hardware wallet. While the details of the process
> are out of scope in this document, the flow should be something similar to
> the following:
>
> 1) The software wallet initiates a _wallet policy registration_ on the
> hardware wallet; the information should include the wallet policy, but also
> a unique *name* that identifies the policy.
> 2) The hardware wallet shows the wallet policy to the user using the
> secure screen.
> 3) After inspecting the policy and comparing it with a trusted source (for
> example a printed backup), the user approves the policy.
> 4) If stateful, the hardware wallet persists the policy in its permanent
> memory; if stateless, it returns a "proof of registration".
>
> The details of how to create a proof of registration are out of scope for
> this document; using a *message authentication codes* on a hash committing
> to the wallet policy, its name and any additional metadata is an effective
> solution if correctly executed.
>
> Once a policy is registered, the hardware wallet can perform the usual
> operations securely:
> - generating receive and change addresses;
> - showing addresses on the secure screen;
> - sign transactions spending from a wallet, while correctly identifying
> change addresses and computing the transaction fees.
>
> Before any of the actions mentioned above, the hardware wallet will
> retrieve the policy from its permanent storage if stateful; if stateless it
> will validate the _proof of registration_ before using the wallet policy
> provided by the client.
> Once the previously registered policy is correctly identified and approved
> by the user (for example by its name), and *as long as the policy
> registration was executed securely*, hardware wallets can provide a user
> experience similar to the usual one for single-signature transactions.
>
> === Avoiding blowup in descriptor size ===
>
> While reusing a pubkey in different branches of a miniscript is explicitly
> forbidden by miniscript (as it has certain negative security implications),
> it is still reasonable to reuse the same *xpub* in multiple places, albeit
> with different final steps of derivation (so that the actual pubkeys that
> are used in the script are indeed different).
>
> For example, using Taproot, a *3*-of-*5* multisignature wallet could use:
> - a key path with a 5-of-5 MuSig
> - a script tree with a tree of 10 different 3-of-3 MuSig2 scripts, that
> are generated, plus a leaf with a fallback *3*-of-*5* multisignature using
> plain multisignature (with `OP_CHECKSIGADD`).
>
> This could look similar to:
>
> ```
> tr(musig2(xpubA,xpubB,xpubC,xpubD,xpubE)/<0;1>/*), {
> {
> {
> pk(musig2(xpubA,xpubB,xpubC)/<2;3>/*),
> {
> pk(musig2(xpubA,xpubB,xpubD)/<4;5>/*)
> pk(musig2(xpubA,xpubB,xpubE)/<6;7>/*),
> }
> },
> {
> pk(musig2(xpubA,xpubC,xpubD)/<8;9>/*),
> {
> pk(musig2(xpubA,xpubC,xpubE)/<10;11>/*),
> pk(musig2(xpubA,xpubD,xpubE)/<12;13>/*)
> }
> }
> },
> {
> {
> pk(musig2(xpubB,xpubC,xpubD)/<14;15>/*),
> pk(musig2(xpubB,xpubC,xpubE)/<16;17>/*)
> },
> {
> pk(musig2(xpubB,xpubD,xpubE)/<18;19>/*),
> {
> pk(musig2(xpubC,xpubD,xpubE)/<20;21>/*),
> sortedmulti_a(3,
> xpubA/<22;23>/*,
> xpubB/<22;23>/*,
> xpubC/<22;23>/*,
> xpubD/<22;23>/*,
> xpubE/<22;23>/*)
> }
> }
> }
> })
> ```
>
> Note that each root xpub appears 8 times. With xpubs being up to 118 bytes
> long, the length of the full descriptor can get extremely long (the problem
> gets *exponentially* worse with larger multisignature schemes).
>
> Replacing the common part of the key with a short key placeholder and
> moving the key expression separately helps to keep the size of the wallet
> policy small, which is crucial to allow human inspection in the
> registration flow.
>
> === Restrictions on the supported descriptors ====
>
> The policy language proposed in this document purposely targets only a
> stricter subset of the output descriptors language, and it attempts to
> generalize in the most natural way the approach that is already used for
> single-signature *accounts* (as described in BIP-44 [3], BIP-49 [4], BIP-84
> [5], or BIP-86 [6]), or in multisignature setups (see for example BIP-48
> [7] and BIP-87 [8]).
>
> Unlike the BIPs mentioned above, it is not tied to any specific script
> template, as it applies to arbitrary scripts that can be represented with
> descriptors and miniscript.
>
> Supporting only a reduced feature set when compared to output descriptors
> helps in implementations (especially on hardware wallets), while attempting
> to capture all the common use cases. More features can be added in the
> future if motivated by real world necessity.
>
> By keeping the structure of the wallet policy language very close to that
> of descriptors, it should be straightforward to:
> - write wallet policy parsers;
> - extract the descriptors defined by a wallet policy;
> - convert a pair of descriptors describing a wallet "account" used in
> current implementations into the corresponding wallet policy.
>
>
> == Wallet policies ==
>
> This section formally defines wallet policies, and how they relate to
> output script descriptors.
>
> === Formal definition ===
>
> A wallet policy is composed by a wallet descriptor template, together with
> a vector of key information items.
>
> ==== Wallet descriptor template ====
>
> A wallet descriptor template is a `SCRIPT` expression.
>
> `SCRIPT` expressions:
> - `sh(SCRIPT)` (top level only): P2SH embed the argument.
> - `wsh(SCRIPT)` (top level or inside `sh` only): P2WSH embed the argument.
> - `pkh(KP)` (not inside `tr`): P2PKH output for the given public key (use
> `addr` if you only know the pubkey hash).
> - `wpkh(KP)` (top level or inside `sh` only): P2WPKH output for the given
> compressed pubkey.
> - `multi(k,KP_1,KP_2,...,KP_n)`: k-of-n multisig script.
> - `sortedmulti(k,KP_1,KP_2,...,KP_n)`: k-of-n multisig script with keys
> sorted lexicographically in the resulting script.
> - `tr(KP)` or `tr(KP,TREE)` (top level only): P2TR output with the
> specified key as internal key, and optionally a tree of script paths.
> - any valid miniscript template (inside `wsh` or `tr` only).
>
> `TREE` expressions:
> - any `SCRIPT` expression
> - An open brace `{`, a `TREE` expression, a comma `,`, a `TREE`
> expression, and a closing brace `}`
>
> Note: "miniscript templates" are not formally defined in this version of
> the document, but it is straightforward to adapt this approach.
>
> `KP` expressions (key placeholders) consist of
> - a single character `@`
> - followed by a non-negative decimal number, with no leading zeros (except
> for `@0`).
> - possibly followed by either:
> - the string `/**`, or
> - a string of the form `/<NUM;NUM>/*`, for two distinct decimal numbers
> `NUM` representing unhardened derivations
>
> The `/**` in the placeholder template represents commonly used paths for
> receive/change addresses, and is equivalent to `<0;1>`.
>
> The placeholder `@i` for some number *i* represents the *i*-th key in the
> vector of key origin information (which must be of size at least *i* + 1,
> or the wallet policy is invalid).
>
> ==== Key informations vector ====
>
> Each element of the key origin information vector is a `KEY` expression.
>
> - Optionally, key origin information, consisting of:
> - An open bracket `[`
> - Exactly 8 hex characters for the fingerprint of the master key from
> which this key is derived from (see [BIP32](
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for
> details)
> - Followed by zero or more `/NUM'` path elements to indicate hardened
> derivation steps between the fingerprint and the xpub that follows
> - A closing bracket `]`
> - Followed by the actual key, which is either
> - a hex-encoded pubkey, which is either
> - inside `wpkh` and `wsh`, only compressed public keys are permitted
> (exactly 66 hex characters starting with `02` or `03`.
> - inside `tr`, x-only pubkeys are also permitted (exactly 64 hex
> characters).
> - a serialized extended public key (`xpub`) (as defined in [BIP 32](
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki))
>
> The placeholder `@i` for some number *i* represents the *i*-th key in the
> vector of key orIgin information (which must be of size at least *i* + 1,
> or the wallet policy is invalid).
>
> The policy template is invalid if any placeholder `@i` has derivation
> steps while the corresponding `(i+1)`-th element of the keys vector is not
> an xpub.
>
> ==== Additional rules ====
>
> The wallet policy is invalid if any placeholder expression with additional
> derivation steps is used when the corresponding key information is not an
> xpub.
>
> The key information vector *should* be ordered so that placeholder `@i`
> never appear for the first time before an occurrence of `@j` for some `j <
> i`; for example, the first placeholder is always `@0`, the next one is
> `@1`, etc.
>
> === Descriptor derivation ===
>
> From a wallet descriptor template (and the associated vector of key
> informations), one can therefore obtain the 1-dimensional descriptor for
> receive and change addresses by:
>
> - replacing each key placeholder with the corresponding key origin
> information;
> - replacing every `/**` with `/0/*` for the receive descriptor, and
> `/1/*` for the change descriptor;
> - replacing every `/<M,N>` with `/M` for the receive descriptor, and `/N`
> for the change descriptor.
>
> For example, the wallet descriptor `pkh(@0/**)` with key information
> `["[d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL"]`
> produces the following two descriptors:
>
> - Receive descriptor:
> `pkh([d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/0/*)`
>
> - Change descriptor:
> `pkh([d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)`
>
> === Implementation guidelines ===
>
> Implementations must not necessarily implement all of the possible wallet
> policies defined by this standard, but it is recommended to clearly
> document any limitation.
>
> Implementations can add additional metadata that is stored together with
> the wallet policy for the purpose of wallet policy registration and later
> usage. Metadata can be vendor-specific and is out of the scope of this
> document.
>
> Any implementation in a general-purpose software wallet allowing arbitrary
> scripts (or any scripts that involve external cosigners) should put great
> care into a process for backing up a wallet policy. In fact, unlike typical
> single-signature scenarios, the seed alone is no longer enough to discover
> wallet policies with existing funds, and the loss of the backup is likely
> to lead to permanent loss of funds.
>
> Avoiding key reuse among different wallet accounts is also extremely
> important, but out of scope for this document.
>
> == Examples ==
>
> Some examples of wallet descriptor templates (vectors of keys omitted for
> simplicity):
> - Template for a native segwit account:
> wpkh(@0/**)
> - Template for a taproot BIP86 account:
> tr(@0/**)
> - Template for a native segwit 2-of-3:
> wsh(sortedmulti(2, at 0/**, at 1/**, at 2/**))
> - Template with miniscript for "1 of 2 equally likely keys":
> wsh(or_b(pk(@0/**),s:pk(@1/**)))
>
> More examples (esp. targeting miniscript on taproot) will be added in the
> future.
>
> == References ==
>
> * [1] - Output Script Descriptors:
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md
> * [2] - BIP-129 (Bitcoin Secure Multisig Setup):
> https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki
> * [3] - BIP-44:
> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
> * [4] - BIP-49:
> https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki
> * [5] - BIP-84:
> https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki
> * [6] - BIP-86:
> https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki
> * [7] - BIP-48:
> https://github.com/bitcoin/bips/blob/master/bip-0048.mediawiki
> * [8] - BIP-87:
> https://github.com/bitcoin/bips/blob/master/bip-0087.mediawiki
>
> _______________________________________________
> 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/20220508/2f271848/attachment-0001.html>

2023-06-07 23:09:04

- reply

📅 Original date posted:2022-05-08
📝 Original message:> it is easier to get everyone to agree when everyone has something to gain
That's unquestionably true. It doesn't really sound like what you said
originally tho.
> most users are either apathetic or trusting in the developers that
initiated it being activated. This is a dangerous dynamic to lean on
I don't disagree.
> I do not "expect" improvement by any other means than is typical in life:
competition and adaptation in response to an adverse and changing
environment.
> Why are you talking about companies and bloat while I am speaking about
being conservative?
Sounds like we agree then. However, when you said "when [designers]
speculate and lead the process, they create problems instead" I took that
to mean that you think designers shouldn't lead the process. I think
designers and engineers should lead the process, as you said, "[when] their
specialization allows them to solve a problem faster than someone else
might."
> thinking that adding complication to Bitcoin's base layer is somehow a
means of valuing simplicity
You seem to be missing my point. I am certainly not saying the words you're
putting in my mouth there. What I am saying is that a number of people have
been calling covenants for a number of years before Jeremy created CTV, and
all discussed proposals were more powerful and complex than CTV. I do think
that the design of CTV had a goal of simplicity, and I believe it achieved
that goal. If CTV were not proposed and developed, we would very likely
have seen a more complex covenant opcode on the table. I certainly would
like to see a more powerful covenant opcode myself.
> I have no reason to care about your "99%" confidence in something
I'm not asking you to care about my confidence. I'm asking to consider my
logic. Feel free to take any claims about my confidence as an aside.
> Speaking for myself, and likely the great majority of the market
... are you trying to speak for yourself, or are you trying to assert that
your opinion is the market majority opinion? If I may echo your opinion of
me, I have no reason to care about your confidence that your opinion is
everyone else's opinion as well. I'll take that as an aside ; )
> Your self-ascribed ability to assess the market is objectively
overconfident
I'm not the one claiming to speak for the market ^ I'm only relaying the
fact that the vast majority of folks I see on the dev mailing list who talk
about covenants, even occasionally, are in support of them generally, and
it seems the majority of those people who generally support covenants, if
not the vast majority, support CTV. That's what I see. Feel free to not
believe me, but the dev mailing list records are all there for you to
verify.
> That cost [of a change to bitcoin] is only offset AFTER the feature has
reached saturation of usage.
I think that's objectively false. Were it true, it would mean that every
change can only at best reach break-even, which would mean that no change
is worth doing.
> we might be too aggressive in our pace of feature speculation
> If we keep piling on features...
> Complexity can yield centralization, we should be more careful.
Are you in the "ossification now" camp, John? Or perhaps, ossification
soon? I agree that the bar of quality should continually be raised for
making changes to bitcoin, and ossification (or as near as possible) should
be the eventual goal. Perhaps we just disagree on how quickly to raise the
bar.
> However many people in the world that may want CTV, that number is surely
less than 1% of the Bitcoin user base.
I don't disagree that 1% isn't an unlikely number for the fraction of
bitcoin users who currently want specifically CTV. However, I would guess
the percentage of users who hold something close to your opinion isn't much
different from that number. Measuring things like this as a percentage of
the total bitcoin userbase is kind of worthless.
> Cry harder.
> your being offended is not important to this topic
Perhaps not, but its still no reason to act like an asshole, John. If you
think personal attacks, childish jeers, and angry dismissals will be
convincing to people who read this mailing list, you're sorely mistaken.
On Wed, May 4, 2022 at 8:01 AM LORD HIS EXCELLENCY JAMES HRMH <
willtech at live.com.au> wrote:
> Good Afternoon,
>
> The basic principle of Bitcoin is operating the consensus fungibility. All
> transactions are published on the public ledger. What is valuable is the
> consensus as we have it, not what it may become from some proposal that may
> harm fungibility. Without consensus Bitcoin is not what is valued by the
> current consensus. Consensus is exactly why Bitcoin is fungible if that can
> be made clear. That is why it is important to defend consensus. We have
> agreed Bitcoin has certain properties including being immutable,
> transparent, published, distributed, trustless. Consensus provides we make
> software to allow transfer of Bitcoin via ownership of a UTXO in a manner
> in accordance with consensus. If we do not value Bitcoin to defend the
> consensus we admin all kinds of features without purpose to complicate the
> operation of a wallet for a standard user. Bitcoin and the consensus is all
> about the standard user in order to be fungible. A valuable use-case does
> not approve an enhancement. Most users will never be involved in the
> consensus process and in the interest of being fungible all developers and
> the consensus must ensure their interest in a wallet being upgraded is in
> their beneficial interest. Making a fidget toy that can do anything is not
> useful until it can make the bed, cook breakfast, and pour the coffee, that
> is, to do something useful that a user will want.
>
> One test of this is how many users will object if a feature is taken away.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this
> email if misdelivered.
> ------------------------------
> *From:* bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on
> behalf of John Carvalho via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Monday, 2 May 2022 6:37 PM
> *To:* bitcoin-dev at lists.linuxfoundation.org <
> bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Working Towards Consensus
>
> Jeremy,
>
> The path to consensus is to propose things that everyone needs. Demand
> comes from the market, not the designers.
>
> Designers (engineers) solve problems with designs, but when they speculate
> and lead the process, they create problems instead. Bitcoin is not a place
> for speculative feature additions. Bitcoin cannot afford a culture of
> additive features no one is asking for. Bitcoin thrives in a culture of
> "NO." Rejection of change is Bitcoin's primary feature.
>
> There is NO HOPE of EVER getting the majority of Bitcoin users to be able
> to grasp, audit, and meaningfully consent to complicated new features, nor
> to assess how they may interact with existing features in undesirable ways
> or affect Bitcoin's incentive structure. To ignore this is a selfish
> egomania that too many devs succumb to. The public already trusts Core devs
> more than they probably should, and it is unwise to lean on that trust.
>
> You are of course welcome to try and research and document all of the
> details about how this plays out in practice, but you will fail to specify
> a path to approval or any sort of clear governance structure for ensuring
> that speculative features get into Bitcoin. You will seek and only see a
> bias that allows you to get what YOU want. Until you focus on what everyone
> wants, you will not reach consensus on anything.
>
> Bitcoin changes should solve obvious problems and provide easy wins on
> optimization, security, and privacy. Seek simplicity and efficiency, not
> complication.
>
> We have yet to saturate usage of the features we have added already in the
> past 5 years. Use those. It is becoming apparent over time that many
> features can be accomplished off-chain, or without a blockchain, or by
> merely anchoring into currently available bitcoin transaction types.
>
> There is simply no urgency or problem that any of the proposed soft fork
> features are trying to address. This includes APO, CTV, sidechain
> proposals, etc, etc.
>
> Your aggression to your purpose is the antithesis of consensus, as it
> indicates your incentives are external to it.
>
> --
> John Carvalho
> CEO, Synonym.to <http://synonym.to/>
>
>
> On Mon, May 2, 2022 at 3:43 AM <
> bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: What to do when contentious soft fork activations are
> attempted (Billy Tetrud)
> 2. Working Towards Consensus (Jeremy Rubin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 1 May 2022 14:14:29 -0500
> From: Billy Tetrud <billy.tetrud at gmail.com>
> To: alicexbt <alicexbt at protonmail.com>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] What to do when contentious soft fork
> activations are attempted
> Message-ID:
> <
> CAGpPWDb-T4OB0NKv7O5k9yhDQJtmag1QLqM1jJN9fQMoNTPLug at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1 alicexbt
>
> We of course want knowledgeable bitcoiners who aren't knowledgeable about a
> certain proposal to be skeptical. But what we don't want is for that
> natural skepticism-from-ignorance to be interpreted as opposition, or
> really a strong signal of any kind. Any thoughts from ignorance, whether
> self-aware or not, should be given small weight. It seems the vast majority
> of push back has been this kind of skepticism from ignorance. And to a
> certain degree I think we want to give time for understanding to those who
> have not participated in the first, second, third, etc round of discussion
> on a proposal. It may not be reasonable to say "you had the last 2 years of
> time to voice your concern".
>
> Now that CTV is being taken seriously as a proposal, we probably should
> give the community who is finally taking a serious look at it time to
> understand, get their questions answered, and come to terms with it. This
> is not to say that CTV as a technology or proposal has been rushed, or has
> not had enough work put into it, but rather that the community as a whole
> has not paid enough attention to it for long enough.
>
> The wrong approach is: "how do I yell more loudly next time I see something
> I'm uncomfortable with?" The right approach is to educate those who aren't
> educated on the proposal and gather consensus on what people think when
> they understand enough about it to contribute to that consensus. If you
> care about consensus, you should respect the consensus process and be ok
> with consensus being not your preferred outcome. If you don't care about
> consensus, then you're basically attacking the bitcoin community.
>
> On Sun, May 1, 2022 at 3:22 AM alicexbt via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Hi Michael,
> >
> > Maybe the whole thing worked as designed. Some users identified what was
> > going on, well known Bitcoin educators such as Andreas Antonopoulos,
> Jimmy
> > Song etc brought additional attention to the dangers, a URSF movement
> > started to gain momentum and those attempting a contentious soft fork
> > activation backed off. (Disappointingly Bitcoin Optech didn't cover my
> > previous posts to this mailing list 1
> > <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html
> >,
> > 2
> > <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
> >,
> > 3
> > <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
> >
> > highlighting the dangers many months ago or recent posts. Normally Optech
> > is very high signal.)
> >
> >
> > Some users have been misled and there is nothing great being achieved by
> > doing this on social media. Andreas is clueless about BIP 119 and other
> > covenant proposals. He is spreading misinformation and some of the URSF
> > enthusiasts do not understand what are they even opposing or going to run
> > with risks involved.
> >
> >
> > Answering the subject of this email: "What to do when contentious soft
> > forks activations are attempted?"
> >
> > - Do not consider something contentious because someone said it on
> mailing
> > list
> > - Do not spread misinformation
> > - Read all posts in detail with different opinions
> > - Avoid personal attacks
> > - Look at the technical details, code etc. and comment on things that
> > could be improved
> >
> >
> >
> > /dev/fd0
> >
> > Sent with ProtonMail <https://protonmail.com/> secure email.
> >
> > ------- Original Message -------
> > On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via bitcoin-dev
> > bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> >
> > I?ve been in two minds on whether to completely move on to other topics
> or
> > to formulate some thoughts on the recent attempt to activate a
> contentious
> > soft fork. In the interests of those of us who have wasted
> > days/weeks/months of our time on this (with no personal upside) and who
> > don?t want to repeat this exercise again I thought I should at least
> raise
> > the issue for discussion of what should be done differently if this is
> > tried again in future.
> >
> > This could be Jeremy with OP_CTV at a later point (assuming it is still
> > contentious) or anyone who wants to pick up a single opcode that is not
> yet
> > activated on Bitcoin and try to get miners to signal for it bypassing
> > technical concerns from many developers, bypassing Bitcoin Core and
> > bypassing users.
> >
> > Maybe the whole thing worked as designed. Some users identified what was
> > going on, well known Bitcoin educators such as Andreas Antonopoulos,
> Jimmy
> > Song etc brought additional attention to the dangers, a URSF movement
> > started to gain momentum and those attempting a contentious soft fork
> > activation backed off. (Disappointingly Bitcoin Optech didn't cover my
> > previous posts to this mailing list 1
> > <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html
> >,
> > 2
> > <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
> >,
> > 3
> > <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
> >
> > highlighting the dangers many months ago or recent posts. Normally Optech
> > is very high signal.)
> >
> > Alternatively this was the first time a contentious soft fork activation
> > was attempted, we were all woefully unprepared for it and none of us knew
> > what we were doing.
> >
> > I?m unsure on the above. I?d be interested to hear thoughts. What I am
> > sure of is that it is totally unacceptable for one individual to bring
> the
> > entire Bitcoin network to the brink of a chain split. There has to be a
> > personal cost to that individual dissuading them from trying it again
> > otherwise they?re motivated to try it again every week/month. Perhaps the
> > personal cost that the community is now prepared if that individual tries
> > it again is sufficient. I?m not sure. Obviously Bitcoin is a
> permissionless
> > network, Bitcoin Core and other open source projects are easily forked
> and
> > no authority (I?m certainly no authority) can stop things like this
> > happening again.
> >
> > I?ll follow the responses if people have thoughts (I won't be responding
> > to the instigators of this contentious soft fork activation attempt) but
> > other than that I?d like to move on to other things than contentious soft
> > fork activations. Thanks to those who have expressed concerns publicly
> (too
> > many to name, Bob McElrath was often wording arguments better than I
> could)
> > and who were willing to engage with the URSF conversation. If an
> individual
> > can go directly to miners to get soft forks activated bypassing technical
> > concerns from many developers, bypassing Bitcoin Core and bypassing users
> > Bitcoin is fundamentally broken. The reason I still have hope that it
> isn't
> > is that during a period of general apathy some people were willing to
> stand
> > up and actively resist it.
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.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/20220501/7158d8ed/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sun, 1 May 2022 19:43:29 -0700
> From: Jeremy Rubin <jeremy.l.rubin at gmail.com>
> To: Bitcoin development mailing list
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] Working Towards Consensus
> Message-ID:
> <CAD5xwhhdEgADWwLwbjRKp-UFCw9hHjDsc-L=pkiwW=
> bmhFqBNw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Developers,
>
> There is much to say about the events of the last two weeks and the
> response to them. I've been searching for the right words to share here,
> but I think it best that short of a more thoughtful writeup I start with a
> timely small step with the below comments.
>
> First, let me be clear: I am not advancing a Speedy Trial(ST) activation of
> Bitcoin Improvement Proposal-119 (BIP-119) CheckTemplateVerify (CTV) at
> this time.
>
> I'm skipping any discussion of the drama here. Most of you are interested
> in developing Bitcoin, not drama. Let's try to keep this thread focused on
> the actual work. I'll make some limited comments on the drama in a separate
> thread, for those who care to hear from me on the subject directly.
>
> I believe that the disinformation spread around my post ("7 Theses on a
> next step for BIP-119"[0]) created three main negative outcomes within the
> Bitcoin community:
>
> 1. Confusion about how Bitcoin's "technical consensus" works and how
> changes are "approved".
> 2. Fear about the safety of CTV and covenants more broadly.
> 3. Misunderstandings around the properties of Speedy Trial, User Activated
> Soft Fork (UASF), User Resisted Soft Fork (URSF), Soft Forks, Hard Forks,
> and more.
>
> While I cannot take responsibility for the spread of the disinformation, I
> do apologize to anyone dealing with it for the role my actions have had in
> leading to the current circumstance.
>
> I personally take some solace in knowing that the only way out of this is
> through it. The conversations happening now seem to have been more or less
> inevitable, this has brought them to the surface, and as a technical
> community we are able to address them head on if -- as individuals and
> collectively -- we choose to. And, viewed through a certain lens, these
> conversations represent incredibly important opportunities to participate
> in defining the future of Bitcoin that would not be happening otherwise.
> Ultimately, I am grateful to live in a time where I am able to play a small
> role in such an important process. This is the work.
>
> In the coming months, I expect the discourse to be messy, but I think the
> work is clear cut that we should undertake at least the following:
>
> 1. Make great efforts to better document how Bitcoin's technical consensus
> process works today, how it can be improved, and how changes may be
> formally reviewed while still being unofficially advanced.
> 2. Work diligently to address the concerns many in the community have
> around the negative potential of covenants and better explain the
> trade-offs between levels of functionality.
> 3. Renew conversations about activation and release mechanisms and
> re-examine our priors around why Speedy Trial may have been acceptable for
> Taproot, was not acceptable for BIP-119, but may not be optimal long
> term[1], and work towards processes that better captures the Bitcoin
> network's diverse interests and requirements.
> 4. Work towards thoroughly systematizing knowledge around covenant
> technologies so that in the coming months we may work towards delivering a
> coherent pathway for the Bitcoin technical community to evaluate and put up
> for offer to the broader community an upgrade or set of upgrades to improve
> Bitcoin's capabilities for self sovereignty, privacy, scalability, and
> decentralization.
>
> This may not be the easiest path to take, but I believe that this work is
> critical to the future of Bitcoin. I welcome all reading this to share your
> thoughts with this list on how we might work towards consensus going
> forward, including any criticisms of my observations and recommendations
> above. While I would expect nothing less than passionate debate when it
> comes to Bitcoin, remember that at the end of the day we all largely share
> a mission to make the world a freer place, even if we disagree about how we
> get there.
>
> Yours truly,
>
> Jeremy
>
> [0]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
> [1]: http://r6.ca/blog/20210615T191422Z.html I quite enjoyed Roconnor's
> detailed post on Speedy Trial
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/9009e65d/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 84, Issue 4
> ******************************************
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220508/76fe3e01/attachment-0001.html>

2023-06-07 23:09:02

- reply

📅 Original date posted:2022-05-02
📝 Original message:John,
> The path to consensus is to propose things that everyone needs.
If there's an insight here, it isn't clear what it is to me. As stated,
this is something I can only 100% disagree with. Its possible that
literally nothing about bitcoin is something that "everyone needs". Its
pretty clear that not "everyone needs" taproot. Its even questionable
whether "everyone needs" bitcoin. Are you really saying that no change
should be added to bitcoin unless it is something literally all bitcoin
users are currently asking for, or maybe just will want to use sometime
soon? The majority of bitcoin users don't even custody their own funds, so
practically all features are something those users aren't using. If you
want to convince people of whatever argument you're making, you're going to
have to get a little more specific and rather less hyperbolic.
> Designers (engineers) solve problems with designs, but when they
speculate and lead the process, they create problems instead.
How do you expect any improvement to ever happen to bitcoin if designers
can't design things unless end-users have asked for it. Every good product
designer knows that users do not know how to design products. Users have
problems, designers create solutions. Companies that have implemented
features that users directly ask for end up with awful bloated confusing
products. Surely this isn't what you're suggesting we do in bitcoin, right?
> Seek simplicity and efficiency, not complication.
This is an extraordinarily ironic thing to say to Jeremy Rubin, who
designed CTV with exactly that in mind. It is an incredibly simple opcode
that doesn't allow recursive covenants or various other things that people
have been worried about in the past about covenants. I'm 99% confident that
there is no simpler, more efficient, and less complicated covenant opcode
than CTV that can even possibly be designed. The only one on par is
TXHASH+CSFS and that has more complex implications than CTV.
There are MANY people out there that would like more complex, more powerful
covenants. "The market" is in fact demanding it. And yet because we must
move carefully in Bitcoin, CTV is a compromise that focuses on simplicity
and incremental change rather than radical change.
Do you really disagree that CTV was intended to be as simple as possible
and achieves that goal?
> There is simply no urgency or problem that any of the proposed soft fork
features are trying to address.
That is pretty subjective, and very debatable. But ignoring the
debatableness of it, why is urgency even necessary for an improvement to
bitcoin? Should we wait until a problem is urgent to fix it? Or should we
get ahead of it so we don't risk making hasty mistakes?
> Your aggression to your purpose is the antithesis of consensus, as it
indicates your incentives are external to it.
This is a personal attack John, and there have been too many of those
lately. This is a completely unacceptable thing to say on this mailing
list. I ask that you take your words back and apologize. Please be more
objective and temper your strong emotions.
You know what is antithetical to consensus? People throwing around personal
attacks, asserting that consensus is something without evidence, and
failing to acknowledge the many opinions out there that are different from
theirs. You write your email as if there's only one person in this world
who wants CTV. You know this isn't the case.
On Mon, May 2, 2022 at 3:56 AM John Carvalho via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Jeremy,
>
> The path to consensus is to propose things that everyone needs. Demand
> comes from the market, not the designers.
>
> Designers (engineers) solve problems with designs, but when they speculate
> and lead the process, they create problems instead. Bitcoin is not a place
> for speculative feature additions. Bitcoin cannot afford a culture of
> additive features no one is asking for. Bitcoin thrives in a culture of
> "NO." Rejection of change is Bitcoin's primary feature.
>
> There is NO HOPE of EVER getting the majority of Bitcoin users to be able
> to grasp, audit, and meaningfully consent to complicated new features, nor
> to assess how they may interact with existing features in undesirable ways
> or affect Bitcoin's incentive structure. To ignore this is a selfish
> egomania that too many devs succumb to. The public already trusts Core devs
> more than they probably should, and it is unwise to lean on that trust.
>
> You are of course welcome to try and research and document all of the
> details about how this plays out in practice, but you will fail to specify
> a path to approval or any sort of clear governance structure for ensuring
> that speculative features get into Bitcoin. You will seek and only see a
> bias that allows you to get what YOU want. Until you focus on what everyone
> wants, you will not reach consensus on anything.
>
> Bitcoin changes should solve obvious problems and provide easy wins on
> optimization, security, and privacy. Seek simplicity and efficiency, not
> complication.
>
> We have yet to saturate usage of the features we have added already in the
> past 5 years. Use those. It is becoming apparent over time that many
> features can be accomplished off-chain, or without a blockchain, or by
> merely anchoring into currently available bitcoin transaction types.
>
> There is simply no urgency or problem that any of the proposed soft fork
> features are trying to address. This includes APO, CTV, sidechain
> proposals, etc, etc.
>
> Your aggression to your purpose is the antithesis of consensus, as it
> indicates your incentives are external to it.
>
> --
> John Carvalho
> CEO, Synonym.to <http://synonym.to/>
>
>
> On Mon, May 2, 2022 at 3:43 AM <
> bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>
>> Send bitcoin-dev mailing list submissions to
>> bitcoin-dev at lists.linuxfoundation.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> or, via email, send a message with subject or body 'help' to
>> bitcoin-dev-request at lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>> bitcoin-dev-owner at lists.linuxfoundation.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of bitcoin-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: What to do when contentious soft fork activations are
>> attempted (Billy Tetrud)
>> 2. Working Towards Consensus (Jeremy Rubin)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 1 May 2022 14:14:29 -0500
>> From: Billy Tetrud <billy.tetrud at gmail.com>
>> To: alicexbt <alicexbt at protonmail.com>, Bitcoin Protocol Discussion
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] What to do when contentious soft fork
>> activations are attempted
>> Message-ID:
>> <
>> CAGpPWDb-T4OB0NKv7O5k9yhDQJtmag1QLqM1jJN9fQMoNTPLug at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> +1 alicexbt
>>
>> We of course want knowledgeable bitcoiners who aren't knowledgeable about
>> a
>> certain proposal to be skeptical. But what we don't want is for that
>> natural skepticism-from-ignorance to be interpreted as opposition, or
>> really a strong signal of any kind. Any thoughts from ignorance, whether
>> self-aware or not, should be given small weight. It seems the vast
>> majority
>> of push back has been this kind of skepticism from ignorance. And to a
>> certain degree I think we want to give time for understanding to those who
>> have not participated in the first, second, third, etc round of discussion
>> on a proposal. It may not be reasonable to say "you had the last 2 years
>> of
>> time to voice your concern".
>>
>> Now that CTV is being taken seriously as a proposal, we probably should
>> give the community who is finally taking a serious look at it time to
>> understand, get their questions answered, and come to terms with it. This
>> is not to say that CTV as a technology or proposal has been rushed, or has
>> not had enough work put into it, but rather that the community as a whole
>> has not paid enough attention to it for long enough.
>>
>> The wrong approach is: "how do I yell more loudly next time I see
>> something
>> I'm uncomfortable with?" The right approach is to educate those who aren't
>> educated on the proposal and gather consensus on what people think when
>> they understand enough about it to contribute to that consensus. If you
>> care about consensus, you should respect the consensus process and be ok
>> with consensus being not your preferred outcome. If you don't care about
>> consensus, then you're basically attacking the bitcoin community.
>>
>> On Sun, May 1, 2022 at 3:22 AM alicexbt via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> > Hi Michael,
>> >
>> > Maybe the whole thing worked as designed. Some users identified what was
>> > going on, well known Bitcoin educators such as Andreas Antonopoulos,
>> Jimmy
>> > Song etc brought additional attention to the dangers, a URSF movement
>> > started to gain momentum and those attempting a contentious soft fork
>> > activation backed off. (Disappointingly Bitcoin Optech didn't cover my
>> > previous posts to this mailing list 1
>> > <
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html
>> >,
>> > 2
>> > <
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
>> >,
>> > 3
>> > <
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>> >
>> > highlighting the dangers many months ago or recent posts. Normally
>> Optech
>> > is very high signal.)
>> >
>> >
>> > Some users have been misled and there is nothing great being achieved by
>> > doing this on social media. Andreas is clueless about BIP 119 and other
>> > covenant proposals. He is spreading misinformation and some of the URSF
>> > enthusiasts do not understand what are they even opposing or going to
>> run
>> > with risks involved.
>> >
>> >
>> > Answering the subject of this email: "What to do when contentious soft
>> > forks activations are attempted?"
>> >
>> > - Do not consider something contentious because someone said it on
>> mailing
>> > list
>> > - Do not spread misinformation
>> > - Read all posts in detail with different opinions
>> > - Avoid personal attacks
>> > - Look at the technical details, code etc. and comment on things that
>> > could be improved
>> >
>> >
>> >
>> > /dev/fd0
>> >
>> > Sent with ProtonMail <https://protonmail.com/> secure email.
>> >
>> > ------- Original Message -------
>> > On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via
>> bitcoin-dev
>> > bitcoin-dev at lists.linuxfoundation.org wrote:
>> >
>> >
>> > I?ve been in two minds on whether to completely move on to other topics
>> or
>> > to formulate some thoughts on the recent attempt to activate a
>> contentious
>> > soft fork. In the interests of those of us who have wasted
>> > days/weeks/months of our time on this (with no personal upside) and who
>> > don?t want to repeat this exercise again I thought I should at least
>> raise
>> > the issue for discussion of what should be done differently if this is
>> > tried again in future.
>> >
>> > This could be Jeremy with OP_CTV at a later point (assuming it is still
>> > contentious) or anyone who wants to pick up a single opcode that is not
>> yet
>> > activated on Bitcoin and try to get miners to signal for it bypassing
>> > technical concerns from many developers, bypassing Bitcoin Core and
>> > bypassing users.
>> >
>> > Maybe the whole thing worked as designed. Some users identified what was
>> > going on, well known Bitcoin educators such as Andreas Antonopoulos,
>> Jimmy
>> > Song etc brought additional attention to the dangers, a URSF movement
>> > started to gain momentum and those attempting a contentious soft fork
>> > activation backed off. (Disappointingly Bitcoin Optech didn't cover my
>> > previous posts to this mailing list 1
>> > <
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html
>> >,
>> > 2
>> > <
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
>> >,
>> > 3
>> > <
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>> >
>> > highlighting the dangers many months ago or recent posts. Normally
>> Optech
>> > is very high signal.)
>> >
>> > Alternatively this was the first time a contentious soft fork activation
>> > was attempted, we were all woefully unprepared for it and none of us
>> knew
>> > what we were doing.
>> >
>> > I?m unsure on the above. I?d be interested to hear thoughts. What I am
>> > sure of is that it is totally unacceptable for one individual to bring
>> the
>> > entire Bitcoin network to the brink of a chain split. There has to be a
>> > personal cost to that individual dissuading them from trying it again
>> > otherwise they?re motivated to try it again every week/month. Perhaps
>> the
>> > personal cost that the community is now prepared if that individual
>> tries
>> > it again is sufficient. I?m not sure. Obviously Bitcoin is a
>> permissionless
>> > network, Bitcoin Core and other open source projects are easily forked
>> and
>> > no authority (I?m certainly no authority) can stop things like this
>> > happening again.
>> >
>> > I?ll follow the responses if people have thoughts (I won't be responding
>> > to the instigators of this contentious soft fork activation attempt) but
>> > other than that I?d like to move on to other things than contentious
>> soft
>> > fork activations. Thanks to those who have expressed concerns publicly
>> (too
>> > many to name, Bob McElrath was often wording arguments better than I
>> could)
>> > and who were willing to engage with the URSF conversation. If an
>> individual
>> > can go directly to miners to get soft forks activated bypassing
>> technical
>> > concerns from many developers, bypassing Bitcoin Core and bypassing
>> users
>> > Bitcoin is fundamentally broken. The reason I still have hope that it
>> isn't
>> > is that during a period of general apathy some people were willing to
>> stand
>> > up and actively resist it.
>> >
>> > --
>> > Michael Folkson
>> > Email: michaelfolkson at protonmail.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/20220501/7158d8ed/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sun, 1 May 2022 19:43:29 -0700
>> From: Jeremy Rubin <jeremy.l.rubin at gmail.com>
>> To: Bitcoin development mailing list
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: [bitcoin-dev] Working Towards Consensus
>> Message-ID:
>> <CAD5xwhhdEgADWwLwbjRKp-UFCw9hHjDsc-L=pkiwW=
>> bmhFqBNw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Developers,
>>
>> There is much to say about the events of the last two weeks and the
>> response to them. I've been searching for the right words to share here,
>> but I think it best that short of a more thoughtful writeup I start with a
>> timely small step with the below comments.
>>
>> First, let me be clear: I am not advancing a Speedy Trial(ST) activation
>> of
>> Bitcoin Improvement Proposal-119 (BIP-119) CheckTemplateVerify (CTV) at
>> this time.
>>
>> I'm skipping any discussion of the drama here. Most of you are interested
>> in developing Bitcoin, not drama. Let's try to keep this thread focused on
>> the actual work. I'll make some limited comments on the drama in a
>> separate
>> thread, for those who care to hear from me on the subject directly.
>>
>> I believe that the disinformation spread around my post ("7 Theses on a
>> next step for BIP-119"[0]) created three main negative outcomes within the
>> Bitcoin community:
>>
>> 1. Confusion about how Bitcoin's "technical consensus" works and how
>> changes are "approved".
>> 2. Fear about the safety of CTV and covenants more broadly.
>> 3. Misunderstandings around the properties of Speedy Trial, User Activated
>> Soft Fork (UASF), User Resisted Soft Fork (URSF), Soft Forks, Hard Forks,
>> and more.
>>
>> While I cannot take responsibility for the spread of the disinformation, I
>> do apologize to anyone dealing with it for the role my actions have had in
>> leading to the current circumstance.
>>
>> I personally take some solace in knowing that the only way out of this is
>> through it. The conversations happening now seem to have been more or less
>> inevitable, this has brought them to the surface, and as a technical
>> community we are able to address them head on if -- as individuals and
>> collectively -- we choose to. And, viewed through a certain lens, these
>> conversations represent incredibly important opportunities to participate
>> in defining the future of Bitcoin that would not be happening otherwise.
>> Ultimately, I am grateful to live in a time where I am able to play a
>> small
>> role in such an important process. This is the work.
>>
>> In the coming months, I expect the discourse to be messy, but I think the
>> work is clear cut that we should undertake at least the following:
>>
>> 1. Make great efforts to better document how Bitcoin's technical consensus
>> process works today, how it can be improved, and how changes may be
>> formally reviewed while still being unofficially advanced.
>> 2. Work diligently to address the concerns many in the community have
>> around the negative potential of covenants and better explain the
>> trade-offs between levels of functionality.
>> 3. Renew conversations about activation and release mechanisms and
>> re-examine our priors around why Speedy Trial may have been acceptable for
>> Taproot, was not acceptable for BIP-119, but may not be optimal long
>> term[1], and work towards processes that better captures the Bitcoin
>> network's diverse interests and requirements.
>> 4. Work towards thoroughly systematizing knowledge around covenant
>> technologies so that in the coming months we may work towards delivering a
>> coherent pathway for the Bitcoin technical community to evaluate and put
>> up
>> for offer to the broader community an upgrade or set of upgrades to
>> improve
>> Bitcoin's capabilities for self sovereignty, privacy, scalability, and
>> decentralization.
>>
>> This may not be the easiest path to take, but I believe that this work is
>> critical to the future of Bitcoin. I welcome all reading this to share
>> your
>> thoughts with this list on how we might work towards consensus going
>> forward, including any criticisms of my observations and recommendations
>> above. While I would expect nothing less than passionate debate when it
>> comes to Bitcoin, remember that at the end of the day we all largely share
>> a mission to make the world a freer place, even if we disagree about how
>> we
>> get there.
>>
>> Yours truly,
>>
>> Jeremy
>>
>> [0]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>> [1]: http://r6.ca/blog/20210615T191422Z.html I quite enjoyed Roconnor's
>> detailed post on Speedy Trial
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/9009e65d/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> ------------------------------
>>
>> End of bitcoin-dev Digest, Vol 84, Issue 4
>> ******************************************
>>
> _______________________________________________
> 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/20220502/ee18ad51/attachment-0001.html>

2023-06-07 23:09:00

- reply

📅 Original date posted:2022-05-01
📝 Original message:I've been thinking about writing something about covenant proposals from
the viewpoint of wallet vaults specifically (mostly because that's the use
case I care most about).
CTV is basically the minimal covenant opcode you can do that doesn't have
malleability. Everything else either introduces malleability, infinite
recursion, or has interactions with other proposed opcodes that could
introduce potentially undesirable effects like those.
TXHASH+CSFS seems like on its own might enable pretty much
identical capabilities to CTV (including no malleability). But it can also
do other things (mostly because CSFS can do other things), which isn't
necessarily a bad thing, but its more stuff to be analyzed. TXHASH+CSFS in
terms of wallet vaults seems to provide no benefits over CTV as far as I
can imagine.
It seems pretty clear that anything involving OP_CAT is out for the time
being. There are so many things it can enable that it seems most people
aren't comfortable adding it at the moment.
APO wallet vaults seem rather hacky, inefficient, and limited. Certainly
not easy to reason about. But this is somewhat a function of my limited
understanding of them. Its not clear to me if anyone is actually suggesting
that we should use APO for covenants, but it doesn't feel like the right
approach.
TLUV + IN_OUT_AMOUNT can do infinitely recursive covenants. IN_OUT_AMOUNT
wasn't very clearly specified that I know of, but its not a very robust way
of ensuring the correct amount goes where you want. If TLUV requires a
single input and a single output, IN_OUT_AMOUNT makes sense because you can
simply do opcode math to determine if the output is receiving enough coins
(and not eg being all lost as fees). Maybe it could be extended to allow
multiple outputs, but extending it to allow for multiple inputs would be
difficult and you'd probably want a completely different mechanism for
that. If you're doing any math the script itself around amounts and fees,
this doesn't work well in any scenario where multiple inputs might send to
the same address, or be combined into the same output, since each input's
script can't interact.
But since TLUV at its most basic should be able to say "remove the only
tapleaf in this tree and replace it with this other tap tree", it should be
able to do pretty arbitrary covenants. It ideally should be paired up with
something that has better control over how input amounts flow to outputs
than IN_OUT_AMOUNT allows (see the design considerations here
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>).
TLUV is built for evictions, but it seems its likely not really very good
at that, as Zman mentioned in his post about OP_EVICT
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html>
(which is a covenant opcode that can't be used for wallet vaults, tho
perhaps its characteristics can be used in a kind of TLUV2 opcode that does
evictions better, but also can add tapleaves).
OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf> is
another interesting one. Also has a form that allows recursive covenants.
It also has similar awkwardness as TLUV + IN_OUT_AMOUNT around multi-input
transactions. It has the half-spend problem if two outputs are combined
that specify the same output index and script pattern. It also seems like a
rather expensive opcode to use beyond very simple covenants, since the
scripts basically has to be duplicated in the transaction specifying the
covenant and then again when the subsequent transaction is spent. Its not
very taproot friendly either: would you have to specify the entire taproot
script tree? Any similar opcode that requires specifying the exact
script(s) fundamentally can't take advantage taproot's ability to keep
scripts private until that spend path is actually used.
As far as I can tell, few of these other covenant opcodes have even been
concretely specified, let alone analyzed enough to know whether they're
worth pursuing. It seems like all but CTV (potentially TXHASH+CSFS) have
significant flaws and would need reworking in order to fix them.
I guess in short, I agree with you. Over these other ideas that have gotten
significant attention, none really seem to be of high enough quality to be
put into bitcoin in their current state.
On Thu, Apr 28, 2022 at 3:47 AM alicexbt via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> CTV and other covenant proposals, tradeoffs, and overlapping features are
> among the topics being explored recently. I had some views and questions on
> this subject.:
>
> a) Does bitcoin already have opcodes with overlapping features? Yes
>
> b) Can we have multiple ways with some overlapping features to do bitcoin
> covenants with some tradeoffs? Yes
> _
> c) What are these tradeoffs if we compare CTV, APO, TLUV and TXHASH+CSFS?
>
> I am sure about a) because it was already answered in CTV chat by Jeremy
> and sheshek. Example: CHECKSIG and CHECKSIGADD is redundant with OP_IF and
> OP_ADD
>
> Not sure if we have "consensus" on b) but I don't see anything wrong with
> it.
>
> For c) I would prefer CTV because:
>
> - Simpler
> - Blockspace effient
> - Can be used even without taproot
>
> Covering bare script, as in segwit v0, is necessary. Exposing a pubkey in
> case of an EC break will be a disaster, and vaults imply very long lived
> storage. Root CA offline certificates can often have shelf life measured in
> decades. However, NSA has issued warnings, NIST has issued guidelines, and
> executive order to prepare for the quantum shift. As a result, forcing
> everyone into a quantum-unsafe position is unsustainable.
>
> Other developers might use a different way to do bitcoin covenant for
> other reasons. Example: Russel O'Connor would prefer general OP_TXHASH
> design
>
> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/> secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/84cd21d4/attachment-0001.html>

2023-06-07 23:08:59

- reply

📅 Original date posted:2022-05-12
📝 Original message:@Antoine
> it's also hard to predict in advance the liquidity needs of the
sub-pools.
Definitely. Better than not being able to use the pool at all when
someone's offline tho.
> this fan-out transaction could interfere with the confirmation of the
simple withdraw transactions
> So there is an open question about the "honest" usage of the sub-pool
states themselves.
I don't follow this one. How would it interfere? How would it call into
question the "honesty" of the sub-pools? Why would honesty matter? I would
assume they can all be structured trustlessly.
> one could envision an accumulator committing directly to balances too
Are you suggesting that there would be some kind of opcode that operates on
this accumulator to shift around balances of some participants without
disturbing others? Sounds reasonable.
> I think the challenge is to find a compact accumulator with those
properties.
The Merkle Sum Trees like are used in Taro sound like they could probably
be useful for that.
> It's more likely a lot of them will delegate this operation to
third-party providers, with the known reductions in terms of
trust-minimizations.
There is of course that limitation. But a third party empowered only to
keep the pool functioning is much better than one given the ability to
spend on your behalf without your confirmation. This would be a big
improvement despite there still being minor privacy downsides.
> Hmmm, how could you prevent the always-online service from using the
receiving-key in "spending" mode if the balance stacked there becomes
relevant ?
You mean if your balance in the pool is 1000 sats and the service
facilitates receiving 100 sats, that service could then steal those 100
sats? And you're asking how you could prevent that? Well first of all, if
you're in a channel, not only does your service need to want to steal your
funds, but your channel partner(s) must also sign for that as well - so
they both must be malicious for these funds to be stolen. I can't see a way
to prevent that, but at least this situation prevents them from stealing
your whole 1100 sats, and can only steal 100 sats.
> see https://gitlab.com/lightning-signer/docs for wip in that direction.
Interesting. I'm glad someone's been working on this kind of thing
> A malicious pool participant could still commit her off-chain balance in
two partitions and send spends to the A&B hosting "receiving-keys" entities
without them being aware of the conflict, in the lack of a reconciliation
such as a publication space ?
Actually, I was envisioning that the always-online services holding a
receive-only key would *all* be online. So all participants of the pool
would have a representative, either one with a spending key or with just a
receiving-key (which could also be used to simply sign pool state changes
that don't negatively affect the balance of the user they represent). So
there still would be agreement among all participants on pool state
changes.
I kind of think if both techniques (sub-pools and limited-trust services)
are used, it might be able to substantially increase the ability for a pool
to operate effectively (ie substantially decrease the average downtime).
@ZmnSCPxj
> Is this not just basically channel factories?
It is.
> To reduce the disruption if any one pool participant is down, have each
sub-pool have only 2 participants each.
Yes. But the benefit of the pool over just having individual 2 person
channels is that you can change around the structure of the channels within
the pool without doing on-chain transactions. As Antoine mentioned, it may
often not be predictable which 2-person channels would be beneficial in the
future. So you want the pool to be as responsive as possible to the
changing needs of the pool.
On Tue, May 10, 2022 at 11:45 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Billy,
>
>
> > Very interesting exploration. I think you're right that there are issues
> with the kind of partitioning you're talking about. Lightning works because
> all participants sign all offchain states (barring data loss). If a
> participant can be excluded from needing to agree to a new state, there
> must be an additional mechanism to ensure the relevant state for that
> participant isn't changed to their detriment.
> >
> > To summarize my below email, the two techniques I can think for solving
> this problem are:
> >
> > A. Create sub-pools when the whole group is live that can be used by the
> sub- pool participants later without the whole group's involvement. The
> whole group is needed to change the whole group's state (eg close or open
> sub-pools), but sub-pool states don't need to involve the whole group.
>
> Is this not just basically channel factories?
>
> To reduce the disruption if any one pool participant is down, have each
> sub-pool have only 2 participants each.
> More participants means that the probability that one of them is offline
> is higher, so you use the minimum number of participants in the sub-pool: 2.
> This makes any arbitrary sub-pool more likely to be usable.
>
> But a 2-participant pool is a channel.
> So a large multiparticipant pool with sub-pools is just a channel factory
> for a bunch of channels.
>
> I like this idea because it has good tradeoffs, so channel factories ho.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220512/940da85e/attachment.html>

2023-06-07 23:08:57

- reply

📅 Original date posted:2022-05-01
📝 Original message:Hi Antoine,
Very interesting exploration. I think you're right that there are issues
with the kind of partitioning you're talking about. Lightning works because
all participants sign all offchain states (barring data loss). If a
participant can be excluded from needing to agree to a new state, there
must be an additional mechanism to ensure the relevant state for that
participant isn't changed to their detriment.
To summarize my below email, the two techniques I can think for solving
this problem are:
A. Create sub-pools when the whole group is live that can be used by the
sub- pool participants later without the whole group's involvement. The
whole group is needed to change the whole group's state (eg close or open
sub-pools), but sub-pool states don't need to involve the whole group.
B. Have an always-online system empowered to sign only for group updates
that *do not* change the owner's balance in the group. This could be done
with a hardware-wallet like device, or could be done with some kind of new
set of opcodes that can be used to verify that a particular transaction
isn't to the owner's detriment.
I had some thoughts that I think don't pan out, but here they are anyway:
What if the pool state transaction (that returns everyone's money) has each
participant sign the input + their personal output (eg with sighash flags)?
That way the transaction could have outputs swapped out by a subset of
participants as needed. Some kind of eltoo mechanism could then ensure that
the latest transaction can override earlier transactions. As far as the
non-participating members are concerned, they don't care whether the newest
state is published or whether the newest state they participated in is
published - because their output is identical either way. However, I can
see that there might be problems related to separate groups of participants
creating conflicting transactions, ie A B & C create a partition like this,
and so do D E & F, but they don't know about each other's state. If they
have some always-online coordination mechanism, this could be solved as
long as the participants aren't malicious. But it still leaves open the
possibility that some participants could intentionally grief others by
intentionally creating conflicting state transactions. Theoretically it
could be structured so that no funds could be directly stolen, but it seems
unavoidable that some group of members could create a secret transaction
that when published makes the most recent honest state not minable.
Come to think of it tho, this doesn't actually solve the double spending
problem. The fundamental issue is that if you have a subset of participants
creating partitions like this, without the involvement of the whole group,
its impossible for any subset of participants to know for sure that there
isn't a double-spending partition amongst another set of members of the
group.
On-chain bitcoin transactions prevent double spending by ensuring that
everyone knows what outputs have been spent. Payment channels prevent
double spending by ensuring that everyone that's part of the channel knows
what the current channel state is. Any 3rd layer probably needs this exact
property: everyone involved must know the state. So you should be able to
create a partition when the whole group is live, and thereafter the members
of that partition can use that partition without involving the rest of the
group. I think that pattern can work to any level of depth. After thinking
about this, I conjecture it might be a fundamental property of the double
spending problem. All participants must be aware of the whole state
otherwise the double spending problem exists for those who aren't aware of
the whole state.
> this is forcing the pool/factory user to share their key materials with
potentially lower trusted entities, if they don't self-host the tower
instances.
I had a conceptual idea a while back (that I can't find at the moment)
about offline lightning receiving. The concept is that each lightning node
in a channel has two separate keys: a spending-key and a receiving-key. The
spending-key must be used manually by the node owner to send payments,
however the receiving-key can be given to an always-online service that can
use that key only to either receive funds (ie update the state to a more
favorable state).
Right now with just a single-hot-key setup you need to trust your online
system to only sign receiving transactions and would refuse to sign any
proposed channel update not in the owner's favor. However, if the node was
compromised all bets are off - the entire channel balance could be stolen.
You could do this logic inside a hardware-wallet-like device that checks
the proposed updates and verifies the new state is favorable before
signing. This could go a long way to hardening lightning nodes against
potential compromise.
But if we go a step further, what if we enable that logic of ensuring the
state is more favorable with an on-chain mechanism? This was where my idea
got a bit hand wavy, but I think it could theoretically be done. The
receiving-key would be able to sign receiving transactions that would only
be valid when the most recent state signed by the spending-key is also
included in the script sig in some way. Some Script would then validate
that the receiving-key state being published is more favorable than the
spending-key state in that transaction's outputs. You'd have a couple
guarantees:
1. The usual guarantee that if the presented last spending-key state is
actually out of date, the transaction could be overridden by the newer
state in some way (eg eltoo style or punishment).
2. The state being published can be no worse than the presented
spending-key state. Yes, your channel partner could compromise your
receiving/routing node and then publish an out of date receiving-key
channel state that's based on the most-recent spending-key state, but it
would limit your losses to at most the amount of money you've received
since the last time you manually signed a channel state with your
spending-key. Because the always-online system empowered to receive does
*not* have the spending-key, anyone that compromises that node can't spend
and the damage is limited.
While less straight-forward than for receiving, in principle it seems like
something similar could be done for routing (which would require presenting
the state of multiple channels, and so has some additional complexities
there I haven't worked out).
This kind of thing might be a way of working around interactivity
requirements of payment pools and the like. All participants still have to
be aware of the whole state (eg of the payment pool), but this awareness
can be delegated to a system you have limited trust in. Payment pool
participants could delegate an always-online system empowered with a
separate key to sign payment pool updates that user's state isn't changed
for, allowing the payment pool to do its thing without exposing the user to
hot-key vulnerabilities in that always-online system. Double spending is
prevented because the user can access their always-online system to get the
full payment pool state.
So in short, while I think there may be no way to fundamentally not require
interactivity, there are workarounds that can limit how often full
interactivity is needed as well as ways to make it easier to provide that
full interactivity without compromising other aspects of each participant's
security.
On Thu, Apr 28, 2022 at 8:20 AM Antoine Riard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> This post recalls the noticeable interactivity issue encumbering payment
> pools and channel factories in the context of a high number of
> participants, describes how the problem can be understood and proposes few
> solutions with diverse trust-minizations and efficiency assumptions. It is
> intended to capture the theoretical bounds of the "interactivity issue",
> where technical completeness of the solutions is exposed in future works.
>
> The post assumes a familiarity with the CoinPool paper concepts and
> terminology [0].
>
> # The interactivity requirement grieving payment pools/channel factories
>
> Payment pools and channel factories are multi-party constructions enabling
> to share the ownership of a single on-chain UTXO among many
> off-chain/promised balances. Payment pool improves on the channel factory
> construction fault-tolerance by reducing the number of balance outputs
> disclosed on-chain to a single one in case of unilateral user exits.
>
> However, those constructions require all the users to be online and
> exchange rounds of signatures to update the balance distribution. Those
> liveliness/interactivity requirements are increasing with the number of
> users, as there are higher odds of *one* lazzy/buggy/offline user stalling
> the pool/factory updates.
>
> In echo, the design of LN was envisioned for a network of
> always-online/self-hosted participants, the early deployment of LN showed
> the resort to delegated channel hosting solutions, relieving users from the
> liveliness requirement. While the trust trade-offs of those solutions are
> significant, they answer the reality of a world made of unreliable networks
> and mobile devices.
>
> Minding that observation, the attractiveness of pools/factories might be
> questioned.
>
> # The interactivity requirement palliatives and their limits
>
> Relatively straightforward solutions to lower the interactivity
> requirement, or its encumbered costs, can be drawn out. Pools/factories
> users could own (absolute) timelocked kick-out abilities to evict offline
> users who are not present before expiration.
>
> E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
> Each of them owns a Withdraw transaction to exit their individual balances
> at any time. Each user should have received the pre-signed components from
> the others guaranteeing the unilateral ability to publish the Withdraw.
>
> A kick-out ability playable by any pool user could be provided by
> generating a second set of Withdraw transactions, with the difference of
> the nLocktime field setup to an absolute height T + X, where T is the
> height at which the corresponding Update transaction is generated and X the
> kick-out delay. For this set of kick-out transactions, the complete
> witnesses should be fully shared among Alice, Bob, Caroll and Dave. That
> way, if Caroll is unresponsive to move the pool state forward after X, any
> one of Alice, Bob or Dave can publish the Caroll kick-out Withdraw
> transaction, and pursue operations without that unresponsive party.
>
> While decreasing the interactivity requirement to the timelock delay, this
> solution is constraining the kicked user to fallback on-chain encumbering
> the UTXO set with one more entry.
>
> Another solution could be to assume the widespread usage of node towers
> among the pool participants. Those towers would host the full logic and key
> state necessary to receive an update request and produce a user's approval
> of it. As long as one tower instance is online per-user, the pool/factory
> can move forward. Yet this is forcing the pool/factory user to share their
> key materials with potentially lower trusted entities, if they don't
> self-host the tower instances.
>
> Ideally, I think we would like a trust-minimized solution enabling
> non-interactive, off-chain updates of the pool/factory, with no or minimal
> consumption of blockspace.
>
> For the remainder of this post, only the pool use-case will be mentioned.
> Though, I think the observations/implications can be extended to factories
> as well.
>
> # Non-interactive Off-chain Pool Partitions
>
> If a pool update fails because of lack of online unanimity, a partition
> request could be exchanged among the online subset of users ("the
> actives"). They decide to partition the pool by introducing a new layer of
> transactions gathering the promised/off-chain outputs of the actives. The
> set of outputs belonging to the passive users remains unchanged.
>
> The actives spend their Withdraw transactions `user_balance` outputs back
> to a new intermediate Update transaction. This "intermediate" Update
> transaction is free to re-distribute the pool balances among the active
> users. To guarantee the unilateral withdraw ability of a partitioned-up
> balance, the private components of the partitioned Withdraw transactions
> should be revealed among the set of active users.
>
> E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
> Pool is at state N, Bob and Dave are offline. Alice and Caroll agree to
> partition the pool, each of them owns a Withdraw transaction
> ready-to-be-attached on the Update transaction N. They generate a new
> partitioning Update transaction with two inputs spending respectively
> Alice's Withdraw transaction `user_balance` output and Caroll's Withdraw
> transaction `user-balance` output. From this partitioning Update
> transaction, two new second-layer Withdraw ones are issued.
>
> Alice and Caroll reveal to each other the private components of their
> first-layer Withdraw transactions, allowing to publish the full branch :
> first-layer Update transaction, first-layer Withdraw transactions,
> second-layer partitioning Update transaction, second-layer partitioned
> Withdraw transaction. At that step, I think the partitioning should be
> complete.
>
> Quickly, a safety issue arises with pool partitioning. A participant of
> the active set A could equivocate the partition state by signing another
> spend of her Withdraw transaction allocating her balance to an Update
> transaction of a "covert" set of active users B.
>
> This equivocation exists because there is no ordering of the off-chain
> spend of the Withdraw transactions and any Withdraw transaction can be
> freely spent by its owner. This issue appears as similar to solving the
> double-spend problem.
>
> Equivocation is a different case than multiple *parallel* partitions,
> where there is no intersection between the partitioned balances. The
> parallel partitions are still rooting from the same Update transaction N. I
> think the safety of parallel partitions is yet to be explored.
>
> # Current solutions to the double-spend problem : Bitcoin base-layer &
> Lightning Network
>
> Of course, the double-spend issue is already addressed on the Bitcoin
> base-layer due to nodes consensus convergence on the most-proof-of-work
> accumulated valid chain of blocks. While reorg can happen, a UTXO cannot be
> spent twice on the same chain. This security model can be said to be
> prophylactic, i.e an invalid block cannot be applied to a node's state and
> should be rejected.
>
> The double-spend issue is also solved in its own way in payment channels.
> If a transaction is published, of which the correctness has been revoked
> w.r.t negotiated, private channel state, the wronged channel users must
> react in consequence. This security model can be said to be corrective,
> states updates are applied first on the global ledger then eventually
> corrected.
>
> A solution to the pool partition equivocation issue appears as either
> based on a prophylactic one or a corrective security model.
>
> Let's examine first, a reactive security model similar to LN-Penalty. At
> pool partition proposals, the owners of the partitioned-up Withdraw
> transactions could reveal a revocation secret enabling correction in case
> of wrongdoing (e.g single-show signatures). However, such off-chain
> revocation can be committed towards multiple sets of honest "active" users.
> Only one equivocating balance spend can succeed, letting the remaining set
> of honest users still be deprived of their expected partitioned balances.
>
> E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
> Alice contacts Bob to form a first partition, then Caroll to form a second
> one, then Dave to form a last one. If she is successful in that
> equivocation trick, she can *triple*-spend her balance against any goods or
> out-of-pool payments.
>
> Assuming the equivocation is discovered once realized, Bob, Caroll and
> Dave are all left with a branch of transactions all including Alice's
> Withdraw one. However only one branch can be fully published, as a Withdraw
> transaction can be played only once following the pool semantic.
> Game-theory-wise, Bob, Caroll and Dave have an interest to enter in a fee
> race to be the first to confirm and earn the Alice balance spend.
>
> The equivocation is only bounded by the maximal number of equivocating
> sets one can form, namely the number of pool users. However, correction can
> only be limited to the equivocated balance. Therefore, it appears that
> corrective security models in the context of multi-party are always
> producing an economic disequilibrium.
>
> An extension of this corrective model could be to require off-pool
> collaterals locked-up, against which the revocation secret would be
> revealed at partition generation. However, this fix is limited to the
> collateral liquidity available. One collateral balance should be guaranteed
> for each potential victim, thus the collateral liquidity should be equal to
> the number of pool users multiplied by the equivocatable balance amount.
>
> It sounds like a more economic-efficient security model of the pool
> partitioning can be established with a prophylactic technique.
>
> # Trusted coordinator
>
> A genuine solution could be to rely on a coordinator collecting the
> partition declaration and order them canonically. The pool partition
> candidates can then fetch them and decide their partitions acceptance
> decisions on that. Of course, the coordinator is trusted and can drop or
> dissimulate any partition, thus enabling partitioned balance equivocation.
>
> # Trust-minimized : Partition Statements
>
> A pool partition invalidity can be defined by the existence of two
> second-layer Update transactions at the same state number spending the same
> Withdraw transaction balance output. Each Update transaction signature can
> be considered as a "partition statement". A user wishing to join a
> partition should ensure there is no conflicting partition statement before
> applying the partition to her local state.
>
> The open question is from where the conflict should be observed. A
> partition statement log could be envisioned and monitored by pool users
> before to accept any partition.
>
> I think multiple partition statement publication spaces can be drawn out,
> with different trust-minization trade-offs.
>
> # Publication space : Distributed Bulletin Boards
>
> The set of "active" pool users could host their own boards of partition
> statements. They would coordinate on the statement order through a
> consensus algorithm (e.g Raft). For redundancy, a user can have multiple
> board instances. If a user falls offline, they can fetch the statement
> order from the other users boards.
>
> However, while this solution distributes the trust across all the other
> users, it's not safe in case of malicious user coalitions agreeing among
> themselves to drop a partition statement. Therefore, a user catching up
> online can be feeded with an incorrect view of the existing partitions, and
> thus enter into an equivocated partition.
>
> # Publication space : On-chain Authoritative Board
>
> Another solution could be to designate an authoritative UTXO at pool
> setup. This UTXO could be spent by any user of the pool set (1-of-N) to a
> covenanted transaction sending back to a Taproot output with the same
> internal key. The Merkelized tree tweaked could be modified by the spender
> to stamp the partition statements as leaves hashes. The statement data is
> not committed in the leaves itself and the storage can be delegated to
> out-of-band archive servers.
>
> E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
> Alice and Bob decide to start a partition, they commit a hash of the
> partitioning Update transaction as a Taproot tree leaf and they spend the
> pool authoritative UTXO. They also send a copy of the Update transaction to
> an archive server.
>
> At a later time, Alice proposes to Caroll to start a partition. Caroll
> follows the chain of transactions forming the on-chain authoritative board,
> she fetches the merkle branches and leaves data payload from an archive
> server, verifying the authenticity of the branches and payload. As Alice
> has already published a partition statement spending her Withdraw, Caroll
> should refuse the partition proposal.
>
> Even if a pool user goes offline, she can recover the correct partition
> statement logs, as it has been committed in the chain from the
> authoritative UTXO. If the statement data is not available from servers,
> the pool user should not engage in partitions.
>
> Assuming the spend confirms in every block, this solution enables
> partitions every 10min. The cost can be shared across pool instances, if
> the authoritative signers set is made of multiple pool instances signers
> sets. A threshold signature scheme could be used to avoid interactivity
> beyond the aggregated key setup. However, batching across pool instances
> increases the set of data to verify by the partition candidate users, which
> could be a grievance for bandwidth-constrained clients.
>
> # Fiability of the Publication of Partition Statements
>
> Whatever ends up being used as a partition statement log, there is still
> the question of the incentives of pool users to publish the partition
> statements. A malicious user could act in coalition with the equivocating
> entity to retain the publication of her partition statement. Thus, an
> honest user would only be aware of her own partition statement and accept
> the partition proposal from the will-be equivocating entity.
>
> I think that leveraging covenants a revocation mechanism could be attached
> on any equivocating branch of transactions, allowing in the above case a
> single honest user to punish the publication. While a revocation mechanism
> does not work in case of multiple defrauded users, I believe the existence
> of a revocation mechanism makes the formation of malicious coalitions
> unsafe for their conjurers.
>
> Indeed, any user entering in the coalition is not guaranteed to be blinded
> to other equivocating branches generated by the partition initiator.
> Therefore, the publication of a partition statement by everyone is
> holistically optimal to discover any equivocating candidate among the pool
> users.
>
> Further research should establish the soundness of the partition statement
> publication game-theory.
>
> # Writing the Partition Statements to a new Consensus Data Structure
>
> To avoid a solution relying on game-theory, a new consensus data structure
> could be introduced to register and order the partition statements. This
> off-chain contract register could be a Merkle tree, where every leaf is a
> pool balance identified by a key. This register would be established
> on-chain at the same time the pool is set up.
>
> Every time the pool is partitioned, the tree leaves would be updated with
> the partition statement committed to. Only one partition could be
> registered per user by state number. The publication branch would be
> invalid if it doesn't point back to the corresponding contract register
> tree entries. When the first-layer pool Update transaction is replaced, the
> tree should transition to a blank state too.
>
> Beyond the high cost of yet-another softfork to introduce such consensus
> data structure, the size of the witness to write into the contract register
> could be so significant that the economic attractiveness of pool
> partitioning is decreased in consequence.
>
> If you have read so far, thank you. And curious if anyone has more ideas
> or thoughts on the high interactivity issue ?
>
> Thanks Gleb for the review.
>
> Cheers,
> Antoine
>
> [0] https://coinpool.dev/
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/29523d35/attachment-0001.html>

2023-06-07 23:08:56

- reply

📅 Original date posted:2022-05-01
📝 Original message:> if you are perfectly rational, you can certainly imagine a "what if"
where your goal is different from your current goal and figure out what you
would do ***if*** that were your goal instead.
I see what you're saying, and I'm a lot more on board with that. I still
think "rational" can't mean "perfect" - like "perfectly rational" is not
the same as "you magically get to the optimal answer". But I think my line
of thinking on this is a lot more pedantic than my previous contention. But
I will agree that for a given specific objective goal (that ignores other
goals), there is an objective set of answers that any logical person should
eventually be able to agree on. Of course, if there's any subjectivity in
the goal, then discussing the goal amongst two different people will really
mean that each of them are discussing slightly different goals, which
breaks the premise. So really for alignment to happen, the goal in question
needs to be really specific in order to remove any significant
subjectivity.
> better-than-human rationality
I like to think of rationality in the following way. Any economic actor is
a being that has goals they want to maximize for, and tools at their
disposal to analyze and affect their world. A rational actor is one that
attempts to use their tools to the best of their ability to maximize their
goals. Perhaps goals is a misleading word to use here, since it implies
something that can be achieved, whereas I really mean a set of weighted
metrics that can hypothetically always be improved upon. But in any case, a
human starts with goals built into their genetics, which in turn build
themselves into the structure of their body. The tools a human has is also
their body and their brain. The brain is not a perfect tool, and neither is
the rest of the body. However, humans use what they have to make decisions
and act on their world. The goals a human has evolve as they have
experiences in the world (which end up physically changing their brain). In
this sense, every human, and every possible actor really, must be a
rational actor. They're all doing the best they can, even if the tools at
their disposal are very suboptimal for maximizing their underlying goals.
What more can you ask of a rational actor than to use the tools they have
to achieve their goals?
So I don't think anyone is more or less "rational" than anyone else. They
just have different goals and different levels of ability to maximize those
goals. In my definition above, the goals are completely arbitrary. They
don't have to be anything in particular. A person could have the goal of
maximizing the number of paper clips in the world, at all other costs. This
would almost certainly be "bad" for that person, and "bad" for the world,
but if that's really what their goals are, then that "badness" is a
subjectivity that you and I would be placing on that goal because our goals
are completely different from it. To the being with that goal, it is a
totally perfect goal.
The idea that someone can be "more rational" than someone else kind of
boils everything down to one dimension. In reality, everyone has their
different skills and proficiencies. In a futures market, you might be
better at predicting the price of salmon, but you might be quite bad at
predicting human population changes over time. Does this mean you're "more
rational" about salmon but "less rational" about how human populations
change? I would say a better way to describe this is proficiency, rather
than rationality.
</digression>
> a future market
A futures market for predictions is an interesting idea. I haven't really
heard about such a thing really being done other than in little
experiments. Are you suggesting we use one to help make decisions about
bitcoin? One issue is that the questions a futures market answers have to,
like my conclusion in the above paragraph, be completely objective. So a
futures market can't answer the question "what's the best way to design
covenants?" tho it could answer the question "will CTV be activated by
2024?". But as a consequence, I don't think a future's market could help
much in the formulation of appropriate goals for bitcoin. That would need
to be hashed out by making a lot of different compromises amongst
everyone's various subjective opinion's about what is best.
And I think that's really what I'm suggesting here, is that we bitcoiners
discuss what the objective goals of bitcoin should be, or at least what
bounds on those goals there should be. And once we have these objective
goals, we can be aligned on how to appropriately solve them. It wouldn't
avoid the nashing of teeth needed to hash out the subjective parts of our
opinions in getting to those goals, but it could avoid much nashing of
teeth in the other half of the conversation: how to achieve the goals we
have reached consensus on.
Eg, should a goal of bitcoin be that 50% of the world's population should
require spending no more than 1% of their income to be able to run a full
node? Were we to decide on something akin to that, it would at least be a
question that has an objective truth value to it, even if we couldn't
feasibly confirm to 100% certainty whether we have achieved it, we could
probably confirm with some acceptable level of certainty below 100%.
On Sat, Apr 30, 2022 at 1:14 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Billy,
>
> > @Zman
> > > if two people are perfectly rational and start from the same
> information, they *will* agree
> > I take issue with this. I view the word "rational" to mean basically
> logical. Someone is rational if they advocate for things that are best for
> them. Two humans are not the same people. They have different circumstances
> and as a result different goals. Two actors with different goals will
> inevitably have things they rationally and logically disagree about. There
> is no universal rationality. Even an AI from outside space and time is
> incredibly likely to experience at least some value drift from its peers.
>
> Note that "the goal of this thing" is part of the information where both
> "start from" here.
>
> Even if you and I have different goals, if we both think about "given this
> goal, and these facts, is X the best solution available?" we will both
> agree, though our goals might not be the same as each other, or the same as
> "this goal" is in the sentence.
> What is material is simply that the laws of logic are universal and if you
> include the goal itself as part of the question, you will reach the same
> conclusion --- but refuse to act on it (and even oppose it) because the
> goal is not your own goal.
>
> E.g. "What is the best way to kill a person without getting caught?" will
> probably have us both come to the same broad conclusion, but I doubt either
> of us has a goal or sub-goal to kill a person.
> That is: if you are perfectly rational, you can certainly imagine a "what
> if" where your goal is different from your current goal and figure out what
> you would do ***if*** that were your goal instead.
>
> Is that better now?
>
> > > 3. Can we actually have the goals of all humans discussing this topic
> all laid out, *accurately*?
> > I think this would be a very useful exercise to do on a regular basis.
> This conversation is a good example, but conversations like this are rare.
> I tried to discuss some goals we might want bitcoin to have in a paper I
> wrote about throughput bottlenecks. Coming to a consensus around goals, or
> at very least identifying various competing groupings of goals would be
> quite useful to streamline conversations and to more effectively share
> ideas.
>
>
> Using a future market has the attractive property that, since money is
> often an instrumental sub-goal to achieve many of your REAL goals, you can
> get reasonably good information on the goals of people without them having
> to actually reveal their actual goals.
> Also, irrationality on the market tends to be punished over time, and a
> human who achieves better-than-human rationality can gain quite a lot of
> funds on the market, thus automatically re-weighing their thoughts higher.
>
> However, persistent irrationalities embedded in the design of the human
> mind will still be difficult to break (it is like a program attempting to
> escape a virtual machine).
> And an uninformed market is still going to behave pretty much randomly.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/c23d0f10/attachment-0001.html>

2023-06-07 23:08:53

- reply

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

2023-06-07 23:08:42

- reply

📅 Original date posted:2022-05-01
📝 Original message:+1 alicexbt
We of course want knowledgeable bitcoiners who aren't knowledgeable about a
certain proposal to be skeptical. But what we don't want is for that
natural skepticism-from-ignorance to be interpreted as opposition, or
really a strong signal of any kind. Any thoughts from ignorance, whether
self-aware or not, should be given small weight. It seems the vast majority
of push back has been this kind of skepticism from ignorance. And to a
certain degree I think we want to give time for understanding to those who
have not participated in the first, second, third, etc round of discussion
on a proposal. It may not be reasonable to say "you had the last 2 years of
time to voice your concern".
Now that CTV is being taken seriously as a proposal, we probably should
give the community who is finally taking a serious look at it time to
understand, get their questions answered, and come to terms with it. This
is not to say that CTV as a technology or proposal has been rushed, or has
not had enough work put into it, but rather that the community as a whole
has not paid enough attention to it for long enough.
The wrong approach is: "how do I yell more loudly next time I see something
I'm uncomfortable with?" The right approach is to educate those who aren't
educated on the proposal and gather consensus on what people think when
they understand enough about it to contribute to that consensus. If you
care about consensus, you should respect the consensus process and be ok
with consensus being not your preferred outcome. If you don't care about
consensus, then you're basically attacking the bitcoin community.
On Sun, May 1, 2022 at 3:22 AM alicexbt via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Michael,
>
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional attention to the dangers, a URSF movement
> started to gain momentum and those attempting a contentious soft fork
> activation backed off. (Disappointingly Bitcoin Optech didn't cover my
> previous posts to this mailing list 1
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html>,
> 2
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html>,
> 3
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html>
> highlighting the dangers many months ago or recent posts. Normally Optech
> is very high signal.)
>
>
> Some users have been misled and there is nothing great being achieved by
> doing this on social media. Andreas is clueless about BIP 119 and other
> covenant proposals. He is spreading misinformation and some of the URSF
> enthusiasts do not understand what are they even opposing or going to run
> with risks involved.
>
>
> Answering the subject of this email: "What to do when contentious soft
> forks activations are attempted?"
>
> - Do not consider something contentious because someone said it on mailing
> list
> - Do not spread misinformation
> - Read all posts in detail with different opinions
> - Avoid personal attacks
> - Look at the technical details, code etc. and comment on things that
> could be improved
>
>
>
> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/> secure email.
>
> ------- Original Message -------
> On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via bitcoin-dev
> bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
> I’ve been in two minds on whether to completely move on to other topics or
> to formulate some thoughts on the recent attempt to activate a contentious
> soft fork. In the interests of those of us who have wasted
> days/weeks/months of our time on this (with no personal upside) and who
> don’t want to repeat this exercise again I thought I should at least raise
> the issue for discussion of what should be done differently if this is
> tried again in future.
>
> This could be Jeremy with OP_CTV at a later point (assuming it is still
> contentious) or anyone who wants to pick up a single opcode that is not yet
> activated on Bitcoin and try to get miners to signal for it bypassing
> technical concerns from many developers, bypassing Bitcoin Core and
> bypassing users.
>
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional attention to the dangers, a URSF movement
> started to gain momentum and those attempting a contentious soft fork
> activation backed off. (Disappointingly Bitcoin Optech didn't cover my
> previous posts to this mailing list 1
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html>,
> 2
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html>,
> 3
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html>
> highlighting the dangers many months ago or recent posts. Normally Optech
> is very high signal.)
>
> Alternatively this was the first time a contentious soft fork activation
> was attempted, we were all woefully unprepared for it and none of us knew
> what we were doing.
>
> I’m unsure on the above. I’d be interested to hear thoughts. What I am
> sure of is that it is totally unacceptable for one individual to bring the
> entire Bitcoin network to the brink of a chain split. There has to be a
> personal cost to that individual dissuading them from trying it again
> otherwise they’re motivated to try it again every week/month. Perhaps the
> personal cost that the community is now prepared if that individual tries
> it again is sufficient. I’m not sure. Obviously Bitcoin is a permissionless
> network, Bitcoin Core and other open source projects are easily forked and
> no authority (I’m certainly no authority) can stop things like this
> happening again.
>
> I’ll follow the responses if people have thoughts (I won't be responding
> to the instigators of this contentious soft fork activation attempt) but
> other than that I’d like to move on to other things than contentious soft
> fork activations. Thanks to those who have expressed concerns publicly (too
> many to name, Bob McElrath was often wording arguments better than I could)
> and who were willing to engage with the URSF conversation. If an individual
> can go directly to miners to get soft forks activated bypassing technical
> concerns from many developers, bypassing Bitcoin Core and bypassing users
> Bitcoin is fundamentally broken. The reason I still have hope that it isn't
> is that during a period of general apathy some people were willing to stand
> up and actively resist it.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.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/20220501/7158d8ed/attachment.html>

2023-06-07 23:08:28

- reply

📅 Original date posted:2022-04-28
📝 Original message:@Zman
> if two people are perfectly rational and start from the same information,
they *will* agree
I take issue with this. I view the word "rational" to mean basically
logical. Someone is rational if they advocate for things that are best for
them. Two humans are not the same people. They have different circumstances
and as a result different goals. Two actors with different goals will
inevitably have things they rationally and logically disagree about. There
is no universal rationality. Even an AI from outside space and time is
incredibly likely to experience at least some value drift from its peers.
> 3. Can we actually have the goals of all humans discussing this topic
all laid out, *accurately*?
I think this would be a very useful exercise to do on a regular basis. This
conversation is a good example, but conversations like this are rare. I
tried to discuss some goals
<https://github.com/fresheneesz/bitcoinThroughputAnalysis#general-goals> we
might want bitcoin to have in a paper I wrote about throughput bottlenecks.
Coming to a consensus around goals, or at very least identifying various
competing groupings of goals would be quite useful to streamline
conversations and to more effectively share ideas.
@Nadav
> 1. There's a real cost attached to voting
This is IMO a huge downside. It prevents many from participating at all.
And it also give a big advantage to those who have a large monetary
consequence. It exacerbates the common problem in votes where special
interests spend lots of time and money to get something passed that is bad
overall, while its not bad enough for most people to spend time and money
opposing it.
> 3. Custodians don't get disproportionate voting power with their
customers' funds (not without getting themselves into fractional reserve,
at least).
I disagree. A. they already have fractional reserve most likely, but you're
right that it would cut into their normal rehypothication. But B.
custodians would definitely have an advantage because of holding people's
funds. They can use those funds however they want. If they think this vote
is more valuable to them then their normal rehypothication, they can direct
a lot of funds.
> 5. Selling your vote if you're disinterested in the outcome isn't a
no-brainer like in the naive scheme.
This is a good point, and is something I missed above when I was talking
about coin-weighted polling. However, literally all signaling of any kind
is subject to this kind of thing, unless you do something like blind voting
(where the voter can't prove how they voted to a would be vote buyer). Not
sure how you'd do blind voting in a way people can trust. Then again, if
these things aren't actually voting, and its quite likely that people would
talk about any significant vote buying effort, its possible that such an
effort could be adjusted for.
On Thu, Apr 28, 2022 at 11:09 AM Billy Tetrud <billy.tetrud at gmail.com>
wrote:
> @Keagan
> > we have to have a way (formalized or not) of deciding when the "lesser
> experts" in aggregate have better judgement.
>
> I agree. Its certainly convenient for development speed to limit the
> number of cooks in the kitchen. But for the largest cryptocurrency in the
> world, we're going to have to face the reality that the number of
> stakeholders has grown vastly larger than the developer community and those
> who implicitly trust the developer community, or any particular part of the
> dev community working on any particular upgrade.
>
> > Perhaps it warrants zooming out beyond even what my proposal aims to
> solve
>
> I very much like the way you framed the question, and I think these are
> important, potentially existential questions we should urge the bitcoin
> community to think deeply about.
>
> > 1. ... what would be the threshold for saying "this consensus change is
> ready for activation"?
>
> This is indeed the basic question.
>
> > 1a. Does that threshold change based on the nature of the consensus
> change
>
> I don't think the threshold of consensus changes should depend on the type
> of consensus change. Any consensus change, no matter how small, introduces
> risk, can cause bugs, can open a back door. Naturally, simpler changes
> should be able to *reach* consensus faster, because presumably it would
> take less analysis, and be easier to explain and convince people of. But
> that doesn't mean the bar of consensus should be lower. I think it should
> not. A change may look small and innocuous when it is in fact not, and it
> would be less than ideal for people to try to pretend there's sufficient
> consensus by insisting that a change is so "small" that no more is needed.
>
> > 1b. Do different constituencies (end users, wallets, exchanges, coinjoin
> coordinators, layer2 protocols, miners) have a desired minimum or maximum
> representation in this "threshold"?
>
> There is a lot to say about this simple question. I think it should be
> recognized that the "say" anyone or any group has depends on their total
> future (or perhaps only total near-term) economic influence on the network.
> This is related to the concept of the "economic majority". What is the
> "economic majority"? We could say this depends exactly on the proportion of
> bitcoin you own, but I don't think that would be quite right. For example,
> a miner that (hypothetically) keeps no bitcoin except for what is being
> changed into fiat has an important role and significant economic influence
> on bitcoin. Miners provide a service. Their livelihood depends on
> bitcoiners, and the livelihood of bitcoin depends in part on miners.
> Similarly, a vendor who accepts bitcoin directly but converts it all to
> fiat provides a service as well. They expand the network of where bitcoin
> is directly useful. People willing to pay for things in bitcoin also
> similarly expand bitcoin's network.
>
> I think it only makes sense to align incentives and attempt to match the
> amount of representation a group gets to the amount of economic influence
> they have on the network. To do otherwise would invite a schism.
>
> Based on the above, I'm thinking that there are only really two components
> of what should comprise the weight of any person or group's say: 1. the
> stake they have in bitcoin, and 2. the value they provide to bitcoin. Let
> me elaborate:
>
> Bitcoin has a purpose. That purpose is as a currency. The directly
> valuable aspects of that are as a store of value and as a means of
> exchange. The properties of bitcoin lead to benefits to using it as both of
> those things. Therefore, the stake people have in holding bitcoin should
> count heavily because the value of holding is a major purpose of bitcoin.
> But at the same time the ability to transact bitcoin should also count
> pretty heavily because its also a major purpose of bitcoin and at the same
> time accepting or spending bitcoin expands the network. If we were able to
> economically equate those two things, we might get closer to a way to
> figure out how to ideally distribute representation. Similarly, we could
> add miners and developers into this mix, comparing them based on the value
> they provide to the network.
>
> So let:
> holdAmount = the value of bitcoin they're holding over a given period of
> time T
> transactionVolume = the volume of transaction value over a given period of
> time T
> miningVolume = the value of bitcoin they mined over time period T
> technologyValue = the value of new technological developments produced
> over time period T
>
> A group's representation should =
> (holdAmount*A + transactionVolume*B + miningVolume*C + technologyValue*D)
> /
> (totalLiveBitcoin*A + totalTransactionVolume*B + totalMiningVolume*C +
> totalTechnologyValue*D)
>
> where A through D are constants that relate the value of holding vs the
> value of transacting vs the value of mining vs the value of building
> bitcoin technology. We could split this up so that eg the representation
> that holders in total should have just by holding is: A/(A+B+C+D)
>
> For example, an equivalence could be: how much value does holding bitcoin
> give the average user per year? How much value does transacting give the
> average user per year? These are fuzzy and subjective and potentially
> dubious, but bare with me. Let's say that on average, a holder gets a
> benefit of 2% of their holdings per year (on a risk adjusted basis). That
> would be a benefit of $13.25 billion per year. And let's say that the ~$1.642
> trillion of transactions per year
> <https://data.nasdaq.com/data/BCHAIN/ETRVU-bitcoin-estimated-transaction-volume-usd> bitcoin
> is doing has about 33% being actual exchanges of goods and services
> <https://www.newsbtc.com/tech/only-33-of-bitcoin-payments-used-to-purchase-goods-economic-value-in-question/> and
> for that 33% the transactors in sum also get a benefit of about 2% of the
> transacted amount. That would be a benefit of $10.8 billion per year. If we
> proxy the value of bitcoin mining to the network as the revenue they
> received, perhaps this is as much as $15.3 billion
> <https://www.prnewswire.com/news-releases/bitcoin-miners-revenue-rose-206-in-2021-301482452.html#:~:text=The%20report%20finds%20that%20on,in%20terms%20of%20Bitcoin%20mining.>.
> How do we calculate the value of developers? I don't know a good proxy for
> that. But for kicks, why don't we say its as much as miners at $15.3
> billion.
>
> Using these numbers, the representation for each:
>
> Holders: 13.25/(13.25+10.8+15.3+15.3) = 24%
> Transactors: 10.8/(13.25+10.8+15.3+15.3) = 20%
> Miners: 15.3/(13.25+10.8+15.3+15.3) = 27%
> Developers: Also 27%
>
> Maybe we could approximate that as each of the four categories has a 1/4th
> share of representation. Values of A through D are certainly up for debate.
>
> In any case, to get back to the question at hand (1b), I don't see any
> reason to think there's a minimum or maximum representation for each
> primary constituency. However, there would of course be minimum and maximum
> bounds on our confidence for how much value/stake each constituency has,
> and therefore a confidence range on how much representation they should
> have.
>
> But this 4 part group of holders, transactors, miners, and developers
> seems to make a lot of sense to me. These are the main groups, and any
> other subgroup can neatly fit into one or more of those.
>
> With the assumption that the above numbers are somewhat accurate, it seems
> reasonable to say that any majority of those four groups should be able to
> prevent a change from happening. Maybe even any 40% of any of those groups.
> Were we to roll this all into a single count, 40% of any group of 25% of
> the whole is 10%, so it kind of supports the idea of a 90% threshold.
> Although of course right now we have a 90% threshold on just miner
> signaling. But since that's the only direct signaling we have, I think we
> prudently erred on the safe side. But perhaps if we have something near
> 100% consensus in support of a change among the other 3 categories, perhaps
> we could safely reduce the miner signaling quite a bit, perhaps not to 60%
> (because of chain split concerns) but perhaps to 70% or 75%.
>
> > what tests can we devise to measure those levels of support directly? If
> we can't measure it directly, can we measure different indicators that
> would help us infer or solve for the knowledge we want?
>
> For 3 of the 4 groups, there seems to me clear mechanisms we can use:
> * Holders: Something akin to my coin-weighted polling proposal here
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>
> .
> * Transactors: Something akin to your transaction signaling proposal
> above. Tho I would strongly suggest removing the tie between miner
> signaling and transaction signaling to make it purely informational.
> * Miner signaling as usual, or perhaps extended to provide a way for
> miners to actively signal against a change
> <https://github.com/fresheneesz/bip-trinary-version-signaling>.
>
> For developers, I would say we probably need to come to consensus with
> discussion, but hopefully we could be a bit more structured about it. For
> example, we could get rough measures of consensus by gathering explicit
> reviews on a proposal. Opinions like "I don't like it" or "This is great,
> let's do it!" would count for very little, reviews that look into a
> particular section deeply or review the broad idea as a whole would count a
> bit more, and reviews that discuss many good points and reasons about a
> large fraction of the proposal would carry even more weight. This is of
> course again subjective, but at least it would provide a framework to work
> within, and a way to at least approximate a developer consensus weighted by
> actual knowledge of and thought put into the subject. If we went further to
> attempt to collect together these reviews in a structured way, it would
> make it easier for someone to relatively quickly (ie by spending a few
> hours reading through reviews) verify for themselves approximately what
> consensus "is".
>
> > 3. Can any of the answers to #2 be "gamed"?
>
> As long as we understand the limitations of the measurements, I don't
> think they can be gamed. However, they can leave a lot of room for doubt.
> Eg, a coin-weighted poll might only have a response rate of 5% of the coin.
> If we allow signals to both support or oppose a change, I think that would
> substantially increase the meaningfulness of the data - at least we know
> the consensus among those who care / are aware enough to signal (without
> allowing opposition signaling, a low response rate means we have no idea
> how many of the non signalers oppose a thing).
>
> The transaction signaling can be gamed a bit, because someone can simply
> spend more money to send more signals. This might favor bad actors a bit
> (honest actors presumably wouldn't attempt to game the system).
>
> Miner signaling doesn't really seem gameable.
>
> TBH, developer consensus is probably the most gameable. All it is is talk.
> Putting coin weight behind it would bias things, and often the
> loudest/frequentest talkers get an advantage. Putting some major thought
> into how to de-bias developer consensus seems like the most important thing
> to figure out.
>
> > Perhaps .. we are doomed to this painful process of arguing .. until
> there's only one opinion left standing.. However, if this is the case, I
> don't think we can honestly claim that devs don't control the protocol.
>
> If we argue until the last left standing, is it even "the developers" in
> control? Might it rather be the talkers, the yellers, the busy bodies? I
> can't think of anyone worse being in control. I very much hope we're not
> doomed to that fate. However, to avoid it, we need to come up with a
> logical solution that is defendable and encodable into the social fabric of
> bitcoin (just like sound money and nacho keys nacho cheese).
>
> On Thu, Apr 28, 2022 at 12:18 AM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> @Felipe
>> > the consensus should follow the current line: discussions and tests
>> carried out by experts. We all know that the most important devs have the
>> most weight in discussions. And that's how it should be
>>
>> We have up til this point been miraculously lucky that the vast majority
>> of prominent bitcoin developers are in relative alignment on the big
>> picture philosophy and have all seemed to be honest and open in general.
>> However, we cannot rely on this era of philosopher kings to continue.
>> Relying on experts in this way is an enormous attack vector. It should not
>> be the "most important" devs who carry the most weight, but weight should
>> be carried by the logic of what is being said. The speaker should ideally
>> not matter in consensus building. So I agree with Keagan's implication that
>> this is not how bitcoin should govern itself. We should move away from
>> appeals to authority towards something more amorphous and difficult to
>> control.
>>
>> @Jeremy
>> > if there were a way to sign with a NUMS point for ring signature
>> purposes
>>
>> Do you have any link you could point to about NUMS points? I assume this
>> would be a way to aggregate coin-weighted signals in a way that helps hide
>> who signaled in what direction?
>>
>> > if NUMS points are common these ring signatures protocols might not be
>> too useful for collecting signals
>>
>> I'm curious: why is it better if its less common? I'm used to privacy
>> properties increasing as the privacy technique used becomes more common.
>>
>> @Erik
>> > it doesn't address the "what about people who don't know there's a vote
>> going on"
>> > how nonexperts can "have a say" when they simply don't understand the
>> relevant issues.
>>
>> I think a useful way to think about this is in terms of preferences and
>> representation, rather than in the terms of coming to the best technical
>> solution. The fact of the matter is that value is subjective and therefore
>> there is no "best" technical solution all the time. Sometimes the
>> preferences of stakeholders must be weighed and a compromise come to.
>> Hopefully most of these kinds of compromises can happen in the free market
>> on upper layers. But certainly some of them happen on the consensus layer.
>>
>> An expert with deep knowledge can deeply understand a design or change
>> well enough to come to a full opinion about it according to their
>> preferences. But even other experts might not have read enough about a
>> thing, or just don't have time to delve deeply into that particular aspect.
>> They'll have to rely partly on their ability to make a determination from
>> partial knowledge and their ability to evaluate the trustworthiness and
>> skill of those who have deeper knowledge than them. Nonexperts and
>> non-technical people have to rely on those kinds of things even more so.
>> Many people only have social signals to rely on. What do the people they
>> trust say?
>>
>> I believe that the truth gets out eventually. Those who have deep
>> knowledge will eventually convince those who don't, tho that may take a
>> long time to play out. As annoying as the twitterati is, I think we should
>> get used to needing to give their opinions a bit of weight in terms of
>> measuring consensus. Of course, we shouldn't be making technical decisions
>> based on what nontechnical people want or think, however, what we should do
>> is make sure that we are explaining the changes we propose to make clearly
>> enough that a certainly level of comfort diffuses into the social circles
>> of people who care about bitcoin but don't understand it at a technical
>> enough level to participate in technical decision making. At a certain
>> point, if not enough people are comfortable with a change, the change
>> shouldn't be made yet until enough people are convinced its probably safe
>> and probably good. Think of the large set of non-technical people to be a
>> glue that connects together otherwise unconnected pockets of wisdom.
>>
>> Doing things this way would almost certainly lead to slower development.
>> But development of the consensus layer slowing over time should be what we
>> all expect, and I daresay what we should all want eventually.
>>
>> > it will just be a poll of "people who pay attention to the dev list and
>> maybe some irc rooms"
>>
>> Maybe. But if there were mechanisms for broader consensus measuring,
>> perhaps more would pay attention. Perhaps some way to affect change would
>> lead more to have discussions and participate.
>>
>> Even if its a small group at first, I think it would be very useful
>> information to see both who explicitly supports something, who explicitly
>> is against something, and also who is paying attention but neutral (maybe
>> even actively signaling as "neutral').
>>
>> > unless there's a great ux around the tooling my guess is that it won't
>> garner a lot of meaningful data:
>>
>> I agree. Tooling would be very important here.
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 27, 2022 at 3:13 PM Erik Aronesty <erik at q32.com> wrote:
>>
>>>
>>>>
>>>> Have you taken a look at my proposal
>>>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>?
>>>> The proposal is, to be clear, *not* "voting" but rather polling that isn't
>>>> programmatically connected to activation. The intention is for people
>>>> (developers) to look at the polling results and make an educated analysis
>>>> of it as far as how it should contribute to consensus gathering.
>>>>
>>>
>>> it's cool, and i agree it's somewhat censorship resistant
>>>
>>>
>>>> Let's say everyone who participates in polling broadcasts it along the
>>>> bitcoin network (a separate network would probably be better, so as to not
>>>> interfere with normal bitcoin, but I digress),
>>>>
>>>
>>> right, anyone can then publish a json file with polling aggregates at a
>>> certain block height and anyone can quickly check to see if they are lying
>>> or missing data
>>>
>>>
>>>> Similar structures could be added to any script configuration to allow
>>>> signing of polls without any significant exposure.
>>>>
>>>
>>> rubin's suggestion around tapscript anon voting could help with anonymity
>>>
>>> .... all of this is cool ...
>>>
>>> but it doesn't address the "what about people who don't know there's a
>>> vote going on" or other the other social issues with "weighted polling" in
>>> general, like how nonexperts can "have a say" when they simply don't
>>> understand the relevant issues. i personally feel like i'm "only a very
>>> little bit up on the issues" and i have more tech knowledge than most
>>> people i know
>>>
>>> also, it will just be a poll of "people who pay attention to the dev
>>> list and maybe some irc rooms"
>>>
>>> might be worth experimenting with... but unless there's a great ux
>>> around the tooling my guess is that it won't garner a lot of meaningful
>>> data:
>>>
>>> open source, simple cli, gitian build, installs easily on all platforms,
>>> works well with bitcoind rpc, works with ledger, can import a seed, etc.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220428/7beecb19/attachment-0001.html>

2023-06-07 23:08:27

- reply

📅 Original date posted:2022-04-28
📝 Original message:@Keagan
> we have to have a way (formalized or not) of deciding when the "lesser
experts" in aggregate have better judgement.
I agree. Its certainly convenient for development speed to limit the number
of cooks in the kitchen. But for the largest cryptocurrency in the world,
we're going to have to face the reality that the number of stakeholders has
grown vastly larger than the developer community and those who implicitly
trust the developer community, or any particular part of the dev community
working on any particular upgrade.
> Perhaps it warrants zooming out beyond even what my proposal aims to solve
I very much like the way you framed the question, and I think these are
important, potentially existential questions we should urge the bitcoin
community to think deeply about.
> 1. ... what would be the threshold for saying "this consensus change is
ready for activation"?
This is indeed the basic question.
> 1a. Does that threshold change based on the nature of the consensus change
I don't think the threshold of consensus changes should depend on the type
of consensus change. Any consensus change, no matter how small, introduces
risk, can cause bugs, can open a back door. Naturally, simpler changes
should be able to *reach* consensus faster, because presumably it would
take less analysis, and be easier to explain and convince people of. But
that doesn't mean the bar of consensus should be lower. I think it should
not. A change may look small and innocuous when it is in fact not, and it
would be less than ideal for people to try to pretend there's sufficient
consensus by insisting that a change is so "small" that no more is needed.
> 1b. Do different constituencies (end users, wallets, exchanges, coinjoin
coordinators, layer2 protocols, miners) have a desired minimum or maximum
representation in this "threshold"?
There is a lot to say about this simple question. I think it should be
recognized that the "say" anyone or any group has depends on their total
future (or perhaps only total near-term) economic influence on the network.
This is related to the concept of the "economic majority". What is the
"economic majority"? We could say this depends exactly on the proportion of
bitcoin you own, but I don't think that would be quite right. For example,
a miner that (hypothetically) keeps no bitcoin except for what is being
changed into fiat has an important role and significant economic influence
on bitcoin. Miners provide a service. Their livelihood depends on
bitcoiners, and the livelihood of bitcoin depends in part on miners.
Similarly, a vendor who accepts bitcoin directly but converts it all to
fiat provides a service as well. They expand the network of where bitcoin
is directly useful. People willing to pay for things in bitcoin also
similarly expand bitcoin's network.
I think it only makes sense to align incentives and attempt to match the
amount of representation a group gets to the amount of economic influence
they have on the network. To do otherwise would invite a schism.
Based on the above, I'm thinking that there are only really two components
of what should comprise the weight of any person or group's say: 1. the
stake they have in bitcoin, and 2. the value they provide to bitcoin. Let
me elaborate:
Bitcoin has a purpose. That purpose is as a currency. The directly valuable
aspects of that are as a store of value and as a means of exchange. The
properties of bitcoin lead to benefits to using it as both of those things.
Therefore, the stake people have in holding bitcoin should count heavily
because the value of holding is a major purpose of bitcoin. But at the same
time the ability to transact bitcoin should also count pretty heavily
because its also a major purpose of bitcoin and at the same time accepting
or spending bitcoin expands the network. If we were able to economically
equate those two things, we might get closer to a way to figure out how to
ideally distribute representation. Similarly, we could add miners and
developers into this mix, comparing them based on the value they provide to
the network.
So let:
holdAmount = the value of bitcoin they're holding over a given period of
time T
transactionVolume = the volume of transaction value over a given period of
time T
miningVolume = the value of bitcoin they mined over time period T
technologyValue = the value of new technological developments produced over
time period T
A group's representation should =
(holdAmount*A + transactionVolume*B + miningVolume*C + technologyValue*D)
/
(totalLiveBitcoin*A + totalTransactionVolume*B + totalMiningVolume*C +
totalTechnologyValue*D)
where A through D are constants that relate the value of holding vs the
value of transacting vs the value of mining vs the value of building
bitcoin technology. We could split this up so that eg the representation
that holders in total should have just by holding is: A/(A+B+C+D)
For example, an equivalence could be: how much value does holding bitcoin
give the average user per year? How much value does transacting give the
average user per year? These are fuzzy and subjective and potentially
dubious, but bare with me. Let's say that on average, a holder gets a
benefit of 2% of their holdings per year (on a risk adjusted basis). That
would be a benefit of $13.25 billion per year. And let's say that the ~$1.642
trillion of transactions per year
<https://data.nasdaq.com/data/BCHAIN/ETRVU-bitcoin-estimated-transaction-volume-usd>
bitcoin
is doing has about 33% being actual exchanges of goods and services
<https://www.newsbtc.com/tech/only-33-of-bitcoin-payments-used-to-purchase-goods-economic-value-in-question/>
and
for that 33% the transactors in sum also get a benefit of about 2% of the
transacted amount. That would be a benefit of $10.8 billion per year. If we
proxy the value of bitcoin mining to the network as the revenue they
received, perhaps this is as much as $15.3 billion
<https://www.prnewswire.com/news-releases/bitcoin-miners-revenue-rose-206-in-2021-301482452.html#:~:text=The%20report%20finds%20that%20on,in%20terms%20of%20Bitcoin%20mining.>.
How do we calculate the value of developers? I don't know a good proxy for
that. But for kicks, why don't we say its as much as miners at $15.3
billion.
Using these numbers, the representation for each:
Holders: 13.25/(13.25+10.8+15.3+15.3) = 24%
Transactors: 10.8/(13.25+10.8+15.3+15.3) = 20%
Miners: 15.3/(13.25+10.8+15.3+15.3) = 27%
Developers: Also 27%
Maybe we could approximate that as each of the four categories has a 1/4th
share of representation. Values of A through D are certainly up for debate.
In any case, to get back to the question at hand (1b), I don't see any
reason to think there's a minimum or maximum representation for each
primary constituency. However, there would of course be minimum and maximum
bounds on our confidence for how much value/stake each constituency has,
and therefore a confidence range on how much representation they should
have.
But this 4 part group of holders, transactors, miners, and developers seems
to make a lot of sense to me. These are the main groups, and any other
subgroup can neatly fit into one or more of those.
With the assumption that the above numbers are somewhat accurate, it seems
reasonable to say that any majority of those four groups should be able to
prevent a change from happening. Maybe even any 40% of any of those groups.
Were we to roll this all into a single count, 40% of any group of 25% of
the whole is 10%, so it kind of supports the idea of a 90% threshold.
Although of course right now we have a 90% threshold on just miner
signaling. But since that's the only direct signaling we have, I think we
prudently erred on the safe side. But perhaps if we have something near
100% consensus in support of a change among the other 3 categories, perhaps
we could safely reduce the miner signaling quite a bit, perhaps not to 60%
(because of chain split concerns) but perhaps to 70% or 75%.
> what tests can we devise to measure those levels of support directly? If
we can't measure it directly, can we measure different indicators that
would help us infer or solve for the knowledge we want?
For 3 of the 4 groups, there seems to me clear mechanisms we can use:
* Holders: Something akin to my coin-weighted polling proposal here
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>
.
* Transactors: Something akin to your transaction signaling proposal above.
Tho I would strongly suggest removing the tie between miner signaling and
transaction signaling to make it purely informational.
* Miner signaling as usual, or perhaps extended to provide a way for miners
to actively signal against a change
<https://github.com/fresheneesz/bip-trinary-version-signaling>.
For developers, I would say we probably need to come to consensus with
discussion, but hopefully we could be a bit more structured about it. For
example, we could get rough measures of consensus by gathering explicit
reviews on a proposal. Opinions like "I don't like it" or "This is great,
let's do it!" would count for very little, reviews that look into a
particular section deeply or review the broad idea as a whole would count a
bit more, and reviews that discuss many good points and reasons about a
large fraction of the proposal would carry even more weight. This is of
course again subjective, but at least it would provide a framework to work
within, and a way to at least approximate a developer consensus weighted by
actual knowledge of and thought put into the subject. If we went further to
attempt to collect together these reviews in a structured way, it would
make it easier for someone to relatively quickly (ie by spending a few
hours reading through reviews) verify for themselves approximately what
consensus "is".
> 3. Can any of the answers to #2 be "gamed"?
As long as we understand the limitations of the measurements, I don't think
they can be gamed. However, they can leave a lot of room for doubt. Eg, a
coin-weighted poll might only have a response rate of 5% of the coin. If we
allow signals to both support or oppose a change, I think that would
substantially increase the meaningfulness of the data - at least we know
the consensus among those who care / are aware enough to signal (without
allowing opposition signaling, a low response rate means we have no idea
how many of the non signalers oppose a thing).
The transaction signaling can be gamed a bit, because someone can simply
spend more money to send more signals. This might favor bad actors a bit
(honest actors presumably wouldn't attempt to game the system).
Miner signaling doesn't really seem gameable.
TBH, developer consensus is probably the most gameable. All it is is talk.
Putting coin weight behind it would bias things, and often the
loudest/frequentest talkers get an advantage. Putting some major thought
into how to de-bias developer consensus seems like the most important thing
to figure out.
> Perhaps .. we are doomed to this painful process of arguing .. until
there's only one opinion left standing.. However, if this is the case, I
don't think we can honestly claim that devs don't control the protocol.
If we argue until the last left standing, is it even "the developers" in
control? Might it rather be the talkers, the yellers, the busy bodies? I
can't think of anyone worse being in control. I very much hope we're not
doomed to that fate. However, to avoid it, we need to come up with a
logical solution that is defendable and encodable into the social fabric of
bitcoin (just like sound money and nacho keys nacho cheese).
On Thu, Apr 28, 2022 at 12:18 AM Billy Tetrud <billy.tetrud at gmail.com>
wrote:
> @Felipe
> > the consensus should follow the current line: discussions and tests
> carried out by experts. We all know that the most important devs have the
> most weight in discussions. And that's how it should be
>
> We have up til this point been miraculously lucky that the vast majority
> of prominent bitcoin developers are in relative alignment on the big
> picture philosophy and have all seemed to be honest and open in general.
> However, we cannot rely on this era of philosopher kings to continue.
> Relying on experts in this way is an enormous attack vector. It should not
> be the "most important" devs who carry the most weight, but weight should
> be carried by the logic of what is being said. The speaker should ideally
> not matter in consensus building. So I agree with Keagan's implication that
> this is not how bitcoin should govern itself. We should move away from
> appeals to authority towards something more amorphous and difficult to
> control.
>
> @Jeremy
> > if there were a way to sign with a NUMS point for ring signature
> purposes
>
> Do you have any link you could point to about NUMS points? I assume this
> would be a way to aggregate coin-weighted signals in a way that helps hide
> who signaled in what direction?
>
> > if NUMS points are common these ring signatures protocols might not be
> too useful for collecting signals
>
> I'm curious: why is it better if its less common? I'm used to privacy
> properties increasing as the privacy technique used becomes more common.
>
> @Erik
> > it doesn't address the "what about people who don't know there's a vote
> going on"
> > how nonexperts can "have a say" when they simply don't understand the
> relevant issues.
>
> I think a useful way to think about this is in terms of preferences and
> representation, rather than in the terms of coming to the best technical
> solution. The fact of the matter is that value is subjective and therefore
> there is no "best" technical solution all the time. Sometimes the
> preferences of stakeholders must be weighed and a compromise come to.
> Hopefully most of these kinds of compromises can happen in the free market
> on upper layers. But certainly some of them happen on the consensus layer.
>
> An expert with deep knowledge can deeply understand a design or change
> well enough to come to a full opinion about it according to their
> preferences. But even other experts might not have read enough about a
> thing, or just don't have time to delve deeply into that particular aspect.
> They'll have to rely partly on their ability to make a determination from
> partial knowledge and their ability to evaluate the trustworthiness and
> skill of those who have deeper knowledge than them. Nonexperts and
> non-technical people have to rely on those kinds of things even more so.
> Many people only have social signals to rely on. What do the people they
> trust say?
>
> I believe that the truth gets out eventually. Those who have deep
> knowledge will eventually convince those who don't, tho that may take a
> long time to play out. As annoying as the twitterati is, I think we should
> get used to needing to give their opinions a bit of weight in terms of
> measuring consensus. Of course, we shouldn't be making technical decisions
> based on what nontechnical people want or think, however, what we should do
> is make sure that we are explaining the changes we propose to make clearly
> enough that a certainly level of comfort diffuses into the social circles
> of people who care about bitcoin but don't understand it at a technical
> enough level to participate in technical decision making. At a certain
> point, if not enough people are comfortable with a change, the change
> shouldn't be made yet until enough people are convinced its probably safe
> and probably good. Think of the large set of non-technical people to be a
> glue that connects together otherwise unconnected pockets of wisdom.
>
> Doing things this way would almost certainly lead to slower development.
> But development of the consensus layer slowing over time should be what we
> all expect, and I daresay what we should all want eventually.
>
> > it will just be a poll of "people who pay attention to the dev list and
> maybe some irc rooms"
>
> Maybe. But if there were mechanisms for broader consensus measuring,
> perhaps more would pay attention. Perhaps some way to affect change would
> lead more to have discussions and participate.
>
> Even if its a small group at first, I think it would be very useful
> information to see both who explicitly supports something, who explicitly
> is against something, and also who is paying attention but neutral (maybe
> even actively signaling as "neutral').
>
> > unless there's a great ux around the tooling my guess is that it won't
> garner a lot of meaningful data:
>
> I agree. Tooling would be very important here.
>
>
>
>
>
>
>
> On Wed, Apr 27, 2022 at 3:13 PM Erik Aronesty <erik at q32.com> wrote:
>
>>
>>>
>>> Have you taken a look at my proposal
>>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>?
>>> The proposal is, to be clear, *not* "voting" but rather polling that isn't
>>> programmatically connected to activation. The intention is for people
>>> (developers) to look at the polling results and make an educated analysis
>>> of it as far as how it should contribute to consensus gathering.
>>>
>>
>> it's cool, and i agree it's somewhat censorship resistant
>>
>>
>>> Let's say everyone who participates in polling broadcasts it along the
>>> bitcoin network (a separate network would probably be better, so as to not
>>> interfere with normal bitcoin, but I digress),
>>>
>>
>> right, anyone can then publish a json file with polling aggregates at a
>> certain block height and anyone can quickly check to see if they are lying
>> or missing data
>>
>>
>>> Similar structures could be added to any script configuration to allow
>>> signing of polls without any significant exposure.
>>>
>>
>> rubin's suggestion around tapscript anon voting could help with anonymity
>>
>> .... all of this is cool ...
>>
>> but it doesn't address the "what about people who don't know there's a
>> vote going on" or other the other social issues with "weighted polling" in
>> general, like how nonexperts can "have a say" when they simply don't
>> understand the relevant issues. i personally feel like i'm "only a very
>> little bit up on the issues" and i have more tech knowledge than most
>> people i know
>>
>> also, it will just be a poll of "people who pay attention to the dev list
>> and maybe some irc rooms"
>>
>> might be worth experimenting with... but unless there's a great ux around
>> the tooling my guess is that it won't garner a lot of meaningful data:
>>
>> open source, simple cli, gitian build, installs easily on all platforms,
>> works well with bitcoind rpc, works with ledger, can import a seed, etc.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220428/4eac8acc/attachment-0001.html>

2023-06-07 23:08:26

- reply

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

2023-06-07 23:08:25

- reply

📅 Original date posted:2022-04-27
📝 Original message:@Erik
> Miners can block votes from the chain
This would seem to not realistically ever happen in Keagan's proposal,
since miners can only include transactions that signal the same way they're
signaling. So yes, they could block those transactions, but it would be
very much against their interests to do so, and they cannot block
transactions that signal against them. That is assuming that *some* miners
signal differently. If literally (or practically) 100% of the miners signal
the same way, then you're right that it blocks alternative signals, but at
the same time, the signals will still be there in the mempool for all to
see at the time.
The other points against this style of transaction signaling sound correct
to me.
> We can collect votes off-chain by signing messages and publishing them
"somewhere", but where would that be?
Have you taken a look at my proposal
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>?
The proposal is, to be clear, *not* "voting" but rather polling that isn't
programmatically connected to activation. The intention is for people
(developers) to look at the polling results and make an educated analysis
of it as far as how it should contribute to consensus gathering.
In that proposal, a central publishing place is not necessary, as any
comparison of two different sets of poll results can simply be merged into
one set to get the most accurate picture. It would be very easy to see if
someone is dishonestly publishing incomplete poll results. In a proper
implementation of this, everyone should be able to have poll results that
match almost exactly, especially when looking at the results for eg > 1
week in the past.
> How do you make this censorship-resistant?
Let's say everyone who participates in polling broadcasts it along the
bitcoin network (a separate network would probably be better, so as to not
interfere with normal bitcoin, but I digress), and anyone who wants to
collect poll data simply collects it all. That would be censorship
resistant in the exact same way bitcoin is censorship resistant.
> Suppose someone's coins are protected by a hot/cold covenant, like TLUV
or CTV: parse scripts? Ick.
Ideally, address types would take this into account. In taproot, one could
simply sign a poll message with the key spendpath key but one could also
embed a poll-signing path in a particular unspendable leaf in the MAST if
they want to designate a different poll-signing key. For non-taproot, an
address format could be redefined to be, instead of hash(publickey), to be
hash(hash(publickey)+hash(pollSigningKey)). Or something similar. That way
the spending public key doesn't need to be revealed in order to sign a poll
message.
Similar structures could be added to any script configuration to allow
signing of polls without any significant exposure.
On Wed, Apr 27, 2022 at 9:28 AM Erik Aronesty <erik at q32.com> wrote:
> There are many challenges with on-chain voting, here are a few:
>
> - We may not want votes on-chain, because it creates miner incentives for
> contentious BIP's to drive up fees
> - Miners can block votes from the chain
> - Cold storage votes are probably the most important for certain proposals
> (like vaulting), but are the least-likely to vote
> - Awareness and participation in blockchain voting is typically very low
> and is mostly limited to big exchanges
>
> And off chain voting is even worse:
>
> - We can collect votes off-chain by signing messages and publishing them
> "somewhere", but where would that be?
> - How do you make this censorship-resistant?
> - Suppose someone's coins are protected by a hot/cold covenant, like TLUV
> or CTV: parse scripts? Ick.
>
> Although I do wish sometimes that this were not the case, I feel like the
> verbal wrangling and rough/messy-consensus building remains our best choice.
>
> On Wed, Apr 27, 2022 at 10:07 AM Chris Riley via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> >> we should not let the wealthy make consensus decisions.
>>
>> >We shouldn't let the wealthy continue to control our governments.
>> However, bitcoin is not a government. Its a financial network.
>> >The fact of the matter is that fundamentally, the economic majority
>> controls where the chain goes. Its very likely that the wealthy
>> >are disproportionately represented in the economic majority. Attempting
>> to subvert the economic majority seems like a bad idea.
>> >The reality of control there will come out one way or another, and being
>> honest about it is probably the best way to avoid major schisms in the
>> future.
>>
>> Yes, the economic majority is important: Who else has more incentive to
>> protect the security and thus the value embodied in the network than people
>> who have invested money and time in the network? A group of people with
>> 1/10/100/1000 bitcoins each has more economic incentive to do so than a
>> similar sized group with 1/10/100/1000 satoshis each. Likewise, it is
>> significantly easier to mobilize 1 million people "voting" with 100
>> satoshis each - a total of 1 BTC - vs 10000 people each voting with 100
>> bitcoins each - a total of 1 million BTC. I don't think anyone would say
>> that even if those 1 million people, for example, thought that we should
>> increase the number of bitcoins via perpetual inflation it would be a good
>> idea to listen to it however the vote was done whether via transaction
>> flags or something else. Of course they could fork off.
>>
>> Cheers, :-)
>> Chris
>>
>>
>>
>>
>>
>> On Wed, Apr 27, 2022 at 4:11 AM Billy Tetrud via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> > A transaction signaling in the affirmative MUST NOT be included in a
>>> block that does not signal in the affirmative
>>>
>>> I feel like I've heard this idea somewhere before. Its an interesting
>>> idea.
>>>
>>> It should be noted that there is a consequence of this: holders wouldn't
>>> have much say. People that transact a lot (or happen to be transacting a
>>> lot during the signaling time period) would have a very disproportionate
>>> ability to pressure miners than people who aren't transacting much. This
>>> would probably be a pretty good proxy for future mining revenue that
>>> supports (or is against) a particular thing. However, the network does do
>>> more than just transact, so I would be a bit worried that such a mechanism
>>> would bias the system towards things that are good for transactors and bad
>>> for holders. Things like more coin inflation, larger blocks, etc.
>>>
>>> Another consideration is that miners are already incentivized to follow
>>> the money here. Adding an *additional* incentive might be distorting the
>>> market, so to speak.
>>>
>>> An alternative I proposed was a way to do weighted polling of holders:
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html
>>>
>>> The polling wouldn't be directly connected to the activation mechanism
>>> in any way, but would just be a mechanism to gauge some portion of
>>> consensus. If enough people were involved, theoretically it could be hooked
>>> up to activation, but I would be pretty wary of doing that directly as well.
>>>
>>> > we should not let the wealthy make consensus decisions.
>>>
>>> We shouldn't let the wealthy continue to control our governments.
>>> However, bitcoin is not a government. Its a financial network. The fact of
>>> the matter is that fundamentally, the economic majority controls where the
>>> chain goes. Its very likely that the wealthy are disproportionately
>>> represented in the economic majority. Attempting to subvert the economic
>>> majority seems like a bad idea. The reality of control there will come out
>>> one way or another, and being honest about it is probably the best way to
>>> avoid major schisms in the future.
>>>
>>> > Does a scheme like this afford us a better view into consensus than we
>>> have today?
>>>
>>> It does more than provide a view. It directly changes the game theory
>>> around how activation works. If we wanted to simply get a better view into
>>> consensus, we could allow the same thing, but allow any block to mine any
>>> transaction regardless of transaction signaling. Then it would be more
>>> purely informational.
>>>
>>> > Can it be gamed to give us a *worse* view into consensus? How?
>>> > Does it measure the right thing? If not, what do you think is the
>>> right thing to measure?
>>>
>>> Doesn't seem like it could be gamed, but as I mentioned above, the
>>> honest mechanics of it might be themselves undesirably distorting.
>>>
>>>
>>>
>>> On Tue, Apr 26, 2022 at 3:49 PM Bryan Bishop via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> You may be interested in these posts on transaction signalling:
>>>>
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
>>>>
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
>>>>
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html
>>>>
>>>>
>>>> On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Alongside the debate with CTV right now there's a second debate that
>>>>> was not fully hashed out in the activation of Taproot. There is a lot of
>>>>> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
>>>>> etc. A significant reason for the breakdown in civility around this debate
>>>>> is that because we don't have a means of measuring user support for
>>>>> proposed sof-fork changes, it invariably devolves into people claiming that
>>>>> their circles support/reject a proposal, AND that their circles are more
>>>>> broadly representative of the set of Bitcoin users as a whole.
>>>>>
>>>>> It seems everyone in this forum has at one point or another said "I
>>>>> would support activation of ____ if there was consensus on it, but there
>>>>> isn't". This statement, in order to be true, requires that there exist a
>>>>> set of conditions that would convince you that there is consensus. People
>>>>> have tried to dodge this question by saying "it's obvious", but the reality
>>>>> is that it fundamentally isn't. My bubble has a different "obvious" answer
>>>>> than any of yours.
>>>>>
>>>>> Secondly, due to the trauma of the block size wars, no one wants to
>>>>> utter a statement that could imply that miners have any influence over what
>>>>> rulesets get activated or don't. As such "miner signaling" is consistently
>>>>> devalued as a signal for market demand. I don't think this is reasonable
>>>>> since following the events of '17 miners are aware that they have the
>>>>> strong incentive that they understand market demand. Nevertheless, as it
>>>>> stands right now the only signal we have to work with is miner signaling,
>>>>> which I think is rightly frustrating to a lot of people.
>>>>>
>>>>> So how can we measure User Support for a proposed rule change?
>>>>>
>>>>> I've had this idea floating around in the back of my head for a while,
>>>>> and I'd like to solicit some feedback here. Currently, all forms of
>>>>> activation that are under consideration involve miner signaling in one form
>>>>> or another. What if we could make it such that users could more directly
>>>>> pressure miners to act on their behalf? After all, if miners are but the
>>>>> humble servants of user demands, this should be in alignment with how
>>>>> people want Bitcoin to behave.
>>>>>
>>>>> Currently, the only means users have of influencing miner decisions
>>>>> are A. rejection of blocks that don't follow rules and B. paying fees for
>>>>> transaction inclusion. I suggest we combine these in such a way that
>>>>> transactions themselves can signal for upgrade. I believe (though am not
>>>>> certain) that there are "free" bits in the version field of a transaction
>>>>> that are presently ignored. If we could devise a mapping between some of
>>>>> those free bits, and the signaling bits in the block header, it would be
>>>>> possible to have rules as follows:
>>>>>
>>>>> - A transaction signaling in the affirmative MUST NOT be included in a
>>>>> block that does not signal in the affirmative
>>>>> - A transaction that is NOT signaling MAY be included in a block
>>>>> regardless of that block's signaling vector
>>>>> - (Optional) A transaction signaling in the negative MUST NOT be
>>>>> included in a block that signals in the affirmative
>>>>>
>>>>> Under this set of conditions, a user has the means of sybil-resistant
>>>>> influence over miner decisions. If a miner cannot collect the fees for a
>>>>> transaction without signaling, the user's fee becomes active economic
>>>>> pressure for the miner to signal (or not, if we include some variant of the
>>>>> negative clause). In this environment, miners could have a better view into
>>>>> what users do want, as would the Bitcoin network at large.
>>>>>
>>>>> Some may take issue with the idea that people can pay for the outcome
>>>>> they want and may try to compare a method like this to Proof of Stake, but
>>>>> there are only 3 sybil resistant mechanisms I am aware of, and any "real"
>>>>> view into what social consensus looks like MUST be sybil resistant:
>>>>>
>>>>> - Hashpower
>>>>> - Proof of personhood (KYC)
>>>>> - Capital burn/risk
>>>>>
>>>>> Letting hashpower decide this is the thing that is currently
>>>>> contentious, KYC is dead on arrival both on technical and social grounds,
>>>>> which really just leaves some means of getting capital into the process of
>>>>> consensus measurement. This mechanism I'm proposing is measurable
>>>>> completely en-protocol and doesn't require trust in institutions that fork
>>>>> futures would. Additionally it could be an auxiliary feature of the soft
>>>>> fork deployment scheme chosen making it something you could neatly package
>>>>> all together with the deployment itself.
>>>>>
>>>>> There are many potential tweaks to the design I propose above:
>>>>> 1. Do we include a notion of negative signaling (allowing for the
>>>>> possibility of rejection)
>>>>> 2. Do we make it such that miner signaling must be congruent with >X%
>>>>> of transactions, where congruence is that the signal must match any
>>>>> non-neutral signal of transaction.
>>>>>
>>>>> Some anticipated objections:
>>>>>
>>>>> 1. signaling isn't voting, no deployment should be made without
>>>>> consensus first.
>>>>> - yeah well we can't currently measure consensus right now, so that's
>>>>> not a super helpful thing to say and is breeding ground for abuse in the
>>>>> form of certain people making the unsubstantiated claim that consensus does
>>>>> or does not exist for a particular initiative
>>>>>
>>>>> 2. This is just a proposal for "pay to play", we should not let the
>>>>> wealthy make consensus decisions.
>>>>> - I agree that wealth should not be able to strong-arm decision
>>>>> making. But the status quo seems even worse where we let publicly
>>>>> influential people decide consensus in such a way where not only do they
>>>>> not "lose ammunition" in the process of campaigning, but actually accrue
>>>>> it, creating really bad long-term balances of power.
>>>>>
>>>>> 3. Enforcing this proposal requires its own soft fork.
>>>>> - Yes. It does...and there's a certain cosmic irony to that, but
>>>>> before we consider how to make this happen, I'd like to even discuss
>>>>> whether or not it's a good idea.
>>>>>
>>>>> 4. This gives CoinJoin pool operators and L2 protocol implementations
>>>>> power over deciding consensus.
>>>>> - I see this as an improvement over the status quo
>>>>>
>>>>> 5. This encourages "spam"
>>>>> - If you pay the fees, it's not spam.
>>>>>
>>>>> The biggest question I'd like to pose to the forum is:
>>>>> - Does a scheme like this afford us a better view into consensus than
>>>>> we have today?
>>>>> - Can it be gamed to give us a *worse* view into consensus? How?
>>>>> - Does it measure the right thing? If not, what do you think is the
>>>>> right thing to measure? (assuming we could)
>>>>> - Should I write a BIP spec'ing this out in detail?
>>>>>
>>>>> Cheers,
>>>>> Keagan
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> - Bryan
>>>> https://twitter.com/kanzure
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> 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/20220427/532c8a5a/attachment-0001.html>

2023-06-07 23:08:22

- reply

📅 Original date posted:2022-04-27
📝 Original message:> A transaction signaling in the affirmative MUST NOT be included in a
block that does not signal in the affirmative
I feel like I've heard this idea somewhere before. Its an interesting idea.
It should be noted that there is a consequence of this: holders wouldn't
have much say. People that transact a lot (or happen to be transacting a
lot during the signaling time period) would have a very disproportionate
ability to pressure miners than people who aren't transacting much. This
would probably be a pretty good proxy for future mining revenue that
supports (or is against) a particular thing. However, the network does do
more than just transact, so I would be a bit worried that such a mechanism
would bias the system towards things that are good for transactors and bad
for holders. Things like more coin inflation, larger blocks, etc.
Another consideration is that miners are already incentivized to follow the
money here. Adding an *additional* incentive might be distorting the
market, so to speak.
An alternative I proposed was a way to do weighted polling of holders:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html
The polling wouldn't be directly connected to the activation mechanism in
any way, but would just be a mechanism to gauge some portion of consensus.
If enough people were involved, theoretically it could be hooked up to
activation, but I would be pretty wary of doing that directly as well.
> we should not let the wealthy make consensus decisions.
We shouldn't let the wealthy continue to control our governments. However,
bitcoin is not a government. Its a financial network. The fact of the
matter is that fundamentally, the economic majority controls where the
chain goes. Its very likely that the wealthy are disproportionately
represented in the economic majority. Attempting to subvert the economic
majority seems like a bad idea. The reality of control there will come out
one way or another, and being honest about it is probably the best way to
avoid major schisms in the future.
> Does a scheme like this afford us a better view into consensus than we
have today?
It does more than provide a view. It directly changes the game theory
around how activation works. If we wanted to simply get a better view into
consensus, we could allow the same thing, but allow any block to mine any
transaction regardless of transaction signaling. Then it would be more
purely informational.
> Can it be gamed to give us a *worse* view into consensus? How?
> Does it measure the right thing? If not, what do you think is the right
thing to measure?
Doesn't seem like it could be gamed, but as I mentioned above, the honest
mechanics of it might be themselves undesirably distorting.
On Tue, Apr 26, 2022 at 3:49 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> You may be interested in these posts on transaction signalling:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html
>
>
> On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Alongside the debate with CTV right now there's a second debate that was
>> not fully hashed out in the activation of Taproot. There is a lot of
>> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
>> etc. A significant reason for the breakdown in civility around this debate
>> is that because we don't have a means of measuring user support for
>> proposed sof-fork changes, it invariably devolves into people claiming that
>> their circles support/reject a proposal, AND that their circles are more
>> broadly representative of the set of Bitcoin users as a whole.
>>
>> It seems everyone in this forum has at one point or another said "I would
>> support activation of ____ if there was consensus on it, but there isn't".
>> This statement, in order to be true, requires that there exist a set of
>> conditions that would convince you that there is consensus. People have
>> tried to dodge this question by saying "it's obvious", but the reality is
>> that it fundamentally isn't. My bubble has a different "obvious" answer
>> than any of yours.
>>
>> Secondly, due to the trauma of the block size wars, no one wants to utter
>> a statement that could imply that miners have any influence over what
>> rulesets get activated or don't. As such "miner signaling" is consistently
>> devalued as a signal for market demand. I don't think this is reasonable
>> since following the events of '17 miners are aware that they have the
>> strong incentive that they understand market demand. Nevertheless, as it
>> stands right now the only signal we have to work with is miner signaling,
>> which I think is rightly frustrating to a lot of people.
>>
>> So how can we measure User Support for a proposed rule change?
>>
>> I've had this idea floating around in the back of my head for a while,
>> and I'd like to solicit some feedback here. Currently, all forms of
>> activation that are under consideration involve miner signaling in one form
>> or another. What if we could make it such that users could more directly
>> pressure miners to act on their behalf? After all, if miners are but the
>> humble servants of user demands, this should be in alignment with how
>> people want Bitcoin to behave.
>>
>> Currently, the only means users have of influencing miner decisions are
>> A. rejection of blocks that don't follow rules and B. paying fees for
>> transaction inclusion. I suggest we combine these in such a way that
>> transactions themselves can signal for upgrade. I believe (though am not
>> certain) that there are "free" bits in the version field of a transaction
>> that are presently ignored. If we could devise a mapping between some of
>> those free bits, and the signaling bits in the block header, it would be
>> possible to have rules as follows:
>>
>> - A transaction signaling in the affirmative MUST NOT be included in a
>> block that does not signal in the affirmative
>> - A transaction that is NOT signaling MAY be included in a block
>> regardless of that block's signaling vector
>> - (Optional) A transaction signaling in the negative MUST NOT be included
>> in a block that signals in the affirmative
>>
>> Under this set of conditions, a user has the means of sybil-resistant
>> influence over miner decisions. If a miner cannot collect the fees for a
>> transaction without signaling, the user's fee becomes active economic
>> pressure for the miner to signal (or not, if we include some variant of the
>> negative clause). In this environment, miners could have a better view into
>> what users do want, as would the Bitcoin network at large.
>>
>> Some may take issue with the idea that people can pay for the outcome
>> they want and may try to compare a method like this to Proof of Stake, but
>> there are only 3 sybil resistant mechanisms I am aware of, and any "real"
>> view into what social consensus looks like MUST be sybil resistant:
>>
>> - Hashpower
>> - Proof of personhood (KYC)
>> - Capital burn/risk
>>
>> Letting hashpower decide this is the thing that is currently contentious,
>> KYC is dead on arrival both on technical and social grounds, which really
>> just leaves some means of getting capital into the process of consensus
>> measurement. This mechanism I'm proposing is measurable completely
>> en-protocol and doesn't require trust in institutions that fork futures
>> would. Additionally it could be an auxiliary feature of the soft fork
>> deployment scheme chosen making it something you could neatly package all
>> together with the deployment itself.
>>
>> There are many potential tweaks to the design I propose above:
>> 1. Do we include a notion of negative signaling (allowing for the
>> possibility of rejection)
>> 2. Do we make it such that miner signaling must be congruent with >X% of
>> transactions, where congruence is that the signal must match any
>> non-neutral signal of transaction.
>>
>> Some anticipated objections:
>>
>> 1. signaling isn't voting, no deployment should be made without consensus
>> first.
>> - yeah well we can't currently measure consensus right now, so that's not
>> a super helpful thing to say and is breeding ground for abuse in the form
>> of certain people making the unsubstantiated claim that consensus does or
>> does not exist for a particular initiative
>>
>> 2. This is just a proposal for "pay to play", we should not let the
>> wealthy make consensus decisions.
>> - I agree that wealth should not be able to strong-arm decision making.
>> But the status quo seems even worse where we let publicly influential
>> people decide consensus in such a way where not only do they not "lose
>> ammunition" in the process of campaigning, but actually accrue it, creating
>> really bad long-term balances of power.
>>
>> 3. Enforcing this proposal requires its own soft fork.
>> - Yes. It does...and there's a certain cosmic irony to that, but before
>> we consider how to make this happen, I'd like to even discuss whether or
>> not it's a good idea.
>>
>> 4. This gives CoinJoin pool operators and L2 protocol implementations
>> power over deciding consensus.
>> - I see this as an improvement over the status quo
>>
>> 5. This encourages "spam"
>> - If you pay the fees, it's not spam.
>>
>> The biggest question I'd like to pose to the forum is:
>> - Does a scheme like this afford us a better view into consensus than we
>> have today?
>> - Can it be gamed to give us a *worse* view into consensus? How?
>> - Does it measure the right thing? If not, what do you think is the right
>> thing to measure? (assuming we could)
>> - Should I write a BIP spec'ing this out in detail?
>>
>> Cheers,
>> Keagan
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> - Bryan
> https://twitter.com/kanzure
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/6f7eba77/attachment-0001.html>

2023-06-07 23:08:18

- reply

📅 Original date posted:2022-04-26
📝 Original message:> the hot wallet can only spend a certain amount from the hot wallet spend
and the rest would .. be sent back
That would definitely be the way to do it. The ability to steal from the
hot wallet in my opinion shouldn't really be a "concern" about CTV, but
rather an understood tradeoff of a CTV wallet vault. In fact, its hardly
even a trade off - a CTV vault can be created that is usable exactly as a
normal multisig wallet if the user wants to use it that way. The unvaulting
would simply add an additional (and optional) usability improvement over
normal multisig. The security considerations around choosing the
appropriate maximum amount to unvault at a time (with one key) is just
something that someone would need to decide based on basically their
comfort level. It sounds like you said something very similar in your point
2.
Would I like to have a wallet vault that doesn't have this security
consideration? Sure. But that isn't to say a wallet vault with that hitch
isn't a very useful advance to self-custody setups.
> You also get the nice benefit of learning about compromised keys without
having to risk all funds associated with that key.
This is an interesting tack-on attribute. A built in honey pot. If you only
allow 1% of your savings to be taken out at a time (with one key), is 1% of
your savings worth knowing that your wallet has been partially compromised?
Maybe it would be.
On Mon, Apr 25, 2022 at 11:51 AM Buck O Perley via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Just a couple of comments re-CTV vault security concerns.
>
>
> 1. One way to assuage the concern of the hot wallet vulnerability
> is pre-program the spends such that the hot wallet can only
> spend a certain amount from the hot wallet spend and the rest would
> kind of be "recursive" in that it would be sent back to a
> new instantiation of the CTV vault. I believe kanzure's vaults
> does this w/ the non-covenant version using pre-signed transactions
> (https://github.com/kanzure/python-vaults). While this doesn't
> prevent the theft it caps off the total risk. I would argue that
> this is strictly better than a multisig because you can also use
> multisig as you normally would if you want but you have the option
> if you think your hot key is secure to use that spending path.
> You also get the nice benefit of learning about compromised
> keys without having to risk all funds associated with that key.
>
>
> 2. As to how to improve UX for CTV with other proposals, I think
> you get a lot of benefits when using with taproot because you can
> use CTV in tapleaves to secure specific spend conditions, but can
> always fall back to other off-ramps (e.g. a musig key path spend or
> other script path conditions). Of course you can do this without
> taproot but taproot makes this more space efficient. This idea has
> been used to some effect in some recent exploration of how CTV can
> help improve UX around DLCs. You could even do this to help with
> the problems of not sending the right amount such that you have a
> really really cold key or set of keys for example such that if you
> have UTXOs that have values that can't be spent with the given CTV
> commitment, then you just use that other branch.
>
> - Buck
>
> ------- Original Message -------
>
> > Date: Sun, 24 Apr 2022 18:03:52 -0500
> > From: Billy Tetrud billy.tetrud at gmail.com
> >
>
> > To: "Russell O'Connor" roconnor at blockstream.com, Bitcoin Protocol
> >
>
> > Discussion bitcoin-dev at lists.linuxfoundation.org
> >
>
> > Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting
> > ("transitory") soft forks)
> > Message-ID:
> > CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A at mail.gmail.com
> >
>
> > Content-Type: text/plain; charset="utf-8"
> >
>
> > @Matt
> >
>
> > > both of which are somewhat frustrating limitations, but not security
> >
>
> > limitations, only practical ones.
> >
>
> > So I think the first limitation you mentioned (that if your hot wallet's
> > key gets stolen you need) can be legitimately considered a security
> > limitation. Not because you need to rotate your keys, but because you
> might
> > not know your hot wallet key has been stolen. If you unvault an output to
> > your hot wallet, the thief could be lying in wait, ready to steal those
> > funds upon them landing. At that point, you would then know your hot
> wallet
> > key was compromised and could rotate your vault keys in order to prevent
> > further theft. However, the fact that there is a clear theft
> vulnerability
> > is something I would say should be considered a "security limitation".
> >
>
> > As you mentioned, this is of course also a security limitation of a hot
> > wallet, so this setup definitely has a lot of advantages over a simple
> hot
> > wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
> > you can see that while theft of a single key would never result in any
> > theft in that setup, it could in a CTV vault. The other trade offs there
> > are ones of practicality and convenience.
> >
>
> > This isn't to say a CTV vault wouldn't be useful. Just that it has
> > significant trade offs.
> >
>
> > @Russel
> >
>
> > > the original MES vault .. commits to the destination address during
> >
>
> > unvaulting
> >
>
> > I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> > for me to understand that it does that. However, I can imagine how it
> > might do that.
> >
>
> > One possibility is that the intended destination is predetermined and
> > hardcoded. This wouldn't be very useful, and also wouldn't be different
> > than how CTV could do it, so I assume that isn't what you envisioned this
> > doing.
> >
>
> > I can imagine instead that the definition of the pattern could be
> specified
> > as a number indicating the number of stack items in the pattern, followed
> > by that number of stack items. If that's how it is done, I can see the
> user
> > inputting an intended destination script (corresponding to the intended
> > destination address) which would then be somehow rotated in to the right
> > spot within the pattern, allowing the pattern to specify the coins
> > eventually reaching an address with that script. However, this could be
> > quite cumbersome, and would require fully specifying the scripts along
> the
> > covenant pathways leading to a fair amount of information duplication
> > (since scripts must be specified both in the covenant and in spending the
> > subsequent output). Both of these things would seem to make OP_COV in
> > practice quite an expensive opcode to spend with. It also means that,
> since
> > the transactor must fully specify the script, its not possible to take
> > advantage of taproot's script hiding capabilities (were it to send to a
> > taproot address).
> >
>
> > However, my assumptions might be incorrect. If you think OP_COV would be
> a
> > useful opcode, I would encourage you to write up a complete
> specification.
> >
>
> > > What ways can we build a secured vault that commits to the destination
> >
>
> > address?
> >
>
> > Some kind of passed-through state allows doing this. With OP_COV (if my
> > assumptions above are correct), the intended destination can be passed
> > through the output script pattern(s). With my own proposed
> > op_pushoutputstack
> >
> https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md
> ,
> >
>
> > state is passed as an attachment on the output more directly. Curious
> what
> > you think about that proposal.
> >
>
> > > Are there elegant ways of building secure vaults by using CTV plus
> >
>
> > something else.
> >
>
> > Since CTV predefines all the transactions that can happen under its
> > control, passed state like this can't help because any dynamic state
> would
> > change the template and render the CTV transaction invalid. I don't see
> any
> > way of solving this problem for CTV.
> >
>
> > I'm curious how you think op_cat could enable this with CTV (other than
> the
> > cat+schnorr tricks that don't require CTV at all).
> >
>
> >
>
> >
>
> > On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
>
> > > Okay, Matt explained to me the intended application of CTV vaults off
> > > list, so I have a better understanding now.
> > >
>
> > > The CTV vault scheme is designed as an improvement over the traditional
> > > management of hot-wallets and cold-wallets. The CTV vault is logically
> on
> > > the "cold-side" and lets funds be sent from the "cold" side to one's
> own
> > > the hot wallet after the unvaulting delay. In this case, the hot wallet
> > > funds are always at risk, so it isn't unexpected that those funds
> could be
> > > stolen. After all, that is how hot wallets are today. The advantage is
> > > that funds can be moved from the "cold" side without needing to dig
> out the
> > > cold keys.
> > >
>
> > > The MES vault scheme applies to a different scenario. In the MES case
> it
> > > is the hot funds are inside the vault, and it is the hot key that
> unvaults
> > > the funds and sends them to customer's addresses after a delay. If the
> > > hot-key is used in any unauthorised way, then funds can be sent to the
> > > address of the cold key (the MES vault actually does something fancy in
> > > case of recovery, but it could be adapted to simply send funds to a
> cold
> > > wallet).
> > >
>
> > > The MES vault lie somewhere between "better" and "different" when
> compared
> > > to the CTV vault. If one is unwilling to use the MES vault on the hot
> side
> > > and have every withdrawl vetted, then, while you could use the MES
> design
> > > on the cold side like the CTV vault, it wouldn't really offer you any
> > > advantages over a CTV vault. However, if you are interested in managing
> > > all your payments through a vault (as I've been imagining) then the CTV
> > > vault comes across as ineffective when compared to an MES style vault.
> > >
>
> > > On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo lf-lists at mattcorallo.com
> > > wrote:
> > >
>
> > > > Still trying to make sure I understand this concern, let me know if
> I get
> > > > this all wrong.
> > > >
>
> > > > On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > > >
>
> > > > > It's not the attackers only choice to succeed. If an attacker
> steals
> > > > > the hot key, then they have
> > > > > the option to simply wait for the user to unvault their funds of
> their
> > > > > own accord and then race /
> > > > > outspend the users transaction with their own. Indeed, this is
> what we
> > > > > expect would happen in the
> > > > > dark forest.
> > > >
>
> > > > Right, a key security assumption of the CTV-based vaults would be
> that
> > > > you MUST NOT EVER withdraw
> > > > more in one go than your hot wallet risk tolerance, but given that
> your
> > > > attack isn't any worse than
> > > > simply stealing the hot wallet key immediately after a withdraw.
> > > >
>
> > > > It does have the drawback that if you ever get a hot wallet key
> stole you
> > > > have to rotate all of your
> > > > CTV outputs and your CTV outputs must never be any larger than your
> hot
> > > > wallet risk tolerance
> > > > amount, both of which are somewhat frustrating limitations, but not
> > > > security limitations, only
> > > > practical ones.
> > > >
>
> > > > > And that's not even mentioning the issues already noted by the
> document
> > > > > regarding fee management,
> > > > > which would likely also benefit from a less constrained design for
> > > > > covenants.
> > > >
>
> > > > Of course I've always been in favor of a less constrained covenants
> > > > design from day one for ten
> > > > reasons, but that's a whole other rabbit hole :)
> > >
>
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/ad1ab383/attachment-0001.html>

2023-06-07 23:08:08

- reply

📅 Original date posted:2022-04-23
📝 Original message:> assuming people pay attention and listen to the individuals who were
trusted during that period
Bitcoin is not run by a group of authorities of olde. By asking people to
trust "those.. around in 2015-2017" you're asking people to blindly trust
authorities. This, in my strong opinion, goes against the bitcoin ethos,
and is an incredibly harmful way to push for your agenda. I'd very much
recommend you reassess the way you're going about what you're trying to do.
I fear you risk losing respect in the community by implying without any
evidence that certain people are "taking advantage" of some situation and
attempting "to confuse".
On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If the next few weeks go how I fear they will it could get messy. If you
> care about Bitcoin's consensus rules I'd request you pay attention so you
> can make an informed view on what to run and what to support. For those of
> you who were around in 2015-2017 you'll know what to expect. The right
> outcome endured in 2017 and I'm sure the right outcome will endure here
> assuming people pay attention and listen to the individuals who were
> trusted during that period. There are always a large number of motivated
> parties who are incentivized to break nodes off from Bitcoin and may seek
> to take advantage of a contentious soft fork activation attempt.
>
> Remember that if all the information is presented to users in a clear way
> well ahead of time then they can make their own mind up. I fear that things
> will be made as convoluted as possible in a way intended to confuse and
> information will be withheld until the last minute. When in doubt it is
> generally better to rely on the status quo and tried and trusted. In this
> case that would be Bitcoin Core. Alternative releases such as those seeking
> to attempt to activate CTV or indeed those seeking to resist the activation
> of CTV really should only be considered if you are informed on exactly what
> you are running.
>
> If you are interested in the effort to resist the contentious soft fork
> activation attempt of CTV please join ##ursf on Libera IRC.
>
> Have a good weekend. Hopefully those behind this contentious soft fork
> activation attempt will see sense and we can go back to more productive
> things than resisting contentious soft forks.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.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/20220423/1ab9bc29/attachment.html>

2023-06-07 23:07:51

- reply

📅 Original date posted:2022-04-23
📝 Original message:@Zac
> More use cases means more blockchain usage which increases the price of
a transaction for *everyone*.
This is IMO a ridiculous opposition. Anything that increases the utility of
the bitcoin network will increase usage of the blockchain and increase the
price of a transaction on average. It is absurd to say such a thing is bad
for bitcoin. Its like the old saying: "nobody goes there any more - its too
crowded".
> I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
users.
This is a fair opinion to take on the face of it. However, I completely
disagree with it. Why must any change benefit *all* users? Did segwit
benefit all users? Did taproot? What if an upgrade benefits 90% of users
a LOT and at the same time doesn't negatively affect the other 10%? Is that
a bad change? I think you'd find it very difficult to argue it is.
Regardless of the above, I think CTV *does *in fact likely provide
substantial benefit to all users in the following ways:
1. CTV allows much easier/cheaper ways of improving their security via
wallet vaults, DLCs, channels, and many other use cases. This means both
societal benefit that grows the value of the bitcoin network and on-chain
benefit that reduces the fees people have to pay for certain utility, which
leads to lower fees for everyone.
2. Wallet vaults specifically, that CTV would unlock, would make it
substantially easier and cheaper to hold funds in a multi key vault (akin
to but better than a classic multisig wallet). This could substantially
increase the fraction of users that self-custody their bitcoin. This
increased self-custodiation would substantially improve the
decentralization of bitcoin in terms of holdership which is an important
part of bitcoin's resilience, which would be a huge benefit to anyone that
holds bitcoin or relies on the bitcoin network in any way.
Even if a minority (eg 20%) of bitcoin users use CTV, it would have a
substantial positive effect for everyone because of these things.
On Fri, Apr 22, 2022 at 10:40 AM Corey Haddad via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> >*A change that increases the number of use cases of Bitcoin affects all
> users and is *not* non-invasive. More use cases means more blockchain usage
> which increases the price of a transaction for *everyone*.*
>
> This manages to be both incorrect and philosophically opposed to what
> defines success of the project . Neither the number of ways that people
> figure out how to innovatively harness Bitcoin's existing capabilities, nor
> the number or complexity of any optional transaction types that the Bitcoin
> protocol supports have any bearing on transaction fees. Demand for
> blockspace from transactions, which is just plain *use* - and not *use
> cases* - is what could drive up transaction fees.
>
> On the philosophical level, as designers of the system, we all hope and
> work to make Bitcoin so useful, appealing, and secure that there is massive
> demand for blockspace, even in the face of high transaction fees. As an
> individual thinking only of their next on-chain transaction, it is
> understandable that one might hope for low fees and partially-filled
> blocks. Longer term, the health of the system can both be measured by and
> itself depends on high transaction demand and fee pressure.
>
> If you were trying to argue that CTV is invasive because it may increase
> transaction demand and therefore cost users more fees, that is 1) an
> endorsement of CTV's desirability and 2) reveals that you consider any
> increased free-market competition (i.e. more demand) to be "invasive".
>
>
> *>I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
> users. *
>
> As for Peter Todd's "any change of Bitcoin must benefit *all* users", that
> is absolutely a reasonable thing to consider. However, in order to make
> practical use of that maxim, we must adopt in our minds a *generic*, or
> "model user", and then replicate them so that we may meaningfully
> understand a least a proxy for "all users". In reality, there will always
> be someone (and at this point, probably a "user" too) who wouldn't benefit
> from a change, or at least think they won't. Some users of Bitcoin may even
> want Bitcoin to fail, so we cannot afford assume that people have alignment
> of goals or vision just by virtue of being a 'user'.
>
> Corey
>
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/1bd348d3/attachment.html>

2023-06-07 23:07:48

- reply

📅 Original date posted:2022-04-28
📝 Original message:> the point of a vault is the ability to keep your primary wallet keys in
*highly* deep cold storage
I think we're both right. You're also right that there are many possible
configurations including the one you mentioned. I can see good reasons to
use multisig even if both keys are quickly on hand. My only point was that
using a wallet vault that unvaults to a multisig isn't a best of both
worlds, but rather has different trade offs. Sounds like we agree.
On Thu, Apr 28, 2022 at 6:14 PM Nadav Ivgi <nadav at shesek.info> wrote:
> > The whole point of a wallet vault is that you can get the security of a
> multisig wallet without having to sign using as many keys.
>
> In my view, the point of a vault is the ability to keep your primary
> wallet keys in *highly* deep cold storage (e.g. metal backup only, not
> loaded on any HW wallets, with geographically distributed shares and a slow
> cumbersome process for collecting them), which is made possible because
> you're not supposed to actually need to use these keys, except for the
> extraordinary (typically once or twice in a lifetime?) circumstances of
> theft.
>
> The user can then use a warmer model for the keys they use more frequently
> for the covenant-encumbered two-step spending. But these warmer keys can
> themselves also be cold and/or multi-sig, yet more accessible. For example,
> a 2-of-2 with standard hardware wallets you have within reach in your
> apartment.
>
> So if you have a cold wallet that you anticipate having to access once
> every, say, 2-3 months, no matter what scheme you currently use to secure
> it, you can improve your overall security by using that same scheme for
> securing the covenant-encumbered keys, then use a colder more secure scheme
> for your primary keys under the assumption that you'll only have to access
> them at most once every several years.
>
> IIUC what you were describing is that you can use your regular multisig
> scheme for the primary cold wallet keys, and a 1-of-1 for the
> covenant-encumbered keys (which can even be hot on your phone etc).
>
> Both approaches are valid, one gets you more security while the other gets
> you more convenience. And there is of course a whole range of options that
> can be chosen in between that gets you some of both.
>
> shesek
>
> On Wed, Apr 27, 2022 at 11:09 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> @Russell
>> > OP_PUBKEY, and OP_PUBKEYHASH as wildcards
>>
>> Ah I see. Very interesting. Thanks for clarifying.
>>
>> @Nadav
>> > You can have a CTV vault where the hot key signer is a multisig to get
>> the advantages of both.
>>
>> Yes, you can create a CTV vault setup where you unvault to a multisig
>> wallet, but you don't get the advantages of both. Rather you get none of
>> the advantages and still have all the downsides you get with a multisig
>> wallet. The whole point of a wallet vault is that you can get the security
>> of a multisig wallet without having to sign using as many keys.
>>
>> On Mon, Apr 25, 2022 at 5:28 PM Russell O'Connor <
>> roconnor at blockstream.com> wrote:
>>
>>> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud at gmail.com>
>>> wrote:
>>>
>>>> @Russel
>>>> > the original MES vault .. commits to the destination address during
>>>> unvaulting
>>>>
>>>> I see. Looking at the MES16 paper, OP_COV isn't described clearly
>>>> enough for me to understand that it does that. However, I can imagine how
>>>> it *might* do that.
>>>>
>>>> One possibility is that the intended destination is predetermined and
>>>> hardcoded. This wouldn't be very useful, and also wouldn't be different
>>>> than how CTV could do it, so I assume that isn't what you envisioned this
>>>> doing.
>>>>
>>>> I can imagine instead that the definition of the pattern could be
>>>> specified as a number indicating the number of stack items in the pattern,
>>>> followed by that number of stack items. If that's how it is done, I can see
>>>> the user inputting an intended destination script (corresponding to the
>>>> intended destination address) which would then be somehow rotated in to the
>>>> right spot within the pattern, allowing the pattern to specify the coins
>>>> eventually reaching an address with that script. However, this could be
>>>> quite cumbersome, and would require fully specifying the scripts along the
>>>> covenant pathways leading to a fair amount of information duplication
>>>> (since scripts must be specified both in the covenant and in spending the
>>>> subsequent output). Both of these things would seem to make OP_COV in
>>>> practice quite an expensive opcode to spend with. It also means that, since
>>>> the transactor must fully specify the script, its not possible to take
>>>> advantage of taproot's script hiding capabilities (were it to send to a
>>>> taproot address).
>>>>
>>>
>>> So my understanding is that the COV proposal in MES lets you check that
>>> the output's scriptPubKey matches the corresponding script item from the
>>> stack, but the script item's value additionally allows some wildcard
>>> values. In particular, it makes use of the otherwise reserved opcodes
>>> OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing any, let's say,
>>> 32-byte or 20-byte push value.
>>>
>>> If you just used COV by itself, then these wildcards would be
>>> third-party malleable, but you also have to sign the transaction with the
>>> hot wallet key, which removes the malleability.
>>>
>>> No need to rotate anything into place.
>>>
>>> I hope this makes sense.
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220428/3ab92a1c/attachment-0001.html>

2023-06-07 23:07:47

- reply

📅 Original date posted:2022-04-26
📝 Original message:@Russell
> OP_PUBKEY, and OP_PUBKEYHASH as wildcards
Ah I see. Very interesting. Thanks for clarifying.
@Nadav
> You can have a CTV vault where the hot key signer is a multisig to get
the advantages of both.
Yes, you can create a CTV vault setup where you unvault to a multisig
wallet, but you don't get the advantages of both. Rather you get none of
the advantages and still have all the downsides you get with a multisig
wallet. The whole point of a wallet vault is that you can get the security
of a multisig wallet without having to sign using as many keys.
On Mon, Apr 25, 2022 at 5:28 PM Russell O'Connor <roconnor at blockstream.com>
wrote:
> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> @Russel
>> > the original MES vault .. commits to the destination address during
>> unvaulting
>>
>> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
>> for me to understand that it does that. However, I can imagine how it
>> *might* do that.
>>
>> One possibility is that the intended destination is predetermined and
>> hardcoded. This wouldn't be very useful, and also wouldn't be different
>> than how CTV could do it, so I assume that isn't what you envisioned this
>> doing.
>>
>> I can imagine instead that the definition of the pattern could be
>> specified as a number indicating the number of stack items in the pattern,
>> followed by that number of stack items. If that's how it is done, I can see
>> the user inputting an intended destination script (corresponding to the
>> intended destination address) which would then be somehow rotated in to the
>> right spot within the pattern, allowing the pattern to specify the coins
>> eventually reaching an address with that script. However, this could be
>> quite cumbersome, and would require fully specifying the scripts along the
>> covenant pathways leading to a fair amount of information duplication
>> (since scripts must be specified both in the covenant and in spending the
>> subsequent output). Both of these things would seem to make OP_COV in
>> practice quite an expensive opcode to spend with. It also means that, since
>> the transactor must fully specify the script, its not possible to take
>> advantage of taproot's script hiding capabilities (were it to send to a
>> taproot address).
>>
>
> So my understanding is that the COV proposal in MES lets you check that
> the output's scriptPubKey matches the corresponding script item from the
> stack, but the script item's value additionally allows some wildcard
> values. In particular, it makes use of the otherwise reserved opcodes
> OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing any, let's say,
> 32-byte or 20-byte push value.
>
> If you just used COV by itself, then these wildcards would be third-party
> malleable, but you also have to sign the transaction with the hot wallet
> key, which removes the malleability.
>
> No need to rotate anything into place.
>
> I hope this makes sense.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/3a386891/attachment-0001.html>

2023-06-07 23:07:45

- reply

📅 Original date posted:2022-04-24
📝 Original message:@Matt
> both of which are somewhat frustrating limitations, but not security
limitations, only practical ones.
So I think the first limitation you mentioned (that if your hot wallet's
key gets stolen you need) can be legitimately considered a security
limitation. Not because you need to rotate your keys, but because you might
*not know* your hot wallet key has been stolen. If you unvault an output to
your hot wallet, the thief could be lying in wait, ready to steal those
funds upon them landing. At that point, you would then know your hot wallet
key was compromised and could rotate your vault keys in order to prevent
further theft. However, the fact that there is a clear theft vulnerability
is something I would say should be considered a "security limitation".
As you mentioned, this is of course also a security limitation of a hot
wallet, so this setup definitely has a lot of advantages over a simple hot
wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
you can see that while theft of a single key would never result in any
theft in that setup, it could in a CTV vault. The other trade offs there
are ones of practicality and convenience.
This isn't to say a CTV vault wouldn't be useful. Just that it has
significant trade offs.
@Russel
> the original MES vault .. commits to the destination address during
unvaulting
I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
for me to understand that it does that. However, I can imagine how it
*might* do that.
One possibility is that the intended destination is predetermined and
hardcoded. This wouldn't be very useful, and also wouldn't be different
than how CTV could do it, so I assume that isn't what you envisioned this
doing.
I can imagine instead that the definition of the pattern could be specified
as a number indicating the number of stack items in the pattern, followed
by that number of stack items. If that's how it is done, I can see the user
inputting an intended destination script (corresponding to the intended
destination address) which would then be somehow rotated in to the right
spot within the pattern, allowing the pattern to specify the coins
eventually reaching an address with that script. However, this could be
quite cumbersome, and would require fully specifying the scripts along the
covenant pathways leading to a fair amount of information duplication
(since scripts must be specified both in the covenant and in spending the
subsequent output). Both of these things would seem to make OP_COV in
practice quite an expensive opcode to spend with. It also means that, since
the transactor must fully specify the script, its not possible to take
advantage of taproot's script hiding capabilities (were it to send to a
taproot address).
However, my assumptions might be incorrect. If you think OP_COV would be a
useful opcode, I would encourage you to write up a complete specification.
> What ways can we build a secured vault that commits to the destination
address?
Some kind of passed-through state allows doing this. With OP_COV (if my
assumptions above are correct), the intended destination can be passed
through the output script pattern(s). With my own proposed
op_pushoutputstack
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>,
state is passed as an attachment on the output more directly. Curious what
you think about that proposal.
> Are there elegant ways of building secure vaults by using CTV plus
something else.
Since CTV predefines all the transactions that can happen under its
control, passed state like this can't help because any dynamic state would
change the template and render the CTV transaction invalid. I don't see any
way of solving this problem for CTV.
I'm curious how you think op_cat could enable this with CTV (other than the
cat+schnorr tricks that don't require CTV at all).
On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Okay, Matt explained to me the intended application of CTV vaults off
> list, so I have a better understanding now.
>
> The CTV vault scheme is designed as an improvement over the traditional
> management of hot-wallets and cold-wallets. The CTV vault is logically on
> the "cold-side" and lets funds be sent from the "cold" side to *one's own*
> the hot wallet after the unvaulting delay. In this case, the hot wallet
> funds are always at risk, so it isn't unexpected that those funds could be
> stolen. After all, that is how hot wallets are today. The advantage is
> that funds can be moved from the "cold" side without needing to dig out the
> cold keys.
>
> The MES vault scheme applies to a different scenario. In the MES case it
> is the hot funds are inside the vault, and it is the hot key that unvaults
> the funds and sends them to *customer's addresses* after a delay. If the
> hot-key is used in any unauthorised way, then funds can be sent to the
> address of the cold key (the MES vault actually does something fancy in
> case of recovery, but it could be adapted to simply send funds to a cold
> wallet).
>
> The MES vault lie somewhere between "better" and "different" when compared
> to the CTV vault. If one is unwilling to use the MES vault on the hot side
> and have every withdrawl vetted, then, while you could use the MES design
> on the cold side like the CTV vault, it wouldn't really offer you any
> advantages over a CTV vault. However, if you are interested in managing
> all your payments through a vault (as I've been imagining) then the CTV
> vault comes across as ineffective when compared to an MES style vault.
>
> On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> Still trying to make sure I understand this concern, let me know if I get
>> this all wrong.
>>
>> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
>> > It's not the attackers *only choice to succeed*. If an attacker steals
>> the hot key, then they have
>> > the option to simply wait for the user to unvault their funds of their
>> own accord and then race /
>> > outspend the users transaction with their own. Indeed, this is what we
>> expect would happen in the
>> > dark forest.
>>
>> Right, a key security assumption of the CTV-based vaults would be that
>> you MUST NOT EVER withdraw
>> more in one go than your hot wallet risk tolerance, but given that your
>> attack isn't any worse than
>> simply stealing the hot wallet key immediately after a withdraw.
>>
>> It does have the drawback that if you ever get a hot wallet key stole you
>> have to rotate all of your
>> CTV outputs and your CTV outputs must never be any larger than your hot
>> wallet risk tolerance
>> amount, both of which are somewhat frustrating limitations, but not
>> security limitations, only
>> practical ones.
>>
>> > And that's not even mentioning the issues already noted by the document
>> regarding fee management,
>> > which would likely also benefit from a less constrained design for
>> covenants.
>>
>> Of course I've always been in favor of a less constrained covenants
>> design from day one for ten
>> reasons, but that's a whole other rabbit hole :)
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220424/d2cb24bb/attachment-0001.html>

2023-06-07 23:07:43

- reply

📅 Original date posted:2022-04-23
📝 Original message:> If an attacker steals the hot key, then they have the option to simply
wait for the user to unvault their funds
This is definitely true. Its kind of a problem with most vault proposals.
Its one of the primary reasons I designed an alternative proposal
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults>. The
OP_BEFOREBLOCKVERIFY opcode I proposed solves this security hole by
automatically swapping control of the UTXO over to the intended recipient
after a timeout. Alternatively, if OP_BBV weren't available, OP_POS in
conjunction with OP_CD could encode things such that the transaction
with the hot key could only spend to the intended recipient.
I'm curious if there are any other covenant proposals that have a solution
to that problem. I'm not aware of any that do other than my proposal.
On Fri, Apr 22, 2022 at 12:25 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This vault design (https://github.com/jamesob/simple-ctv-vault)
>> is a good benchmark for evaluating covenant proposals because it's (i)
>> simple and (ii) has high utility for many users of Bitcoin. I would
>> love to see it implemented in one or all of these alternatives, but I
>> am almost certain no one will do it in the next few months because the
>> implementations, tooling, and in some cases even complete
>> specifications do not exist.
>>
>
> Quoting from the link above:
> Detecting theft
>
> This unvault step is critical because it allows us to detect unexpected
> behavior. If an attacker had stolen our hot wallet keys, their only choice
> to succeed in the theft is to trigger an unvault.
>
>
> It's not the attackers *only choice to succeed*. If an attacker steals
> the hot key, then they have the option to simply wait for the user to
> unvault their funds of their own accord and then race / outspend the users
> transaction with their own. Indeed, this is what we expect would happen in
> the dark forest.
>
> A key feature of the MES vault design is that the destination address is
> included, and committed to, by the unvaulting step. However, this can only
> be achieved with a less constrained design for covenants.
>
> I suppose I can see that the damage from a hot key theft could be more
> contained under some circumstances using a CTV vault, but let us not
> overstate the value of the CTV vault.
>
> And that's not even mentioning the issues already noted by the document
> regarding fee management, which would likely also benefit from a less
> constrained design for covenants.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/cd3d2e54/attachment-0001.html>

2023-06-07 23:07:20

- reply

📅 Original date posted:2022-04-21
📝 Original message:Hi Michael,
I'm sympathetic to the idea of allowing time for the community to absorb,
review, analyze, discuss, etc any new substantial change to bitcoin,
especially consensus changes. I certainly think that over time the
frequency of soft forks should generally go down on average, with
ossification at some point being the ideal endpoint (perhaps in the next
10-20 years).
However, many of the messages of opposition/caution seem to imply that
analysis of a consensus change can't begin until the last change has been
completed. This is quite clearly not the case. And as far as I can tell the
CTV spec was functionally completed *before* the taproot spec was (sometime
in early 2020).
Jeremy included a nice list of "ticked boxes" that are all indicators of
maturity of not only the spec but implementations and testing. I would
expect any considered opposition to CTV to at least address that checklist,
but you did not.
I think it would be interesting to compare the state of CTV now with the
state of taproot when activation. One example is that Taproot had been on
Signet for about 1 month
<https://www.coindesk.com/tech/2021/01/14/bitcoin-cores-latest-release-is-out-heres-whats-in-it/>
before
consensus developed <https://gnusha.org/taproot-activation/2021-02-16.log>
in support of pulling the trigger on a softfork for taproot. CTV has had a
signet running for almost twice that long already if not longer. So
Michael, what do you think is missing from Jeremy's checklist? Where do you
think the checklist fails to meet your ideal bar of acceptance?
Not only that but CTV is a simpler change than taproot. I assume you'd
agree that a simpler change should require correspondingly less
review/analysis/etc, right? If not, I'd appreciate it if you could comment
as to why.
> There are a number of individuals who have stated opposition to
attempting to activate a CTV soft fork in the near term
As Jeremy has noted, none of these indicate or suspect any technical issues
in CTV. Basically all of them are basically saying "too soon" without much
concrete reasons. I believe in consensus weighted by quality-of-logic, and
most of the ones in your list do not contain any supported logic at all.
Many are borderline ad hominems at Jeremy. So to me, most hold little
weight. The ones with some logic included seem to basically be "I'm not
involved enough to know or knowledgeable enough to review, and therefore
I'm hesitant". Now to be fair, many of the acks listed in Jeremy's also
hold little weight to me for the same reasons, with a few exceptions like Bram
Cohen's discussion
<https://twitter.com/bramcohen/status/1224823869933899776> and a Corenell
paper <https://arxiv.org/abs/2005.11776>. But there's clearly been quite a
bit of review on the PR <https://github.com/bitcoin/bitcoin/pull/21702> as
well. By contrast I've seen literally no opposition to CTV based on the
proposal at all.
With regards to the idea that more time is needed to review/discuss. I
wonder if any of those opposed to near term speedy trial of CTV plan on
doing a deeper review/exploration of it in the next year? If not, then what
will delaying do? Are these people simply waiting to see more people in
their social bubble becomes familiar and comfortable with CTV?
> I have a better (and safer) way forward which is to continue to build out
use cases of CTV, convince the community it is the best tool for the job
(whatever use case(s) that is), compare it to other existing covenant
enabling proposals
While I think this is a more valid position to take than your other points,
I disagree with it. I am also sympathetic to the idea that alternatives
should be evaluated and the best one at hand should be chosen. However, it
is a simple fact that the "best" solution possible is almost never going to
be found or created, even after absurd amounts of time (eg millenia). We
live in a time bound world, with time bound human lives. I assume you've
heard of the phrase "don't let the perfect become the enemy of the good". I
assert that your argument is to do just that: to make the perfect become
the enemy of the good.
There is some trade off between time to usage (think time to market) and
the quality of the solution. We didn't choose taproot because it was the
best possible solution, we chose it because it was a pretty good solution
and the solution we had. Yes alternatives have been discussed (at least
since 2013), but alternatives to CTV have also been discussed (eg OP_CAT)
for probably just as long. There have been a number of random
back-of-the-napkin alternative proposals to CTV. None have gained anything
resembling support. I proposed one of them
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>
myself. And I certainly agree that CTV isn't perfect and doesn't do
everything I want it to do. But despite this, I think having CTV is better
than not having it. Even if its eventually mostly replaced by some more
complex covenant opcode, CTV can provide a LOT of value in a number of ways
until that point (which will likely be at least 4 years). And its also
likely that a more full featured covenant opcode will take *longer* if CTV
doesn't get out there and show the uninformed why covenants are important.
As far as I can tell, its uncontroversial that CTV is the simplest and
safest of all the covenant proposals. Do you disagree?
> Taproot had overwhelming community consensus so it had much less chain
split risk
IMO this is a completely invalid argument. If a speedy trial is done and
90% miner activation happens, that is quite a high supermajority
percentage. If such a thing happens, there is basically 0 chance of any
chain split happening directly from activation. The only chain split risk,
then, would be from anyone who thinks it would be then worth it to hard
fork away from that chain, which you have already said you wouldn't be one
of. So I have to say, this additional chain split risk you speak of sounds
completely imaginary to me.
~BT
On Wed, Apr 20, 2022 at 8:49 AM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The client has a Speedy trial release similar to Taproots with
> parameters proposed to be....
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it
> wastes the time of people who could be working on all sorts of valuable
> projects for the ecosystem. Worst case, we take a Russian roulette style
> gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new
> soft fork code, either CTV code or any new activation code. Running Bitcoin
> Core 23.0 out the box will not signal for any new soft fork and will not
> enforce any new soft fork rules (CTV or otherwise). Of course it will
> continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest
> blog post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client
> attempting to activate CTV. One would expect that many will continue to run
> versions of Bitcoin Core that will not enforce CTV rules and will not
> activate it. But whether Jeremy's client will be a majority, significant
> minority, insignificant minority of full nodes and miners would be
> speculation on my part. (Personally I highly doubt those running Jeremy's
> client will be a majority which leaves a significant minority and
> insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar
> parameters to that used for Taproot. That would mean seeking 90 percent of
> miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he tries again with a different activation
> attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but
> presumably still a possibility) then the CTV soft fork could activate
> unless full nodes resist it. This resistance would most likely be in the
> form of a UASF style client which rejects blocks that apply the CTV rules
> and/or includes transactions that don't meet the CTV rules post activation.
> We would now be in chain split territory with two different assets and
> blockchains like we had with BTC and BCH.
>
> If I oppose this activation attempt and the associated chain split risk
> what should I do?
>
> Firstly, you can register your opposition to this soft fork activation
> attempt on Jeremy's site: https://utxos.org/signals/
>
> It seems Jeremy will continue this activation attempt regardless but it
> will be useful for others to see clearly that this a contentious soft fork
> activation attempt and act accordingly. So far only 3 individuals'
> opposition is registered on his site.
>
> Secondly, if it is looking like 90 percent (or whatever percentage Jeremy
> uses) of miners are going to signal for a CTV soft fork then you can
> consider joining a UASF style effort to resist the soft fork activation
> attempt. I will certainly seek to participate and will continue to inform
> this list of efforts in this direction.
>
> The saddest thing is that if Jeremy's soft fork activation attempt causes
> the uncertainty, confusion and disruption I fear it could it will make
> future soft forks that do have community consensus orders of magnitude
> harder to pull off. There are a number of soft fork proposals that I'm
> personally excited about (enabling covenants, eltoo, Simplicity, CISA etc)
> that long term we might get with a sensible approach to only activating
> soft forks that have community consensus. But the more uncertainty,
> confusion and disruption we create over contentious soft forks the more
> dangerous any soft fork of any form will appear. The primary focus will
> need to be resisting soft forks that don't have community consensus and
> ensuring Bitcoin doesn't splinter into a large number of different
> assets/blockchains with different combinations of soft forks active.
>
> So if you oppose this soft fork activation attempt please voice your
> opposition, run full node software that doesn't include CTV and CTV
> activation code such as Bitcoin Core and if/when necessary and available
> run full node software that proactively rejects application of the CTV
> rules.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Devs,
>
> In advance of the CTV meeting today, I wanted to share what my next step
> is in advocating for CTV, as well as 7 theses for why I believe it to be
> the right course of action to take at this time.
>
> Please see the post at
> https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/.
>
> As always, open to hear any and all feedback,
>
> Jeremy
>
>
> archived at:
> https://web.archive.org/web/20220419172825/https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>
>
> _______________________________________________
> 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/20220420/ce6a05e9/attachment-0001.html>

2023-06-07 23:07:08

- reply

📅 Original date posted:2022-04-26
📝 Original message:@Erik
> can we all agree that this verbal and social wrangling and chest
pounding seems, right now, to remain the best system of achieving
consensus? or can we do better?
I would love to see more people interested in discussing this. Social
wrangling is certainly the best we have, but is it the best we can do?
Certainly a certain amount of discussion and back and forth is necessary to
come to consensus, but it would be nice to have a discussion and come to a
consensus on things like the minimum things required to decided consensus
is for something (the absence of which makes it obvious that consensus is
currently against), and the maximum amount of things required after which
it would be clear and obvious that consensus for something has been
achieved.
> wallet votes (sign a message signalling... ), can cause centralization
pressures
I'm curious to know why you think this is the case. If you mean that
centralization of custody is a problem for this, I very much agree.
However, I don't see how having wallet votes would incentivize
centralization of custody. Rather the opposite actually - one more reason
to self-custody.
Regardless, I wouldn't suggest having wallet *votes* per se. I would doubt
we'd get a high enough response rate on that to really determine what
broader consensus of coin-owners is. However, if we had coin-weighted
polling, it would I think be a very useful signal by which we could
determine something (to some degree of uncertainty) about what consensus is
among that group (of coin owners who take the poll).
Theoretically, the economic majority of bitcoin holders can direct the
majority of mining power, and can control where the current chain goes (of
course not discounting the ability of the economic minority to hard fork
away if they want, taking a proportional minority amount of mining power
with them).
One could also think of it like Polybius's three part government, where the
parts in bitcoin would be: developers, miners, and holders. Perhaps a
consensus among all of them should be ideally sought after for a smooth
upgrade. Because of the blocksize wars, many think miners should simply act
as a machine to implement the will of the bitcoiners. However, I think
people sometimes forget that miners are also bitcoiners and they have a
unique and important perspective. If the opinions and interests of miners
is already adequately considered as part of our chaotic discussions on what
consensus is, then great. If not, it would seem that the miner signaling
process is a reasonable place for miners to decide to delay and force more
discussion. While its unlikely the average user knows much about the
technical aspects of consensus changes, the fact is that there are many
non-developer stakeholders, and it would I think be a very beneficial
achievement to figure out a way to incorporate those stakeholders into the
process of determining consensus on the most important changes to bitcoin:
consensus changes.
On Tue, Apr 26, 2022 at 11:32 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> - it occurs to me that the real problem we have isn't whether miners lead
> or users lead. we know that users lead, we just need miners to be "ready"
> and have time to upgrade their software
>
> - in the case of "evil" forks, i also don't need or want miners to
> "defend" bitcoin... (if bitcoin is so broken that a bad fork gets past all
> of the users, the miners have lost their purpose, so that is a fallacy of
> reification and should be ignored)
>
> - we cannot measure user consensus in any systematic way, or else we
> resort to gaming the system or centralization
>
> - wallet votes (sign a message signalling... ), can cause
> centralization pressures
> - node signals (node published signal) will be sybil attacked
> - eyeballs... (lol)
>
> - can we all agree that this verbal and social wrangling and chest
> pounding seems, right now, to remain the best system of achieving
> consensus? or can we do better?
>
>
>
>
>
>
>
>
>
>
> On Tue, Apr 26, 2022 at 1:42 AM Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via
>> bitcoin-dev wrote:
>> > > Semi-mandatory in that only "threshold" blocks must signal, so if
>> > only 4% or 9% of miners aren't signalling and the threshold is set
>> > at 95% or 90%, no blocks will be orphaned.
>> > How do nodes decide on which blocks are orphaned if only some of them
>> have
>> > to signal, and others don't? Is it just any block that would cause the
>> > whole threshold period to fail?
>>
>> Yes, exactly those. See [0] or [1].
>>
>> [0]
>> https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling
>>
>> [1] https://github.com/bitcoin/bips/pull/1021
>> (err, you apparently acked that PR)
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> 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/20220426/01bdfa65/attachment.html>

2023-06-07 23:06:23

- reply

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

2023-06-07 23:06:22

- reply

📅 Original date posted:2022-03-31
📝 Original message:> Many users, miners and exchanges still think its voting
Why do you care what they think? Why does it matter if they misunderstand?
> it is not an imaginary group of people
If the people aren't imaginary, then its their importance that's imaginary.
> One example of a mining pool
This isn't even sufficient evidence that they don't understand. Its quite
possible they're using the word "voting" loosely or that they don't
understand english very well. And again, so what if they tweet things that
are not correctly worded? This is not a reason to change how we design
bitcoin soft forks.
Its not even wrong to say that a particular signaling round is very much
like voting. What's wrong is saying that bitcoin upgrades are made if and
only if miners vote to approve those changes.
> I see a problem that exists
You haven't convinced me this is a significant problem. What are the
concrete downsides? Why do you think this can't be fixed by simple
persistent explaining? You can find groups of people who misunderstand
basically any aspect of bitcoin. The solution to people misunderstanding
the design is never to change how bitcoin is designed.
On Wed, Mar 30, 2022 at 4:14 PM pushd <pushd at protonmail.com> wrote:
> > No it does not. This narrative is the worst. A bad explanation of
> speedy trial can mislead people into thinking miner signalling is how
> Bitcoin upgrades are voted in. But a bad explanation can explain anything
> badly.
>
> I agree it is worst but why do you think this narrative exists? People
> have tried explaining it. Many users, miners and exchanges still think its
> voting. I think the problem is with activation method so BIP 8/LOT=TRUE is
> a solution.
>
>
> > The solution is not to change how we engineer soft forks, it's to
> explain speedy trial better to this imaginary group of important people
> that think miner signaling is voting.
>
> We can suggest different solutions but the problem exists and it is not an
> imaginary group of people.
>
> One example of a mining pool: https://archive.ph/oyH04
>
>
> > We shouldn't change how we engineer Bitcoin because of optics. I
> completely object to that point continuing to be used.
>
> Voting as described on wiki is quite similar to what happens during miners
> signaling followed by activation if a certain threshold is reached. If some
> participants in this process consider it voting instead of signaling for
> readiness then listing advantages of a better activation method should help
> everyone reading this thread/email.
>
> Sorry, I don't understand your objection. I see a problem that exists
> since years and a better activation method fixes it. There are other
> positives for using BIP 8/LOT=TRUE which I shared in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html
>
> I will continue to discuss this problem with solutions until we use better
> activation methods for future soft forks in any discussion about activation
> methods.
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
>
> ------- Original Message -------
> On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud <
> billy.tetrud at gmail.com> wrote:
>
> @Pushd
>
> > Speedy trial makes it worse by misleading lot of bitcoin users
> including miners to consider signaling as voting and majority votes decide
> if a soft fork gets activated
>
> No it does not. This narrative is the worst. A bad explanation of speedy
> trial can mislead people into thinking miner signalling is how Bitcoin
> upgrades are voted in. But a bad explanation can explain anything badly.
> The solution is not to change how we engineer soft forks, it's to explain
> speedy trial better to this imaginary group of important people that think
> miner signaling is voting.
>
> We shouldn't change how we engineer Bitcoin because of optics. I
> completely object to that point continuing to be used.
>
> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > Any case where a flawed proposal makes it through getting activation
>> parameters set and released, but doesn't achieve supermajority hashpower
>> support is made worse by bip8/lot=true in comparison to speedy trial.
>>
>> - Flawed proposal making it through activation is a failure of review
>> process
>>
>> - Supermajority hashpower percentage decided by bitcoin core developers
>> can choose to not follow old or new consensus rules at any point
>>
>> - Speedy trial makes it worse by misleading lot of bitcoin users
>> including miners to consider signaling as voting and majority votes decide
>> if a soft fork gets activated
>>
>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus
>> rules as they do right now if they wish to mine blocks for subsidy and fees.
>>
>>
>> Note: Mining pools or individual miners can participate in soft fork
>> discussions regardless of activation method and share their concern which
>> can be evaluated based on technical merits.
>>
>>
>> pushd
>> ---
>>
>> parallel lines meet at infinity?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220330/88f65484/attachment.html>

2023-06-07 23:06:21

- reply

📅 Original date posted:2022-03-30
📝 Original message:@Pushd
> Speedy trial makes it worse by misleading lot of bitcoin users including
miners to consider signaling as voting and majority votes decide if a soft
fork gets activated
No it does not. This narrative is the worst. A bad explanation of speedy
trial can mislead people into thinking miner signalling is how Bitcoin
upgrades are voted in. But a bad explanation can explain anything badly.
The solution is not to change how we engineer soft forks, it's to explain
speedy trial better to this imaginary group of important people that think
miner signaling is voting.
We shouldn't change how we engineer Bitcoin because of optics. I completely
object to that point continuing to be used.
On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Any case where a flawed proposal makes it through getting activation
> parameters set and released, but doesn't achieve supermajority hashpower
> support is made worse by bip8/lot=true in comparison to speedy trial.
>
> - Flawed proposal making it through activation is a failure of review
> process
>
> - Supermajority hashpower percentage decided by bitcoin core developers
> can choose to not follow old or new consensus rules at any point
>
> - Speedy trial makes it worse by misleading lot of bitcoin users including
> miners to consider signaling as voting and majority votes decide if a soft
> fork gets activated
>
> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus
> rules as they do right now if they wish to mine blocks for subsidy and fees.
>
>
> Note: Mining pools or individual miners can participate in soft fork
> discussions regardless of activation method and share their concern which
> can be evaluated based on technical merits.
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220330/60a6697e/attachment.html>

2023-06-07 23:06:18

- reply

📅 Original date posted:2022-03-11
📝 Original message:Thanks for pointing out that PR @pushd. Looks like pretty good evidence for
what the status of consensus was around BIP8 in the last 2 years.
@Jorge, I tried to engage with you on the topic of activation rules last
year. This is where we left it
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019172.html>.
If I'm being frank, you were not clear about what you advocated for, you
didn't seem to take the time to understand what I was advocating for and
what I was asking you and trying to discuss with you, and you ghosted some
of my questions to you. I think you have some ideas that are important to
consider, but you're quite a bit more difficult to communicate with than
the average bitcoin-dev user, and I'd suggest that if you want your
concerns addressed, you figure out how to interact more constructively with
people on here. You're being very defensive and adversarial. Please take a
step back and try to be more objective. That is IHMO the best way for your
thoughts to be heard and understood.
I think involving users more in activation is a good avenue of thought for
improving how bitcoin does soft forks. I also think the idea you brought up
of some way for people to signal opposition is a good idea. I've suggested
a mechanism for signature-based user polling
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019022.html>,
I've also suggested a mechanism
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019117.html>
where miners can actively signal for opposing a soft fork. It seems like
there should be some common ground between us in those ideas. Where it
seems we may perhaps unreconcilably disagree are that A. miners are users
too and generally have interests that are important and different than most
users, and giving them at least some mechanism to force discussion is
appropriate, and B. chain splits are no joke and should almost never be
possible accidentally and therefore we should make a significant effort to
avoid them, which almost definitely means orderly coordination of miners.
Do you have anything concrete you want to propose? An example mechanism?
Are you simply here advocating your support for BIP8+LOT=true?
On Fri, Mar 11, 2022 at 7:47 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón <jtimon at jtimon.cc> wrote:
>
>> I talked about this. But the "no-divergent-rules" faction doesn't like
>> it, so we can pretend we have listened to this "faction" and addressed all
>> its concerns, I guess.
>> Or perhaps it's just "prosectution complex", but, hey, what do I know
>> about psychology?
>>
>
> Your accusations of bad faith on the part of myself and pretty much
> everyone else makes me disinclined to continue this discussion with you.
> I'll reply, but if you want me to continue beyond this, then you need to
> knock it off with the accusations.
>
>
>> A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr. It turns out that, at
>>> the time of that proposal, a large amount of hash power simply did not have
>>> the firmware required to support signalling. That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mining
>>> power offline if it had been deployed. Imagine if the firmware couldn't be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>> Yes, I like this solution too, with a little caveat: an easy mechanism
>> for users to actively oppose a proposal.
>> Luke alao talked about this.
>> If users oppose, they should use activation as a trigger to fork out of
>> the network by invalidating the block that produces activation.
>> The bad scenario here is that miners want to deploy something but users
>> don't want to.
>> "But that may lead to a fork". Yeah, I know.
>> I hope imagining a scenario in which developers propose something that
>> most miners accept but some users reject is not taboo.
>>
>
> This topic is not taboo.
>
> There are a couple of ways of opting out of taproot. Firstly, users can
> just not use taproot. Secondly, users can choose to not enforce taproot
> either by running an older version of Bitcoin Core or otherwise forking the
> source code. Thirdly, if some users insist on a chain where taproot is
> "not activated", they can always softk-fork in their own rule that
> disallows the version bits that complete the Speedy Trial activation
> sequence, or alternatively soft-fork in a rule to make spending from (or
> to) taproot addresses illegal.
>
> As for mark, he wasn't talking about activation, but quantum computing
>> concerns. Perhaps those have been "addressed"?
>> I just don't know where.
>>
>
> Quantum concerns were discussed. Working from memory, the arguments were
> (1) If you are worried about your funds not being secured by taproot, then
> don't use taproot addresses, and (2) If you are worried about everyone
> else's funds not being quantum secure by other people choosing to use
> taproot, well it is already too late because over 5M BTC is currently
> quantum insecure due to pubkey reuse <
> https://nitter.net/pwuille/status/1108091924404027392>. I think it is
> unlikely that a quantum breakthrough will sneak up on us without time to
> address the issue and, at the very least, warn people to move their funds
> off of taproot and other reused addresses, if not forking in some quantum
> secure alternative. A recent paper <
> https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.pdf>
> suggest that millions physical qubits will be needed to break EC in a day
> with current error correction technology. But even if taproot were to be
> very suddenly banned, there is still a small possibility for recovery
> because one can prove ownership of HD pubkeys by providing a zero-knowledge
> proof of the chaincode used to derive them.
> _______________________________________________
> 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/20220311/932ee5d6/attachment.html>

2023-06-07 23:06:10

- reply

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

2023-06-07 23:06:08

- reply

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

2023-06-07 23:06:07

- reply

📅 Original date posted:2022-03-17
📝 Original message:@Jorge
> Any user polling system is going to be vulnerable to sybil attacks.
Not the one I'll propose right here. What I propose specifically is
a coin-weighted signature-based poll with the following components:
A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90%
support:10%}> for each UTXO they want to respond to the poll with.
B. A signed message like that is valid only while that UTXO has not been
spent.
C. Poll results are considered only at each particular block height, where
the support and opposition responses are weighted by the UTXO amount (and
the support/oppose fraction in the message). This means you'd basically see
a rolling poll through the blockchain as new signed poll messages come in
and as their UTXOs are spent.
This is not vulnerable to sybil attacks because it requires access to UTXOs
and response-weight is directly tied to UTXO amount. If someone signs a
poll message with a key that can unlock (or is in some other designated way
associated with) a UTXO, and then spends that UTXO, their poll response
stops being counted for all block heights after the UTXO was spent.
Why put support and oppose fractions in the message? Who would want to both
support and oppose something? Any multiple participant UTXO would. Eg
lightning channels would, where each participant disagrees with the other.
They need to sign together, so they can have an agreement to sign for the
fractions that match their respective channel balances (using a force
channel close as a last resort against an uncooperative partner as usual).
This does have the potential issue of public key exposure prior to spending
for current addresses. But that could be fixed with a new address type that
has two public keys / spend paths: one for spending and one for signing.
> In perfect competition the mining power costs per chain tends to equal
the rewards offered by that chain, both in subsidy and transaction fees.
Agreed, but it takes time for an economic shock to reach its new
equilibrium. That period of time, which might be rather precarious, should
be considered in a plan to preserve a minority fork.
> Would you rather that proposal be deployed with speedy trial activation
or with BIP8+LOT=true activation?
For a proposal I don't want to succeed, I absolutely would prefer speedy
trial over BIP8+LOT=true. Speedy trial at 90% signaling threshold can
quickly determine that the proposal (hopefully) does not have enough
consensus among miners. By contrast, BIP8+LOT=true could polarize the
debate, worsening the community's ability to communicate and talk through
issues. It would also basically guarantee that a fork happens, which in the
best case (in my hypothetical point of view where I don't like the
proposal) would mean some small minority forks off the network, which
reduces the main chain's value somewhat (at least temporarily). Worst case
a small majority forces the issue at near 50% which would cause all sorts
of blockchain issues and would have a high probability of leading to a
hardfork by the minority.
All this sounds rather more tenable with speedy trial. Any proposal has
less chance of causing an actual fork (soft or otherwise) with speedy trial
vs LOT=true. LOT=true guarantees a fork if even a single person is running
it. LOT=true could certainly come in handy to initiate a UASF, but IMO
that's better left as a plan B or C.
> segwit... all the consequences of the change are not opt in.
I definitely agree there. The consequences of a soft fork are not always
opt in. That's basically what my example of a "dumb majority soft fork" is,
and sounds like what your "evil fork" basically is.
On Thu, Mar 17, 2022 at 7:19 AM Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon at jtimon.cc> wrote:
> > A mechanism of soft-forking against activation exists. What more do you
> want? Are we supposed to write the code on behalf of this hypothetical
> group of users who may or may not exist for them just so that they can have
> a node that remains stalled on Speedy Trial lockin? That simply isn't
> reasonable, but if you think it is, I invite you to create such a fork.
>
> I want BIP+LOT=true to be used. I want speedy trial not to be used.
> Luke wrote the code to resist BIP8+LOT=true, and if he didn't, I could
> write it myself, yes.
> If you think that's not reasonable code to ever run, I don't think
> you're really getting the "softfork THAT YOU OPPOSE" part of the
> hypothetical right. Let me try to help with an example, although I
> hope we don't get derailed in the implementation details of the
> hypothetical evil proposal.
>
> Suppose someone proposes a weight size limit increase by a extension
> block softfork.
> Or instead of that, just imagine the final version of the covenants
> proposal has a backdoor in it or something.
>
>
> Would you rather that proposal be deployed with speedy trial
> activation or with BIP8+LOT=true activation?
>
> >>
> >> Please, try to imagine an example for an activation that you wouldn't
> like yourself. Imagine it gets proposed and you, as a user, want to resist
> it.
> >
> >
> > If I believe I'm in the economic majority then I'll just refuse to
> upgrade my node, which was option 2. I don't know why you dismissed it.
>
> Not upgrading your node doesn't prevent the softfork from being
> activated in your chain.
> A softfork may affect you indirectly even if you don't use the new
> features yourself directly.
> You may chose to stay in the old chain even if you don't consider
> you're "in the economic majority" at that moment.
>
> > Not much can prevent a miner cartel from enforcing rules that users
> don't want other than hard forking a replacement POW. There is no
> effective difference between some developers releasing a malicious
> soft-fork of Bitcoin and the miners releasing a malicious version
> themselves. And when the miner cartel forms, they aren't necessarily going
> to be polite enough to give a transparent signal of their new rules.
> However, without the economic majority enforcing their set of rules, the
> cartel continuously risks falling apart from the temptation of transaction
> fees of the censored transactions.
>
> It is true that a mining cartel doesn't need to use speedy trial or
> BIP8+LOT=true to apply rule changes they want just because we do.
> But they would do if they wanted to maintain the appearance of benevolence.
>
> > On the other hand, If I find out I'm in the economic minority then I
> have little choice but to either accept the existence of the new rules or
> sell my Bitcoin. Look, you cannot have the perfect system of money all by
> your lonesome self. Money doesn't have economic value if no one else wants
> to trade you for it. Just ask that poor user who YOLO'd his own taproot
> activation in advance all by themselves. I'm sure they think they've got
> just the perfect money system, with taproot early and everything. But now
> their node is stuck at block 692261 and hasn't made progress since. No
> doubt they are hunkered down for the long term, absolutely committed to
> their fork and just waiting for the rest of the world to come around to how
> much better their version of Bitcoin is than the rest of us.
>
> Well, you could also have the option to stay in the old chain with the
> economic minority, it doesn't have to be you alone.
> We agree that one person alone can't use a currency.
>
> > Even though you've dismissed it, one of the considerations of taproot
> was that it is opt-in for users to use the functionality. Future
> soft-forks ought to have the same considerations to the extent possible.
>
> Well, the same could be said about segwit. And yet all the
> consequences of the change are not opt in.
> For example, segwit contained a block size limit increase.
> Sure, you can just not validate the witnesses, but then you're no
> longer a full node.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220317/082e92f9/attachment.html>

2023-06-07 23:06:05

- reply

📅 Original date posted:2022-03-17
📝 Original message:@Aj Your steps seem reasonable. I definitely agree step one (talking to
each other) is obviously the ideal solution, when it works.
Step 2 (futures market) is the option I would say I understand the least.
In any case, a futures market seems like it only incorporates the
opinions/predictions of the group of people willing to bet money on things
like this. This is likely to be a rather small group of particular types of
people. I find it a bit difficult to reconcile the theories that betting
rings like this are good at predicting against the inherent selection bias
of the group of betting individuals. Going just by number of individuals
(or probably even by amount of currency risked) this seems like a futures
market would inherently be a small and biased group. Potentially useful,
but I wouldn't assume that it could be taken stand-alone as a proxy for
consensus.
I'm curious what you think about a coin-weighted poll like I suggested here
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019022.html>
being
added to that list of steps? Surely this would be a broader group of people
than a futures market, tho still obviously a group subject to selection
bias.
@jeremy drops the bomb. I'm sure Jorge will be running this within the
year.
On Tue, Mar 15, 2022 at 12:25 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Boker tov bitcoin devs,
>
> A mechanism of soft-forking against activation exists. What more do you
>> want?
>>
>
> Agreed -- that should be enough.
>
>
>
>> Are we supposed to write the code on behalf of this hypothetical group of
>> users who may or may not exist for them just so that they can have a node
>> that remains stalled on Speedy Trial lockin?
>>
> That simply isn't reasonable, but if you think it is, I invite you to
>> create such a fork.
>>
>
> Disagree.
>
> It is a reasonable ask.
>
> I've done it in about 40 lines of python:
> https://github.com/jeremyrubin/forkd
>
> Merry Christmas Jorge, please vet the code carefully before running.
>
> Peace,
>
> Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220316/0bf6deff/attachment.html>

2023-06-07 23:06:03

- reply

📅 Original date posted:2022-03-12
📝 Original message:> If I find out I'm in the economic minority then I have little choice but
to either accept the existence of the new rules or sell my Bitcoin
I do worry about what I have called a "dumb majority soft fork". This is
where, say, mainstream adoption has happened, some crisis of some magnitude
happens that convinces a lot of people something needs to change now. Let's
say it's another congestion period where fees spike for months. Getting
into and out of lighting is hard and maybe even the security of lightning's
security model is called into question because it would either take too
long to get a transaction on chain or be too expensive. Panicy people might
once again think something like "let's increase the block size to 1GB, then
we'll never have this problem again". This could happen in a segwit-like
soft fork.
In a future where Bitcoin is the dominant world currency, it might not be
unrealistic to imagine that an economic majority might not understand why
such a thing would be so dangerous, or think the risk is low enough to be
worth it. At that point, we in the economic minority would need a plan to
hard fork away. One wouldn't necessarily need to sell all their majority
fork Bitcoin, but they could.
That minority fork would of course need some mining power. How much? I
don't know, but we should think about how small of a minority chain we
could imagine might be worth saving. Is 5% enough? 1%? How long would the
chain stall if hash power dropped to 1%?
TBH I give the world a ~50% chance that something like this happens in the
next 100 years. Maybe Bitcoin will ossify and we'll lose all the people
that had deep knowledge on these kinds of things because almost no one's
actively working on it. Maybe the crisis will be too much for people to
remain rational and think long term. Who knows? But I think that at some
point it will become dangerous if there isn't a well discussed well vetted
plan for what to do in such a scenario. Maybe we can think about that 10
years from now, but we probably shouldn't wait much longer than that. And
maybe it's as simple as: tweak the difficulty recalculation and then just
release a soft fork aware Bitcoin version that rejects the new rules or
rejects a specific existing post-soft-fork block. Would it be that simple?
On Sat, Mar 12, 2022, 07:35 Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon at jtimon.cc> wrote:
>
>>
>> A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr. It turns out that, at
>>> the time of that proposal, a large amount of hash power simply did not have
>>> the firmware required to support signalling. That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mining
>>> power offline if it had been deployed. Imagine if the firmware couldn't be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>>>> Yes, I like this solution too, with a little caveat: an easy mechanism
>>>> for users to actively oppose a proposal.
>>>> Luke alao talked about this.
>>>> If users oppose, they should use activation as a trigger to fork out of
>>>> the network by invalidating the block that produces activation.
>>>> The bad scenario here is that miners want to deploy something but users
>>>> don't want to.
>>>> "But that may lead to a fork". Yeah, I know.
>>>> I hope imagining a scenario in which developers propose something that
>>>> most miners accept but some users reject is not taboo.
>>>>
>>>
>>> This topic is not taboo.
>>>
>>> There are a couple of ways of opting out of taproot. Firstly, users can
>>> just not use taproot. Secondly, users can choose to not enforce taproot
>>> either by running an older version of Bitcoin Core or otherwise forking the
>>> source code. Thirdly, if some users insist on a chain where taproot is
>>> "not activated", they can always softk-fork in their own rule that
>>> disallows the version bits that complete the Speedy Trial activation
>>> sequence, or alternatively soft-fork in a rule to make spending from (or
>>> to) taproot addresses illegal.
>>>
>>
>> Since it's about activation in general and not about taproot
>> specifically, your third point is the one that applies.
>> Users could have coordinated to have "activation x" never activated in
>> their chains if they simply make a rule that activating a given proposal
>> (with bip8) is forbidden in their chain.
>> But coordination requires time.
>>
>
> A mechanism of soft-forking against activation exists. What more do you
> want? Are we supposed to write the code on behalf of this hypothetical
> group of users who may or may not exist for them just so that they can have
> a node that remains stalled on Speedy Trial lockin? That simply isn't
> reasonable, but if you think it is, I invite you to create such a fork.
>
>
>> Please, try to imagine an example for an activation that you wouldn't
>> like yourself. Imagine it gets proposed and you, as a user, want to resist
>> it.
>>
>
> If I believe I'm in the economic majority then I'll just refuse to upgrade
> my node, which was option 2. I don't know why you dismissed it.
>
> Not much can prevent a miner cartel from enforcing rules that users don't
> want other than hard forking a replacement POW. There is no effective
> difference between some developers releasing a malicious soft-fork of
> Bitcoin and the miners releasing a malicious version themselves. And when
> the miner cartel forms, they aren't necessarily going to be polite enough
> to give a transparent signal of their new rules. However, without the
> economic majority enforcing their set of rules, the cartel continuously
> risks falling apart from the temptation of transaction fees of the censored
> transactions.
>
> On the other hand, If I find out I'm in the economic minority then I have
> little choice but to either accept the existence of the new rules or sell
> my Bitcoin. Look, you cannot have the perfect system of money all by your
> lonesome self. Money doesn't have economic value if no one else wants to
> trade you for it. Just ask that poor user who YOLO'd his own taproot
> activation in advance all by themselves. I'm sure they think they've got
> just the perfect money system, with taproot early and everything. But now
> their node is stuck at block 692261
> <https://b10c.me/blog/007-spending-p2tr-pre-activation/> and hasn't made
> progress since. No doubt they are hunkered down for the long term,
> absolutely committed to their fork and just waiting for the rest of the
> world to come around to how much better their version of Bitcoin is than
> the rest of us.
>
> Even though you've dismissed it, one of the considerations of taproot was
> that it is opt-in for users to use the functionality. Future soft-forks
> ought to have the same considerations to the extent possible.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220312/95ceba55/attachment-0001.html>

2023-06-07 23:06:01

- reply

📅 Original date posted:2022-03-11
📝 Original message:> BIP 8 did in fact have broad consensus
I hear you claim this often Luke, but claiming its so does not make it so.
Do you think BIP8 still has broad consensus? If that's the case, maybe all
that's needed is to gather some evidence
<https://www.youtube.com/watch?v=U7rXOgL4oFQ> and present it.
On Thu, Mar 10, 2022 at 6:38 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote:
> > The "no-miner-veto" concerns are, to an extent, addressed by the short
> > timeline of Speedy Trial. No more waiting 2 years on the miners dragging
> > their feet.
>
> It's still a miner veto. The only way this works is if the full deployment
> (with UASF fallback) is released in parallel.
>
> > If you are so concerned about listening to legitimate criticism, maybe
> you
> > can design a new deployment mechanism that addresses the concerns of the
> > "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> > faction.
>
> BIP8 already does that.
>
> > A major contender to the Speedy Trial design at the time was to mandate
> > eventual forced signalling, championed by luke-jr. It turns out that, at
> > the time of that proposal, a large amount of hash power simply did not
> have
> > the firmware required to support signalling. That activation proposal
> > never got broad consensus,
>
> BIP 8 did in fact have broad consensus before some devs decided to ignore
> the
> community and do their own thing. Why are you trying to rewrite history?
>
> > and rightly so, because in retrospect we see
> > that the design might have risked knocking a significant fraction of
> mining
> > power offline if it had been deployed. Imagine if the firmware couldn't
> be
> > quickly updated or imagine if the problem had been hardware related.
>
> They had 18 months to fix their broken firmware. That's plenty of time.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220310/c8344427/attachment-0001.html>

2023-06-07 23:05:58

- reply

📅 Original date posted:2022-03-17
📝 Original message:@Antoine
> B overrides A and starts to replace package A in the network mempools
nearest to Alice. I think those peers won't have bandwidth saving from
adopting a replacement staggering strategy.
That's an interesting point, but even with that fact, the method would be
effective at limiting spam. While yes, considering just a single unit of
potential spam, only the nodes that didn't relay the spam in the first
place would save bandwidth. However, the point is not to prevent a single
unit, but to prevent thousands of units of spam. Even if in the situation
you describe Bob and Alice sent 100 replacement transaction per seconds, it
would lead to only 1 transaction sent by Bob's peers and only 2
transactions sent by Alice's peers (within a given stagger/cooldown
window). That seems pretty effective to me.
> I wonder if a "diff-only" strategy.. would be more interesting
I think a diff-only relay strategy is definitely interesting. But its
completely orthogonal. A diff only strategy isn't really a spam reduction
mechanism, but rather a relay optimization that reduces bandwidth on all
relay. Both can be done - seems like it could be argued that both should be
done.
>> For example, some nth bit of nSequence with nVersion 3 means "this
transaction won't have more than X vbytes of descendants"
>what if the pinning transaction has a parent with a junk feerate ?
I think you're right that this scheme would also be susceptible to pinning.
One thing I've identified as pretty much always suboptimal in any kind of
policy is cliffs. Hard cut offs very often cause problems. You see this in
welfare cliffs where the cliff disincentivizes people from earning more
money for example. Its almost always better to build in a smooth gradient.
Rate limiting where a node would relay replacement transaction data up to a
certain point and then stop is a cliff like this. The descendant byte limit
is a cliff like this. If such things were to be actually done, I'd
recommend building in some kind of gradient where, say, every X vbytes of
descendents requires Y additional feerate, or something to that effect.
That way you can always add more descendents as long as you're willing to
pay a higher and higher feerate for them. However, I think simply removing
the absolute feerate rule is a better solution to that kind of RBF pinning.
On Thu, Mar 17, 2022 at 4:32 AM Antoine Riard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Mempoololic Anonymous fellow,
>
> > 2. Staggered broadcast of replacement transactions: within some time
> > interval, maybe accept multiple replacements for the same prevout, but
> only
> > relay the original transaction.
>
> If the goal of replacement staggering is to save on bandwidth, I'm not
> sure it's going to be effective if you consider replacement done from a
> shared-utxo. E.g, Alice broadcasts a package to confirm her commitment,
> relay is staggered until T. At the same time, Bob broadcasts a package to
> confirm his version of the commitment at a slightly better feerate, relay
> is staggered until T.
>
> At T, package A gradually floods from Alice's peers and package B does the
> same from Bob's peers. When there is an intersection. B overrides A and
> starts to replace package A in the network mempools nearest to Alice. I
> think those peers won't have bandwidth saving from adopting a replacement
> staggering strategy.
>
> Or maybe that's something completely different if you have in mind ? I
> think it's worth more staggering detail to guess if it's robust against all
> the replacement propagations patterns.
>
> Though if we aim to save on replacement bandwidth I wonder if a
> "diff-only" strategy, assuming some new p2p mechanism, would be more
> interesting (as discussed in the recent "Thoughts on fee bumping thread").
>
> > A lingering concern that I have about this idea is it would then be
> > possible to impact the propagation of another person’s transaction, i.e.,
> > an attacker can censor somebody’s transaction from ever being announced
> by
> > a node if they send enough transactions to fill up the rate limit.
> > Obviously this would be expensive since they're spending a lot on fees,
> but
> > I imagine it could be profitable in some situations to spend a few
> thousand
> > dollars to prevent anyone from hearing about a transaction for a few
> hours.
> > This might be a non-issue in practice if the rate limit is generous and
> > traffic isn’t horrendous, but is this a problem?
>
> I think I share the concern too about an attacker exhausting a node
> transaction relay ressources to prevent another person's transaction to
> propagate, especially if the transaction targeted is a L2's time-sensitive
> one. In that latter context, an attacker would aim to delay the relay of a
> time-sensitive transaction (e.g a HTLC-success) to the miners, until the
> timelock expires. The malicious delay period should swallow the go-to-chain
> HTLC deadline ("the deadline for received HTLCs this node fulfilled" in
> bolt 2 parlance), in that current example 18 blocks.
>
> Let's say we allocate 10 MB of bandwidth per-block period. Once the 10 MB
> are exhausted, there is no more bandwidth allocated until the next block is
> issued. If the top mempool feerate is 1 sat/vb, such naive design would
> allow an attacker to buy all the p2p network bandwidth period for 0.1 BTC.
> If an attacker aims to jam a HTLC transaction for the 18 blocks period, the
> cost is of 1,8 BTC. If the attacker is a LN counterparty to a HTLC worth
> more than 1.8 BTC, the attack sounds economically profitable.
>
> Worst, the p2p network bandwidth is a public resource while a HTLC is a
> private, off-chain contract. An attacker could be counterparty to many
> HTLCs, where each HTLC individual value is far inferior to the global p2p
> bandwidth cost but the sum, only known to the attacker, is superior to.
> Therefore, it sounds to me that p2p network bandwidth might be attractive
> if the stealing are batched.
>
> Is the attacker scenario described credible ? Are the numbers sketched out
> realistic ?
>
> If yes, I think one design insight for eventual transaction relay rate
> limiting would be to make them "dynamic", and not naively fixed for a
> period. By making them dynamic, an attacker would have to compete with the
> effective feerate proposed by the victim transaction. E.g, if the
> HTLC-success feerate is of 10 sat/vb, an attacker would have to propose a
> stream of malicious transaction of more than 10 sat/vb during the whole
> HTLC deadline period for the transaction-relay jamming to be effective.
>
> Further, the attack might be invisible from the victim standpoint, the
> malicious flow of feerate competitive transactions can be hard to
> dissociate from an honest one. Thus, you can expect the
> HTLC transaction issuer to only slowly increase the feerate at each block,
> and those moves to be anticipated by the attacker. Even if the transaction
> issuer adopts a scorched-earth approach for the latest blocks of the
> deadline, the absolute value of the HTLC burnt in fees might still be less
> than the transaction relay bandwidth exhaustion paid by the attacker
> because the attack is batched by the attacker.
>
> I'm not sure if this reasoning is correct. Though if yes, the issue sounds
> really similar to "flood&loot" attack affecting LN previously researched on
> [0]. What worries me more with this "exhaust&loot" is that if we introduce
> bounded transaction relay rate limiting, it sounds a cheaper public
> ressource to buy than the mempool..
>
> [0] https://arxiv.org/pdf/2006.08513.pdf
>
> Anyway, I would say it's worthy to investigate more transaction relay rate
> limiting designs and especially carefully weigh the implications for L2s.
> Those ones might have to adjust their fee-bumping and transaction
> rebroadcast strategies in consequence.
>
> > Suhas and Matt [proposed][0] adding a policy rule allowing users to
> specify
> > descendant limits on their transactions. For example, some nth bit of
> > nSequence with nVersion 3 means "this transaction won't have more than X
> > vbytes of descendants" where X = max(1000, vsizeof(tx)) or something. It
> > solves the pinning problem with package RBF where the attacker's package
> > contains a very large and high-fee descendant.
>
> Hey, what if the pinning transaction has a parent with a junk feerate ?
>
> Let's say you have commitment tx for a HTLC of value 500000 sats, with top
> mempool feerate of 50 sat/vbyte. The commitment tx is pinned by a malicious
> tx of size 1000 vbytes, matching top mempool feerate. This malicious tx has
> a second unconfirmed parent (in addition to the commitment) of size
> MAX_STANDARD_TX_WEIGHT offering a 1 sat/vb. I think the pinning transaction
> ancestor score would be less than 2 sat/vb and thus considered irrelevant
> for block template inclusion ? At the same time, as the pinning transaction
> is attached with a top mempool feerate, the honest user wouldn't be able to
> replace it with a better-feerate proposal ? Unless adopting a
> scorched-earth approach, although economically I don't think this
> fee-bumping strategy is safe in case of batch-pinning.
>
> It might be fixable if we make one additional requirement "The child
> transaction subject to the user-elected descendant limit must have only one
> unconfirmed parent" (here the commitment
> transaction) ? Though I'm not even sure of the robustness of this fix. The
> commitment transaction itself could be used as a junk parent to downgrade
> the pinning transaction ancestor score. E.g, using a revoked commitment
> transaction with `max_accepted_htlcs` on both sides, pre-signed with a
> feerate of 1 sat/vb. We might restrict the maximum number of pending HTLCs
> network-wise to make the worst commitment transaction size reasonable,
> though not sure if my LN colleagues are going to like the idea..
>
> Is that reasoning correct and conform to our Ancestor Set Based algorithm
> approach ? Maybe more details are needed.
>
> > Also, coming back to the idea of "we can't just use {individual,
> ancestor}
> > feerate," I'm interested in soliciting feedback on adding a “mining
> score”
> > calculator. I've implemented one [here][2] which takes the transaction in
> > question, grabs all of the connected mempool transactions (including
> > siblings, coparents, etc., as they wouldn’t be in the ancestor nor
> > descendant sets), and builds a “block template” using our current mining
> > algorithm. The mining score of a transaction is the ancestor feerate at
> > which it is included.
>
> I don't have a strong opinion there yet, though if we make this "block
> template" construction the default one, I would be really conservative to
> avoid malicious child attachment on multi-party transactions downgrading
> the block inclusion efficiency.
>
> Antoine
>
> Le mer. 9 mars 2022 à 10:37, Gloria Zhao via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> Hi RBF friends,
>>
>> Posting a summary of RBF discussions at coredev (mostly on transaction
>> relay rate-limiting), user-elected descendant limit as a short term
>> solution to unblock package RBF, and mining score, all open for feedback:
>>
>> One big concept discussed was baking DoS protection into the p2p level
>> rather than policy level. TLDR: The fees are not paid to the node operator,
>> but to the miner. While we can use fees to reason about the cost of an
>> attack, if we're ultimately interested in preventing resource exhaustion,
>> maybe we want to "stop the bleeding" when it happens and bound the amount
>> of resources used in general. There were two main ideas:
>>
>> 1. Transaction relay rate limiting (i.e. the one you proposed above or
>> some variation) with a feerate-based priority queue
>> 2. Staggered broadcast of replacement transactions: within some time
>> interval, maybe accept multiple replacements for the same prevout, but only
>> relay the original transaction.
>>
>> Looking to solicit feedback on these ideas and the concept in general. Is
>> it a good idea (separate from RBF) to add rate-limiting in transaction
>> relay? And is it the right direction to think about RBF DoS protection this
>> way?
>>
>> A lingering concern that I have about this idea is it would then be
>> possible to impact the propagation of another person’s transaction, i.e.,
>> an attacker can censor somebody’s transaction from ever being announced by
>> a node if they send enough transactions to fill up the rate limit.
>> Obviously this would be expensive since they're spending a lot on fees, but
>> I imagine it could be profitable in some situations to spend a few thousand
>> dollars to prevent anyone from hearing about a transaction for a few hours.
>> This might be a non-issue in practice if the rate limit is generous and
>> traffic isn’t horrendous, but is this a problem?
>>
>> And if we don't require an increase in (i.e. addition of "new") absolute
>> fees, users are essentially allowed to “recycle” fees. In the scenario
>> where we prioritize relay based on feerate, users could potentially be
>> placed higher in the queue, ahead of other users’ transactions, multiple
>> times, without ever adding more fees to the transaction. Again, maybe this
>> isn’t a huge deal in practice if we set the parameters right, but it seems…
>> not great, in principle.
>>
>> ---------
>>
>> It's probably also a good idea to point out that there's been some
>> discussion happening on the gist containing my original post on this thread
>> (https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff).
>>
>> Suhas and Matt [proposed][0] adding a policy rule allowing users to
>> specify descendant limits on their transactions. For example, some nth bit
>> of nSequence with nVersion 3 means "this transaction won't have more than X
>> vbytes of descendants" where X = max(1000, vsizeof(tx)) or something. It
>> solves the pinning problem with package RBF where the attacker's package
>> contains a very large and high-fee descendant.
>>
>> We could add this policy and deploy it with package RBF/package relay so
>> that LN can use it by setting the user-elected descendant limit flag on
>> commitment transactions. (Otherwise package RBF is blocked until we find a
>> more comprehensive solution to the pinning attack).
>>
>> It's simple to [implement][1] as a mempool policy, but adds some
>> complexity for wallets that use it, since it limits their use of UTXOs from
>> transactions with this bit set.
>>
>> ---------
>>
>> Also, coming back to the idea of "we can't just use {individual,
>> ancestor} feerate," I'm interested in soliciting feedback on adding a
>> “mining score” calculator. I've implemented one [here][2] which takes the
>> transaction in question, grabs all of the connected mempool transactions
>> (including siblings, coparents, etc., as they wouldn’t be in the ancestor
>> nor descendant sets), and builds a “block template” using our current
>> mining algorithm. The mining score of a transaction is the ancestor feerate
>> at which it is included.
>>
>> This would be helpful for something like ancestor-aware funding and
>> fee-bumping in the wallet: [3], [4]. I think if we did the rate-limited
>> priority queue for transaction relay, we'd want to use something like this
>> as the priority value. And for RBF, we probably want to require that a
>> replacement have a higher mining score than the original transactions. This
>> could be computationally expensive to do all the time; it could be good to
>> cache it but that could make mempool bookkeeping more complicated. Also, if
>> we end up trying to switch to a candidate set-based algorithm for mining,
>> we'd of course need a new calculator.
>>
>> [0]:
>> https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4058140#gistcomment-4058140
>> [1]: https://github.com/glozow/bitcoin/tree/2022-02-user-desclimit
>> [2] https://github.com/glozow/bitcoin/tree/2022-02-mining-score
>> [3]: https://github.com/bitcoin/bitcoin/issues/9645
>> [4]: https://github.com/bitcoin/bitcoin/issues/15553
>>
>> Best,
>> Gloria
>>
>> On Tue, Feb 8, 2022 at 4:58 AM Anthony Towns <aj at erisian.com.au> wrote:
>>
>>> On Mon, Feb 07, 2022 at 11:16:26AM +0000, Gloria Zhao wrote:
>>> > @aj:
>>> > > I wonder sometimes if it could be sufficient to just have a relay
>>> rate
>>> > > limit and prioritise by ancestor feerate though. Maybe something
>>> like:
>>> > > - instead of adding txs to each peers setInventoryTxToSend
>>> immediately,
>>> > > set a mempool flag "relayed=false"
>>> > > - on a time delay, add the top N (by fee rate) "relayed=false" txs to
>>> > > each peer's setInventoryTxToSend and mark them as "relayed=true";
>>> > > calculate how much kB those txs were, and do this again after
>>> > > SIZE/RATELIMIT seconds
>>>
>>> > > - don't include "relayed=false" txs when building blocks?
>>>
>>> The "?" was me not being sure that point is a good suggestion...
>>>
>>> Miners might reasonably decide to have no rate limit, and always relay,
>>> and never exclude txs -- but the question then becomes is whether they
>>> hear about the tx at all, so rate limiting behaviour could still be a
>>> potential problem for whoever made the tx.
>>>
>>> > Wow cool! I think outbound tx relay size-based rate-limiting and
>>> > prioritizing tx relay by feerate are great ideas for preventing
>>> spammers
>>> > from wasting bandwidth network-wide. I agree, this would slow the low
>>> > feerate spam down, preventing a huge network-wide bandwidth spike. And
>>> it
>>> > would allow high feerate transactions to propagate as they should,
>>> > regardless of how busy traffic is. Combined with inbound tx request
>>> > rate-limiting, might this be sufficient to prevent DoS regardless of
>>> the
>>> > fee-based replacement policies?
>>>
>>> I think you only want to do outbound rate limits, ie, how often you send
>>> INV, GETDATA and TX messages? Once you receive any of those, I think
>>> you have to immediately process / ignore it, you can't really sensibly
>>> defer it (beyond the existing queues we have that just build up while
>>> we're busy processing other things first)?
>>>
>>> > One point that I'm not 100% clear on: is it ok to prioritize the
>>> > transactions by ancestor feerate in this scheme? As I described in the
>>> > original post, this can be quite different from the actual feerate we
>>> would
>>> > consider a transaction in a block for. The transaction could have a
>>> high
>>> > feerate sibling bumping its ancestor.
>>> > For example, A (1sat/vB) has 2 children: B (49sat/vB) and C (5sat/vB).
>>> If
>>> > we just received C, it would be incorrect to give it a priority equal
>>> to
>>> > its ancestor feerate (3sat/vB) because if we constructed a block
>>> template
>>> > now, B would bump A, and C's new ancestor feerate is 5sat/vB.
>>> > Then, if we imagine that top N is >5sat/vB, we're not relaying C. If we
>>> > also exclude C when building blocks, we're missing out on good fees.
>>>
>>> I think you're right that this would be ugly. It's something of a
>>> special case:
>>>
>>> a) you really care about C getting into the next block; but
>>> b) you're trusting B not being replaced by a higher fee tx that
>>> doesn't have A as a parent; and
>>> c) there's a lot of txs bidding the floor of the next block up to a
>>> level in-between the ancestor fee rate of 3sat/vB and the tx fee
>>> rate of 5sat/vB
>>>
>>> Without (a), maybe you don't care about it getting to a miner quickly.
>>> If your trust in (b) was misplaced, then your tx's effective fee rate
>>> will drop and (because of (c)), you'll lose anyway. And if the spam ends
>>> up outside of (c)'s range, either the rate limiting won't take effect
>>> (spam's too cheap) and you'll be fine, or you'll miss out on the block
>>> anyway (spam's paying more than your tx rate) and you never had any hope
>>> of making it in.
>>>
>>> Note that we already rate limit via INVENTORY_BROADCAST_MAX /
>>> *_INVENTORY_BROADCAST_INTERVAL; which gets to something like 10,500 txs
>>> per 10 minutes for outbound connections. This would be a weight based
>>> rate limit instead-of/in-addition-to that, I guess.
>>>
>>> As far as a non-ugly approach goes, I think you'd have to be smarter
>>> about
>>> tracking the "effective fee rate" than the ancestor fee rate manages;
>>> maybe that's something that could fall out of Murch and Clara's candidate
>>> set blockbuilding ideas [0] ?
>>>
>>> Perhaps that same work would also make it possible to come up with
>>> a better answer to "do I care that this replacement would invalidate
>>> these descendents?"
>>>
>>> [0] https://github.com/Xekyo/blockbuilding
>>>
>>> > > - keep high-feerate evicted txs around for a while in case they get
>>> > > mined by someone else to improve compact block relay, a la the
>>> > > orphan pool?
>>> > Replaced transactions are already added to vExtraTxnForCompact :D
>>>
>>> I guess I was thinking that it's just a 100 tx LRU cache, which might
>>> not be good enough?
>>>
>>> Maybe it would be more on point to have a rate limit apply only to
>>> replacement transactions?
>>>
>>> > For wallets, AJ's "All you need is for there to be *a* path that
>>> follows
>>> > the new relay rules and gets from your node/wallet to perhaps 10% of
>>> > hashpower" makes sense to me (which would be the former).
>>>
>>> Perhaps a corollarly of that is that it's *better* to have the mempool
>>> acceptance rule only consider economic incentives, and have the spam
>>> prevention only be about "shall I tell my peers about this?"
>>>
>>> If you don't have that split; then the anti-spam rules can prevent you
>>> from getting the tx in the mempool at all; whereas if you do have the
>>> split, then even if the bitcoind anti-spam rules are blocking you at
>>> every turn, you can still send your tx to miners by some other route,
>>> and then they can add it to their mempool directly without any hassle.
>>>
>>> Cheers,
>>> aj
>>>
>>> _______________________________________________
>> 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/20220317/4fcd061a/attachment-0001.html>

2023-06-07 23:05:56

- reply

📅 Original date posted:2022-03-14
📝 Original message:Hi Gloria,
It seems you're responding to what I wrote on github. Happy to respond, but
perhaps we should keep it there so the conversation is kept linearly
together?
I'm curious what you think of my thoughts on what you brought up most
recently in this thread about rate limiting / staggered window dos
protection stuff.
Cheers,
BT
On Mon, Mar 14, 2022 at 5:29 AM Gloria Zhao <gloriajzhao at gmail.com> wrote:
> Hi Billy,
>
> > We should expect miners will be using a more complex, more optimal way
> of determining what blocks they're working on [...] we should instead run
> with the assumption that miners keep all potentially relevant transactions
> in their mempools, including potentially many conflicting transctions, in
> order to create the most profitable blocks. And therefore we shouldn't put
> the constraint on normal non-mining full nodes to do that same more-complex
> mempool behavior or add any complexity for the purpose of denying
> transaction replacements.
>
> > I think a lot of the complexity in these ideas is because of the attempt
> to match relay rules with miner
> inclusion rules.
>
> I think the assumption that miners are using a completely different
> implementation of mempool and block template building is false. IIUC, most
> miners use Bitcoin Core and perhaps configure their node differently (e.g.
> larger mempool and different minfeerates), but also use `getblocktemplate`
> which means the same ancestor package-based mining algorithm.
>
> Of course, I'm not a miner, so if anybody is a miner or has seen miners'
> setups, please correct me if I'm wrong.
>
> In either case, we would want our mining algorithm to result in block
> templates that are as close as possible to perfectly incentive compatibile.
>
> Fundamentally, I believe default mempool policy (which perhaps naturally
> creates a network-wide transaction relay policy) should be as close to the
> mining code as possible. Imagine node A only keeps 1 block's worth of
> transactions, and node B keeps a (default) 300MB mempool. The contents of
> node A's mempool should be as close as possible to a block template
> generated from node B's mempool. Otherwise, node A's mempool is not very
> useful - their fee estimation is flawed and compact block relay won't do
> them much good if they need to re-request a lot of block transactions.
> Next, imagine that node B is a miner. It would be very suboptimal if the
> mining code was ancestor package-based (i.e. supports CPFP), but the
> mempool policy only cared about individual feerate, and evicted low-fee
> parents despite their high-fee children. It's easy to see why this would be
> suboptimal.
> Attempting to match mempool policy with the mining algorithm is also
> arguably the point of package relay. Our mining code uses ancestor packages
> which is good, but we only submit transactions one at a time to the
> mempool, so a transaction's high-fee children can't be considered until
> they are all already in the mempool. Package relay allows us to start
> thinking about ancestor packages immediately when evaluating transactions
> for submission to the mempool.
>
> The attempt to match policy with miner inclusion rules is deliberate and
> necessary.
>
> > I want to echo James O'Beirne's opinion on this that this may be the
> wrong path to go down (a path of more complexity without much gain). He
> said: "Special consideration for "what should be in the next block" and/or
> the caching of block templates seems like an imposing dependency, dragging
> in a bunch of state and infrastructure to a question that should be solely
> limited to mempool feerate aggregates and the feerate of the particular txn
> package a wallet is concerned with."
>
> It seems that I under-explained the purpose of building/caching block
> templates in my original post, since both you and James have the same
> misunderstanding. Since RBF's introduction, we have improved to an ancestor
> package-based mining algorithm. This supports CPFP (incentive compatible)
> and it is now common to see more complex "families" of transactions as
> users fee-bump transactions (market is working, yay). On the other hand, we
> no longer have an accurate way of determining a transaction's "mining
> score," i.e., the feerate of this transaction's ancestor package when it is
> included in a block template using our current mining algorithm.
>
> This limitation is a big blocker in proposing new fee/feerate RBF rules.
> For example, if we say "the transaction needs a better feerate," this is
> obviously flawed, since the original transactions may have very
> high-feerate children, and the replacement transaction may have low feerate
> parents. So what we really want is "the transaction needs to be more
> incentive compatible to mine based on our mining algorithm," but we have no
> way of getting that information right now.
>
> In my original post, I [described 4 heuristics to get transaction's
> "mining score"][1] using the current data cached in the mempool (e.g. max
> ancestor feerate of descendant set), as well as why they don't work. As
> such, the best way to calculate a transaction's mining score AFAICT is to
> grab all of the related transactions and build a mini "block template" with
> them. The [implementation][2] I sent last week also cuts out some of the
> fluff, so the pseudocode looks like this:
>
> // Get ALL connected entries (ancestors, descendants, siblings, cousins,
> coparents, etc.)
> vector<TxMempoolEntry> cluster = mempool.GetAllTransactionsRelatedTo(txid);
> sort(cluster, ancestorfeerate);
>
> // For deducting ancestors when they are included separately
> vector<ModifiedTxMempoolEntry> modified_entries;
>
> while (!cluster.empty() and !modified_entries.empty()) {
> iter = BetterAncestorFeerateOf(cluster, modified_entries);
> best_ancestor_package = GetAncestorSet(iter);
> mining_score = Feerate(best_ancestor_package);
> for (entry : best_ancestor_package) {
> mining_scores[entry] = mining_score;
> for (descendant : GetAllDescendants(entry) {
>
> modified_entries[descendant].DeductAncestorFromAccounting(entry);
> }
> }
> }
>
> Perhaps somebody will come up with a better way to do this, but this is my
> solution, and I hope I've now sufficiently described why I've made an
> effort to think about this. It's not because I want to make things more
> fancy or complicated, but because we currently have no way of accurately
> determining a transaction's mining score. The reason I proposed a
> persistent block template is so we can efficiently query the mining score
> of all transactions in the mempool.
>
> > However, I do think that these DOS concerns are quite overblown. I wrote
> up a comment on your rbf-improvements.md
> <https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4093100#gistcomment-4093100> detailing
> my thought process on that. The summary is that as long as the fee-rate
> relay rule is maintained, any "spam" is actually paid for, either by the
> "first" transaction in the spam chain, or by the "spam" itself.
>
> The DoS concern is not overblown. I recommend you re-read the [current RBF
> policy][3]; Rule 3 and 4 *are* the feerate relay rules. Removing Rule 3
> means allowing recycled fees, so new transactions are not necessarily
> "paying" anything.
>
> [1]:
> https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4093100#mining-score-of-a-mempool-transaction
> [2]: https://github.com/glozow/bitcoin/tree/2022-02-mining-score
> [3]:
> https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
>
> Best,
> Gloria
>
> On Sat, Mar 12, 2022 at 8:18 AM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> In reading through more of the discussion, it seems the idea I presented
>> above might basically be a reformulation of t-bast's rate-limiting idea
>> presented in this comment
>> <https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4081349#gistcomment-4081349>.
>> Perhaps he could comment on whether that characterization is accurate.
>>
>> On Fri, Mar 11, 2022 at 10:22 AM Billy Tetrud <billy.tetrud at gmail.com>
>> wrote:
>>
>>> Hi Gloria,
>>>
>>> > 1. Transaction relay rate limiting
>>>
>>> I have a similar concern as yours, that this could prevent higher
>>> fee-rate transactions from being broadcast.
>>>
>>> > 2. Staggered broadcast of replacement transactions: within some time
>>> interval, maybe accept multiple replacements for the same prevout, but only
>>> relay the original transaction.
>>>
>>> By this do you mean basically having a batching window where, on
>>> receiving a replacement transaction, a node will wait for a period of time,
>>> potentially receiving many replacements for the same transaction (or many
>>> separate conflicting transactions), and only broadcasting the "best" one(s)
>>> at the end of that time window?
>>>
>>> Its an interesting idea, but it would produce a problem. Every hop that
>>> replacement transaction takes would be delayed by this staggered window. If
>>> the window were 3 minutes and transactions generally take 20 hops to get to
>>> the majority of miners, a "best-case average" delay might be 3.75 minutes
>>> (noting that among your 8 nodes, its quite likely one of them would have a
>>> window ending much sooner than 3 minutes). Some (maybe 3% of) nodes would
>>> experience delays of more than 20 minutes. That kind of delay isn't great.
>>>
>>> However it made me think of another idea: a transaction replacement
>>> broadcast cooldown. What if nodes kept track of the time they broadcasted
>>> the last replacement for a package and had a relay cooldown after the last
>>> replacement was broadcasted? A node receiving a replacement would relay the
>>> replacement immediately if the package its replacing was broadcasted more
>>> than X seconds ago, and otherwise it would wait until the time when that
>>> package was broadcasted at least X seconds ago to broadcast it. Any
>>> replacements it receives during that waiting period would replace as
>>> normal, meaning the unrebroadcasted replacement would never be
>>> broadcasted, and only the highest value replacement would be broadcasted at
>>> the end of the cooldown.
>>>
>>> This wouldn't prevent a higher-fee-rate transaction from being
>>> broadcasted (like rate limiting could), but would still be effective at
>>> limiting unnecessary data transmission. Another benefit is that in the
>>> non-adversarial case, replacement transactions wouldn't be subject to any
>>> delay at all (while in the staggered broadcast idea, most replacements
>>> would experience some delay). And in the adversarial case, where a
>>> malicious actor broadcasts a low-as-possible-value replacement just before
>>> yours, the worst case delay is just whatever the cooldown period is. I
>>> would imagine that maybe 1 minute would be a reasonable worst-case delay.
>>> This would limit spam for a transaction that makes it into a block to ~10x
>>> (9 to 1). I don't see much of a downside to doing this beyond just the
>>> slight additional complexity of relay rules (and considering it could save
>>> substantial additional code complexity, even that is a benefit).
>>>
>>> All a node would need to do is keep a timestamp on each transaction they
>>> receive for when it was broadcasted and check it when a replacement comes
>>> in. If now-broadcastDate < cooldown, set a timer for cooldown -
>>> (now-broadcastDate) to broadcast it. If another replacement comes in, clear
>>> that timer and repeat using the original broadcast date (since the
>>> unbroadcast transaction doesn't have a broadcast date yet).
>>>
>>> I think it might also be useful to note that eliminating "extra data"
>>> caused by careless or malicious actors (spam or whatever you want to call
>>> it) should not be the goal. It is impossible to prevent all spam. What we
>>> should be aiming for is more specific: we should attempt to design a system
>>> where spam is manageable. Eg if our goal is to ensure that a bitcoin node
>>> uses no more than 10% of the bandwidth of a "normal" user, if current
>>> non-spam traffic only requires 1% of a "normal" users's bandwidth, then the
>>> network can bear a 9 to 1 ratio of spam. When a node spins up, there is a
>>> lot more data to download and process. So we know that all full nodes can
>>> handle at least as much traffic as they handle during IBD. What's the
>>> difference between those amounts? I'm not sure, but I would guess that IBD
>>> is at least a couple times more demanding than a fully synced node. So I
>>> might suggest that as long as spam can be kept below a ratio of maybe 2 to
>>> 1, we should consider the design acceptable (and therefore more complexity
>>> unnecessary).
>>>
>>> The 1 minute broadcast cooldown I mentioned before wouldn't be quite
>>> sufficient to achieve that ratio. But a 3.33 minute cooldown would be.
>>> Whether this is "too much" is something that would have to be discussed, I
>>> suspect a worst-case adversarial 3.33 minute delay would not be "too much".
>>> Doing this could basically eliminate any risk of actual service denial via
>>> replacement transactions.
>>>
>>> However, I do think that these DOS concerns are quite overblown. I wrote
>>> up a comment on your rbf-improvements.md
>>> <https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4093100#gistcomment-4093100> detailing
>>> my thought process on that. The summary is that as long as the fee-rate
>>> relay rule is maintained, any "spam" is actually paid for, either by the
>>> "first" transaction in the spam chain, or by the "spam" itself. Even
>>> without something like a minimum RBF relay delay limiting how much spam
>>> could be created, the economics of the fee-rate rule already sufficiently
>>> mitigate the issue of spam.
>>> On Wed, Mar 9, 2022 at 9:37 AM Gloria Zhao via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hi RBF friends,
>>>>
>>>> Posting a summary of RBF discussions at coredev (mostly on transaction
>>>> relay rate-limiting), user-elected descendant limit as a short term
>>>> solution to unblock package RBF, and mining score, all open for feedback:
>>>>
>>>> One big concept discussed was baking DoS protection into the p2p level
>>>> rather than policy level. TLDR: The fees are not paid to the node operator,
>>>> but to the miner. While we can use fees to reason about the cost of an
>>>> attack, if we're ultimately interested in preventing resource exhaustion,
>>>> maybe we want to "stop the bleeding" when it happens and bound the amount
>>>> of resources used in general. There were two main ideas:
>>>>
>>>> 1. Transaction relay rate limiting (i.e. the one you proposed above or
>>>> some variation) with a feerate-based priority queue
>>>> 2. Staggered broadcast of replacement transactions: within some time
>>>> interval, maybe accept multiple replacements for the same prevout, but only
>>>> relay the original transaction.
>>>>
>>>> Looking to solicit feedback on these ideas and the concept in general.
>>>> Is it a good idea (separate from RBF) to add rate-limiting in transaction
>>>> relay? And is it the right direction to think about RBF DoS protection this
>>>> way?
>>>>
>>>> A lingering concern that I have about this idea is it would then be
>>>> possible to impact the propagation of another person’s transaction, i.e.,
>>>> an attacker can censor somebody’s transaction from ever being announced by
>>>> a node if they send enough transactions to fill up the rate limit.
>>>> Obviously this would be expensive since they're spending a lot on fees, but
>>>> I imagine it could be profitable in some situations to spend a few thousand
>>>> dollars to prevent anyone from hearing about a transaction for a few hours.
>>>> This might be a non-issue in practice if the rate limit is generous and
>>>> traffic isn’t horrendous, but is this a problem?
>>>>
>>>> And if we don't require an increase in (i.e. addition of "new")
>>>> absolute fees, users are essentially allowed to “recycle” fees. In the
>>>> scenario where we prioritize relay based on feerate, users could
>>>> potentially be placed higher in the queue, ahead of other users’
>>>> transactions, multiple times, without ever adding more fees to the
>>>> transaction. Again, maybe this isn’t a huge deal in practice if we set the
>>>> parameters right, but it seems… not great, in principle.
>>>>
>>>> ---------
>>>>
>>>> It's probably also a good idea to point out that there's been some
>>>> discussion happening on the gist containing my original post on this thread
>>>> (https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff).
>>>>
>>>> Suhas and Matt [proposed][0] adding a policy rule allowing users to
>>>> specify descendant limits on their transactions. For example, some nth bit
>>>> of nSequence with nVersion 3 means "this transaction won't have more than X
>>>> vbytes of descendants" where X = max(1000, vsizeof(tx)) or something. It
>>>> solves the pinning problem with package RBF where the attacker's package
>>>> contains a very large and high-fee descendant.
>>>>
>>>> We could add this policy and deploy it with package RBF/package relay
>>>> so that LN can use it by setting the user-elected descendant limit flag on
>>>> commitment transactions. (Otherwise package RBF is blocked until we find a
>>>> more comprehensive solution to the pinning attack).
>>>>
>>>> It's simple to [implement][1] as a mempool policy, but adds some
>>>> complexity for wallets that use it, since it limits their use of UTXOs from
>>>> transactions with this bit set.
>>>>
>>>> ---------
>>>>
>>>> Also, coming back to the idea of "we can't just use {individual,
>>>> ancestor} feerate," I'm interested in soliciting feedback on adding a
>>>> “mining score” calculator. I've implemented one [here][2] which takes the
>>>> transaction in question, grabs all of the connected mempool transactions
>>>> (including siblings, coparents, etc., as they wouldn’t be in the ancestor
>>>> nor descendant sets), and builds a “block template” using our current
>>>> mining algorithm. The mining score of a transaction is the ancestor feerate
>>>> at which it is included.
>>>>
>>>> This would be helpful for something like ancestor-aware funding and
>>>> fee-bumping in the wallet: [3], [4]. I think if we did the rate-limited
>>>> priority queue for transaction relay, we'd want to use something like this
>>>> as the priority value. And for RBF, we probably want to require that a
>>>> replacement have a higher mining score than the original transactions. This
>>>> could be computationally expensive to do all the time; it could be good to
>>>> cache it but that could make mempool bookkeeping more complicated. Also, if
>>>> we end up trying to switch to a candidate set-based algorithm for mining,
>>>> we'd of course need a new calculator.
>>>>
>>>> [0]:
>>>> https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4058140#gistcomment-4058140
>>>> [1]: https://github.com/glozow/bitcoin/tree/2022-02-user-desclimit
>>>> [2] https://github.com/glozow/bitcoin/tree/2022-02-mining-score
>>>> [3]: https://github.com/bitcoin/bitcoin/issues/9645
>>>> [4]: https://github.com/bitcoin/bitcoin/issues/15553
>>>>
>>>> Best,
>>>> Gloria
>>>>
>>>> On Tue, Feb 8, 2022 at 4:58 AM Anthony Towns <aj at erisian.com.au> wrote:
>>>>
>>>>> On Mon, Feb 07, 2022 at 11:16:26AM +0000, Gloria Zhao wrote:
>>>>> > @aj:
>>>>> > > I wonder sometimes if it could be sufficient to just have a relay
>>>>> rate
>>>>> > > limit and prioritise by ancestor feerate though. Maybe something
>>>>> like:
>>>>> > > - instead of adding txs to each peers setInventoryTxToSend
>>>>> immediately,
>>>>> > > set a mempool flag "relayed=false"
>>>>> > > - on a time delay, add the top N (by fee rate) "relayed=false" txs
>>>>> to
>>>>> > > each peer's setInventoryTxToSend and mark them as "relayed=true";
>>>>> > > calculate how much kB those txs were, and do this again after
>>>>> > > SIZE/RATELIMIT seconds
>>>>>
>>>>> > > - don't include "relayed=false" txs when building blocks?
>>>>>
>>>>> The "?" was me not being sure that point is a good suggestion...
>>>>>
>>>>> Miners might reasonably decide to have no rate limit, and always relay,
>>>>> and never exclude txs -- but the question then becomes is whether they
>>>>> hear about the tx at all, so rate limiting behaviour could still be a
>>>>> potential problem for whoever made the tx.
>>>>>
>>>>> > Wow cool! I think outbound tx relay size-based rate-limiting and
>>>>> > prioritizing tx relay by feerate are great ideas for preventing
>>>>> spammers
>>>>> > from wasting bandwidth network-wide. I agree, this would slow the low
>>>>> > feerate spam down, preventing a huge network-wide bandwidth spike.
>>>>> And it
>>>>> > would allow high feerate transactions to propagate as they should,
>>>>> > regardless of how busy traffic is. Combined with inbound tx request
>>>>> > rate-limiting, might this be sufficient to prevent DoS regardless of
>>>>> the
>>>>> > fee-based replacement policies?
>>>>>
>>>>> I think you only want to do outbound rate limits, ie, how often you
>>>>> send
>>>>> INV, GETDATA and TX messages? Once you receive any of those, I think
>>>>> you have to immediately process / ignore it, you can't really sensibly
>>>>> defer it (beyond the existing queues we have that just build up while
>>>>> we're busy processing other things first)?
>>>>>
>>>>> > One point that I'm not 100% clear on: is it ok to prioritize the
>>>>> > transactions by ancestor feerate in this scheme? As I described in
>>>>> the
>>>>> > original post, this can be quite different from the actual feerate
>>>>> we would
>>>>> > consider a transaction in a block for. The transaction could have a
>>>>> high
>>>>> > feerate sibling bumping its ancestor.
>>>>> > For example, A (1sat/vB) has 2 children: B (49sat/vB) and C
>>>>> (5sat/vB). If
>>>>> > we just received C, it would be incorrect to give it a priority
>>>>> equal to
>>>>> > its ancestor feerate (3sat/vB) because if we constructed a block
>>>>> template
>>>>> > now, B would bump A, and C's new ancestor feerate is 5sat/vB.
>>>>> > Then, if we imagine that top N is >5sat/vB, we're not relaying C. If
>>>>> we
>>>>> > also exclude C when building blocks, we're missing out on good fees.
>>>>>
>>>>> I think you're right that this would be ugly. It's something of a
>>>>> special case:
>>>>>
>>>>> a) you really care about C getting into the next block; but
>>>>> b) you're trusting B not being replaced by a higher fee tx that
>>>>> doesn't have A as a parent; and
>>>>> c) there's a lot of txs bidding the floor of the next block up to a
>>>>> level in-between the ancestor fee rate of 3sat/vB and the tx fee
>>>>> rate of 5sat/vB
>>>>>
>>>>> Without (a), maybe you don't care about it getting to a miner quickly.
>>>>> If your trust in (b) was misplaced, then your tx's effective fee rate
>>>>> will drop and (because of (c)), you'll lose anyway. And if the spam
>>>>> ends
>>>>> up outside of (c)'s range, either the rate limiting won't take effect
>>>>> (spam's too cheap) and you'll be fine, or you'll miss out on the block
>>>>> anyway (spam's paying more than your tx rate) and you never had any
>>>>> hope
>>>>> of making it in.
>>>>>
>>>>> Note that we already rate limit via INVENTORY_BROADCAST_MAX /
>>>>> *_INVENTORY_BROADCAST_INTERVAL; which gets to something like 10,500 txs
>>>>> per 10 minutes for outbound connections. This would be a weight based
>>>>> rate limit instead-of/in-addition-to that, I guess.
>>>>>
>>>>> As far as a non-ugly approach goes, I think you'd have to be smarter
>>>>> about
>>>>> tracking the "effective fee rate" than the ancestor fee rate manages;
>>>>> maybe that's something that could fall out of Murch and Clara's
>>>>> candidate
>>>>> set blockbuilding ideas [0] ?
>>>>>
>>>>> Perhaps that same work would also make it possible to come up with
>>>>> a better answer to "do I care that this replacement would invalidate
>>>>> these descendents?"
>>>>>
>>>>> [0] https://github.com/Xekyo/blockbuilding
>>>>>
>>>>> > > - keep high-feerate evicted txs around for a while in case they get
>>>>> > > mined by someone else to improve compact block relay, a la the
>>>>> > > orphan pool?
>>>>> > Replaced transactions are already added to vExtraTxnForCompact :D
>>>>>
>>>>> I guess I was thinking that it's just a 100 tx LRU cache, which might
>>>>> not be good enough?
>>>>>
>>>>> Maybe it would be more on point to have a rate limit apply only to
>>>>> replacement transactions?
>>>>>
>>>>> > For wallets, AJ's "All you need is for there to be *a* path that
>>>>> follows
>>>>> > the new relay rules and gets from your node/wallet to perhaps 10% of
>>>>> > hashpower" makes sense to me (which would be the former).
>>>>>
>>>>> Perhaps a corollarly of that is that it's *better* to have the mempool
>>>>> acceptance rule only consider economic incentives, and have the spam
>>>>> prevention only be about "shall I tell my peers about this?"
>>>>>
>>>>> If you don't have that split; then the anti-spam rules can prevent you
>>>>> from getting the tx in the mempool at all; whereas if you do have the
>>>>> split, then even if the bitcoind anti-spam rules are blocking you at
>>>>> every turn, you can still send your tx to miners by some other route,
>>>>> and then they can add it to their mempool directly without any hassle.
>>>>>
>>>>> Cheers,
>>>>> aj
>>>>>
>>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220314/a77ad21d/attachment-0001.html>

2023-06-07 23:05:54

- reply

📅 Original date posted:2022-03-12
📝 Original message:In reading through more of the discussion, it seems the idea I presented
above might basically be a reformulation of t-bast's rate-limiting idea
presented in this comment
<https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4081349#gistcomment-4081349>.
Perhaps he could comment on whether that characterization is accurate.
On Fri, Mar 11, 2022 at 10:22 AM Billy Tetrud <billy.tetrud at gmail.com>
wrote:
> Hi Gloria,
>
> > 1. Transaction relay rate limiting
>
> I have a similar concern as yours, that this could prevent higher fee-rate
> transactions from being broadcast.
>
> > 2. Staggered broadcast of replacement transactions: within some time
> interval, maybe accept multiple replacements for the same prevout, but only
> relay the original transaction.
>
> By this do you mean basically having a batching window where, on receiving
> a replacement transaction, a node will wait for a period of time,
> potentially receiving many replacements for the same transaction (or many
> separate conflicting transactions), and only broadcasting the "best" one(s)
> at the end of that time window?
>
> Its an interesting idea, but it would produce a problem. Every hop that
> replacement transaction takes would be delayed by this staggered window. If
> the window were 3 minutes and transactions generally take 20 hops to get to
> the majority of miners, a "best-case average" delay might be 3.75 minutes
> (noting that among your 8 nodes, its quite likely one of them would have a
> window ending much sooner than 3 minutes). Some (maybe 3% of) nodes would
> experience delays of more than 20 minutes. That kind of delay isn't great.
>
> However it made me think of another idea: a transaction replacement
> broadcast cooldown. What if nodes kept track of the time they broadcasted
> the last replacement for a package and had a relay cooldown after the last
> replacement was broadcasted? A node receiving a replacement would relay the
> replacement immediately if the package its replacing was broadcasted more
> than X seconds ago, and otherwise it would wait until the time when that
> package was broadcasted at least X seconds ago to broadcast it. Any
> replacements it receives during that waiting period would replace as
> normal, meaning the unrebroadcasted replacement would never be
> broadcasted, and only the highest value replacement would be broadcasted at
> the end of the cooldown.
>
> This wouldn't prevent a higher-fee-rate transaction from being broadcasted
> (like rate limiting could), but would still be effective at limiting
> unnecessary data transmission. Another benefit is that in the
> non-adversarial case, replacement transactions wouldn't be subject to any
> delay at all (while in the staggered broadcast idea, most replacements
> would experience some delay). And in the adversarial case, where a
> malicious actor broadcasts a low-as-possible-value replacement just before
> yours, the worst case delay is just whatever the cooldown period is. I
> would imagine that maybe 1 minute would be a reasonable worst-case delay.
> This would limit spam for a transaction that makes it into a block to ~10x
> (9 to 1). I don't see much of a downside to doing this beyond just the
> slight additional complexity of relay rules (and considering it could save
> substantial additional code complexity, even that is a benefit).
>
> All a node would need to do is keep a timestamp on each transaction they
> receive for when it was broadcasted and check it when a replacement comes
> in. If now-broadcastDate < cooldown, set a timer for cooldown -
> (now-broadcastDate) to broadcast it. If another replacement comes in, clear
> that timer and repeat using the original broadcast date (since the
> unbroadcast transaction doesn't have a broadcast date yet).
>
> I think it might also be useful to note that eliminating "extra data"
> caused by careless or malicious actors (spam or whatever you want to call
> it) should not be the goal. It is impossible to prevent all spam. What we
> should be aiming for is more specific: we should attempt to design a system
> where spam is manageable. Eg if our goal is to ensure that a bitcoin node
> uses no more than 10% of the bandwidth of a "normal" user, if current
> non-spam traffic only requires 1% of a "normal" users's bandwidth, then the
> network can bear a 9 to 1 ratio of spam. When a node spins up, there is a
> lot more data to download and process. So we know that all full nodes can
> handle at least as much traffic as they handle during IBD. What's the
> difference between those amounts? I'm not sure, but I would guess that IBD
> is at least a couple times more demanding than a fully synced node. So I
> might suggest that as long as spam can be kept below a ratio of maybe 2 to
> 1, we should consider the design acceptable (and therefore more complexity
> unnecessary).
>
> The 1 minute broadcast cooldown I mentioned before wouldn't be quite
> sufficient to achieve that ratio. But a 3.33 minute cooldown would be.
> Whether this is "too much" is something that would have to be discussed, I
> suspect a worst-case adversarial 3.33 minute delay would not be "too much".
> Doing this could basically eliminate any risk of actual service denial via
> replacement transactions.
>
> However, I do think that these DOS concerns are quite overblown. I wrote
> up a comment on your rbf-improvements.md
> <https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4093100#gistcomment-4093100> detailing
> my thought process on that. The summary is that as long as the fee-rate
> relay rule is maintained, any "spam" is actually paid for, either by the
> "first" transaction in the spam chain, or by the "spam" itself. Even
> without something like a minimum RBF relay delay limiting how much spam
> could be created, the economics of the fee-rate rule already sufficiently
> mitigate the issue of spam.
> On Wed, Mar 9, 2022 at 9:37 AM Gloria Zhao via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi RBF friends,
>>
>> Posting a summary of RBF discussions at coredev (mostly on transaction
>> relay rate-limiting), user-elected descendant limit as a short term
>> solution to unblock package RBF, and mining score, all open for feedback:
>>
>> One big concept discussed was baking DoS protection into the p2p level
>> rather than policy level. TLDR: The fees are not paid to the node operator,
>> but to the miner. While we can use fees to reason about the cost of an
>> attack, if we're ultimately interested in preventing resource exhaustion,
>> maybe we want to "stop the bleeding" when it happens and bound the amount
>> of resources used in general. There were two main ideas:
>>
>> 1. Transaction relay rate limiting (i.e. the one you proposed above or
>> some variation) with a feerate-based priority queue
>> 2. Staggered broadcast of replacement transactions: within some time
>> interval, maybe accept multiple replacements for the same prevout, but only
>> relay the original transaction.
>>
>> Looking to solicit feedback on these ideas and the concept in general. Is
>> it a good idea (separate from RBF) to add rate-limiting in transaction
>> relay? And is it the right direction to think about RBF DoS protection this
>> way?
>>
>> A lingering concern that I have about this idea is it would then be
>> possible to impact the propagation of another person’s transaction, i.e.,
>> an attacker can censor somebody’s transaction from ever being announced by
>> a node if they send enough transactions to fill up the rate limit.
>> Obviously this would be expensive since they're spending a lot on fees, but
>> I imagine it could be profitable in some situations to spend a few thousand
>> dollars to prevent anyone from hearing about a transaction for a few hours.
>> This might be a non-issue in practice if the rate limit is generous and
>> traffic isn’t horrendous, but is this a problem?
>>
>> And if we don't require an increase in (i.e. addition of "new") absolute
>> fees, users are essentially allowed to “recycle” fees. In the scenario
>> where we prioritize relay based on feerate, users could potentially be
>> placed higher in the queue, ahead of other users’ transactions, multiple
>> times, without ever adding more fees to the transaction. Again, maybe this
>> isn’t a huge deal in practice if we set the parameters right, but it seems…
>> not great, in principle.
>>
>> ---------
>>
>> It's probably also a good idea to point out that there's been some
>> discussion happening on the gist containing my original post on this thread
>> (https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff).
>>
>> Suhas and Matt [proposed][0] adding a policy rule allowing users to
>> specify descendant limits on their transactions. For example, some nth bit
>> of nSequence with nVersion 3 means "this transaction won't have more than X
>> vbytes of descendants" where X = max(1000, vsizeof(tx)) or something. It
>> solves the pinning problem with package RBF where the attacker's package
>> contains a very large and high-fee descendant.
>>
>> We could add this policy and deploy it with package RBF/package relay so
>> that LN can use it by setting the user-elected descendant limit flag on
>> commitment transactions. (Otherwise package RBF is blocked until we find a
>> more comprehensive solution to the pinning attack).
>>
>> It's simple to [implement][1] as a mempool policy, but adds some
>> complexity for wallets that use it, since it limits their use of UTXOs from
>> transactions with this bit set.
>>
>> ---------
>>
>> Also, coming back to the idea of "we can't just use {individual,
>> ancestor} feerate," I'm interested in soliciting feedback on adding a
>> “mining score” calculator. I've implemented one [here][2] which takes the
>> transaction in question, grabs all of the connected mempool transactions
>> (including siblings, coparents, etc., as they wouldn’t be in the ancestor
>> nor descendant sets), and builds a “block template” using our current
>> mining algorithm. The mining score of a transaction is the ancestor feerate
>> at which it is included.
>>
>> This would be helpful for something like ancestor-aware funding and
>> fee-bumping in the wallet: [3], [4]. I think if we did the rate-limited
>> priority queue for transaction relay, we'd want to use something like this
>> as the priority value. And for RBF, we probably want to require that a
>> replacement have a higher mining score than the original transactions. This
>> could be computationally expensive to do all the time; it could be good to
>> cache it but that could make mempool bookkeeping more complicated. Also, if
>> we end up trying to switch to a candidate set-based algorithm for mining,
>> we'd of course need a new calculator.
>>
>> [0]:
>> https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4058140#gistcomment-4058140
>> [1]: https://github.com/glozow/bitcoin/tree/2022-02-user-desclimit
>> [2] https://github.com/glozow/bitcoin/tree/2022-02-mining-score
>> [3]: https://github.com/bitcoin/bitcoin/issues/9645
>> [4]: https://github.com/bitcoin/bitcoin/issues/15553
>>
>> Best,
>> Gloria
>>
>> On Tue, Feb 8, 2022 at 4:58 AM Anthony Towns <aj at erisian.com.au> wrote:
>>
>>> On Mon, Feb 07, 2022 at 11:16:26AM +0000, Gloria Zhao wrote:
>>> > @aj:
>>> > > I wonder sometimes if it could be sufficient to just have a relay
>>> rate
>>> > > limit and prioritise by ancestor feerate though. Maybe something
>>> like:
>>> > > - instead of adding txs to each peers setInventoryTxToSend
>>> immediately,
>>> > > set a mempool flag "relayed=false"
>>> > > - on a time delay, add the top N (by fee rate) "relayed=false" txs to
>>> > > each peer's setInventoryTxToSend and mark them as "relayed=true";
>>> > > calculate how much kB those txs were, and do this again after
>>> > > SIZE/RATELIMIT seconds
>>>
>>> > > - don't include "relayed=false" txs when building blocks?
>>>
>>> The "?" was me not being sure that point is a good suggestion...
>>>
>>> Miners might reasonably decide to have no rate limit, and always relay,
>>> and never exclude txs -- but the question then becomes is whether they
>>> hear about the tx at all, so rate limiting behaviour could still be a
>>> potential problem for whoever made the tx.
>>>
>>> > Wow cool! I think outbound tx relay size-based rate-limiting and
>>> > prioritizing tx relay by feerate are great ideas for preventing
>>> spammers
>>> > from wasting bandwidth network-wide. I agree, this would slow the low
>>> > feerate spam down, preventing a huge network-wide bandwidth spike. And
>>> it
>>> > would allow high feerate transactions to propagate as they should,
>>> > regardless of how busy traffic is. Combined with inbound tx request
>>> > rate-limiting, might this be sufficient to prevent DoS regardless of
>>> the
>>> > fee-based replacement policies?
>>>
>>> I think you only want to do outbound rate limits, ie, how often you send
>>> INV, GETDATA and TX messages? Once you receive any of those, I think
>>> you have to immediately process / ignore it, you can't really sensibly
>>> defer it (beyond the existing queues we have that just build up while
>>> we're busy processing other things first)?
>>>
>>> > One point that I'm not 100% clear on: is it ok to prioritize the
>>> > transactions by ancestor feerate in this scheme? As I described in the
>>> > original post, this can be quite different from the actual feerate we
>>> would
>>> > consider a transaction in a block for. The transaction could have a
>>> high
>>> > feerate sibling bumping its ancestor.
>>> > For example, A (1sat/vB) has 2 children: B (49sat/vB) and C (5sat/vB).
>>> If
>>> > we just received C, it would be incorrect to give it a priority equal
>>> to
>>> > its ancestor feerate (3sat/vB) because if we constructed a block
>>> template
>>> > now, B would bump A, and C's new ancestor feerate is 5sat/vB.
>>> > Then, if we imagine that top N is >5sat/vB, we're not relaying C. If we
>>> > also exclude C when building blocks, we're missing out on good fees.
>>>
>>> I think you're right that this would be ugly. It's something of a
>>> special case:
>>>
>>> a) you really care about C getting into the next block; but
>>> b) you're trusting B not being replaced by a higher fee tx that
>>> doesn't have A as a parent; and
>>> c) there's a lot of txs bidding the floor of the next block up to a
>>> level in-between the ancestor fee rate of 3sat/vB and the tx fee
>>> rate of 5sat/vB
>>>
>>> Without (a), maybe you don't care about it getting to a miner quickly.
>>> If your trust in (b) was misplaced, then your tx's effective fee rate
>>> will drop and (because of (c)), you'll lose anyway. And if the spam ends
>>> up outside of (c)'s range, either the rate limiting won't take effect
>>> (spam's too cheap) and you'll be fine, or you'll miss out on the block
>>> anyway (spam's paying more than your tx rate) and you never had any hope
>>> of making it in.
>>>
>>> Note that we already rate limit via INVENTORY_BROADCAST_MAX /
>>> *_INVENTORY_BROADCAST_INTERVAL; which gets to something like 10,500 txs
>>> per 10 minutes for outbound connections. This would be a weight based
>>> rate limit instead-of/in-addition-to that, I guess.
>>>
>>> As far as a non-ugly approach goes, I think you'd have to be smarter
>>> about
>>> tracking the "effective fee rate" than the ancestor fee rate manages;
>>> maybe that's something that could fall out of Murch and Clara's candidate
>>> set blockbuilding ideas [0] ?
>>>
>>> Perhaps that same work would also make it possible to come up with
>>> a better answer to "do I care that this replacement would invalidate
>>> these descendents?"
>>>
>>> [0] https://github.com/Xekyo/blockbuilding
>>>
>>> > > - keep high-feerate evicted txs around for a while in case they get
>>> > > mined by someone else to improve compact block relay, a la the
>>> > > orphan pool?
>>> > Replaced transactions are already added to vExtraTxnForCompact :D
>>>
>>> I guess I was thinking that it's just a 100 tx LRU cache, which might
>>> not be good enough?
>>>
>>> Maybe it would be more on point to have a rate limit apply only to
>>> replacement transactions?
>>>
>>> > For wallets, AJ's "All you need is for there to be *a* path that
>>> follows
>>> > the new relay rules and gets from your node/wallet to perhaps 10% of
>>> > hashpower" makes sense to me (which would be the former).
>>>
>>> Perhaps a corollarly of that is that it's *better* to have the mempool
>>> acceptance rule only consider economic incentives, and have the spam
>>> prevention only be about "shall I tell my peers about this?"
>>>
>>> If you don't have that split; then the anti-spam rules can prevent you
>>> from getting the tx in the mempool at all; whereas if you do have the
>>> split, then even if the bitcoind anti-spam rules are blocking you at
>>> every turn, you can still send your tx to miners by some other route,
>>> and then they can add it to their mempool directly without any hassle.
>>>
>>> Cheers,
>>> aj
>>>
>>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220312/f3ede5ed/attachment-0001.html>

2023-06-07 23:05:54

- reply

📅 Original date posted:2022-03-11
📝 Original message:Hi Gloria,
> 1. Transaction relay rate limiting
I have a similar concern as yours, that this could prevent higher fee-rate
transactions from being broadcast.
> 2. Staggered broadcast of replacement transactions: within some time
interval, maybe accept multiple replacements for the same prevout, but only
relay the original transaction.
By this do you mean basically having a batching window where, on receiving
a replacement transaction, a node will wait for a period of time,
potentially receiving many replacements for the same transaction (or many
separate conflicting transactions), and only broadcasting the "best" one(s)
at the end of that time window?
Its an interesting idea, but it would produce a problem. Every hop that
replacement transaction takes would be delayed by this staggered window. If
the window were 3 minutes and transactions generally take 20 hops to get to
the majority of miners, a "best-case average" delay might be 3.75 minutes
(noting that among your 8 nodes, its quite likely one of them would have a
window ending much sooner than 3 minutes). Some (maybe 3% of) nodes would
experience delays of more than 20 minutes. That kind of delay isn't great.
However it made me think of another idea: a transaction replacement
broadcast cooldown. What if nodes kept track of the time they broadcasted
the last replacement for a package and had a relay cooldown after the last
replacement was broadcasted? A node receiving a replacement would relay the
replacement immediately if the package its replacing was broadcasted more
than X seconds ago, and otherwise it would wait until the time when that
package was broadcasted at least X seconds ago to broadcast it. Any
replacements it receives during that waiting period would replace as
normal, meaning the unrebroadcasted replacement would never be
broadcasted, and only the highest value replacement would be broadcasted at
the end of the cooldown.
This wouldn't prevent a higher-fee-rate transaction from being broadcasted
(like rate limiting could), but would still be effective at limiting
unnecessary data transmission. Another benefit is that in the
non-adversarial case, replacement transactions wouldn't be subject to any
delay at all (while in the staggered broadcast idea, most replacements
would experience some delay). And in the adversarial case, where a
malicious actor broadcasts a low-as-possible-value replacement just before
yours, the worst case delay is just whatever the cooldown period is. I
would imagine that maybe 1 minute would be a reasonable worst-case delay.
This would limit spam for a transaction that makes it into a block to ~10x
(9 to 1). I don't see much of a downside to doing this beyond just the
slight additional complexity of relay rules (and considering it could save
substantial additional code complexity, even that is a benefit).
All a node would need to do is keep a timestamp on each transaction they
receive for when it was broadcasted and check it when a replacement comes
in. If now-broadcastDate < cooldown, set a timer for cooldown -
(now-broadcastDate) to broadcast it. If another replacement comes in, clear
that timer and repeat using the original broadcast date (since the
unbroadcast transaction doesn't have a broadcast date yet).
I think it might also be useful to note that eliminating "extra data"
caused by careless or malicious actors (spam or whatever you want to call
it) should not be the goal. It is impossible to prevent all spam. What we
should be aiming for is more specific: we should attempt to design a system
where spam is manageable. Eg if our goal is to ensure that a bitcoin node
uses no more than 10% of the bandwidth of a "normal" user, if current
non-spam traffic only requires 1% of a "normal" users's bandwidth, then the
network can bear a 9 to 1 ratio of spam. When a node spins up, there is a
lot more data to download and process. So we know that all full nodes can
handle at least as much traffic as they handle during IBD. What's the
difference between those amounts? I'm not sure, but I would guess that IBD
is at least a couple times more demanding than a fully synced node. So I
might suggest that as long as spam can be kept below a ratio of maybe 2 to
1, we should consider the design acceptable (and therefore more complexity
unnecessary).
The 1 minute broadcast cooldown I mentioned before wouldn't be quite
sufficient to achieve that ratio. But a 3.33 minute cooldown would be.
Whether this is "too much" is something that would have to be discussed, I
suspect a worst-case adversarial 3.33 minute delay would not be "too much".
Doing this could basically eliminate any risk of actual service denial via
replacement transactions.
However, I do think that these DOS concerns are quite overblown. I wrote up a
comment on your rbf-improvements.md
<https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4093100#gistcomment-4093100>
detailing
my thought process on that. The summary is that as long as the fee-rate
relay rule is maintained, any "spam" is actually paid for, either by the
"first" transaction in the spam chain, or by the "spam" itself. Even
without something like a minimum RBF relay delay limiting how much spam
could be created, the economics of the fee-rate rule already sufficiently
mitigate the issue of spam.
On Wed, Mar 9, 2022 at 9:37 AM Gloria Zhao via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi RBF friends,
>
> Posting a summary of RBF discussions at coredev (mostly on transaction
> relay rate-limiting), user-elected descendant limit as a short term
> solution to unblock package RBF, and mining score, all open for feedback:
>
> One big concept discussed was baking DoS protection into the p2p level
> rather than policy level. TLDR: The fees are not paid to the node operator,
> but to the miner. While we can use fees to reason about the cost of an
> attack, if we're ultimately interested in preventing resource exhaustion,
> maybe we want to "stop the bleeding" when it happens and bound the amount
> of resources used in general. There were two main ideas:
>
> 1. Transaction relay rate limiting (i.e. the one you proposed above or
> some variation) with a feerate-based priority queue
> 2. Staggered broadcast of replacement transactions: within some time
> interval, maybe accept multiple replacements for the same prevout, but only
> relay the original transaction.
>
> Looking to solicit feedback on these ideas and the concept in general. Is
> it a good idea (separate from RBF) to add rate-limiting in transaction
> relay? And is it the right direction to think about RBF DoS protection this
> way?
>
> A lingering concern that I have about this idea is it would then be
> possible to impact the propagation of another person’s transaction, i.e.,
> an attacker can censor somebody’s transaction from ever being announced by
> a node if they send enough transactions to fill up the rate limit.
> Obviously this would be expensive since they're spending a lot on fees, but
> I imagine it could be profitable in some situations to spend a few thousand
> dollars to prevent anyone from hearing about a transaction for a few hours.
> This might be a non-issue in practice if the rate limit is generous and
> traffic isn’t horrendous, but is this a problem?
>
> And if we don't require an increase in (i.e. addition of "new") absolute
> fees, users are essentially allowed to “recycle” fees. In the scenario
> where we prioritize relay based on feerate, users could potentially be
> placed higher in the queue, ahead of other users’ transactions, multiple
> times, without ever adding more fees to the transaction. Again, maybe this
> isn’t a huge deal in practice if we set the parameters right, but it seems…
> not great, in principle.
>
> ---------
>
> It's probably also a good idea to point out that there's been some
> discussion happening on the gist containing my original post on this thread
> (https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff).
>
> Suhas and Matt [proposed][0] adding a policy rule allowing users to
> specify descendant limits on their transactions. For example, some nth bit
> of nSequence with nVersion 3 means "this transaction won't have more than X
> vbytes of descendants" where X = max(1000, vsizeof(tx)) or something. It
> solves the pinning problem with package RBF where the attacker's package
> contains a very large and high-fee descendant.
>
> We could add this policy and deploy it with package RBF/package relay so
> that LN can use it by setting the user-elected descendant limit flag on
> commitment transactions. (Otherwise package RBF is blocked until we find a
> more comprehensive solution to the pinning attack).
>
> It's simple to [implement][1] as a mempool policy, but adds some
> complexity for wallets that use it, since it limits their use of UTXOs from
> transactions with this bit set.
>
> ---------
>
> Also, coming back to the idea of "we can't just use {individual, ancestor}
> feerate," I'm interested in soliciting feedback on adding a “mining score”
> calculator. I've implemented one [here][2] which takes the transaction in
> question, grabs all of the connected mempool transactions (including
> siblings, coparents, etc., as they wouldn’t be in the ancestor nor
> descendant sets), and builds a “block template” using our current mining
> algorithm. The mining score of a transaction is the ancestor feerate at
> which it is included.
>
> This would be helpful for something like ancestor-aware funding and
> fee-bumping in the wallet: [3], [4]. I think if we did the rate-limited
> priority queue for transaction relay, we'd want to use something like this
> as the priority value. And for RBF, we probably want to require that a
> replacement have a higher mining score than the original transactions. This
> could be computationally expensive to do all the time; it could be good to
> cache it but that could make mempool bookkeeping more complicated. Also, if
> we end up trying to switch to a candidate set-based algorithm for mining,
> we'd of course need a new calculator.
>
> [0]:
> https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4058140#gistcomment-4058140
> [1]: https://github.com/glozow/bitcoin/tree/2022-02-user-desclimit
> [2] https://github.com/glozow/bitcoin/tree/2022-02-mining-score
> [3]: https://github.com/bitcoin/bitcoin/issues/9645
> [4]: https://github.com/bitcoin/bitcoin/issues/15553
>
> Best,
> Gloria
>
> On Tue, Feb 8, 2022 at 4:58 AM Anthony Towns <aj at erisian.com.au> wrote:
>
>> On Mon, Feb 07, 2022 at 11:16:26AM +0000, Gloria Zhao wrote:
>> > @aj:
>> > > I wonder sometimes if it could be sufficient to just have a relay rate
>> > > limit and prioritise by ancestor feerate though. Maybe something like:
>> > > - instead of adding txs to each peers setInventoryTxToSend
>> immediately,
>> > > set a mempool flag "relayed=false"
>> > > - on a time delay, add the top N (by fee rate) "relayed=false" txs to
>> > > each peer's setInventoryTxToSend and mark them as "relayed=true";
>> > > calculate how much kB those txs were, and do this again after
>> > > SIZE/RATELIMIT seconds
>>
>> > > - don't include "relayed=false" txs when building blocks?
>>
>> The "?" was me not being sure that point is a good suggestion...
>>
>> Miners might reasonably decide to have no rate limit, and always relay,
>> and never exclude txs -- but the question then becomes is whether they
>> hear about the tx at all, so rate limiting behaviour could still be a
>> potential problem for whoever made the tx.
>>
>> > Wow cool! I think outbound tx relay size-based rate-limiting and
>> > prioritizing tx relay by feerate are great ideas for preventing spammers
>> > from wasting bandwidth network-wide. I agree, this would slow the low
>> > feerate spam down, preventing a huge network-wide bandwidth spike. And
>> it
>> > would allow high feerate transactions to propagate as they should,
>> > regardless of how busy traffic is. Combined with inbound tx request
>> > rate-limiting, might this be sufficient to prevent DoS regardless of the
>> > fee-based replacement policies?
>>
>> I think you only want to do outbound rate limits, ie, how often you send
>> INV, GETDATA and TX messages? Once you receive any of those, I think
>> you have to immediately process / ignore it, you can't really sensibly
>> defer it (beyond the existing queues we have that just build up while
>> we're busy processing other things first)?
>>
>> > One point that I'm not 100% clear on: is it ok to prioritize the
>> > transactions by ancestor feerate in this scheme? As I described in the
>> > original post, this can be quite different from the actual feerate we
>> would
>> > consider a transaction in a block for. The transaction could have a high
>> > feerate sibling bumping its ancestor.
>> > For example, A (1sat/vB) has 2 children: B (49sat/vB) and C (5sat/vB).
>> If
>> > we just received C, it would be incorrect to give it a priority equal to
>> > its ancestor feerate (3sat/vB) because if we constructed a block
>> template
>> > now, B would bump A, and C's new ancestor feerate is 5sat/vB.
>> > Then, if we imagine that top N is >5sat/vB, we're not relaying C. If we
>> > also exclude C when building blocks, we're missing out on good fees.
>>
>> I think you're right that this would be ugly. It's something of a
>> special case:
>>
>> a) you really care about C getting into the next block; but
>> b) you're trusting B not being replaced by a higher fee tx that
>> doesn't have A as a parent; and
>> c) there's a lot of txs bidding the floor of the next block up to a
>> level in-between the ancestor fee rate of 3sat/vB and the tx fee
>> rate of 5sat/vB
>>
>> Without (a), maybe you don't care about it getting to a miner quickly.
>> If your trust in (b) was misplaced, then your tx's effective fee rate
>> will drop and (because of (c)), you'll lose anyway. And if the spam ends
>> up outside of (c)'s range, either the rate limiting won't take effect
>> (spam's too cheap) and you'll be fine, or you'll miss out on the block
>> anyway (spam's paying more than your tx rate) and you never had any hope
>> of making it in.
>>
>> Note that we already rate limit via INVENTORY_BROADCAST_MAX /
>> *_INVENTORY_BROADCAST_INTERVAL; which gets to something like 10,500 txs
>> per 10 minutes for outbound connections. This would be a weight based
>> rate limit instead-of/in-addition-to that, I guess.
>>
>> As far as a non-ugly approach goes, I think you'd have to be smarter about
>> tracking the "effective fee rate" than the ancestor fee rate manages;
>> maybe that's something that could fall out of Murch and Clara's candidate
>> set blockbuilding ideas [0] ?
>>
>> Perhaps that same work would also make it possible to come up with
>> a better answer to "do I care that this replacement would invalidate
>> these descendents?"
>>
>> [0] https://github.com/Xekyo/blockbuilding
>>
>> > > - keep high-feerate evicted txs around for a while in case they get
>> > > mined by someone else to improve compact block relay, a la the
>> > > orphan pool?
>> > Replaced transactions are already added to vExtraTxnForCompact :D
>>
>> I guess I was thinking that it's just a 100 tx LRU cache, which might
>> not be good enough?
>>
>> Maybe it would be more on point to have a rate limit apply only to
>> replacement transactions?
>>
>> > For wallets, AJ's "All you need is for there to be *a* path that follows
>> > the new relay rules and gets from your node/wallet to perhaps 10% of
>> > hashpower" makes sense to me (which would be the former).
>>
>> Perhaps a corollarly of that is that it's *better* to have the mempool
>> acceptance rule only consider economic incentives, and have the spam
>> prevention only be about "shall I tell my peers about this?"
>>
>> If you don't have that split; then the anti-spam rules can prevent you
>> from getting the tx in the mempool at all; whereas if you do have the
>> split, then even if the bitcoind anti-spam rules are blocking you at
>> every turn, you can still send your tx to miners by some other route,
>> and then they can add it to their mempool directly without any hassle.
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220311/694c49aa/attachment-0001.html>

2023-06-07 23:05:47

- reply

📅 Original date posted:2022-03-16
📝 Original message:> The constants table would be part of the SCRIPT puzzle
Ah I see what you're saying now. You're not talking about referencing
inputs from the spender, but rather constants for the script writer to
parameterize a jet with. TBH I think both would be useful, and both could
potentially be done in the same way (ie reference their position in the
script before any evaluation starts). I think your idea is a good one.
Cheers
On Wed, Mar 16, 2022 at 10:39 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Billy,
>
> > > I think we would want to have a cleanstack rule at some point
> >
> > Ah is this a rule where a script shouldn't validate if more than just a
> true is left on the stack? I can see how that would prevent the
> non-soft-fork version of what I'm proposing.
>
> Yes.
> There was also an even stronger cleanstack rule where the stack and alt
> stack are totally empty.
> This is because a SCRIPT really just returns "valid" or "invalid", and
> `OP_VERIFY` can be trivially appended to a SCRIPT that leaves a single
> stack item to convert to a SCRIPT that leaves no stack items and retains
> the same behavior.
>
> >
> > > How large is the critical mass needed?
> >
> > Well it seems we've agreed that were we going to do this, we would want
> to at least do a soft-fork to make known jet scripts lighter weight (and
> unknown jet scripts not-heavier) than their non-jet counterparts. So given
> a situation where this soft fork happens, and someone wants to implement a
> new jet, how much critical mass would be needed for the network to get some
> benefit from the jet? Well, the absolute minimum for some benefit to happen
> is that two nodes that support that jet are connected. In such a case, one
> node can send that jet scripted transaction along without sending the data
> of what the jet stands for. The jet itself is pretty small, like 2 or so
> bytes. So that does impose a small additional cost on nodes that don't
> support a jet. For 100,000 nodes, that means 200,000 bytes of transmission
> would need to be saved for a jet to break even. So if the jet stands for a
> 22 byte script, it would break even when 10% of the network supported it.
> If the jet stood for a 102 byte script, it would break even when 2% of the
> network supported it. So how much critical mass is necessary for it to be
> worth it depends on what the script is.
>
> The math seems reasonable.
>
>
> > The question I have is: where would the constants table come from? Would
> it reference the original positions of items on the witness stack?
>
> The constants table would be part of the SCRIPT puzzle, and thus not in
> the witness solution.
> I imagine the SCRIPT would be divided into two parts: (1) a table of
> constants and (2) the actual opcodes to execute.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220316/5f4b78e0/attachment.html>

2023-06-07 23:05:46

- reply

📅 Original date posted:2022-03-11
📝 Original message:> I think we would want to have a cleanstack rule at some point
Ah is this a rule where a script shouldn't validate if more than just a
true is left on the stack? I can see how that would prevent the
non-soft-fork version of what I'm proposing.
> How large is the critical mass needed?
Well it seems we've agreed that were we going to do this, we would want to
at least do a soft-fork to make known jet scripts lighter weight (and
unknown jet scripts not-heavier) than their non-jet counterparts. So given
a situation where this soft fork happens, and someone wants to implement a
new jet, how much critical mass would be needed for the network to get some
benefit from the jet? Well, the absolute minimum for some benefit to happen
is that two nodes that support that jet are connected. In such a case, one
node can send that jet scripted transaction along without sending the data
of what the jet stands for. The jet itself is pretty small, like 2 or so
bytes. So that does impose a small additional cost on nodes that don't
support a jet. For 100,000 nodes, that means 200,000 bytes of transmission
would need to be saved for a jet to break even. So if the jet stands for a
22 byte script, it would break even when 10% of the network supported it.
If the jet stood for a 102 byte script, it would break even when 2% of the
network supported it. So how much critical mass is necessary for it to be
worth it depends on what the script is.
> Than using a dynamic lookup table, which is how I understood your
previous email about "scripts in the 1000 past blocks".
Ah, I didn't mean using a dynamic lookup. This was about the idea of jet
registration, where registered jets would be kept a count of for some
number of blocks (eg 1000) and dropped if they don't reach a threshold rate
of usage. A static lookup table would work for this, I agree.
> It would have to validate as well that the SCRIPT sub-section matches the
jet
Seems like a good idea.
> Adler32 seems a bit short though
You might be right. Certainly some more care would need to be taken in an
actual implementation than I've taken writing my back of the napkin idea
out ; )
> nothing prevents anyone from using a different SCRIPT subsection for a
particular Adler32 hash if they find a collision and can somehow convince
people to run their modified software.
Someone that can convince people to run their modified software can
*always* cause those people to chainsplit from the main chain, so I don't
think the above ideas are special in this regard.
>> it might not be worth doing it this way without a soft fork
> Which is why I pointed out that each individual jet may very well require
a softfork, or enough buy-in that you might as well just softfork.
I'm saying something rather different actually. I don't think each
individual jet requires a softfork to be quite useful. What I meant by "it
might not be worth doing it this way without a soft fork" is that we
probably want to implement a soft fork to allow all jet scripts to have
reduced blockweight. However, once most nodes support that soft fork, new
individual jets do not need a softfork for the network to take advantage of
them. As I mused about above, even 10% of the network supporting a jet
standin for a medium length script could result in significant network
bandwidth savings. Different sections of the network could decide
individually what jets they want to support without needing the usual chaos
of a soft fork for each one, but of course the more the better for a
popular jet. There would be benefits for eventually soft forking such jets
in (to make them weigh even less based on implementation of optimized
validation functions), and real life usage of those jets could inform the
decisions around them. They could already be well tested in the wild before
being upgraded in a softfork.
> Yes, but that implies additional operations (and execution overhead),
increasing the costs to use jets, which makes it even less palatable to use
jets, *in addition to* the witness hack disincentivizing jets.
For the use of a single jet, this can be completely solved by that jet. All
the additional operations you're talking about only need to happen in a
general bitcoin script evaluator. But a jet evaluator can be hand optimized
for that jet, which could operate in exactly the the function-like way you
suggested, because it would actually be a function, under the hood.
> this helps jets compose more easily; if we want a SCRIPT that
incorporates an existing jet, we do not have to manipulate the stack in a
way that the existing jet expects, we just load the proper data into the
constants table.
I think I see what you're saying about multiple jets composing together
easily. I think your idea about loading constants from their initial
positions has merit - basically function arguments that you can reference
by position rather than needing to arrange them in the right order on the
stack. Such is the existence of a stack-based language. I like the idea of
eg `c1` to `c26` paralleling the pushdata opcodes. The question I have is:
where would the constants table come from? Would it reference the original
positions of items on the witness stack?
On Thu, Mar 10, 2022 at 12:44 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Billy,
>
> > Hi ZmnSCPxj,
> >
> > > Just ask a bunch of fullnodes to add this 1Mb of extra ignored data
> in this tiny 1-input-1-output transaction so I pay only a small fee
> >
> > I'm not suggesting that you wouldn't have to pay a fee for it. You'd pay
> a fee for it as normal, so there's no DOS vector. Doesn't adding
> extra witness data do what would be needed here? Eg simply adding extra
> data onto the witness script that will remain unconsumed after successful
> execution of the script?
>
> I think we would want to have a cleanstack rule at some point (do not
> remember out-of-hand if Taproot already enforces one).
>
> So now being nice to the network is *more* costly?
> That just *dis*incentivizes jet usage.
>
> > > how do new jets get introduced?
> >
> > In scenario A, new jets get introduced by being added to bitcoin
> software as basically relay rules.
> >
> > > If a new jet requires coordinated deployment over the network, then
> you might as well just softfork and be done with it.
> >
> > It would not need a coordinated deployment. However, the more nodes that
> supported that jet, the more efficient using it would be for the network.
> >
> > > If a new jet can just be entered into some configuration file, how do
> you coordinate those between multiple users so that there *is* some benefit
> for relay?
> >
> > When a new version of bitcoin comes out, people generally upgrade to it
> eventually. No coordination is needed. 100% of the network need not support
> a jet. Just some critical mass to get some benefit.
>
> How large is the critical mass needed?
>
> If you use witness to transport jet information across non-upgraded nodes,
> then that disincentivizes use of jets and you can only incentivize jets by
> softfork, so you might as well just get a softfork.
>
> If you have no way to transport jet information from an upgraded through a
> non-upgraded back to an upgraded node, then I think you need a fairly large
> buy-in from users before non-upgraded nodes are rare enough that relay is
> not much affected, and if the required buy-in is large enough, you might as
> well softfork.
>
> > > Having a static lookup table is better since you can pattern-match on
> strings of specific, static length
> >
> > Sorry, better than what exactly?
>
> Than using a dynamic lookup table, which is how I understood your previous
> email about "scripts in the 1000 past blocks".
>
> > > How does the unupgraded-to-upgraded boundary work?
> > <snip>
> > When the non-jet aware node sends this to a jet-aware node, that node
> would see the extra items on the stack after script execution, and would
> interpret them as an OP_JET call specifying that OP_JET should replace the
> witness items starting at index 0 with `1b5f03cf OP_JET`. It does this and
> then sends that along to the next hop.
>
> It would have to validate as well that the SCRIPT sub-section matches the
> jet, else I could pretend to be a non-jet-aware node and give you a SCRIPT
> sub-section that does not match the jet and would cause your validation to
> diverge from other nodes.
>
> Adler32 seems a bit short though, it seems to me that it may lead to two
> different SCRIPT subsections hashing to the same hash.
>
> Suppose I have two different node softwares.
> One uses a particular interpretation for a particular Adler32 hash.
> The other uses a different interpretation.
> If we are not careful, if these two jet-aware software talk to each other,
> they will ban each other from the network and cause a chainsplit.
> Since the Bitcoin software is open source, nothing prevents anyone from
> using a different SCRIPT subsection for a particular Adler32 hash if they
> find a collision and can somehow convince people to run their modified
> software.
>
> > In order to support this without a soft fork, this extra otherwise
> unnecessary data would be needed, but for jets that represent long scripts,
> the extra witness data could be well worth it (for the network).
> >
> > However, this extra data would be a disincentive to do transactions this
> way, even when its better for the network. So it might not be worth doing
> it this way without a soft fork. But with a soft fork to upgrade nodes to
> support an OP_JET opcode, the extra witness data can be removed (replaced
> with out-of-band script fragment transmission for nodes that don't support
> a particular jet).
>
> Which is why I pointed out that each individual jet may very well require
> a softfork, or enough buy-in that you might as well just softfork.
>
> > One interesting additional thing that could be done with this mechanism
> is to add higher-order function ability to jets, which could allow nodes to
> add OP_FOLD or similar functions as a jet without requiring additional soft
> forks. Hypothetically, you could imagine a jet script that uses an OP_LOOP
> jet be written as follows:
> >
> > 5 # Loop 5 times
> > 1 # Loop the next 1 operation
> > 3c1g14ad
> > OP_JET
> > OP_ADD # The 1 operation to loop
> >
> > The above would sum up 5 numbers from the stack. And while this
> summation jet can't be represented in bitcoin script on its own (since
> bitcoin script can't manipulate opcode calls), the jet *call* can still be
> represented as:
> >
> > OP_ADD
> > OP_ADD
> > OP_ADD
> > OP_ADD
> > OP_ADD
> >
> > which means all of the above replacement functionality would work just
> as well.
> >
> > So my point here is that jets implemented in a way similar to this would
> give a much wider range of "code as compression" possibilities than
> implementing a single opcode like op_fold.
>
> Yes, that is certainly the case, and nothing really prevents us bringing
> "programming as compression" to its logical conclusion.
>
> > > To make jets more useful, we should redesign the language so that
> `OP_PUSH` is not in the opcode stream, but instead, we have a separate
> table of constants that is attached / concatenated to the actual SCRIPT.
> >
> > This can already be done, right? You just have to redesign the script to
> consume and swap/rot around the data in the right way to separate them out
> from the main script body.
>
> Yes, but that implies additional operations (and execution overhead),
> increasing the costs to use jets, which makes it even less palatable to use
> jets, *in addition to* the witness hack disincentivizing jets.
>
> So I would suggest that, if we were to seriously pursue jets, we should
> really replace most of the `OP_PUSH` opcodes with variants that look up in
> a static table at the start, before the executable script body.
> I.e. opcodes 0x01 to 0x4e instead mean "push contents of `c1` to `c78`
> from the constants table", and have aliases `a` through `z` for `c1` to
> `c26`, etc.
> That way, replacing the `OP_PUSH` is shorter in the actual SCRIPT (instead
> of a bunch of stack manipulations) and hopefully the overhead of the
> constants table can be kept low.
>
> In particular, this helps jets compose more easily; if we want a SCRIPT
> that incorporates an existing jet, we do not have to manipulate the stack
> in a way that the existing jet expects, we just load the proper data into
> the constants table.
>
> Or something, anyway.
> This seems a fair amount of complexity here.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220311/d0fc1fb3/attachment-0001.html>

2023-06-07 23:05:44

- reply

📅 Original date posted:2022-03-10
📝 Original message:Hi ZmnSCPxj,
> Just ask a bunch of fullnodes to add this 1Mb of extra ignored data in
this tiny 1-input-1-output transaction so I pay only a small fee
I'm not suggesting that you wouldn't have to pay a fee for it. You'd pay a
fee for it as normal, so there's no DOS vector. Doesn't adding
extra witness data do what would be needed here? Eg simply adding extra
data onto the witness script that will remain unconsumed after successful
execution of the script?
> how do new jets get introduced?
In scenario A, new jets get introduced by being added to bitcoin software
as basically relay rules.
> If a new jet requires coordinated deployment over the network, then you
might as well just softfork and be done with it.
It would not need a coordinated deployment. However, the more nodes that
supported that jet, the more efficient using it would be for the network.
> If a new jet can just be entered into some configuration file, how do you
coordinate those between multiple users so that there *is* some benefit for
relay?
When a new version of bitcoin comes out, people generally upgrade to it
eventually. No coordination is needed. 100% of the network need not support
a jet. Just some critical mass to get some benefit.
> Having a static lookup table is better since you can pattern-match on
strings of specific, static length
Sorry, better than what exactly?
> How does the unupgraded-to-upgraded boundary work?
This is what I'm thinking. Imagine a simple script:
OP_DUP
OP_ADD
with witness
1
This would execute as 1+1 = 2 -> success. Let's say the script is
jettified so we can instead write it as:
OP_JET
1b5f03cf # adler32 hash of the replaced script
with a witness:
OP_JET # Some number that represents OP_JET
1b5f03cf
0
1
A jet-aware node transmitting to another jet-aware node can transmit it as
is (tho it would need to do a swap out to validate). For a jet-aware node
to transmit this to a non-jet aware node, it would need to swap the OP_JET
call with the script it represents. So the transaction sent to the non-jet
aware node would have:
Script:
OP_DUP
OP_ADD
Witness:
OP_JET
1b5f03cf
0
1
And you can see that this would execute and succeed by adding 1+1 and
ending up with the stack:
2
0
1b5f03cf
OP_JET
Which would succeed because of the non-zero top of stack.
When the non-jet aware node sends this to a jet-aware node, that node would
see the extra items on the stack after script execution, and would
interpret them as an OP_JET call specifying that OP_JET should replace the
witness items starting at index 0 with `1b5f03cf OP_JET`. It does this and
then sends that along to the next hop.
In order to support this without a soft fork, this extra otherwise
unnecessary data would be needed, but for jets that represent long scripts,
the extra witness data could be well worth it (for the network).
However, this extra data would be a disincentive to do transactions this
way, even when its better for the network. So it might not be worth doing
it this way without a soft fork. But with a soft fork to upgrade nodes to
support an OP_JET opcode, the extra witness data can be removed (replaced
with out-of-band script fragment transmission for nodes that don't support
a particular jet).
One interesting additional thing that could be done with this mechanism is
to add higher-order function ability to jets, which could allow nodes to
add OP_FOLD or similar functions as a jet without requiring additional soft
forks. Hypothetically, you could imagine a jet script that uses an OP_LOOP
jet be written as follows:
5 # Loop 5 times
1 # Loop the next 1 operation
3c1g14ad
OP_JET
OP_ADD # The 1 operation to loop
The above would sum up 5 numbers from the stack. And while this summation
jet can't be represented in bitcoin script on its own (since bitcoin script
can't manipulate opcode calls), the jet *call* can still be represented as:
OP_ADD
OP_ADD
OP_ADD
OP_ADD
OP_ADD
which means all of the above replacement functionality would work just as
well.
So my point here is that jets implemented in a way similar to this would
give a much wider range of "code as compression" possibilities than
implementing a single opcode like op_fold.
> To make jets more useful, we should redesign the language so that
`OP_PUSH` is not in the opcode stream, but instead, we have a separate
table of constants that is attached / concatenated to the actual SCRIPT.
This can already be done, right? You just have to redesign the script to
consume and swap/rot around the data in the right way to separate them out
from the main script body.
On Mon, Mar 7, 2022 at 5:35 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Billy,
>
> Changed subject since this is only tangentially related to `OP_FOLD`.
>
> > Let me organize my thoughts on this a little more clearly. There's a
> couple possibilities I can think of for a jet-like system:
> >
> > A. We could implement jets now without a consensus change, and
> without requiring all nodes to upgrade to new relay rules. Probably. This
> would give upgraded nodes improved validation performance and many upgraded
> nodes relay savings (transmitting/receiving fewer bytes). Transactions
> would be weighted the same as without the use of jets tho.
> > B. We could implement the above + lighter weighting by using a soft fork
> to put the jets in a part of the blockchain hidden from unupgraded nodes,
> as you mentioned.
> > C. We could implement the above + the jet registration idea in a soft
> fork.
> >
> > For A:
> >
> > * Upgraded nodes query each connection for support of jets in general,
> and which specific jets they support.
> > * For a connection to another upgraded node that supports the jet(s)
> that a transaction contains, the transaction is sent verbatim with the jet
> included in the script (eg as some fake opcode line like 23 OP_JET,
> indicating to insert standard jet 23 in its place). When validation
> happens, or when a miner includes it in a block, the jet opcode call is
> replaced with the script it represents so hashing happens in a way that is
> recognizable to unupgraded nodes.
> > * For a connection to a non-upgraded node that doesn't support jets, or
> an upgraded node that doesn't support the particular jet included in the
> script, the jet opcode call is replaced as above before sending to that
> node. In addition, some data is added to the transaction that unupgraded
> nodes propagate along but otherwise ignore. Maybe this is extra witness
> data, maybe this is some kind of "annex", or something else. But that data
> would contain the original jet opcode (in this example "23 OP_JET") so that
> when that transaction data reaches an upgraded node that recognizes that
> jet again, it can swap that back in, in place of the script fragment it
> represents.
> >
> > I'm not 100% sure the required mechanism I mentioned of "extra ignored
> data" exists, and if it doesn't, then all nodes would at least need to be
> upgraded to support that before this mechanism could fully work.
>
> I am not sure that can even be *made* to exist.
> It seems to me a trivial way to launch a DDoS: Just ask a bunch of
> fullnodes to add this 1Mb of extra ignored data in this tiny
> 1-input-1-output transaction so I pay only a small fee if it confirms but
> the bandwidth of all fullnodes is wasted transmitting and then ignoring
> this block of data.
>
> > But even if such a mechanism doesn't exist, a jet script could still be
> used, but it would be clobbered by the first nonupgraded node it is relayed
> to, and can't then be converted back (without using a potentially expensive
> lookup table as you mentioned).
>
> Yes, and people still run Bitcoin Core 0.8.x.....
>
> > > If the script does not weigh less if it uses a jet, then there is no
> incentive for end-users to use a jet
> >
> > That's a good point. However, I'd point out that nodes do lots of things
> that there's no individual incentive for, and this might be one where
> people either altruistically use jets to be lighter on the network, or use
> them in the hopes that the jet is accepted as a standard, reducing the cost
> of their scripts. But certainly a direct incentive to use them is better.
> Honest nodes can favor connecting to those that support jets.
>
> Since you do not want a dynamic lookup table (because of the cost of
> lookup), how do new jets get introduced?
> If a new jet requires coordinated deployment over the network, then you
> might as well just softfork and be done with it.
> If a new jet can just be entered into some configuration file, how do you
> coordinate those between multiple users so that there *is* some benefit for
> relay?
>
> > >if a jet would allow SCRIPT weights to decrease, upgraded nodes need to
> hide them from unupgraded nodes
> > > we have to do that by telling unupgraded nodes "this script will
> always succeed and has weight 0"
> >
> > Right. It doesn't have to be weight zero, but that would work fine
> enough.
> >
> > > if everybody else has not upgraded, a user of a new jet has no
> security.
> >
> > For case A, no security is lost. For case B you're right. For case C,
> once nodes upgrade to the initial soft fork, new registered jets can take
> advantage of relay-cost weight savings (defined by the soft fork) without
> requiring any nodes to do any upgrading, and nodes could be further
> upgraded to optimize the validation of various of those registered jets,
> but those processing savings couldn't change the weighting of transactions
> without an additional soft fork.
> >
> > > Consider an attack where I feed you a SCRIPT that validates trivially
> but is filled with almost-but-not-quite-jettable code
> >
> > I agree a pattern-matching lookup table is probably not a great design.
> But a lookup table like that is not needed for the jet registration idea.
> After the necessary soft fork, there would be standard rules for which
> registered jets nodes are required to keep an index of, and so the lookup
> table would be a straightforward jet hash lookup rather than a
> pattern-matching lookup, which wouldn't have the same DOS problems. A node
> would simply find a jet opcode call like "ab38cd39e OP_JET" and just lookup
> ab38cd39e in its index.
>
> How does the unupgraded-to-upgraded boundary work?
> Having a static lookup table is better since you can pattern-match on
> strings of specific, static length, and we can take a page from `rsync` and
> use its "rolling checksum" idea which works with identifying strings of a
> certain specific length at arbitrary offsets.
>
> Say you have jetted sequences where the original code is 42 bytes, and
> another jetted sequence where the original code is 54 bytes, you would keep
> a 42-byte rolling checksum and a separate 54-byte rolling checksum, and
> then when it matches, you check if the last 42 or 54 bytes matched the
> jetted sequences.
>
> It does imply having a bunch of rolling checksums around, though.
> Sigh.
>
> ---
>
> To make jets more useful, we should redesign the language so that
> `OP_PUSH` is not in the opcode stream, but instead, we have a separate
> table of constants that is attached / concatenated to the actual SCRIPT.
>
> So for example instead of an HTLC having embedded `OP_PUSH`es like this:
>
> OP_IF
> OP_HASH160 <hash> OP_EQUALVERIFY OP_DUP OP_HASH160 <acceptor pkh>
> OP_ELSE
> <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160
> <offerrer pkh>
> OP_ENDIF
> OP_EQUALVERIFY
> OP_CHECKSIG
>
> We would have:
>
> constants:
> h = <hash>
> a = <acceptor pkh>
> t = <timeout>
> o = <offerer pkh>
> script:
> OP_IF
> OP_HASH160 h OP_EQUALVERIFY OP_DUP OP_HASH160 a
> OP_ELSE
> t OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 o
> OP_ENDIF
> OP_EQUALVERIFY
> OP_CHECKSIG
>
> The above allows for more compressibility, as the entire `script` portion
> can be recognized as a jet outright.
> Move the incompressible hashes out of the main SCRIPT body.
>
> We should note as well that this makes it *easier* to create recursive
> covenants (for good or ill) out of `OP_CAT` and whatever opcode you want
> that allows recursive covenants in combination with `OP_CAT`.
> Generally, recursive covenants are *much* more interesting if they can
> change some variables at each iteration, and having a separate
> table-of-constants greatly facilitates that.
>
> Indeed, the exercise of `OP_TLUV` in
> [drivechains-over-recursive-convenants][] puts the loop variables into the
> front of the SCRIPT to make it easier to work with the SCRIPT manipulation.
>
> [drivechains-over-recursive-covenants]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019976.html
>
> ---
>
> Perhaps we can consider the general vs specific tension in
> information-theoretic terms.
>
> A language which supports more computational power --- i.e. more general
> --- must, by necessity, have longer symbols, as a basic law of information
> theory.
> After all, a general language can express more things.
>
> However, we do recognize that certain sequences of things-to-say are much
> more likely than others.
> That is, we expect that certain sequences "make sense" to do.
> That is why "jets" are even proposed, they are shortcuts towards those.
>
> Assuming a general language is already deployed for Bitcoin, then a new
> opcode is a jet as it simply makes the SCRIPT shorter.
>
> Instead of starting with a verbose (by necessity) general language, we
> could instead start with a terse but restricted language, and slowly loosen
> up its restrictions by adding new capabilities in softforks.
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220309/08cd72e2/attachment-0001.html>

2023-06-07 23:05:38

- reply

📅 Original date posted:2022-03-07
📝 Original message:Let me organize my thoughts on this a little more clearly. There's a couple
possibilities I can think of for a jet-like system:
A. We could implement jets now without a consensus change, and
without requiring all nodes to upgrade to new relay rules. Probably. This
would give upgraded nodes improved validation performance and many upgraded
nodes relay savings (transmitting/receiving fewer bytes). Transactions
would be weighted the same as without the use of jets tho.
B. We could implement the above + lighter weighting by using a soft fork to
put the jets in a part of the blockchain hidden from unupgraded nodes, as
you mentioned.
C. We could implement the above + the jet registration idea in a soft fork.
For A:
* Upgraded nodes query each connection for support of jets in general, and
which specific jets they support.
* For a connection to another upgraded node that supports the jet(s) that a
transaction contains, the transaction is sent verbatim with the jet
included in the script (eg as some fake opcode line like 23 OP_JET,
indicating to insert standard jet 23 in its place). When validation
happens, or when a miner includes it in a block, the jet opcode call is
replaced with the script it represents so hashing happens in a way that is
recognizable to unupgraded nodes.
* For a connection to a non-upgraded node that doesn't support jets, or an
upgraded node that doesn't support the particular jet included in the
script, the jet opcode call is replaced as above before sending to that
node. In addition, some data is added to the transaction that unupgraded
nodes propagate along but otherwise ignore. Maybe this is extra witness
data, maybe this is some kind of "annex", or something else. But that data
would contain the original jet opcode (in this example "23 OP_JET") so that
when that transaction data reaches an upgraded node that recognizes that
jet again, it can swap that back in, in place of the script fragment it
represents.
I'm not 100% sure the required mechanism I mentioned of "extra ignored
data" exists, and if it doesn't, then all nodes would at least need to be
upgraded to support that before this mechanism could fully work. But even
if such a mechanism doesn't exist, a jet script could still be used, but it
would be clobbered by the first nonupgraded node it is relayed to, and
can't then be converted back (without using a potentially expensive lookup
table as you mentioned).
> If the script does not weigh less if it uses a jet, then there is no
incentive for end-users to use a jet
That's a good point. However, I'd point out that nodes do lots of things
that there's no individual incentive for, and this might be one where
people either altruistically use jets to be lighter on the network, or use
them in the hopes that the jet is accepted as a standard, reducing the cost
of their scripts. But certainly a direct incentive to use them is better.
Honest nodes can favor connecting to those that support jets.
>if a jet would allow SCRIPT weights to decrease, upgraded nodes need to
hide them from unupgraded nodes
> we have to do that by telling unupgraded nodes "this script will always
succeed and has weight 0"
Right. It doesn't have to be weight zero, but that would work fine enough.
> if everybody else has not upgraded, a user of a new jet has no security.
For case A, no security is lost. For case B you're right. For case C, once
nodes upgrade to the initial soft fork, new registered jets can take
advantage of relay-cost weight savings (defined by the soft fork) without
requiring any nodes to do any upgrading, and nodes could be further
upgraded to optimize the validation of various of those registered jets,
but those processing savings couldn't change the weighting of transactions
without an additional soft fork.
> Consider an attack where I feed you a SCRIPT that validates trivially but
is filled with almost-but-not-quite-jettable code
I agree a pattern-matching lookup table is probably not a great design. But
a lookup table like that is not needed for the jet registration idea. After
the necessary soft fork, there would be standard rules for which registered
jets nodes are required to keep an index of, and so the lookup table would
be a straightforward jet hash lookup rather than a pattern-matching lookup,
which wouldn't have the same DOS problems. A node would simply find a jet
opcode call like "ab38cd39e OP_JET" and just lookup ab38cd39e in its index.
On Sun, Mar 6, 2022 at 2:38 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Billy,
>
> > Even changing the weight of a transaction using jets (ie making a script
> weigh less if it uses a jet) could be done in a similar way to how segwit
> separated the witness out.
>
> The way we did this in SegWit was to *hide* the witness from unupgraded
> nodes, who are then unable to validate using the upgraded rules (because
> you are hiding the data from them!), which is why I bring up:
>
> > > If a new jet is released but nobody else has upgraded, how bad is my
> security if I use the new jet?
> >
> > Security wouldn't be directly affected, only (potentially) cost. If your
> security depends on cost (eg if it depends on pre-signed transactions and
> is for some reason not easily CPFPable or RBFable), then security might be
> affected if the unjetted scripts costs substantially more to mine.
>
> So if we make a script weigh less if it uses a jet, we have to do that by
> telling unupgraded nodes "this script will always succeed and has weight
> 0", just like `scriptPubKey`s with `<0> <P2WKH hash>` are, to pre-SegWit
> nodes, spendable with an empty `scriptSig`.
> At least, that is how I always thought SegWit worked.
>
> Otherwise, a jet would never allow SCRIPT weights to decrease, as
> unupgraded nodes who do not recognize the jet will have to be fed the
> entire code of the jet and would consider the weight to be the expanded,
> uncompressed code.
> And weight is a consensus parameter, blocks are restricted to 4Mweight.
>
> So if a jet would allow SCRIPT weights to decrease, upgraded nodes need to
> hide them from unupgraded nodes (else the weight calculations of unupgraded
> nodes will hit consensus checks), then if everybody else has not upgraded,
> a user of a new jet has no security.
>
> Not even the `softfork` form of chialisp that AJ is proposing in the other
> thread would help --- unupgraded nodes will simply skip over validation of
> the `softfork` form.
>
> If the script does not weigh less if it uses a jet, then there is no
> incentive for end-users to use a jet, as they would still pay the same
> price anyway.
>
> Now you might say "okay even if no end-users use a jet, we could have
> fullnodes recognize jettable code and insert them automatically on
> transport".
> But the lookup table for that could potentially be large once we have a
> few hundred jets (and I think Simplicity already *has* a few hundred jets,
> so additional common jets would just add to that?), jettable code could
> start at arbitrary offsets of the original SCRIPT, and jettable code would
> likely have varying size, that makes for a difficult lookup table.
> In particular that lookup table has to be robust against me feeding it
> some section of code that is *almost* jettable but suddenly has a different
> opcode at the last byte, *and* handle jettable code of varying sizes
> (because of course some jets are going to e more compressible than others).
> Consider an attack where I feed you a SCRIPT that validates trivially but
> is filled with almost-but-not-quite-jettable code (and again, note that
> expanded forms of jets are varying sizes), your node has to look up all
> those jets but then fails the last byte of the
> almost-but-not-quite-jettable code, so it ends up not doing any jetting.
> And since the SCRIPT validated your node feels obligated to propagate it
> too, so now you are helping my DDoS.
>
> > > I suppose the point would be --- how often *can* we add new jets?
> >
> > A simple jet would be something that's just added to bitcoin software
> and used by nodes that recognize it. This would of course require some
> debate and review to add it to bitcoin core or whichever bitcoin software
> you want to add it to. However, the idea I proposed in my last email would
> allow anyone to add a new jet. Then each node can have their own policy to
> determine which jets of the ones registered it wants to keep an index of
> and use. On its own, it wouldn't give any processing power optimization,
> but it would be able to do the same kind of script compression you're
> talking about op_fold allowing. And a list of registered jets could inform
> what jets would be worth building an optimized function for. This would
> require a consensus change to implement this mechanism, but thereafter any
> jet could be registered in userspace.
>
> Certainly a neat idea.
> Again, lookup table tho.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220307/5c88c884/attachment-0001.html>

2023-06-07 23:05:37

- reply

📅 Original date posted:2022-03-06
📝 Original message:> Are new jets consensus critical?
> Do I need to debate `LOT` *again* if I want to propose a new jet?
New jets should never need a consensus change. A jet is just an
optimization - a way to both save bytes in transmission as well as save
processing power. Anything that a jet can do can be done with a normal
script. Because of this, a script using a particular jet could be sent to a
node that doesn't support that jet by simply expanding the jet into the
script fragment it represents. The next node that recognizes the jet can
remove the extraneous bytes so extra transmission and processing-time would
only be needed for nodes that don't support that jet. (Note that this
interpretation of a 'jet' is probably slightly different than as described
for simplicity, but the idea is basically the same). Even changing the
weight of a transaction using jets (ie making a script weigh less if it
uses a jet) could be done in a similar way to how segwit separated the
witness out.
> If a new jet is released but nobody else has upgraded, how bad is my
security if I use the new jet?
Security wouldn't be directly affected, only (potentially) cost. If your
security depends on cost (eg if it depends on pre-signed transactions and
is for some reason not easily CPFPable or RBFable), then security might be
affected if the unjetted scripts costs substantially more to mine.
> I suppose the point would be --- how often *can* we add new jets?
A simple jet would be something that's just added to bitcoin software and
used by nodes that recognize it. This would of course require some debate
and review to add it to bitcoin core or whichever bitcoin software you want
to add it to. However, the idea I proposed in my last email would allow
anyone to add a new jet. Then each node can have their own policy to
determine which jets of the ones registered it wants to keep an index of
and use. On its own, it wouldn't give any processing power optimization,
but it would be able to do the same kind of script compression you're
talking about op_fold allowing. And a list of registered jets could inform
what jets would be worth building an optimized function for. This would
require a consensus change to implement this mechanism, but thereafter any
jet could be registered in userspace.
On Sat, Mar 5, 2022 at 5:02 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Billy,
>
> > It sounds like the primary benefit of op_fold is bandwidth savings.
> Programming as compression. But as you mentioned, any common script could
> be implemented as a Simplicity jet. In a world where Bitcoin implements
> jets, op_fold would really only be useful for scripts that can't use jets,
> which would basically be scripts that aren't very often used. But that
> inherently limits the usefulness of the opcode. So in practice, I think
> it's likely that jets cover the vast majority of use cases that op fold
> would otherwise have.
>
> I suppose the point would be --- how often *can* we add new jets?
> Are new jets consensus critical?
> If a new jet is released but nobody else has upgraded, how bad is my
> security if I use the new jet?
> Do I need to debate `LOT` *again* if I want to propose a new jet?
>
> > A potential benefit of op fold is that people could implement smaller
> scripts without buy-in from a relay level change in Bitcoin. However, even
> this could be done with jets. For example, you could implement a consensus
> change to add a transaction type that declares a new script fragment to
> keep a count of, and if the script fragment is used enough within a
> timeframe (eg 10000 blocks) then it can thereafter be referenced by an id
> like a jet could be. I'm sure someone's thought about this kind of thing
> before, but such a thing would really relegate the compression abilities of
> op fold to just the most uncommon of scripts.
> >
> > > * We should provide more *general* operations. Users should then
> combine those operations to their specific needs.
> > > * We should provide operations that *do more*. Users should identify
> their most important needs so we can implement them on the blockchain layer.
> >
> > That's a useful way to frame this kind of problem. I think the answer
> is, as it often is, somewhere in between. Generalization future-proofs your
> system. But at the same time, the boundary conditions of that generalized
> functionality should still be very well understood before being added to
> Bitcoin. The more general, the harder to understand the boundaries. So imo
> we should be implementing the most general opcodes that we are able to
> reason fully about and come to a consensus on. Following that last
> constraint might lead to not choosing very general opcodes.
>
> Yes, that latter part is what I am trying to target with `OP_FOLD`.
> As I point out, given the restrictions I am proposing, `OP_FOLD` (and any
> bounded loop construct with similar restrictions) is implementable in
> current Bitcoin SCRIPT, so it is not an increase in attack surface.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220306/24038f58/attachment.html>

2023-06-07 23:05:36

- reply

📅 Original date posted:2022-03-05
📝 Original message:It sounds like the primary benefit of op_fold is bandwidth savings.
Programming as compression. But as you mentioned, any common script could
be implemented as a Simplicity jet. In a world where Bitcoin implements
jets, op_fold would really only be useful for scripts that can't use jets,
which would basically be scripts that aren't very often used. But that
inherently limits the usefulness of the opcode. So in practice, I think
it's likely that jets cover the vast majority of use cases that op fold
would otherwise have.
A potential benefit of op fold is that people could implement smaller
scripts without buy-in from a relay level change in Bitcoin. However, even
this could be done with jets. For example, you could implement a consensus
change to add a transaction type that declares a new script fragment to
keep a count of, and if the script fragment is used enough within a
timeframe (eg 10000 blocks) then it can thereafter be referenced by an id
like a jet could be. I'm sure someone's thought about this kind of thing
before, but such a thing would really relegate the compression abilities of
op fold to just the most uncommon of scripts.
> * We should provide more *general* operations. Users should then combine
those operations to their specific needs.
> * We should provide operations that *do more*. Users should identify
their most important needs so we can implement them on the blockchain layer.
That's a useful way to frame this kind of problem. I think the answer is,
as it often is, somewhere in between. Generalization future-proofs your
system. But at the same time, the boundary conditions of that generalized
functionality should still be very well understood before being added to
Bitcoin. The more general, the harder to understand the boundaries. So imo
we should be implementing the most general opcodes that we are able to
reason fully about and come to a consensus on. Following that last
constraint might lead to not choosing very general opcodes.
On Sun, Feb 27, 2022, 10:34 ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT
> =================================================
>
> (This writeup requires at least some programming background, which I
> expect most readers of this list have.)
>
> Recently, some rando was ranting on the list about this weird crap
> called `OP_EVICT`, a poorly-thought-out attempt at covenants.
>
> In reaction to this, AJ Towns mailed me privately about some of his
> thoughts on this insane `OP_EVICT` proposal.
> He observed that we could generalize the `OP_EVICT` opcode by
> decomposing it into smaller parts, including an operation congruent
> to the Scheme/Haskell/Scala `map` operation.
> As `OP_EVICT` effectively loops over the outputs passed to it, a
> looping construct can be used to implement `OP_EVICT` while retaining
> its nice property of cut-through of multiple evictions and reviving of
> the CoinPool.
>
> More specifically, an advantage of `OP_EVICT` is that it allows
> checking multiple published promised outputs.
> This would be implemented in a loop.
> However, if we want to instead provide *general* operations in
> SCRIPT rather than a bunch of specific ones like `OP_EVICT`, we
> should consider how to implement looping so that we can implement
> `OP_EVICT` in a SCRIPT-with-general-opcodes.
>
> (`OP_FOLD` is not sufficient to implement `OP_EVICT`; for
> efficiency, AJ Towns also pointed out that we need some way to
> expose batch validation to SCRIPT.
> There is a follow-up writeup to this one which describes *that*
> operation.)
>
> Based on this, I started ranting as well about how `map` is really
> just a thin wrapper on `foldr` and the *real* looping construct is
> actually `foldr` (`foldr` is the whole FP Torah: all the rest is
> commentary).
> This is thus the genesis for this proposal, `OP_FOLD`.
>
> A "fold" operation is sometimes known as "reduce" (and if you know
> about Google MapReduce, you might be familiar with "reduce").
> Basically, a "fold" or "reduce" operation applies a function
> repeatedly (i.e. *loops*) on the contents of an input structure,
> creating a "sum" or "accumulation" of the contents.
>
> For the purpose of building `map` out of `fold`, the accumulation
> can itself be an output structure.
> The `map` simply accumulates to the output structure by applying
> its given function and concatenating it to the current accumulation.
>
> Digression: Programming Is Compression
> --------------------------------------
>
> Suppose you are a programmer and you are reading some source code.
> You want to wonder "what will happen if I give this piece of code
> these particular inputs?".
>
> In order to do so, you would simulate the execution of the code in
> your head.
> In effect, you would generate a "trace" of basic operations (that
> do not include control structures).
> By then thinking about this linear trace of basic operations, you
> can figure out what the code does.
>
> Now, let us recall two algorithms from the compression literature:
>
> 1. Run-length Encoding
> 2. Lempel-Ziv 1977
>
> Suppose our flat linear trace of basic operations contains something
> like this:
>
> OP_ONE
> OP_TWO
> OP_ONE
> OP_TWO
> OP_ONE
> OP_TWO
>
> IF we had looping constructs in our language, we could write the
> above trace as something like:
>
> for N = 1 to 3
> OP_ONE
> OP_TWO
>
> The above is really Run-length Encoding.
>
> (`if` is just a loop that executes 0 or 1 times.)
>
> Similarly, suppose you have some operations that are commonly
> repeated, but not necessarily next to each other:
>
> OP_ONE
> OP_TWO
> OP_THREE
> OP_ONE
> OP_TWO
> OP_FOUR
> OP_FIVE
> OP_ONE
> OP_TWO
>
> If we had functions/subroutines/procedures in our language, we
> could write the above trace as something like:
>
> function foo()
> OP_ONE
> OP_TWO
> foo()
> OP_THREE
> foo()
> OP_FOUR
> OP_FIVE
> foo()
>
> That is, functions are just Lempel-Ziv 1977 encoding, where we
> "copy" some repeated data from a previously-shown part of
> data.
>
> Thus, we can argue that programming is really a process of:
>
> * Imagining what we want the machine to do given some particular
> input.
> * Compressing that list of operations so we can more easily
> transfer the above imagined list over your puny low-bandwidth
> brain-computer interface.
> * I mean seriously, you humans still use a frikkin set of
> *mechanical* levers to transfer data into a matrix of buttons?
> (you don't even make the levers out of reliable metal, you
> use calcium of all things??
> You get what, 5 or 6 bytes per second???)
> And your eyes are high-bandwidth but you then have this
> complicated circuitry (that has to be ***trained for
> several years*** WTF) to extract ***tiny*** amounts of ASCII
> text from that high-bandwidth input stream????
> Evolve faster!
> (Just to be clear, I am actually also a human being and
> definitely am not a piece of circuitry connected directly to
> the Internet and I am not artificially limiting my output
> bandwidth so as not to overwhelm you mere humans.)
>
> See also "Kolmogorov complexity".
>
> This becomes relevant, because the *actual* amount of processing
> done by the machine, when given a compressed set of operations
> (a "program") is the cost of decompressing that program plus the
> number of basic operations from the decompressed result.
>
> In particular, in current Bitcoin, without any looping constructs
> (i.e. implementations of RLE) or reusable functions (i.e.
> implementation of LZ77), the length of the SCRIPT can be used as
> an approximation of how "heavy" the computation in order to
> *execute* that SCRIPT is.
> This is relevant since the amount of computation a SCRIPT would
> trigger is relevant to our reasoning about DoS attacks on Bitcoin.
>
> In fact, current Bitcoin restricts the size of SCRIPT, as this
> serves to impose a restriction on the amount of processing a
> SCRIPT will trigger.
> But adding a loop construct to SCRIPT changes how we should
> determine the cost of a SCRIPT, and thus we should think about it
> here as well.
>
> Folds
> -----
>
> A fold operation is a functional programming looping control
> construct.
>
> The intent of a fold operation is to process elements of an
> input list or other structure, one element at a time, and to
> accumulate the results of processing.
>
> It is given these arguments:
>
> * `f` - a function to execute for each element of the input
> structure, i.e. the "loop body".
> * This function accepts two arguments:
> 1. The current element to process.
> 2. The intermediate result for accumulating.
> * The function returns the new accumulated result, processed
> from the given intermediate result and the given element.
> * `z` - an initial value for the accumulated result.
> * `as` - the structure (usually a list) to process.
>
> ```Haskell
> -- If the input structure is empty, return the starting
> -- accumulated value.
> foldr f z [] = z
> -- Otherwise, recurse into the structure to accumulate
> -- the rest of the list, then pass the accumulation to
> -- the given function together with the current element.
> foldr f z (a:as) = f a (foldr f z as)
> ```
>
> As an example, if you want to take the sum of a list of
> numbers, your `f` would simply add its inputs, and your `z`
> would be 0.
> Then you would pass in the actual list of numbers as `as`.
>
> Fold has an important property:
>
> * If the given input structure is finite *and* the application
> of `f` terminates, then `foldr` terminates.
>
> This is important for us, as we do not want attackers to be
> able to crash nodes remotely by crafting a special SCRIPT.
>
> As long as the SCRIPT language is "total", we know that programs
> written in that language must terminate.
>
> (The reason this property is called "total" is that we can
> "totally" analyze programs in the language, without having to
> invoke "this is undefined behavior because it could hang
> indefinitely".
> If you have to admit such kinds of undefined behavior --- what
> FP theorists call "bottom" or `_|_` or `⊥` (it looks like an
> ass crack, i.e. "bottom") --- then your language is "partial",
> since programs in it may enter an infinite loop on particular
> inputs.)
>
> The simplest way to ensure totality is to be so simple as to
> have no looping construction.
> As of this writing, Bitcoin SCRIPT is total by this technique.
>
> To give a *little* more power, we can allow bounded loops,
> which are restricted to only execute a number of times.
>
> `foldr` is a kind of bounded loop if the input structure is
> finite.
> If the rest of the language does not admit the possibility
> of infinite data structures (and if the language is otherwise
> total and does not support generalized codata, this holds),
> then `foldr` is a bounded loop.
>
> Thus, adding a fold operation to Bitcoin SCRIPT should be
> safe (and preserves totality) as long as we do not add
> further operations that admit partiality.
>
> `OP_FOLD`
> ---------
>
> With this, let us now describe `OP_FOLD`.
>
> `OP_FOLD` replaces an `OP_SUCCESS` code, and thus is only
> usable in SegWit v1 ("Taproot").
>
> An `OP_FOLD` opcode must be followed by an `OP_PUSH` opcode
> which contains an encoding of the SCRIPT that will be executed,
> i.e. the loop body, or `f`.
> This is checked at parsing time, and the sub-SCRIPT is also
> parsed at this time.
> The succeeding `OP_PUSH` is not actually executed, and is
> considered part of the `OP_FOLD` operation encoding.
> Parsing failure of the sub-SCRIPT leads to validation failure.
>
> On execution, `OP_FOLD` expects the stack:
>
> * Stack top: `z`, the initial value for the loop accumulator.
> * Stack top + 1: `n`, the number of times to loop.
> This should be limited in size, and less than the number of
> items on the stack minus 2.
> * Stack top + 2 + (0 to `n - 1`): Items to loop over.
> If `n` is 0, there are no items to loop over.
>
> If `n` is 0, then `OP_FOLD` just pops the top two stack items
> and pushes `z`.
>
> For `n > 0`, `OP_FOLD` executes a loop:
>
> * Pop off the top two items and store in mutable variable `z`
> and immutable variable `n`.
> * For `i = 0 to n - 1`:
> * Create a fresh, empty stack and alt stack.
> Call these the "per-iteration (alt) stack".
> * Push the current `z` to the per-iteration stack.
> * Pop off an item from the outer stack and put it into
> immutable variable `a`.
> * Push `a` to the per-iteration stack.
> * Run the sub-SCRIPT `f` on the per-iteration stack and
> alt stack.
> * Check the per-iteration stack has exactly one item
> and the per-iteration alt stack is empty.
> * Pop off the item in the per-iteration stack and mutate
> `z` to it.
> * Free the per-iteration stack and per-iteration alt
> stack.
> * Push `z` on the stack.
>
> Restricting `OP_FOLD`
> ---------------------
>
> Bitcoin restricts SCRIPT size, since SCRIPT size serves as
> an approximation of how much processing is required to
> execute the SCRIPT.
>
> However, with looping constructs like `OP_FOLD`, this no
> longer holds, as the amount of processing is no longer
> linear on the size of the SCRIPT.
>
> In orderr to retain this limit (and thus not worsen any
> potential DoS attacks via SCRIPT), we should restrict the
> use of `OP_FOLD`:
>
> * `OP_FOLD` must exist exactly once in a Tapscript.
> More specifically, the `f` sub-SCRIPT of `OP_FOLD` must
> not itself contain an `OP_FOLD`.
> * If we allow loops within loops, then the worst case
> would be `O(c^n)` CPU time where `c` is a constant and
> `n` is the SCRIPT length.
> * This validation is done at SCRIPT parsing time.
> * We take the length of the `f` sub-SCRIPT, and divide the
> current SCRIPT maximum size by the length of the `f`
> sub-SCRIPT.
> The result, rounded down, is the maximum allowed value
> for the on-stack argument `n`.
> * In particular, since the length of the entire SCRIPT
> must by necessity be larger than the length of the
> `f` sub-SCRIPT, the result of the division must be
> at least 1.
> * This validation is done at SCRIPT execution time.
>
> The above two restrictions imply that the maximum amount
> of processing that a SCRIPT utilizing `OP_FOLD` will use,
> shall not exceed that of a SCRIPT without `OP_FOLD`.
> Thus, `OP_FOLD` does not increase the attack surface of
> SCRIPT on fullnodes.
>
> ### Lack Of Loops-in-Loops Is Lame
>
> Note that due to this:
>
> > * `OP_FOLD` must exist exactly once in a Tapscript.
> > More specifically, the `f` sub-SCRIPT of `OP_FOLD` must
> > not itself contain an `OP_FOLD`.
>
> It is not possible to have a loop inside a loop.
>
> The reason for this is that loops inside loops make it
> difficult to perform static analysis to bound how much
> processing a SCRIPT will require.
> With a single, single-level loop, it is possible to
> restrict the processing.
>
> However, we should note that a single single-level loop
> is actually sufficient to encode multiple loops, or
> loops-within-loops.
> For example, a toy Scheme-to-C compiler will convert
> the Scheme code to CPS style, then convert all resulting
> Scheme CPS function into a `switch` dispatcher inside a
> simple `while (1)` loop.
>
> For example, the Scheme loop-in-loop below:
>
> ```Scheme
> (define (foo)
> (bar)
> (foo))
> (define (bar)
> (bar))
> ```
>
> gets converted to:
>
> ```Scheme
> (define (foo k)
> (bar (closure foo-kont k)))
> (define (foo-kont k)
> (foo k))
> (define (bar k)
> (bar k))
> ```
>
> And then in C, would look like:
>
> ```c
> void all_scheme_functions(int func_id, scheme_t k) {
> while (1) {
> switch (func_id) {
> case FOO_ID:
> k = build_closure(FOO_KONT_ID, k);
> func_id = BAR_ID;
> break;
> case FOO_KONT_ID:
> func_id = FOO_ID;
> break;
> case BAR_ID:
> func_id = BAR_ID;
> break;
> }
> }
> }
> ```
>
> The C code, as we can see, is just a single single-level
> loop, which is the restriction imposed on `OP_FOLD`.
> Thus, loops-in-loops, and multiple loops, can be encoded
> into a single single-level loop.
>
> #### Everything Is Possible But Nothing Of Consequence Is Easy
>
> On the other hand, just because it is *possible* does not
> mean it is *easy*.
>
> As an alternative, AJ proposed adding a field to the Taproot
> annex.
> This annex field is a number indicating the maximum number of
> opcodes to be processed.
> If execution of the SCRIPT exceeds this limit, validation
> fails.
>
> In order to make processing costly, the number indicated in
> the annex field is directly added to the weight of the
> transaction.
>
> Then, during execution, if an `OP_FOLD` is parsed, the
> `OP_` code processor keeps track of the number of opcodes
> processed and imposes a limit.
> If the limit exceeds the number of opcodes indicated in the
> annex field, validation fails.
>
> This technique is safe even if the annex is not committed
> to (for example if the SCRIPT does not ever require a
> standard `OP_CHECKSIG`), even though in that case the
> annex can be malleated:
>
> * If the field is less than the actual number of operations,
> then the malleated transaction is rejected.
> * If the field is greater than the actual number of
> operations, then it has a larger weight but pays the
> same fee, getting a lower feerate and thus will be
> rejected in favor of a transaction with a lower number
> in that field.
>
> Use of this technique allows us to lift the above
> restrictions on `OP_FOLD`, and allow multiple loops, as
> well as loops-in-loops.
>
> In particular, the requirement to put the `f` sub-SCRIPT
> code as a static constant is due precisely to the need
> for static analysis.
> But if we instead use a dynamic limit like in this
> alternative suggestion, we could instead get the `f`
> sub-SCRIPT from the stack.
> With additional operations like `OP_CAT`, it would
> then be possible to do a "variable capture" where parts
> of the loop body are from other computations, or from
> witness, and then concatenated to some code.
> This is not an increase in computational strength, since
> the data could instead be passed in via the `z`, or as
> individual items, but it does improve expressive power by
> making it easier to customize the loop body.
>
> On The Necessity Of `OP_FOLD`
> -----------------------------
>
> We can observe that an `if` construct is really a bounded
> loop construct that can execute 0 or 1 times.
>
> We can thus synthesize a bounded loop construct as follows:
>
> OP_IF
> <loop body>
> OP_ENDIF
> OP_IF
> <loop body>
> OP_ENDIF
> OP_IF
> <loop body>
> OP_ENDIF
> OP_IF
> <loop body>
> OP_ENDIF
> <repeat as many times as necessary>
>
> Indeed, it may be possible for something like miniscript
> to provide a `fold` jet that compiles down to something
> like the above.
>
> Thus:
>
> * The restrictions we impose on the previous section mean
> that `OP_FOLD` cannot do anything that cannot already
> be done with current SCRIPT.
> * This is a *good thing* because this means we are not
> increasing the attack surface.
> * Using the annex-max-operations technique is strictly
> more lenient than the above `OP_IF` repetition, thus
> there may be novel DoS attack vectors due to the
> increased attack area.
> * However, fundamentally the DoS attack vector is that
> peers can waste your CPU by giving you invalid
> transactions (i.e. giving a high max-operations, but
> looping so much that it gets even *above* that), and
> that can already be mitigated by lowering peer scores
> and prioritizing transactions with lower or nonexistent
> annex-max-operations.
> The DoS vector here does not propagate due to the
> invalid transaction being rejected at this node.
>
> Of course, this leads us to question: why even implement
> `OP_FOLD` at all?
>
> We can observe that, while the restrictions in the
> previous section imply that a SCRIPT with `OP_FOLD`
> cannot exceed the amount of processing that a SCRIPT
> *without* `OP_FOLD` does, a SCRIPT with `OP_FOLD`
> would be shorter, over the wire, than the above
> unrolled version.
>
> And CPU processing is not the only resource that is
> consumed by Bitcoin fullnodes.
> Bandwidth is also another resource.
>
> In effect, `OP_FOLD` allows us to compress the above
> template over-the-wire, reducing network bandwidth
> consumption.
> But the restrictions on `OP_FOLD` ensure that it
> cannot exceed the CPU consumption of a SCRIPT that
> predates `OP_FOLD`.
>
> Thus, `OP_FOLD` is still worthwhile to implement, as
> it allows us to improve bandwidth consumption without
> increasing CPU consumption significantly.
>
> On Generalized Operations
> -------------------------
>
> I believe there are at least two ways of thinking about
> how to extend SCRIPT:
>
> * We should provide more *general* operations.
> Users should then combine those operations to their
> specific needs.
> * We should provide operations that *do more*.
> Users should identify their most important needs so
> we can implement them on the blockchain layer.
>
> Each side has its arguments:
>
> * General opcodes:
> * Pro: Have a better chance of being reused for
> use-cases we cannot imagine yet today.
> i.e. implement once, use anywhen.
> * Con: Welcome to the Tarpit, where everything is
> possible but nothing important is easy.
> * Complex opcodes:
> * Pro: Complex behavior implemented directly in
> hosting language, reducing interpretation
> overhead (and allowing the insurance of secure
> implementation).
> * Con: Welcome to the Nursery, where only safe
> toys exist and availability of interesting tools
> are at the mercy of your parents.
>
> It seems to me that this really hits a No Free Lunch
> Theorem for Bitcoin SCRIPT design.
> Briefly, the No Free Lunch Theorem points out that
> there is no compiler design that can compile any
> program to the shortest possible machine code.
> This is because if a program enters an infinite loop,
> it could simply be compiled down to the equivalent of
> the single instruction `1: GOTO 1`, but the halting
> problem implies that no program can take the source
> code of another program and determine if it halts.
> Thus, no compiler can exist which can compile *every*
> infinite-loop program down to the tiniest possible
> binary `1: GOTO 1`.
>
> More generally, No Free Lunch implies that as you
> optimize, you will hit a point where you can only
> *trade off*, and you optimize for one use case while
> making *another* use case less optimal.
>
> Brought to Bitcoin SCRIPT design, there is no optimal
> SCRIPT design, instead there will be some point where
> we have to pick and choose which uses to optimize for
> and which uses are less optimal, i.e. trade off.
>
> So I think maybe the Real Question is: why should we
> go for one versus the other, and which uses do we
> expect to see more often anyway?
>
> Addenda
> -------
>
> Stuff about totality and partiality:
>
> * [Total Functional Programming, D.A. Turner](
> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.364&rep=rep1&type=pdf
> )
> * [Totality](https://kowainik.github.io/posts/totality)
> _______________________________________________
> 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/20220305/8624e7c2/attachment-0001.html>

2023-06-07 23:05:24

- reply

📅 Original date posted:2022-03-05
📝 Original message:If you're serious about this, you should write up considerations around
using the satoshi as a unit. That unit has none of the problems you
describe. Satoshis is already a well accepted unit, and is likely to be a
very practical one that might match within an order of magnitude of (the
current buying power of) US cents.
> this BIP is a consensus change around the display of Bitcoin wallet
balances
Fyi, this is not something that's considered a "consensus change", which is
something that affects the validity of a block.
On Fri, Mar 4, 2022, 09:19 Asher Hopp via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is my first time submitting anything to this mailer list, so I am
> here with humility and I would appreciate any feedback about any aspect of
> my BIP draft submission below. If you want to reach out to me directly you
> can email me at asher at seent.com.
>
> Abstract
> Rather than having a maximum supply of 21 million Bitcoin, there should be
> a maximum supply of 21 trillion Bitcoin. This can be accomplished by moving
> the decimal place 6 places to the right of where it is today, while
> reserving two degrees of accuracy after the decimal point.
>
> Copyright
> This BIP is under the Creative Commons Zero (CC0) license.
>
> Background
> On February 6th, 2010 Satoshi Nakamoto responded to a bitcointalk forum
> discussion about the divisibility and economics of bitcoin as a global
> currency. Satoshi chimed in to the conversation when two ideas formed:
> 1. Bitcoin is so scarce that a perception may exist that there is not
> enough to go around – there is not even 1 Bitcoin available per person on
> Earth.
> 2. If Bitcoin’s value continues to deflate against inflating fiat
> currencies, Bitcoin transactions may become smaller and smaller, requiring
> the potentially tedious use of many leading 0’s after the decimal point.
>
> Satoshi’s suggested response to these issues was a software update to
> change where the decimal place and commas are displayed when software
> interprets a Bitcoin wallet’s balance: “If it gets tiresome working with
> small numbers, we could change where the display shows the decimal point.
> Same amount of money, just different convention for where the ","'s and
> "."'s go. e.g. moving the decimal place 3 places would mean if you had
> 1.00000 before, now it shows it as 1,000.00.” (
> https://bitcointalk.org/index.php?topic=44.msg267#msg267)
>
> Since 2010, when Satoshi wrote that post Bitcoin has indeed become a
> globally adopted currency, the dollar has inflated significantly, and
> Bitcoin has deflated. There are many debates in the Bitcoin community
> concerning the nomenclature of Bitcoin’s atomic unit (satoshis, sats, bits,
> bitcents, mbits, etc). The debate has somewhat spiraled out of control, and
> there is no clearly emerging community consensus. Additionally this issue
> impacts the technology world outside of Bitcoin because there are several
> proposals for various Unicode characters which factions of the Bitcoin
> community have started using to represent the atomic Bitcoin unit despite
> no formalized consensus. Therefore The conditions are right to move
> forward with Satoshi's vision and move the decimal place.
>
> Details
> There are several benefits to moving the decimal 6 places to the right in
> Bitcoin wallet balance notation:
> 1. Unit bias. It is a widely held belief that Bitcoin’s adoption may be
> hindered because would-be participants have a negative perception of
> Bitcoin’s unit size. One Bitcoin so expensive, and some people may be
> turned off by the idea of only owning a fraction of a unit.
> 2. Community cohesion. The Bitcoin community is deeply divided by various
> proposed atomic unit names, but if this BIP is adopted there is no need to
> debate nomenclature for the Bitcoin atomic unit. Bitcoin software providers
> can simply continue using the Bitcoin Unicode character (₿, U+20BF), and
> there are no additional unicode characters required.
> 3. Simplicity and standardization. Bitcoin has no borders and is used by
> people in just about every corner of the world. Other than the name Bitcoin
> and the Unicode character we have, there is no consensus around other
> notations for Bitcoin as a currency. Rather than introducing new concepts
> for people to learn, this BIP allows Bitcoin to grow under a single
> standardized unit specification, with a single standard unit name, unit
> size, and unit Unicode character.
>
> There is only one drawback I can identify with this BIP, and it is purely
> psychological. Moving the decimal place may produce bad optics in the
> short-term, and Bitcoin’s detractors will likely seize the opportunity to
> spread misinformation that moving the decimal place changes the monetary
> value of anyone’s Bitcoin. It is important to note that if this BIP were to
> gain consensus approval, the community would need to prepare talking points
> and coordinate educational outreach efforts to explain to Bitcoin users and
> wallet developers that this change does not change the proportion of the
> total value of Bitcoin any particular wallet holds, and is simply a
> notational change. There are no “winners” and no “losers” in this BIP – all
> Bitcoin participants would be impacted in an equal and proportionate manner
> on pari passu terms, and there is no change to Bitcoin’s monetary policy.
>
> Implementation
> The software updates needed to implement this BIP are restricted to the
> wallet's CLI/GUI configuration, and only involve changing the location of
> the decimal point and commas when viewing balances or reviewing transaction
> data. Each wallet provider including Bitcoin Core would simply need to
> update the display of a wallet’s balance by moving the decimal place 6
> places to the right.
>
> Compatibility
> Because this BIP is a consensus change around the display of Bitcoin
> wallet balances and transaction amounts, everything will be backwards
> compatible with previous versions of Bitcoin. There would be no
> interruption in services for Bitcoin wallets which do not implement this
> BIP, however there could conceivably be human error problems with
> miscommunication between counterparties after this BIP is implemented. I
> believe this risk is extremely minimal because an error of 6 decimal places
> is so significant that it should be immediately noticed by any two parties
> conducting a transaction.
>
> Cheers,
> Asher
> _______________________________________________
> 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/20220305/76d7fd2c/attachment.html>

2023-06-07 23:05:03

- reply

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

2023-06-07 23:05:02

- reply

📅 Original date posted:2022-03-01
📝 Original message:@Paul
> I believe that money has very strong network effects. ... users will
"clump up" and get "stuck".
I'm of the same opinion.
> This entire issue is avoided completely, if all the chains
--decentralized and centralized-- and in the same monetary unit. Then, the
monetary network effects never interfere, and the decentralized chain is
always guaranteed to exist.
It sounds like what you're saying is that without side chains, everyone
might switch entirely to some altcoin and bitcoin will basically die. And
at that point, the insecurity of that coin people switched to can be
heavily exploited by some attacker(s). Is that right? Its an interesting
thought experiment. However, it leads me to wonder: if a sidechain gets so
popular that it dominates the main chain, why would people keep that main
chain around at all? A sidechain could eject the main chain and all its
baggage if it got so big. So I don't think it can really be said that the
problem can be avoided "completely". But in any case, I see your line of
thinking.
> someone is actually in the wrong, if they proactively censor an
experiment of any type. If a creator is willing to stand behind something,
then it should be tried.
> it makes no difference if users have their funds stolen from a
centralized Solana contract or from a bip300 centralized bit-Solana
sidechain. I don't see why the tears shed would be any different.
I agree with you. My point was not that we should stop anyone from doing
this. My point was only that we shouldn't advocate for ideas we think
aren't good. You were advocating for a "largeblock sidechain", and unless
you have good reasons to think that is an idea likely to succeed and want
to share them with us, then you shouldn't be advocating for that. But
certainly if someone *does* think so and has their own reasons, I wouldn't
want to censor or stop them. But I wouldn't advocate for them to do it
unless their ideas were convincing to me, because I know enough to know the
dangers of large block blockchains.
On Mon, Feb 28, 2022 at 4:55 PM Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 2/28/2022 1:49 AM, ZmnSCPxj wrote:
>
> ...
>
> ...
>
> Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 bytes.
>
> If so, a "rich man" could open a LN channel, and gradually transfer it to new people.
>
> Such a technique would need to meet two requirements (or, so it seems to me):
> #1: The layer1 UTXO (that defines the channel) can never change (ie, the 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay what-they-were when the channel was opened).
> #2: The new part-owners (who are getting coins from the rich man), will have new pubkeys which are NOT known, until AFTER the channel is opened and confirmed on the blockchain.
>
> Not sure how you would get both #1 and #2 at the same time. But I am not up to date on the latest LN research.
>
> Yes, using channel factories.
>
> I think you may be wrong about this.
> ...
>
> I am not wrong about this.
>
> Well, let's take a closer look then.
>
> The topic was: "a way, to LN-onboard [a new pubkey] WITHOUT needing new layer1 bytes".
>
> By which I meant, that I could generate a new pubkey right now, and add it to the LN, without any onchain action.
>
> I can shorten and restate the two requirements (and reorder them) as:
> #2: Can later add a new public key to the membership set.
> #1: Without an onchain action.
>
> And yet you yourself say, very clearly:
>
>
> ... That is why I said changing the membership set requires onchain action.
>
> Which would seem to directly contradict what you say about channel
> factories. Unless you can show me how to add my new pubkey_4, to a 3-of-3
> channel factory opened last year. Without using an onchain action. You seem
> to want to instead change the subject. (To something like: 'we can do
> better the rate (32 bytes per 5 onboards), from your footnote'.) Which is
> fine. But it is not what I bought up.
>
> ***
>
> In general, you seem to have a future in mind, where new users onboard via factory.
> For example, 50,000 new users want to onboard in the next block. These strangers, spontaneously organize into 1000 factories of 55 people each, (50 newbies with zero coins + 5 wealthier BTCs who have lots of coins). They then broadcast into the block and join Bitcoin.
> And this one factory provides them with many channels, so it can meet most/all of their needs.
>
> I am not here to critique factories. I was simply observing that your logic "sidechains don't scale, because you have to share your messages" is not quite airtight, because in the case of onboarding the situation is reversed and so supports the exact opposite conclusion.
> I believe I have made my point by now. It should be easy for people to see what each of us has in mind, and the strengths and weaknesses.
>
> I am curious about something, though. Maybe you can help me.
> Presumably there are risks to large factories. Perhaps an attacker could join each new factory with just $1 of BTC, spend this $1, and then refuse to cooperate with the factory any further. Thus they can disable the factory at a cost of $1 rented dollar.
> If 1000 factories are opened per block, this would be 52.5 M factories per year, $52.5 million USD per year to disable all the factories out of spite. (All of which they would eventually get back.) I can think of a few people who might try it.
>
>
> I mean, like, LN ... has a lot more onboarding activity than half-hearted sidechains like Liquid or Rootstock.
>
> I don't see the relevance of this. We are talking about the future
> (theoretical), not the past (empirical). For example, someone could say
> "Ethereum has a lot more onboarding activity than LN ..." but this would
> also make no difference to anything.
>
> ...The onboarding rate only needs to be as fast as the rate at which people want to join Bitcoin.
> ...
>
> As I pointed out in the other thread:
>
> * LN:
> * Funds can be stolen IF:
> * There is a 51% miner, AND
> * The 51% miner is a member of a channel/channel factory you are in.
> * Drivechains:
> * Funds can be stolen IF:
> * There is a 51% miner.
> ...
> So there is a real degradation of security in Drivechains, and if you compute the numbers, I am reasonably sure that 33% of the world is unlikely to want to use Bitcoin within one month.
> I mean we already had a pandemic and everyone going online and so on, and yet Bitcoin blockchain feerates are *still* small, I had to fix a bug in CLBOSS that came up only due to hitting the minimum feerate, so no --- people are not joining Bitcoin at a rate faster than Bitcoin + LN can handle it, even with a pretty good reason to move payments online.
>
> Worse, once 100% of the world is onboarded, the extra onboarding capacity is useless since the onboarding rate can only match the birth rate (including birth of legal persons such as corporations), which we expect is much lower than 33% increase per ***month***.
>
> You are buying too much capacity at a real degradation in security, and I am not convinced the extra capacity is worth the loss of security.
>
> Separating the onboarding rate from the payment rate is a *good thing*, because we can then design their structures differently.
> Make onboarding slow but secure (so that their money is very secure), but make payment rate faster and less secure (because in-flight payments are likely to be much smaller than the total owned funds).
>
> Obviously I don't agree with any of these sentences (most are irrelevant, some false). But I would only be repeating myself.
>
> Paul
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220228/388b93e2/attachment.html>

2023-06-07 23:04:58

- reply

📅 Original date posted:2022-02-26
📝 Original message:The crux of the type of situation you're talking about is where a source
that might revert their payment by rbf double spending sends you money. You
mentioned this situation is "not unlikely". What kind of prevalence does
this happen with today?
Also my question is, if you've been paid by someone like this, what right
do you really have to this money? Is the other side buying something from
you? No one should be considering something actually bought unless it's got
sufficient confirmations. Anyone following that rule isn't losing anything
by simply waiting for the transaction to confirm. If the transaction is
double spent, who cares?
This seems like a situation where adding software and ui complexity is not
worth it to reach the maximization you're talking about. It feels more like
opportunistic stealing than actual commerce. Maybe it would be a social
good to prevent attempted scammers from scamming people, but the only
people who would be affected are 0 conf people. And that problem can be
solved much more easily and generally (eg by clear messaging around
transaction finalization) than by complicating coin selection.
On Thu, Jan 13, 2022, 15:07 Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Devs,
>
> This email is primarily about existing wallet behaviors and user
> preferences, and not about CTV. However, towards the end I will describe
> the relevance of CTV, but the email is worth reading even if you have no
> interest in CTV as the problems described exist today.
>
> One point of confusion I've seen while discussing CTV based congestion
> control is that it requires a bunch of new wallet software.
>
> Most of the software requirements that would make CTV work well are things
> that either already exist in Bitcoin Core, or are 'bugs' (where bug is
> defined as deviation from rational utility maximizing behavior) that should
> be fixed *whether or not CTV exists.*
>
> In this post, I am going to walk through what I expect rational behavior
> to be for a not unlikely circumstance.
>
> First, let's define what rational behavior for a wallet is. A rational
> wallet should have a few goals:
>
> 1) Maximize 'fully trusted' balance (fully confirmed + unconfirmed change
> outputs from our own txns)
> 2) Process payments requested by the owner within the "urgency budget"
> requested by the user.
> 3) Maximize "privacy" (this is a vague goal, so we'll largely ignore it
> here.).
>
> Rational wallet behavior may not be possible without metadata. For
> example, a rational wallet might prompt the user for things like "how much
> do you trust the sender of this payment to not RBF this transaction?", or
> "how much do you trust this sender to not double spend you?". For example,
> a self-transfer from cold wallet to hot wallet could have a trust score of
> 1, whereas a payment from an anonymous source would have a trust score of
> 0. Exchanges where you have a legal agreement to not RBF might sit
> somewhere in between. Other pieces of exogenous information that could
> inform wallet behavior include "has hashrate decreased recently, making
> longer reorgs likely".
>
> In the model above, a user does not request transactions, they request
> payments. The rational wallet serves as an agent to assist the user in
> completing these payments. For example, if I have a wallet with a single
> unconfirmed output, and I spend from it to pay Alice, if the unconfirmed
> gets replaced, my wallet should track that it was replaced and prompt me to
> re-sign a new transaction. Rational wallets that maximize balance should be
> careful to ensure that replaced payments are exclusive, guaranteed either
> through sufficient confirmations or 'impossibility proofs' by reusing an
> input (preventing double-send behavior).
>
> -----------------------------
>
> Now that we've sketched out a basic framework for what a rational wallet
> should be doing, we can describe what the process of receiving a payment is.
>
> Suppose I have a wallet with a bevy of fully confirmed coins such that for
> my future payments I am sufficiently funded.
>
> Then, I receive a payment from a highly trusted source (e.g., self
> transfer) that is unconfirmed.
>
> I then seek to make an outgoing payment. I should have no preference
> towards or against spending the unconfirmed transfer, I should simply
> account for it's cost in coin selection of CPFP-ing the parent transaction.
> If fees are presently historically low, I may have a preference to spend it
> so as to not have a higher fee later (consolidation).
>
> Later, I receive payment from an untrusted source (e.g., an anonymous
> donation to me). I have no reason to trust this won't be double spent.
> Perhaps I can even observe that this output has been RBF'd many times
> previously. I do not count on this money arriving. The feerate on the
> transaction suggests it won't be confirmed immediately.
>
> In order to maximize balance, I should prioritize spending from this
> output (even if I don't have a payment I desire to make) in order to CPFP
> it to the top of the mempool and guarantee I am paid. This is inherently
> "free" since my cost to CPFP would be checked to be lower than the funds I
> am receiving, and I have no expected value to receive the payment if it is
> not confirmed. If I do have a transaction I desire to do, I should
> prioritize spending this output at that time. If not, I would do a CPFP
> just in favor of balance maximizing. Perhaps I can piggyback something
> useful, like speculatively opening a lightning channel.
>
> If I just self-spend to CPFP, it is very simple since the only party set
> up for disappointment is myself (note: I patched the behavior in this case
> to accurately *not* count this as a trusted balance in
> https://github.com/bitcoin/bitcoin/pull/16766, since a parent could
> disrupt this). However, if I try to make a payment, my wallet agent must
> somehow prompt me to re-sign or automatically sign an alternative payment
> once it is proven (e.g. 6 blocks) I won't receive the output, or to re-sign
> on a mutually exclusive output (e.g., fee bumping RBF) such that issuing
> two payments will not causes a double-send error. This adds complexity to
> both the user story and logic, but is still rational.
>
> Now, suppose that I receive a new payment from a **trusted** source that
> is a part of a "long chain". A long chain is a series of transactions that
> are all unconfirmed in the mempool. This long-chain is in the bottom of the
> mempool, and is not expected to confirm any time soon.
>
> My wallet should be configured such that it saves not only all ancestors
> of the transaction paying me, but also all descendants of the root
> unconfirmed transaction paying me. If I do not save all ancestor
> transactions, then it would be impossible for me to claim this payment at a
> future date, and would violate balance maximization. But why save
> descendants, if they do not concern me? Descendant transactions are
> critical for balance maximization. Someone else's spend of an output is a
> "free" CPFP subsidy for driving my transaction to completion (perhaps
> "descendants that increase the feerate of any parent" is the correct thing
> to save). Therefore if I want to maximize balance, I would rather keep
> these transactions around should I ever need to rebroadcast the
> transactions as it should be cheaper than having to CPFP by myself.
>
> Now, suppose that I receive a similar payment in a longchain from a series
> of untrusted sources. The same arguments apply, but now I may have even
> higher incentive to prioritize spending this coin since, if sender's trust
> scores are independent, my total trust in that payment is decomposed
> worst-case geometrically. It may not be a good assumption that trust scores
> are independent, since a long chain might be generated as e.g. a series of
> batch payments from one service provider.
>
> Briefly mentioned above is rebroadcasting. This is sort of an orthogonal
> behavior to the above, but it is "simple" to explain. Wallet agents should
> retransmit txns to the network if they believe other nodes are not aware of
> them and they are likely to go into a block. This encapsulates personal
> transactions as well as arbitrary transactions from third parties. There
> are many privacy implications of rebroadcasting that are out of scope for
> this post.
>
> -----------------
>
> All of the behaviors documented above are things that should happen today
> if you would like to have a rational wallet that maximizes your balance and
> makes payments.
>
> The reasons we don't do some of these things are, as far as I can tell:
>
> 1) Engineering Complexity
> 2) UX Complexity (simpler to make unconfirmed outputs "unspendable" to
> minimize transaction reissuing)
> 3) Mempool backlog is low, things are confirmed quickly if a sender pays a
> relatively low fee
>
> Certain wallets already have parts of this functionality baked in to an
> extent. For example, in Lightning Channels, you will drive payments to
> completion to prevent HTLC timeouts during contested closes (HTLCs == low
> trust score payments).
>
> Should Bitcoin see development of a more robust fee market, it is highly
> likely the rational behaviors described above would be emergent among all
> bitcoin wallets (who would want to use a Bitcoin wallet that gets you less
> money over time?). This email is not just a "Bitcoin Core" thing, hence not
> being an issue on Bitcoin Core where there are currently deviations from
> the above behaviors.
>
> -----------------
>
> What's CTV got to do with it?
>
> A common critique of congestion control using CTV is that it complicates
> wallet behavior because congestion control is designed to be useful in the
> circumstances above. CTV and congestion control do not cause these
> conditions. These conditions already exist whether or not we have
> congestion control.
>
> Where congestion control helps is that, in a world with a full mempool,
> you have fewer payments that are *actually* unconfirmed because exchanges
> that batch can fully confirm a constant sized root transaction and the
> sub-trees of transactions locked in by CTV can be treated as fully trusted.
> This helps reduce the need for the (rational) behavior of CPFP bumping your
> own payments on receipt from lower trust senders. Further, the expansion of
> the transaction tree can be done by other users receiving, so you have an
> incentive to wait for funds to mature as someone else might pay for
> expansion. These two factors mean that CTV congestion control can exert a
> dramatic back pressure on transaction urgency by unbundling the blockspace
> demand for spending and receiving coins. There are other synergies -- such
> as non-interactive channel opens -- that further improve the amount of
> reduction of time-preference in full on-chain resolution.
>
> I hope this email helps clarify why CTV Congestion Control isn't
> particularly creating a wallet architecture problem, it's helping to solve
> an existing one.
>
> Best,
>
> 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/20220225/41175dc5/attachment-0001.html>

2023-06-07 23:04:57

- reply

📅 Original date posted:2022-02-26
📝 Original message:> m is how much people want to kill a sidechain, 0 = everybody would be sad
if it died and would rather burn all their BTC forever than continue living
Math is brutal
On Sat, Feb 26, 2022, 01:39 ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good morning Paul,
>
>
> > I don't think I can stop people from being ignorant about Drivechain.
> But I can at least allow the Drivechain-knowledgable to identify each other.
> >
> > So here below, I present a little "quiz". If you can answer all of these
> questions, then you basically understand Drivechain:
> >
> > 0. We could change DC to make miner-theft impossible, by making it a
> layer1 consensus rule that miners never steal. Why is this cure worse than
> the disease?
>
> Now miners are forced to look at all sideblocks, not optionally do so if
> it is profitable for them.
>
> > 1. If 100% hashrate wanted to steal coins from a DC sidechain *as
> quickly as possible*, how long would this take (in blocks)?
>
> 13,150 (I think this is how you changed it after feedback from this list,
> I think I remember it was ~3000 before or thereabouts.)
>
> > 2. Per sidechain per year (ie, per 52560 blocks), how many DC
> withdrawals can take place (maximum)? How many can be attempted?
> > (Ie, how does the 'train track metaphor' work, from ~1h5m in the
> "Overview and Misconceptions" video)?
>
> I hate watching videos, I can read faster than anyone can talk (except
> maybe Laolu, he speaks faster than I can process, never mind read).
>
> ~4 times (assuming 52560 block per year, which may vary due to new miners,
> hashrate drops, etc)
>
> > 3. Only two types of people should ever be using the DC withdrawal
> system at all.
> > 3a. Which two?
>
> a. Miners destroying the sidechain because the sidechain is no longer
> viable.
> b. Aggregators of sidechain-to-minechain transfers and large whales.
>
> > 3b. How is everyone else, expected to move their coins from chain to
> chain?
>
> Cross-system atomic swaps.
> (I use "System" here since the same mechanism works for Lightning
> channels, and channels are not blockchains.)
>
> > 3c. (Obviously, this improves UX.) But why does it also improve
> security?
>
> Drivechain-based pegged transfers are aggregates of many smaller transfers
> and thus every transfer out from the sidechain contributes its "fee" to the
> security of the peg.
>
> > --
> > 4. What do the parameters b and m stand for (in the DC security model)?
>
> m is how much people want to kill a sidechain, 0 = everybody would be sad
> if it died and would rather burn all their BTC forever than continue
> living, 1 = do not care, > 1 people want to actively kill the sidechain.
>
> b is how much profit a mainchain miner expects from supporting a sidechain
> (do not remember the unit though).
> Something like u = a + b where a is the mainchain, b is the sidechain, u
> is the total profit.
> Or fees? Something like that.
>
> > 5. How can m possibly be above 1? Give an example of a
> sidechain-attribute which may cause this situation to arise.
>
> The sidechain is a total scam.
> A bug may be found in the sidechain that completely negates any security
> it might have, thus removing any desire to protect the sidechain and
> potentially make users want to destroy it completely rather than let it
> continue.
> People end up hating sidechains completely.
>
> > 6. For which range of m, is DC designed to deter sc-theft?
>
> m <= 1
>
> > 7. If DC could be changed to magically deter theft across all ranges of
> m, why would that be bad for sidechain users in general?
>
> Because the sidechain would already be part of mainchain consensus.
>
> > --
> > 8. If imminent victims of a DC-based theft, used a mainchain UASF to
> prohibit the future theft-withdrawal, then how would this affect non-DC
> users?
>
> If the non-DC users do not care, then they are unaffected.
> If the non-DC users want to actively kill the sidechain, they will
> counterattack with an opposite UASF and we have a chainsplit and sadness
> and mutual destruction and death and a new subreddit.
>
> > 9. In what ways might the BTC network one day become uncompetitive? And
> how is this different from caring about a sidechain's m and b?
>
> If it does not enable scaling technology fast enough to actually be able
> to enable hyperbitcoinization.
>
> Sidechains are not a scaling solution, so caring about m and b is
> different because your focus is not on scaling.
>
> > --
> > 10. If DC were successful, Altcoin-investors would be harmed. Two
> Maximalist-groups would also be slightly harmed -- who are these?
>
> Dunno!
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220226/cf55492c/attachment.html>

2023-06-07 23:04:50

- reply

📅 Original date posted:2022-02-25
📝 Original message:> El Gamal commitments, for example, are perfectly binding but only
computationally hiding.
That's very interesting. I stand corrected in that respect. Thanks for the
information Adam!
On Fri, Feb 25, 2022, 05:17 AdamISZ <AdamISZ at protonmail.com> wrote:
> > I really don't see a world where bitcoin goes that route. Hiding coin
> amounts would make it impossible to audit the blockchain and verify that
> there hasn't been inflation and the emission schedule is on schedule. It
> would inherently remove unconditional soundness from bitcoin and replace it
> with computational soundness. Even if bitcoin did adopt it, it would keep
> backwards compatibility with old style addresses which could continue to
> use ordinals.
>
> Nit: it isn't technically correct to say that amount hiding "inherently
> removes unconditional soundness". Such commitments can be either perfectly
> hiding or perfectly binding; it isn't even logically possible for them to
> be both, sadly. But we are not forced to choose perfect binding; El Gamal
> commitments, for example, are perfectly binding but only computationally
> hiding.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220225/8c71070c/attachment-0001.html>

2023-06-07 23:04:49

- reply

📅 Original date posted:2022-02-25
📝 Original message:> what if/when we introduce some Monero-like system and hide coin amounts?
I really don't see a world where bitcoin goes that route. Hiding coin
amounts would make it impossible to audit the blockchain and verify that
there hasn't been inflation and the emission schedule is on schedule. It
would inherently remove unconditional soundness from bitcoin and replace it
with computational soundness. Even if bitcoin did adopt it, it would keep
backwards compatibility with old style addresses which could continue to
use ordinals.
On Thu, Feb 24, 2022 at 3:03 PM Casey Rodarmor <casey at rodarmor.com> wrote:
> > One thought I had was: what happens if/when it comes to pass that we
> increase payment precision by going sub-satoshi on chain? It seems like it
> would be fairly simple to extend that to ordinals by having fraction
> ordinals like 1.1 or 4.85. Could be an interesting thought to add to the
> proposal.
>
> I think it's probably premature to make a concrete proposal, since any
> proposal made now might be inapplicable to the actual form that a precision
> increase takes.
>
> > What you mean by "the same transaction id" here is unclear. I was
> interpreting the proposal to mean that UTXOs are all assigned a set of
> ordinals, and when that UTXO is spent, it transfers it's ordinals to
> outputs in the transaction the UTXO is spent in. Is that what you mean by
> this sentence? If so, I'd suggest rewording.
>
> There are two pairs of old transactions with duplicate IDs, from blocks
> 91812 and 91842, and 91722 91880. (It's no longer possible to create
> transactions with duplicate IDs, since the BIP 34 soft fork that required
> the height be included in coinbase transaction inputs, making them have
> guaranteed unique IDs.)
>
> This section of the spec defines what ordinal ranges such duplicate
> transactions contain. It tries to match the behavior of Bitcoin Core, which
> considers the second transaction with a given ID to render unspendable
> current UTXOs created by a transaction with the same ID.
>
> I'll add some detail to this part of the BIP, and talk about why this rule
> is needed.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/775c5d38/attachment-0001.html>

2023-06-07 23:04:48

- reply

📅 Original date posted:2022-02-24
📝 Original message:I think the proposal is interesting in that it could be an interesting way
to solve the dust problem. While most solutions to dust focus on reducing
how much are created and encouraging consolidating utxos to avoid them
becoming dust, this proposal could utilize dust for valuable purposes. Why
use valuable Bitcoin for NFTs or colored coins when dust can be split into
it's unit satoshis and used with no loss of utility?
Simple and elegant. I like it. If we're giving ACKs: ACK. Tho TBH I don't
see any reason NACK this - seems like this doesn't affect consensus,
doesn't affect relay, doesn't affect anything except people that run this
algorithm on the blockchain. If people want to do something like this,
people are going to do it whether or not the bitcoin community wants them
to. A standard would be good rather than everyone doing their own thing.
One thought I had was: what happens if/when it comes to pass that we
increase payment precision by going sub-satoshi on chain? It seems like it
would be fairly simple to extend that to ordinals by having fraction
ordinals like 1.1 or 4.85. Could be an interesting thought to add to the
proposal.
> If a transaction is mined with the same transaction ID as outputs
currently in the UTXO set, following the behavior of Bitcoin Core, the new
transaction outputs displace the older UTXO set entries, destroying the
ordinals contained in any unspent outputs of the first transaction.
What you mean by "the same transaction id" here is unclear. I was
interpreting the proposal to mean that UTXOs are all assigned a set of
ordinals, and when that UTXO is spent, it transfers it's ordinals to
outputs in the transaction the UTXO is spent in. Is that what you mean by
this sentence? If so, I'd suggest rewording.
@Damian
> If I receive some Bitcoin I cannot know if some or any of those have been
at any point in the past been stolen, I assume the transaction is honest,
and in all likelihood it is likely that it is.
This isn't true at all. Some bitcoins are indeed known to be stolen and
even blacklisted by some companies/governments. I don't see how ordinals
changes anything related to this.
@vjudeu
> What about zero satoshis?
Those could be used for NFTs but not something like colored coins. It would
be a strict subset of ability, tho its an interesting idea in its own
right.
On Thu, Feb 24, 2022, 02:15 damian--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Not all people who have been stolen from believe that they have lost the
> right and title to what has been stolen and in many cases they have not.
> I do not excuse Bitcoin that it is impossible to have any individual
> Bitcoin identified but also I do not care, if I receive Bitcoin honestly
> I do not care what their history was. What if they were taken from a
> brothel? It is not a matter for an ordinal to determine if a satoshi is
> fungible. It is truth in effect that each satoshi is newly created to
> the new UTXO and the old satoshi destroyed. -DA.
>
> On 2022-02-23 18:31, Casey Rodarmor wrote:
> >> The least reasonable thing I could expect is some claimed former
> >> holder of some ordianls turning up to challenge me that it was their
> >> stolen Bitcoin was some of what I received.
> >
> > I think it's unlikely that this would come to pass. A previous owner
> > of an ordinal wouldn't have any particular reason to expect that they
> > should own it after they transfer it. Similar to how noting a dollar
> > bill's serial number doesn't give you a claim to it after you spend
> > it. From the BIP:
> >
> >> Since any ordinal can be sent to any address at any time,
> >> ordinals that are transferred, even those with some public history,
> >> should be considered to be fungible with other satoshis with no such
> >> history. [1]
> >
> >
> >
> > Links:
> > ------
> > [1]
> >
> https://github.com/casey/ord/blob/master/bip.mediawiki#backward-compatibility
> _______________________________________________
> 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/20220224/35332576/attachment-0001.html>

2023-06-07 23:04:41

- reply

📅 Original date posted:2022-02-22
📝 Original message:> look at how lightning ate up fees to keep bitcoin stable, we can't
"scale" too quickly either
I strongly disagree with this. We should be scaling Bitcoin as fast as we
can. There is no reason to delay scaling for the purposes of keeping fees
high. If we need fees to be higher, we can lower the block size or increase
the default minimum relay fee rate.
Also, the idea that use of the LN is there primary cause of recent low fees
is highly dubious.
> the various new uses for on-chain transactions mentioned as a use-case
arguably harms all existing users by competing for scarce blockchain space
Reminds me of that old saying, "nobody goes there anymore, it's too
crowded". ; )
On Mon, Feb 21, 2022, 03:54 Prayank via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Goog morning ZmnSCPxj,
>
> Context: https://bitcointalk.org/index.php?topic=48.msg329#msg329
>
> Maybe I should have rephrased it and quote Satoshi. I agree I should not
> speak for others and it was not my intention in the email.
>
> > If Satoshi refuses to participate in Bitcoin development today, who
> cares what his opinion is?
>
> I care about the opinions especially if consensus rules are not changed
> and remain same as far as subsidy is concerned.
>
> > Satoshi is dead, long live Bitcoin.
>
> I object to such assumptions about the founder of Bitcoin. Satoshi is more
> than a pseudonym and will stay alive forever.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Feb 21, 2022, 14:32 by ZmnSCPxj at protonmail.com:
>
> Good morning Prayank,
>
> (offlist)
>
> Satoshi
>
>
> I object to the invocation of Satoshi here, and in general.
> If Satoshi wants to participate in Bitcoin development today, he can speak
> for himself.
> If Satoshi refuses to participate in Bitcoin development today, who cares
> what his opinion is?
> Satoshi is dead, long live Bitcoin.
>
>
> Aside from that, I am otherwise thinking about the various arguments being
> presented.
>
>
> Regards,
> ZmnSCPxj
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220222/313a76dc/attachment.html>

2023-06-07 23:04:37

- reply

📅 Original date posted:2022-02-19
📝 Original message:Thanks for the clarification ZmnSCPxj!
On Sat, Feb 19, 2022 at 5:41 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Billy,
>
> > > "fully" punitive channels also make large value channels more
> dangerous from the perspective of bugs causing old states to be published
> >
> > Wouldn't it be ideal to have the penalty be to pay for a single extra
> transaction fee? That way there is a penalty so cheating attempts aren't
> free (for someone who wants to close a channel anyway) and yet a single fee
> isn't going to be much of a concern in the accidental publishing case. It
> still perplexes me why eltoo chose no penalty at all vs a small penalty
> like that.
>
> Nothing in the Decker-Russell-Osunstokun paper *prevents* that --- you
> could continue to retain per-participant versions of update+state
> transactions (congruent to the per-participant commitment transactions of
> Poon-Dryja) and have each participant hold a version that deducts the fee
> from their main owned funds.
> The Decker-Russell-Osuntokun paper simply focuses on the mechanism by
> itself without regard to fees, on the understanding that the reader already
> knows fees exist and need to be paid.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220219/93018285/attachment.html>