nostr relay proxy

event page

{"id":"d056cbaf6f7421ed261bc5eb1bd0437e103a9713b53787789f6dada555190161","pubkey":"cbc5ef6b01cbd1ffa2cb95a954f04c385a936c1a86e1bb9ccdf2cf0f4ebeaccb","created_at":1728285973,"kind":1,"tags":[["p","66c292bee0a69c221aebd2f288ffe1efaa3163217161c9539337e2b0dd55136a"],["r","https://delvingbitcoin.org/t/draft-bip-for-op-txhash-and-op-checktxhashverify/121"],["r","https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html"],["r","https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki"]],"content":"in the last post we talked about how we need introspection to make more restrictive statements about where bitcoin is allowed to be spent. for example, to only let the bitcoin be spent in a transaction that pays nifty 500k of the sats.\n\nhow do we make introspection happen in bitcoin scripts? thereā€™s a couple of proposals, each one a bit more involved than the last. weā€™ll start with the simplest proposal, and work our way to the most complex.\n\nthe simplest is probably the least well known: op-tx. this opcode will take a flagset as its input. the flagset ā€œflagsā€ which parts of the tx should be added onto the stack. the interpreter will look at the flags, find that data in the tx, and then pull it in by putting it on the stack.\n\nonce the data is pushed onto the stack, you can make assertions about that data. for example, you could flag to op-tx to push the first output amount and script onto the stack. this would then let you check that the tx is sending at least 500k sats to niftyā€™s address.\n\nop-tx is very simple, but powerful. thereā€™s open questions about how to design the flags that refer to different parts of a transaction, as well as how expensive it can be to do operations on the data. could you maybe make a script that has too long of a run time because of having access to so much transaction data? thereā€™s also issues with limited amounts of data being allowed onto the stack, which you might run into if the tx info is too big.\n\nto try to alleviate concerns about access to too much data, op-txhash has been proposed.\n\ntxhash works similarly, in that it lets you define a flagset which points to different parts of the transaction. instead of pushing the data directly onto the stack, however, it instead hashes the data and pushes the resulting *hash* onto the stack.\n\nso if i wanted to check that the first output of the transaction paid me 500k sats, iā€™d have to figure out the hash of that when writing the locking script. iā€™d then use op-txhash to push the hash of the first output onto the stack, and them compare that to the one i calculated when i first locked the coins up. instead of looking at data directly, weā€™re looking at hashes of data.\n\nthere are some downsides to using hashes. for example, this makes it impossible to do comparisons like ā€œat leastā€ 500k sats sent to nifty. youā€™d have to only accept txs that send exactly 500k sats.\n\nusing hashes has definite upsides though. you can verify a lot more information in a single check. for example instead of checking the amount and address separately, youā€™d check a single hash value that compares them both. this also saves space, and reduces the number of checks that need to be done.\n\nwhich brings us to op-ctv. op-ctv is an opinionated version of op-txhash. instead of allowing you to choose what set of fields from a tx you want to hash and check against, it picks a fixed set of data from the tx that goes into the hash. this means you need a better understanding of exactly what the tx your bitcoin will be spent in to use ctv. you canā€™t just compare the first outputā€™s hash, for example.\n\nop-ctv stands for ā€œcheck template verifyā€; the ā€œtemplateā€ in this case is the fixed set of fields in a tx that will be hashed together.\n\none downside to using op-ctv is that you canā€™t change the amounts or outputs in the spending tx, which makes it more difficult to add fees later to ensure the tx can be mined.\n\nok thatā€™s a good stopping point for the ā€œsimpleā€ hash and direct access proposals for introspection opcodes in bitcoin scripting.\n\nin the next post weā€™ll look at the craziest way that introspection can be added to bitcoin: op-cat šŸ± \n\nenjoying this series about covenant proposals? learn more about how txs work with nostr:npub1vmpf90hq56wzyxht6teg3llpa74rzcepw9suj5unxl3tph24zd4qgtxhm7 online classes šŸ‘Œ \n\n\nRead more about TXHASH and how it relates to CTV/TX here: https://delvingbitcoin.org/t/draft-bip-for-op-txhash-and-op-checktxhashverify/121\n\nOriginal proposal for op-tx is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html\n\nOp-ctv you can find out more about on the Bip119: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki","sig":"4cbdb719a23445eb2637f42f70b6710c7136eb3082bdd9d9356013dabd15ebbc6d2872ba426394e3ae4a63228c3516c5447981e42147c265827f7a7399db4208"}

rendered in 195.73Āµs