|
Title: 5 Bitcoin Script quirks that every Blockchain developer should know Post by: gjgd on November 07, 2021, 07:55:53 PM Hi! I wrote an article about Bitcoin Script and thought I'd share: https://gjgd.medium.com/5-bitcoin-script-quirks-that-every-blockchain-developer-should-know-2b4bf05a9aae
First time poster, please let me know if this board is not the appropriate place to post it Title: Re: 5 Bitcoin Script quirks that every Blockchain developer should know Post by: titular on November 08, 2021, 02:38:42 AM Hi! I wrote an article about Bitcoin Script and thought I'd share: https://gjgd.medium.com/5-bitcoin-script-quirks-that-every-blockchain-developer-should-know-2b4bf05a9aae First time poster, please let me know if this board is not the appropriate place to post it A lot of people here a pretty hesitant to click random links. You should just paste the write up directly on here! Title: Re: 5 Bitcoin Script quirks that every Blockchain developer should know Post by: pooya87 on November 08, 2021, 04:08:47 AM Quote and contains a scriptSig field (the unlocking script) which contains data necessary to spend the transaction After August 2017 when we got SegWit, another field in each transaction was added called "witness" where we store stack items used in "unlocking" the output. In fact every tx spending a SegWit output has an empty signature script.Quote To verify the validity of a transaction, scriptSig data is appended to scriptPubKey data Wrong.Each script is evaluated/executed separately. Appending the data is a source for a bug which was fixed in early days. Quote It consists of a small set of 255 “asymetric cryptography specific” op codes OP codes can be from 0 to 255 but there are actually a lot less OP codes defined than 255 (8-bit) since many values are not yet defined and a handful of old ones were disabled.Quote a bug in the OP_CHECKMULTISIG implementation Although commonly referred to as a bug, I don't think this was actually a bug.I believe that it was a "feature" meant for scalability. Imagine if you wanted to introduce a soft fork where you changed how OP_CHECKMULTISIG works and add additional steps to it. You could technically introduce the new rules for that extra item and the new nodes would pop it, evaluate it as a script and return true/false while old nodes simply ignore it (ie. a soft fork). Keep in mind that prior to SegWit, BIP-147 (mandating the dummy item to be OP_0) was not enforced. Quote Since Segwit, OP_RETURN is also used to store the merkle root of the witness data in Segwit transactions. Clarification: only used in coinbase transaction and is mandatory only if the block contained any SegWit transactions.Quote Because of the need for backward compatible changes in Bitcoin It is not a "need" but a "preference".Title: Re: 5 Bitcoin Script quirks that every Blockchain developer should know Post by: gjgd on November 08, 2021, 04:42:12 AM Thanks pooya, appreciate the clarifications. I updated the post
Title: Re: 5 Bitcoin Script quirks that every Blockchain developer should know Post by: franky1 on November 08, 2021, 05:32:13 AM blockchains are just about header data.
blockchains can still function without any transactions (research empty blocks) any blockchain developer can put in any 'user data' below the header data. it does not have to be transactional, nor need to be using any of the bitcoin tx format rules. so not all blockchain developers need to know. unless you mean bitcoin forkers.. .. but um.. they are not really blockchain developers. they are just copy/paster script kiddies unless you mean crapcoin makers using bitcoin 2009-201X source code.. either way. topic title needs an edit |