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