Nostr Web Client

https://learnmeabitcoin.com/faq/segregated-witness

About BTC segregated witness.

Very interesting, gives me much more insights, SegWit create a new transaction that move the signature outside of the block. Signatures are used to unlock the transaction to a certain account. Signatures are stored inside the witness data blob (3MB max).

Some interesting points to share:

1. The propagating block size on the internet can be 1MB or up to 4MB. Pre-SegWit nodes only accepts the 1MB max transaction section, but they will not accept the signature data, so they won't verify those transactions. But most nodes are SegWit compatible now (84% according to bitaps), so the size will be sum of transaction section + signature section/witness data blob, which is limited to 4MB under the new rule.

2. After taproot, multi-sig scripts and arbitrary data can be put in witness data blob.

I think it could be the main reason why ordinals happened way after "Defi-summer". Because according to banklesstimes, "BTC's Taproot adoption rate touched its all-time high (ATH) of 4.131%, while its utilization soared to 1.553% ".

3. But since the actual transaction block is only 1MB, everything in the witness data blob gets a 75% off discount. (They didn't anticipate the witness data blob will be used in this way). Plus, there's no rule limiting how much witness data is allowed, so ordinals can fill the data blob up until the 4MB limit (including some necessary data fields).

4. In order for ordinals to success, besides pushing the adaption of taproot, the ordinal client software also need to be widely adapted.

非常有趣，让我有了更多的见解。SegWit创建了一个新的转账方式，将签名移出区块。签名是用于将转账解锁到特定帐户的。现在签名存储在witness data blob（最大3MB）中。

以下是一些要点分享：

1. 在互联网上传播的区块大小可以为1MB或最多4MB。Pre-SegWit节点仅接受最大1MB的，转账数据部分的blob。但它们不会接受签名数据，因此它们不会验证SegWit后这些交易。但现在大多数节点都兼容SegWit（根据bitaps的数据，达到了84％），因此大小将是交易部分+签名部分/witness data blob的总和，该总和在新规则下限制为4MB。

2. 在Taproot之后，多重签名脚本和任意数据可以放入witness data blob中。我认为这可能是为什么ordinals发生在“Defi-summer”之后的主要原因，因为根据banklesstimes的报道，“BTC的Taproot采用率达到了历史最高值（ATH）的4.131％，而其利用率飙升至1.553％”。

3. 但由于实际转账部分仅为1MB，因此见证数据块中的所有内容都会享受75％的折扣。（他们没有预料到witness data blob会以这种方式被使用）。此外，没有规定单witness data blob这部分的上限，因此ordinals可以将witness data blob填满，直到4MB的限制（需要包含一些必要的区块数据）。

4. 想要推ordinals的话，除了推动taproot的采用外，ordinals客户端软件还需要得到广泛的采用。

https://blog.bitmex.com/ordinals-data/

#BTC #SegWit #ordinal #taproot #inscription

Kis Sean 2y ago

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

Reply to this note

Please Login to reply.

Discussion

Kis Sean 2y ago

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