Replying to Avatar Kis Sean

https://podcasts.google.com/u/1/feed/aHR0cHM6Ly9uYWRvYnRjLmxpYnN5bi5jb20vcnNz/episode/YWQwYzRmZTktZTY5Ny00NzQwLTlmNWYtYTIyNWExZjJjNTg2?sa=X&ved=0CAUQkfYCahcKEwjY0NOtw4r-AhUAAAAAHQAAAAAQLA

“Bitcoin, Explained 75: Multisig (And Musig)”

This podcast explain different types of multisig throughout BTC's history. Some points I find interesting:

- Before taproot, there are actually a limited amount of signatures of a script, it's tie to the limit of script size. Script includes all the signatures from multisig, so it limits how many signatures/keys will be there

- taproot doesn't required signature count, so it bypassed the limit imposed in the code. But the consensus code has another restriction, the stack can hold up to 1000 signatures/keys. (*but seems like that in the future, you can use a tree to extended it significantly? Not sure how that works)

-Signatures are evaluated to public keys to unlock funds. Taproot enable combining multiple keys into one key, the same applies to signature. The introduction of Schnorr signatures make it possible which the old ECDSA wouldn't be able to provide this feature (But it's still not quantum resistant). It will boost the evaluation time by a lot. But there are some drawbacks, the generation time of combining keys/signatures will grow exponentially with every key/signature added.

#BTC #Blockchain # multisig #signature #SegWit #BitcoinCore

https://podcasts.google.com/feed/aHR0cHM6Ly9uYWRvYnRjLmxpYnN5bi5jb20vcnNz/episode/YTQ1YTI3MWYtODZiNS00MjM0LWJmMTItY2MyMTJmOWZmOWZj?ep=14

"Bitcoin, Explained 72: Inscriptions"

This episode basically explain how arbitrary data is store on the blockchain throughout history:

- Before op return, there are fake utxos/transactions/bounded unspent tokens, which is on chain data pretend to be a transaction. Op return offers 80 bytes total size to store data, which is lightly more attractive than those fake transactions. What's important about this is that transactions are stored in RAM for easy access in the consensus code, so fake transactions also increase unnecessary overhead across the network.

- How inscription bypass this is by storing data in the input/witness data; This doesn't need to be in RAM once the utxo is spent. Only outputs(transactions before spent) need to be in RAM constantly. This is enabled by taproot.

- There are some controversies around this, one is that average node runner who doesn't use the inscription software(used to decode that inscription data), cannot detect what are those inscription data(the cost is too high). So they won't be able to strip that out that part, which take up extra bandwidth across the whole network. If those data got strop out, there's another problem, the mempools won't be consistent so that it's hard to verify past transactions. This splits the network.

-The controversy around taproot is that, taproot is supposed to make transactions easier to bound together and easier to process. But the current reality is that nodes are allowing all kinds of images on chain, that makes normal transaction way more expensive.

#BTC #Blockchain #Ordinals #Inscription #Taproot

Reply to this note

Please Login to reply.

Discussion

No replies yet.