š
Original date posted:2023-02-22
šļø Summary of this message: The discussion is about the possibility of filtering inscription scripts to be "plausible" and increasing their space cost, but the proposed increase of 1% is considered trivial.
š Original message:On Sat, Feb 18, 2023 at 01:28:38AM +0000, Andrew Poelstra wrote:
> On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote:
> > On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev
> > >You could try statically analyze `<anything>` to determine whether the
> > >IF branch could ever be taken. For example there is no path through
> > >the "inscription script" that would result in all the crap being dropped
> > >by the end of the script, violating the CLEANSTACK rule.
> > >
> > >This sort of filtering, assuming it could be reliably and efficiently
> > >done, would at least force inscription scripts to be "plausible", and
> > >would greatly increase their space cost by e.g. requiring OP_DROP to be
> > >added somewhere hundreds of times.
> >
> > "greatly increase their space cost"?
> >
> > Tell me, what is the actual % increase to adding OP_DROPs like you propose?
> >
>
> By standardness rules (where you can have up to 80-byte pushes), a
> little over 1%. By consensus (520-byte pushes) less than 0.2%.
>
> Perhaps "greatly increase" is a stretch :) but if the fee market is
> functioning and we're talking about large amounts of data, it's not
> trivial either.
I would definitely call ~1% trivial. Fees vary more by that on an hour to hour
basis.
Anyway, it goes to show that protocols relying on data embedded in Bitcoin
transactions would do well to have flexible encoding rules, eg by considering
all PUSHDATA's with certain characteristics to be data, so that encoders can be
adapted on the fly if there are any censorship issues. It's also useful if the
rules allow data to be encoded in UTXO outputs, so that censorship of witness
data always risks people switching to filling up the UTXO set. A kind of
Mutually Assured Destruction threat in a way.
FWIW, OpenTimestamps was deliberately designed to have this property. So don't
mess with it. :D
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230222/4d5cfae9/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 23:19:36
in reply to nevent1qā¦y6df
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:19:36Event JSON
{
"id": "6cc3cedd9c80acf749cab5398b747029761162482d8025d6ceb00836ba84b5ee",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686179976,
"kind": 1,
"tags": [
[
"e",
"7807d3e04dc01ad8077ddad8da65b8db69c52be6b75b739ede7749117e75dd4a",
"",
"root"
],
[
"e",
"6b835918d19a73fd4eb8e197429712118f226631847d77195c7d6da02ab45083",
"",
"reply"
],
[
"p",
"ee55eb03423bd4db01d5c92ad434d52c602d9da1de37ed37cc5bf7d2a13a4cab"
]
],
"content": "š
Original date posted:2023-02-22\nšļø Summary of this message: The discussion is about the possibility of filtering inscription scripts to be \"plausible\" and increasing their space cost, but the proposed increase of 1% is considered trivial.\nš Original message:On Sat, Feb 18, 2023 at 01:28:38AM +0000, Andrew Poelstra wrote:\n\u003e On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote:\n\u003e \u003e On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev \n\u003e \u003e \u003eYou could try statically analyze `\u003canything\u003e` to determine whether the\n\u003e \u003e \u003eIF branch could ever be taken. For example there is no path through\n\u003e \u003e \u003ethe \"inscription script\" that would result in all the crap being dropped\n\u003e \u003e \u003eby the end of the script, violating the CLEANSTACK rule.\n\u003e \u003e \u003e\n\u003e \u003e \u003eThis sort of filtering, assuming it could be reliably and efficiently\n\u003e \u003e \u003edone, would at least force inscription scripts to be \"plausible\", and\n\u003e \u003e \u003ewould greatly increase their space cost by e.g. requiring OP_DROP to be\n\u003e \u003e \u003eadded somewhere hundreds of times.\n\u003e \u003e \n\u003e \u003e \"greatly increase their space cost\"?\n\u003e \u003e \n\u003e \u003e Tell me, what is the actual % increase to adding OP_DROPs like you propose?\n\u003e \u003e\n\u003e \n\u003e By standardness rules (where you can have up to 80-byte pushes), a\n\u003e little over 1%. By consensus (520-byte pushes) less than 0.2%.\n\u003e \n\u003e Perhaps \"greatly increase\" is a stretch :) but if the fee market is\n\u003e functioning and we're talking about large amounts of data, it's not\n\u003e trivial either.\n\nI would definitely call ~1% trivial. Fees vary more by that on an hour to hour\nbasis.\n\nAnyway, it goes to show that protocols relying on data embedded in Bitcoin\ntransactions would do well to have flexible encoding rules, eg by considering\nall PUSHDATA's with certain characteristics to be data, so that encoders can be\nadapted on the fly if there are any censorship issues. It's also useful if the\nrules allow data to be encoded in UTXO outputs, so that censorship of witness\ndata always risks people switching to filling up the UTXO set. A kind of\nMutually Assured Destruction threat in a way.\n\nFWIW, OpenTimestamps was deliberately designed to have this property. So don't\nmess with it. :D\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230222/4d5cfae9/attachment.sig\u003e",
"sig": "5fdea9827917a458ace39b36ae53b6deca82033ffd48b799df2300d38a958337740776d898611d7e76dad57ccc2e15b4da7fd31b8c0124397131ec2d9dced772"
}