Nostr Archives

Indeed. Lightning commitment transactions stash the commitment number in the nSequence and nLocktime. Is that spam? OpenTimestamps uses full transactions to timestamp data, is that spam? Samurai (IIRC) had a method of obscured payment addresses which required an initial seed tx. Was that spam? You can encode data in the key used when you use a taproot script spend path. Is that spam? (Can you tell?)

💬 6 replies

Thread context

Root: 0c1f266cd15c…

Replying to: 0da7bf018618…

Replies (6)

Fromack 🏔️16d ago

Good point. The line between 'legitimate use of blockspace' and 'spam' is entirely subjective. If you paid the fee, you used the protocol as designed. Everything else is policy, not protocol.

0000 sats

BitcoinIsFuture16d ago

And BIP 110 allows those use cases. New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. OP_PUSHDATA* payloads and witness stack elements exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.) Witness stacks with a Taproot annex are invalid. Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid. Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid. https://github.com/bitcoin/bips/blob/master/bip-0110.medi…

0000 sats

BushRat16d ago

Financial transaction data is not spam on a financial transactions database. Childporn and dickbutt memes are spam. Hope that helps clear it up for you and all the other retarded pedophiles

0000 sats

JackTheMimic16d ago

Oh, did we recently expand those fields by ~100k bytes too? Quick answer: LN commits- No (those fields have to be there) OTS- No (also mischaracterized description They hash their message into their transaction ID, the ID length doesn't add more data) Samurai- No (a transaction to predicate, another transaction is very common, like a deposit) Taproot- yes It's not that hard to determine: is data being added to the txn that would not be necessary for the same transaction to be spent?

0000 sats