š
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
Erik Aronesty [ARCHIVE] /
npub1y2ā¦5taj0
2023-06-09 13:03:55
in reply to nevent1qā¦404e
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-09 13:03:55Event JSON
{
"id": "4ea3b27cdcce997864e5cf7946a797cc7b233790ba6d123972ff99f8aca9de05",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686315835,
"kind": 1,
"tags": [
[
"e",
"051e2fa4433ba1f2b07138a1681c2429af218c1f2f601189fc0f95041ae2ca20",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "š
Original date posted:2021-10-01\nš Original message:\nmostly thinking out loud\n\nsuppose there is a \"lightweight\" node:\n\n1. ignores utxo's below the dust limit\n2. doesn't validate dust tx\n3. still validates POW, other tx, etc.\n\nthese nodes could possibly get forked - accepting a series of valid,\nmined blocks where there is an invalid but ignored dust tx, however\nthis attack seems every bit as expensive as a 51% attack\n\nOn Fri, Oct 1, 2021 at 3:45 AM Pieter Wuille via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Jumping in late to this thread.\n\u003e\n\u003e I very much agree with how David Harding presents things, with a few comments inline.\n\u003e\n\u003e āāāāāāā Original Message āāāāāāā\n\u003e On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e \u003e \u003e 1. it's not our business what outputs people want to create\n\u003e \u003e\n\u003e \u003e Every additional output added to the UTXO set increases the amount of\n\u003e \u003e work full nodes need to do to validate new transactions. For miners\n\u003e \u003e for whom fast validation of new blocks can significantly affect their\n\u003e \u003e revenue, larger UTXO sets increase their costs and so contributes\n\u003e \u003e towards centralization of mining.\n\u003e \u003e Allowing 0-value or 1-sat outputs minimizes the cost for polluting the\n\u003e \u003e UTXO set during periods of low feerates.\n\u003e \u003e If your stuff is going to slow down my node and possibly reduce my\n\u003e \u003e censorship resistance, how is that not my business?\n\u003e\n\u003e Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus rules fail to account\n\u003e for. Having a relay policy that avoids at the very least economically irrational behavior makes\n\u003e perfect sense to me.\n\u003e\n\u003e It's also not obvious how consensus rules could deal with this, as you don't want consensus rules\n\u003e with hardcoded prices/feerates. There are possibilities with designs like transactions getting\n\u003e a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without\n\u003e introducing bad incentives.\n\u003e\n\u003e \u003e \u003e 2. dust outputs can be used in various authentication/delegation smart\n\u003e \u003e \u003e contracts\n\u003e \u003e\n\u003e \u003e \u003e 3. dust sized htlcs in lightning (\n\u003e \u003e \u003e https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)\n\u003e \u003e \u003e force channels to operate in a semi-trusted mode\n\u003e \u003e\n\u003e \u003e \u003e 4. thinly divisible colored coin protocols might make use of sats as value\n\u003e \u003e \u003e markers for transactions.\n\u003e\n\u003e My personal, and possibly controversial, opinion is that colored coin protocols have no business being on the Bitcoin chain, possibly\n\u003e beyond committing to an occasional batched state update or so. Both because there is little benefit for tokens with a trusted\n\u003e issuer already, and because it competes with using Bitcoin for BTC - the token that pays for its security (at least as long as\n\u003e the subsidy doesn't run out).\n\u003e\n\u003e 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\n\u003e voice hesitancy to worsening the system's scalability properties only to benefit what I consider misguided use.\n\u003e\n\u003e \u003e \u003e 5. should we ever do confidential transactions we can't prevent it without\n\u003e \u003e \u003e compromising privacy / allowed transfers\n\u003e \u003e\n\u003e \u003e I'm not an expert, but it seems to me that you can do that with range\n\u003e \u003e proofs. The range proof for \u003edust doesn't need to become part of the\n\u003e \u003e block chain, it can be relay only.\n\u003e\n\u003e Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, which could be required as part of a relay policy.\n\u003e\n\u003e Cheers,\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "fe3b0a3a0189736365993bdda15483036d1795395ba58d6d2c26046bfd03ae1612f7402349856250a1619987aa711779ba7b0f264b16cf8aad612646b9bca359"
}