One more side note, if you’re looking at BCH ops then look at GROUP, not DSV. Despite what coingeek has published, OP_PUSH_TX does not enable the same generality, for the reason the commenter @joe responded in that thread by scrypt guy
Post by twetch#3613
- i hope you figure out some merkle magic to track back! what did @xhilu say?
- GROUP was not forked in though, OP_DSV was. ugly politics surrounded all that.
What the chain says
- Block
- 657 770
- Time
- 2020-10-21T00:51:45Z
- Signer
- 1C2LvcNr78cS29qkiLEqhLsDWJ1ECJ1Ktc
- App
- twetch
- Type
- post
- Content type
- text/plain
- Name in tx
- twetch#3613
Fields the transaction did not carry are omitted. Open the payload to see the bytes as stored.
Signed by
1C2LvcNr78cS29qkiLEqhLsDWJ1ECJ1Ktc VerifiedReplies (4)
- re "zero drawbacks": there is an enormous legal/PR advantage to being able to say that, strictly speaking, BSV is bitcoin (it follows the original protocol). start pushing changes and you lose that . . .
- He made a thinking face but so far we haven't come up with anything yet. 2 is good to know, although the flip side to the benefits of a finalized protocol is how frustrating it is that BSV's original L1 appears to be "so close yet so far".
For completeness, the other most promising solution is to simply make a generalized unique ID tree that is enforced by miners (although many in the BSV camp would have to reconcile that with their position that all soft forks are "malware").
have you seen this doc?
posting it in case it is useful to you.