Embed *entire directories* of arbitrary data contiguously in BIP110 valid blocks \ stacker news

pull down to refresh

Embed *entire directories* of arbitrary data contiguously in BIP110 valid blocks x.com/steverabinow/status/2085703735762698466

13.9k sats \ 22 comments \ @Scoresby 7 Aug bitcoin

You may have seen Farside Insights (nee BitMex Research) posting about a strange "spam" transaction mined by one of the BIP110 signalling miners (Roughnecks):

The transaction in question was in block 960235:

Farside Insights was thought it was odd because the block was not seen by other mempools and speculated that it may have come from an insider at Roughnecks:

In conclusion, this may indicate that there is an insider at Roughnecks, perhaps not entirely happy with the BIP-110 cause and is putting non-standard spam in blocks, using an out-of-band relay system

But however the transaction got into the block, it seems to be compliant with all BIP110 rules.

Not long after this, the ever-exciting Steve (@steverabinow) posted another entry in his ongoing series BIP110 Advent claiming to be able to embed up to 400kb tar.gz compressed archives in valid BIP110 blocks:

Steve also claims that the insider referred to in his post is actually just "sloppy code":

Let us please stop trying to prevent "spam" transactions via tightened rules. The fee market and block height limits are enough to effectively prevent spam on Bitcoin.

view all related items

392 sats \ 8 replies \ @optimism 7 Aug

One man's spam is another man's ham.

Fee market doesn't fix that because there is nothing to fix. Do realize that there will be a tweeter full of people being absolutely terrified if the fee market prices out their set of 10k sat utxos for an extended period.

There is definitely a weakness in embedding arbitrary data. But BIP-110 is simply not the right way to address it, I think, and it is better to be aware of the weakness and let it be such than to try to introduce questionable code without an expectation of consensus.

418 sats \ 6 replies \ @Scoresby OP 7 Aug

There is definitely a weakness in embedding arbitrary data

If we believe this to be true (and I do), what do you think is a reasonable response?

There have been many proposals over the last few years, and I feel that most of them have failed to be better than paying higher fees. Yes, this will lead to small utxos being priced out, but it seems to me that we are very far from that being a consistent state. And with things like taproot addresses, I wouldn't be surprised if a 1m sat utxo is pretty much always economically viable (I recognize that 1m sats is still quite a lot of money, but in the world where things less than that start to look too expensive, I doubt there will be very much spam at all on the chain).

If we are worried about the cost to noderunners, I believe the blocksize limit is a very safe control there.

228 sats \ 3 replies \ @Filiprogrammer 8 Aug

There is definitely a weakness in embedding arbitrary data
If we believe this to be true (and I do), what do you think is a reasonable response?

Activate Cross-Input Signature Aggregation and remove the witness discount.

11 sats \ 2 replies \ @optimism 8 Aug

Can you remove the witness discount without ignoring incentive formed by having 2 separate limits? I challenged the "witness discount has to be a fork" for a while and I got challenged right back and couldn't find a way to do it without underutilizing available blockspace (i.e. requiring non-profit-maxxing mining).

CISA is awesome conceptually.

244 sats \ 1 reply \ @Filiprogrammer 8 Aug

Removing the witness discount does not hurt miner incentives.
They were mining 1000000 vBytes before, they will be mining 1000000 vBytes afterwards. And vBytes (or Weight Units) are the unit by which fees are measured.

Also since I haven't seen anyone do this before, let's do the math on transaction sizes under different consensus rules.

Consensus Rule ScenariosConsensus Rule Scenarios

Current Rules: No CISA, 75% witness discount
BIP459: CISA Full-Agg, 75% witness discount
BIP459 + Remove Witness Discount: CISA Full-Agg, No witness discount

Transaction TypesTransaction Types

Simple payment with change (1 input, 2 outputs)
3 UTXO Consolidation (3 inputs, 1 output)
5 UTXO Consolidation (5 inputs, 1 output)
10 UTXO Consolidation (10 inputs, 1 output)
Coinjoin (14 inputs, 18 outputs)
~50 kB JPEG Inscription (1 input with data, 1 dust output)

CalculationCalculation

Assuming the use of Schnorr Signatures.

$w$ is the witness cost factor.

$i$ is the input count.

$o$ is the output count.

TX size without CISA:

f (w, i, o) = 10 + 2 w + i * (41 + 66 w) + o * 43

TX size with CISA Full-Agg (Might be off by a byte or two, depends on how it is ultimatelly implemented):

g (w, i, o) = 10 + 2 w + i * 41 + 66 w + o * 43

Simple payment with change (1 input, 2 outputs)Simple payment with change (1 input, 2 outputs)

Current Rules: $f (0.25, 1, 2) = 154$ vBytes
BIP459: $g (0.25, 1, 2) = 154$ vBytes
BIP459 + Remove Witness Discount: $g (1, 1, 2) = 205$ vBytes

33.12% increase

3 UTXO Consolidation (3 inputs, 1 output)3 UTXO Consolidation (3 inputs, 1 output)

Current Rules: $f (0.25, 3, 1) = 226$ vBytes
BIP459: $g (0.25, 3, 1) = 193$ vBytes
BIP459 + Remove Witness Discount: $g (1, 3, 1) = 244$ vBytes

7.96% increase

5 UTXO Consolidation (5 inputs, 1 output)5 UTXO Consolidation (5 inputs, 1 output)

Current Rules: $f (0.25, 5, 1) = 341$ vBytes
BIP459: $g (0.25, 5, 1) = 275$ vBytes
BIP459 + Remove Witness Discount: $g (1, 5, 1) = 326$ vBytes

4.4% decrease

10 UTXO Consolidation (10 inputs, 1 output)10 UTXO Consolidation (10 inputs, 1 output)

Current Rules: $f (0.25, 10, 1) = 628.5$ vBytes
BIP459: $g (0.25, 10, 1) = 480$ vBytes
BIP459 + Remove Witness Discount: $g (1, 10, 1) = 531$ vBytes

15.51% decrease

Coinjoin (14 inputs, 18 outputs)Coinjoin (14 inputs, 18 outputs)

Current Rules: $f (0.25, 14, 18) = 1589.5$ vBytes
BIP459: $g (0.25, 14, 18) = 1375$ vBytes
BIP459 + Remove Witness Discount: $g (1, 14, 18) = 1426$ vBytes

10.29% decrease

~50 kB JPEG Inscription (1 input with data, 1 dust output)~50 kB JPEG Inscription (1 input with data, 1 dust output)

TX size:

f (w) = 10 + 2 w + 41 + 50000 w + 43

Current Rules: $f (0.25) = 12594.5$ vBytes
Remove Witness Discount: $f (1) = 50096$ vBytes

397.76% increase

Let's put it into a table:

	Current Rules	BIP459 + Remove Witness Discount	Change (%)
Simple payment with change	154 vB	205 vB	+33.12%
3 UTXO Consolidation	226 vB	244 vB	+7.96%
5 UTXO Consolidation	341 vB	326 vB	-4.4%
10 UTXO Consolidation	628.5 vB	531 vB	-15.51%
Coinjoin	1589.5 vB	1426 vB	-10.29%
50 kB JPEG Inscription	12594.5 vB	50096 vB	+397.76%

126 sats \ 0 replies \ @Filiprogrammer 8 Aug

Correction: The change from 12594.5 vB to 50096 vB for the 50 kB JPEG inscription is actually a +297.76% increase.

252 sats \ 1 reply \ @optimism 7 Aug

I don't know. If I will find out a good way in the future, I promise that I will write a BIP, get consensus on the change, all that. Burn out on it if I have to. I just know that I've not seen a proposal yet that hits the tradeoffs at the right spot, so until then, I think we should just practice the philosophy shared in Darth's clip from this morning: