This change is longer than preferred, because mTemplates is a map, and as such, the notion of “variant of TX_PUBKEYHASH” is poorly supported.
TX_PUBKEYHASH_*DATA was added, but is largely to quiet compiler warnings, because it is mapped to TX_PUBKEYHASH everywhere, including Solver()’s transaction-type return value.
Intended to enable use cases such as Mike Hearn’s distributed bond markets: https://bitcointalk.org/index.php?topic=92421.0
NAK.
The intended application doesn’t currently exist, so we can’t know that the change is necessary and sufficient to enable it— or am I mistaken? Can you point to its transactions in the chain?
Instead, this would enable a large amount of harmful usage while concurrently removing the incentive to develop and adopt the appropriate payment protocols and overlay networks which would enable them without selling Bitcoin’s future for some short term gains. Redone with more aggressive limits would probably elevate my opinion to MEH, but I’d be concerned that they’d break the intended use case too.
NIT: you’d save a byte by using OP_2DROP instead of DROP DROP
I’m torn on whether or not it is time to implement a standard OP_DROP transaction type. If we do, it feels to me like it should be:
0..64-or-fewer bytes.. OP_DROP ..n.. ..pubkeys.. ..m.. OP_CHECKMULTISIG
64 bytes because 64-byte SHA3 hashes are likely to be common in the next ten years. CHECKMULTISIG instead of CHECKSIG because that gives the most flexibility. And pubkeys instead of a pubkeyhash because I suspect wrapping these in a P2SH transaction will be useful.
You should be able to do whatever you need with one max-64-byte push instead of two max-32-byte pushes. E.g. for distributed bonds the transaction might be
0 PUSH("ISSUE<32-byte-hash>") DROP 1 <pukey> 1 CHECKMULTISIG
Services interested in bond transactions would look for ISSUE+exactly 32 bytes.
RE: removing the incentive to adopt appropriate payment protocols: If there is no new bitcoin address type corresponding to this transaction type, then I don’t think that is an issue.
RE: limits: the intent has always been to move away from hard-coded limits and create a market for transactions based on size, priority and fees paid. Perhaps the right thing to do is allow these as standard transactions, but drop them if they don’t meet the minimum fee threshold (disallow them as “free” transactions).
As I enumerated on Jeff’s call out for mob support ( :P ) , the actually likely applications of this are instant messaging, txn source deanonymization, and timestamping. The first two should be correctly addressed by a payment protocol (optionally via a p2p network), the latter should be accomplished via coinbase timestamping. There would be no reason to develop either of those functions with this transaction type made standard, except preserving Bitcoin’s long term viability. I don’t see how a new address type comes into play there.
Disallowing them as free transactions is elegant. I do like that. I don’t like that this incentivizes script pubkey bloat over scriptsig bloat, mostly because our priority calculation is currently inadequate (treats scriptpubkey and scriptsig size the same).
Updated commit with the following changes:
80 bytes was chosen because OP_DROP + OP_DROP was intended to enable “hash + tiny bit of metadata” as shown in proposals. If the presumed hash size is 64, we want a bit extra.
RE fees: great suggestion. I am now endeavoring to figure out how to disable free transactions for TX_MULTISIG_DATA, and will do so in a separate commit.
RE use cases: as I stated in IRC, I am working on a basic version of TD’s distributed bond proposal right now. I also feel quite strongly that the ability to attach a tiny bit of data to your own transaction should be a fundamental right of every bitcoin user, even unrelated to the distributed bond proposals. The use case crops up again and again, and people are doing to do it anyway, whether we like it or not. See Hal’s description of a standard transaction that right now may be [ab]used for data storage, for example.
@jgarzik You actually think that people have a fundamental right to force third parties to perpetually store information unrelated to securing and inflation proofing Bitcoin as a price of being able to contribute their participation to the decentralized trust the Bitcoin is secure and inflation proof. I don’t agree.
If you instead want to say that creating costs unrelated to operating the currency for users is regrettable but sometimes unavoidable, and that it’s better to enforce some least harmful methods in order to discourage some more harmful ones (e.g. paying to bogus pubkeys) I would agree…. but so long as the OP_DROP data is in scriptpubkey instead of scriptsig, it’s not really a least harmful method.
Dropped data can be left out of the working set as it can’t affect spendability, I think? That means the only cost is disk storage, not disk seeks or memory, and rarely accessed disk storage is cheap. You can buy a terabyte hard disk for almost nothing these days.
This does remind me a lot of the DNS discussions. We definitely don’t want totally random data-intensive applications to stuff data into the chain, for legal reasons if nothing else. On the other hand, financial applications that need to strongly associate data with a particular financial transaction don’t seem unreasonable. Satoshi said once that he spent a long time trying to find a way to allow messages in transactions:
“I badly wanted to find some way to include a comment with indirect transfers, but there just wasn’t a way to do it. Bitcoin uses EC-DSA, which was essential for making the block chain compact enough to be practical with today’s technology because its signatures are an order of magnitude smaller than RSA. But EC-DSA can’t encrypt messages like RSA, it can only be used to verify signatures.”
Sometimes it makes me wonder … if he’d known how to do encryption using the same keys, would v0.1 of Bitcoin have allowed size-limited text messages?
I think the restrictions Gavin proposes would mean any IM system (etc) would be uncompetitive with a well implemented payment protocol.
It’s possible to be too extreme about shrinking the chain. For instance, it’s technically possible to do threshold signatures without CHECKMULTISIG by using secret sharing (see Ibrahim, Ali and EI-Sawy). So maybe CHECKMULTISIG should be made non-standard to encourage somebody to implement that. Or … maybe we should just accept the efficiency hit and get threshold signatures deployed earlier. In practice we chose the latter. You could make the same arguments for addresses (they mean long term storage of a hash, key and sig instead of just a key and sig).
Let’s see what Jeff comes up with. If he builds a really compelling bond market app on testnet and people want to use it, it’ll be easier to judge the costs and benefits.
I agree with @sipa. Only data that is strictly necessary for the world to validate a transaction has a place in the block chain. That’s the whole point of it. Everything that is only significant to the sender and receiver (or miner) should be between the sender and receiver (or miner) and doesn’t need to be stored forever by every other full node in the world.
Really I’d love sending some metadata with transactions for UI purposes, or even messaging between users, but this data should ideally be transient and not carved in stone in the block chain. That just feels wrong.
Would it be possible to have an expiration date on the information? So that the OP_DROP could truly be dropped after some time? I guess not, if they’re hashed into the transaction…
Actually I remembered just after I posted my last message that you do need the entire script in the uxto set because of how the signature hash is calculated.
OTOH I thought of something else - setting aside the uxto set, in terms of long term storage, this kind of thing is fairly neutral. <20 bytes of data> DROP 1 CHECKMULTISIG + a scriptSig is a hash, a key and a sig …. same as a pay-to-address output. Is 20 bytes enough? Well, if it’s just a pointer to some other data store then it’s fine.
526+ }
527+ }
528+
529+ // OP_DATA multisig transactions are never free
530+ if (IsDataCarrier())
531+ nMinFee = nBaseFee;
There’s a lot of interest in oracles coming down the line, it seems, and that’s a use case for this kind of transaction.
If someone popped up with an actual working server that did this, I feel we’d be able to justify the OP_DROP OP_CHECKMULTISIG form.