Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-01 📝 Original message: mostly thinking out loud ...
📅 Original date posted:2021-10-01
📝 Original message:
mostly thinking out loud
suppose there is a "lightweight" node:
1. ignores utxo's below the dust limit
2. doesn't validate dust tx
3. still validates POW, other tx, etc.
these nodes could possibly get forked - accepting a series of valid,
mined blocks where there is an invalid but ignored dust tx, however
this attack seems every bit as expensive as a 51% attack
On Fri, Oct 1, 2021 at 3:45 AM Pieter Wuille via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Jumping in late to this thread.
>
> I very much agree with how David Harding presents things, with a few comments inline.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > > 1. it's not our business what outputs people want to create
> >
> > Every additional output added to the UTXO set increases the amount of
> > work full nodes need to do to validate new transactions. For miners
> > for whom fast validation of new blocks can significantly affect their
> > revenue, larger UTXO sets increase their costs and so contributes
> > towards centralization of mining.
> > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the
> > UTXO set during periods of low feerates.
> > If your stuff is going to slow down my node and possibly reduce my
> > censorship resistance, how is that not my business?
>
> Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically irrational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules could deal with this, as you don't want consensus rules
> with hardcoded prices/feerates. There are possibilities with designs like transactions getting
> a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without
> introducing bad incentives.
>
> > > 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
> >
> > > 4. thinly divisible colored coin protocols might make use of sats as value
> > > markers for transactions.
>
> My personal, and possibly controversial, opinion is that colored coin protocols have no business being on the Bitcoin chain, possibly
> beyond committing to an occasional batched state update or so. Both because there is little benefit for tokens with a trusted
> issuer already, and because it competes with using Bitcoin for BTC - the token that pays for its security (at least as long as
> the subsidy doesn't run out).
>
> Of course, personal opinions are no reason to dictate what people should or can use the chain for, but I do think it's reason to
> voice hesitancy to worsening the system's scalability properties only to benefit what I consider misguided use.
>
> > > 5. should we ever do confidential transactions we can't prevent it without
> > > compromising privacy / allowed transfers
> >
> > I'm not an expert, but it seems to me that you can do that with range
> > proofs. The range proof for >dust doesn't need to become part of the
> > block chain, it can be relay only.
>
> Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, which could be required as part of a relay policy.
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:
mostly thinking out loud
suppose there is a "lightweight" node:
1. ignores utxo's below the dust limit
2. doesn't validate dust tx
3. still validates POW, other tx, etc.
these nodes could possibly get forked - accepting a series of valid,
mined blocks where there is an invalid but ignored dust tx, however
this attack seems every bit as expensive as a 51% attack
On Fri, Oct 1, 2021 at 3:45 AM Pieter Wuille via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Jumping in late to this thread.
>
> I very much agree with how David Harding presents things, with a few comments inline.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > > 1. it's not our business what outputs people want to create
> >
> > Every additional output added to the UTXO set increases the amount of
> > work full nodes need to do to validate new transactions. For miners
> > for whom fast validation of new blocks can significantly affect their
> > revenue, larger UTXO sets increase their costs and so contributes
> > towards centralization of mining.
> > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the
> > UTXO set during periods of low feerates.
> > If your stuff is going to slow down my node and possibly reduce my
> > censorship resistance, how is that not my business?
>
> Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically irrational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules could deal with this, as you don't want consensus rules
> with hardcoded prices/feerates. There are possibilities with designs like transactions getting
> a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without
> introducing bad incentives.
>
> > > 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
> >
> > > 4. thinly divisible colored coin protocols might make use of sats as value
> > > markers for transactions.
>
> My personal, and possibly controversial, opinion is that colored coin protocols have no business being on the Bitcoin chain, possibly
> beyond committing to an occasional batched state update or so. Both because there is little benefit for tokens with a trusted
> issuer already, and because it competes with using Bitcoin for BTC - the token that pays for its security (at least as long as
> the subsidy doesn't run out).
>
> Of course, personal opinions are no reason to dictate what people should or can use the chain for, but I do think it's reason to
> voice hesitancy to worsening the system's scalability properties only to benefit what I consider misguided use.
>
> > > 5. should we ever do confidential transactions we can't prevent it without
> > > compromising privacy / allowed transfers
> >
> > I'm not an expert, but it seems to me that you can do that with range
> > proofs. The range proof for >dust doesn't need to become part of the
> > block chain, it can be relay only.
>
> Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, which could be required as part of a relay policy.
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev