市场解读仅供参考。需要20%起手续费优惠参考币安注册和欧易注册，交易交流来本站电报群。
隔夜美元指数下挫，重新破位104。黄金还在2000以下徘徊。最新经济数据显示，2023 年 11 月美CPI年率放缓至 3.1%，符合预期。然而，与上月相比，价格上涨了0.1%，与预期持平。同时，Core PCE年增长率保持在 4%。目前，市场正等待美联储、欧央和英格兰银行本周晚些时候的政策会议，以了解监管机构对明年初降息的立场。另据彭博社报道，日央官员认为，除非有大量证据表明工资增长能够支持通胀，否则他们不会被迫迅速实施紧缩政策。
隔夜binance抢着把sats铭文给上了，趁着市场刚开始有崩溃迹象，赶紧抢上，仿佛再不上就晚了似的。
下面展开分析一下这次抢上sats，明年升级过滤器后铭文何去何从，以及对casey的另一协议rune（符文）的看法和剖析等。（~ 2500字）
…
今天主要说说sats，铭文，还有ordinal原作者Casey Rodarmor的新协议：Rune（符文）。
先说说binance抢上sats。
首先，binance上ordi比ok晚了5个月。猜测不是它谨慎，或者严肃，而是技术没准备好。
其实binance的技术一直没有ok快。你如果留心观察就很容易发现。
cz是做技术出身的。老徐更是。综合看来，老徐还是更胜一筹。
所以在ordi上，binance是接了个盘。接完盘，刚拉了两波，就崩了。
先是Luke Dashjr进行风险警告，干崩了ordi。
然后整个市场大盘干脆就开始崩溃了。雪上加霜了这是。
可是老让自己用户当接盘侠，平台慢慢就会流失客户的。
所以必须找补一下。
而大盘眼见着这一波红利就要散尽。再不抓紧行动恐怕就迟了。
现去挖掘其他热点又来不及。
于是瞎猫抓死耗子，就赶紧把另外一个铭文sats给上了吧。
研发大半年的技术，也算是复用了。
不过，个人觉得，上sats这个是挺没品的。
为啥呢？因为sats本来就是BTC的最小单位。它这一整，直接李逵当李鬼，给用户认知造成了严重的混淆。
并且未来BTC价位太高之后，可能要拆成sats来显示。它这样一搞，将来怎么处理？
其他平台如果将来改成sats计价，是不是用户会傻傻分不清楚二者？
小白用户更是可能踩坑。想入真sats，却入了假sats。这找谁说理去？
如果cz主政，也许不会允许这种情况发生。
毕竟，感觉上，cz对btc还是有信仰的，而且眼光还算比较长远。
他应该也能考虑到这一层。
但是现在换了领导层，感觉就是变得短视起来，而且对加密的精神完全失去了尊重和敬畏。
算了，吐槽这些也没啥用。反正大家也就是要狂欢一把，谁管身后洪水滔天呢。
BRC-20这个东西，随着明年过滤器的上线，估计也就会慢慢消亡了。
不知道taproot script的过滤标准会定在多少字节。目前普遍接受的OP_RETURN，携带数据的尺寸限制是80字节。
我看了一个典型的ordi的deploy和mint（见 ordiscan.com ），恐怕尺寸还是要比80字节要大。
所以，铭文2.0，要么是把数据剥离到链外，把哈希放在OP_RETURN里。要么，想办法压缩数据，比如JSON改成二进制，塞到80字节内，放在OP_RETURN里。
其实Ordinal的原作者Casey Rodarmor早就提出过一个叫做Rune（符文）的新协议。看他的博客：https://rodarmor.com/blog/runes/
他提出这个，倒不是因为争论数据大小问题，而是他自己反对BRC-20这种东西滥用他的ordinal协议。
有人在玩一些别的类似铭文的东西，比如什么orc、atom之类的，我个人觉得那些都是做加法，也就是在brc-20基础上搞得更复杂，加入更丰富的功能。
其实你会发现，brc-20这东西之所以出众，恰恰是因为做减法！
要做加法，以太坊智能合约就是天花板了。
所以，不是看谁会做加法，加法做得好。而是要看谁会做减法，减法做得好。
从这一点上，casey rodarmor还是有这个气质的。
他自己在博客里也简单点评了几个协议：
– BRC-20： 不是基于UTXO的，而且相当复杂，因为它要求在某些操作中使用序数理论。
– RGB：非常复杂，依赖链外数据，已开发了很长时间，但未被采用。
– Counterparty： 某些操作需要使用本地令牌，不基于UTXO。
– Omni Layer： 某些操作需要本地令牌，不基于UTXO。
– Taproot 资产： 有点复杂，依赖链外数据。
其实对同质化token也就是BRC-20这种应用场景，序数理论根本就是没有意义的了，因为同质化了嘛。所以，在ordinal上做，就是关公耍手术刀。
所以Casey提出，直接把token属性放到OP_RETURN里就完事儿了。
这样还能获得一个额外的好处，那就是符文就和UTXO模型契合起来了。
不过，我阅读了他的rune设计之后，感觉有些东西他还可以再简化。
比如命名，他考虑的是可变长名字。这个brc-20已经有成功经验了。不妨就固定为4字符呢？岂不是更简单？
又比如转账。他居然搞了个tuple，可以批量操作。这个似乎没啥必要？brc-20就是一次铭刻，一次转账。虽然说，坏处是造成大量粉尘转账，但是好处是简单。
看其github https://github.com/casey/runestone/issues 目前还没有发布的迹象。
我的一个想法，如果就是借鉴brc-20成功的地方，把数据格式压缩一下，放到OP_RETURN，其他工具可以简单改造之后读取、索引，是不是会更简单、快捷、易实现，也更容易为市场所接受呢？
