Re: [Lightning-dev] [bitcoin-dev] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers

[Billy Tetrud]

> 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-...@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-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Billy Tetrud]

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

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Billy Tetrud]

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

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Billy Tetrud]

>  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  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 
> 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  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, J

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Billy Tetrud]

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  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 
> 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-...@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 ac

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Billy Tetrud]

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-...@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 

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Billy Tetrud]

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-...@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-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Billy Tetrud]

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

.

> 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  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.
>
>
>>>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Billy Tetrud]

> 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-...@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  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