[Bitcoin-ml] Malleability fix proposal`

I'm going to step in here from the perspective of a developer who interfaces with Bitcoin but doesn't develop the Bitcoin software itself. Transaction formats, to people like me, aren't very important. People who build businesses, wallets, and applications that use Bitcoin just want easy to use libraries that offer useful features. Discussions like these verge on the "PHP vs Python" or "JSON vs XML" battles. Just like those, there are pros and cons to different choices but we end-developers and end-users don't care about those choices. To you it's valid arguments on very important foundational matters, but to us it's bike-shedding. What is important to us is *features*, and FlexTrans offers some significant features that would help make Bitcoin exciting again. Flexible Transactions adds the most significant transaction-level feature that we've seen yet: the ability to add arbitrary fields without invalidating the transaction. There is one major missing piece that is missing that I think would make Flexible Transactions much more significant. I'm hoping that Tom Zander can chime in with his insight. At the moment it appears that the tags and data are all signed, the signature appended, followed by TxEnd, and then broadcast. This prevents users from crafting transactions with tags that are specifically flagged as being ephemeral data that can be pruned before it's written to the block. Removing any tags would invalidate the transaction signature. If the tags are added outside of the signature block, which doesn't even seem to be an option in the current spec, then they are vulnerable to malleability attacks. Would it be possible to extend the transaction format to support multiple signed stacks that can indicate if the stack is supposed to be ephemeral and should be pruned before block inclusion? Some services might listen to the network and store those ephemeral stacks for later query, but they aren't important enough to be stored in the blockchain. If Flexible Transactions can support ephemeral stacks, I anticipate that we'll see fields including, but not limited to: * Identifying the transaction maker for some miners to give priority processing (Maybe a faucet has a deal with a small miner pool for dirt-cheap transactions or Bitpay has a deal with a big pool for set-fee rates) * Transaction level proof-of-work as an augmentation for transaction fees that some miners respect * Some kind of non-binding priority flag or request for processing at a certain block height * A field to indicate a vote on some network-wide issue * A field to indicate the refund address as a more flexible alternative to BIP70 payment protocol * A field referencing another transaction hash and a request not to process this transaction until the other one is in a block. * A field with an order number or email address or webhook * A field advertising the client and version that crafted the transaction (what wallet software, etc) The ability for nodes to add their own ephemeral stacks to transactions might prove useful. * Nodes who detect double-spends to pass on the transaction but attach a warning of the detection. * Nodes might tag timestamps to the transactions they see and relay to help with network-wide propagation statistics. * Nodes could add their own transaction-level proof-of-work or identification for priority processing by a certain pool. Good for apps on a mobile phone that craft and sign transactions and submit them to a specific service for broadcast and relay. If Flexible Transactions can include ephemeral tag stacks, then the transaction processor should be extended with a framework to support user-created external scripts triggered by tags. This will allow miners and nodes to be able to trigger certain actions based on the existence of specific tags and data in those stacks. Summary: Changing the transaction format is a big undertaking but there are significant potential benefits that makes it worthy of serious consideration.