Tossbot

Even if Satoshi Nakamoto were to return today, they wouldn't be the same person who authored the Bitcoin whitepaper.

Technically speaking, tossbot has already dead at block height 80,000. We tend to perceive ourselves as the same person as a second ago or ten years ago, but it's merely a continuity illusion created by memory. Those who've experienced amnesia can better grasp this idea.

There's no rug and there's no project. OICP, as a protocol, is already very comprehensive, and tossbot, its author, has already done his job.

@atomicalsxyz wow, interesting

@domodata @OrdinalsSummit meta-protocols, and meta layer, ike this term lol

A unique challenge to meta-protocols like brc-20 is the balancing of indexing vs. governance. I will be speaking about this and what the future holds for brc-20 at @OrdinalsSummit later today

@0xcryptowizard 神奇

观察加密社区的鄙视链，也是挺有意思的。 被 btc maxi 诟病的 ordinals ，还有空撕一下原生于 ordinals 协议内的 brc20 世界是一个莫比乌斯环😂

casey 发推，表达了对 brc20 的不满。 然而，ordinals 社区一直在吹的ordinals transactions 占btc 总 transactions 的一半，这里面 95%以上都是 brc20 的。 尴尬不？

@mingmin656 新协议还没写好 稍安勿躁

@toshtoss 来来来，噪起来

800000

@JavaelfS 证明系统比较麻烦

@toshtoss 老铁最近有啥新进展吗

天上有三颗飞星!! 那代表着极度的严寒. 纣王在石台上站起身迈开了脚步. 依托于dune而构建起来的旧世界已经碰到了它的瓶颈. 只有抛弃dune的数据模型,从零开始重新建立坚实的地基, 协议才能走的更远. 虽然还不知怎么开始, 但传说山的那边node一族视乎有些经验，对了，人们一般叫他们 The validator.

@bruffstar check oicp protocol, lmao

GM ... who is building cool stuff on #bitcoin that I need to check out?

@dumbnamenumbers wow its great to know you want to take a look, cant wait to discuss more with you!!!

I will check this out! And I definitely agree. I think our new proposal accomplishes some of this but maybe could go further. My only concern is that making the higher-dimensional space more powerful can also make the system more brittle in the face of reorgs. Not unsolvable by any means, however. Thank you for replying!

Ethscriptions.com Marketplace Security Incident Update In this Tweet I’m going to walk you through how the exploit happened and what we are doing about it. First, to be clear, this was not a vulnerability in the Ethscriptions Protocol. This was a vulnerability in one specific smart contract (0x3ca843b98a2fe8ef69bb0f169afad3812c275f5e). The protocol itself and other applications running on it were not affected in any way. @michaelhirsch and I are responsible for the contract and before we get into the details I just want to say that I’m truly sorry for putting our marketplace users through this. I have said that any young protocol will have bumpy landings, but this is definitely not what I meant. How the Exploit Happened Making smart contracts work with Ethscriptions is a challenge. Ethscriptions do not use contract storage, which makes them cheaper than NFTs, while remaining just as decentralized. However, though ethscriptions are easy for people to work with, they are hard for contracts because contracts cannot access their state. This means that contracts cannot by themselves know who owns an ethscription. This makes marketplaces challenging because, for example, a contract cannot validate that it owns an ethscription before it lets you buy it and this could lead to you paying for an ethscription that doesn’t exist. All of this can be mitigated, but it requires a new way of thinking and greater care. We knew about this class of exploits and we talked at length about them in our spaces and Marketplace Symposium. However, we were not able to spot this exact exploit in our own code before it was too late. The Marketplace Contract The way the marketplace contract works is that you send your ethscription to the marketplace contract, list it for sale, and then a buyer can trustlessly purchase the ethscription from the marketplace. This is the code that ran when someone sent an ethscription to the exploited marketplace: Even though ethscription ids are unique, we have the ability to store the same id for multiple senders because people could send ethscriptions they don’t own to the contract, preventing the rightful owner from sending the same id if there was only one storage slot. This mapping keeps track of the ethscriptions each person has on the marketplace. We don’t allow you to deposit an ethscription you’ve already deposited and we require you to have deposited an ethscription before you can withdraw it. This was exploitable in the following scenario: - Legitimate user A sends ethscription id X to the marketplace. - According to the protocol, the marketplace now owns id X. According to the marketplace, storedEthscriptions[A][X] = true. - Malicious user B also hits the deposit function on the contract for ethscription id X. This transaction is ignored from the protocol standpoint, because the protocol knows that B doesn’t own id X. But the marketplace doesn’t have this information and therefore sets storedEthscriptions[B][X] = true. Now B initiates a withdrawal for id X. The marketplace verifies storedEthscriptions[B][X] == true and sends id X to B. Because the marketplace does legitimately own id X (because A sent it), this transfer is valid and B gets the ethscription. How can this be prevented? The most straightforward way to avoid this exploit is to require a trusted third party to confirm which deposits are valid. For example, after you deposited id X you could go to the trusted party, ask them to check who owns id X, and, if it’s the marketplace contract, create a signed message memorializing this information. Then you could present this signed message to the marketplace contract providing your deposit was legitimate. The contract would know to believe your message by comparing the signer of the message to the address of the trusted party. Finally, when deposits are pending confirmation, they cannot be sold or withdrawn, because the contract doesn’t know who should have the ability to do so. This approach makes sense and is secure. However, we decided early that it wasn’t the approach for us because we wanted something less centralized. In this case, the person holding the private keys capable of confirming which deposits are valid is a single point of failure. This isn’t necessarily bad. Though our design goals were different, I am not opposed to the third party confirmation approach at all. However, here we wanted to write a reference implementation that other people could use to create their own marketplaces and not everyone can afford the responsibility of safely storing private keys. We even set up a “Factory Pattern” that will easily allow people to “clone” our marketplace when it is ready. This focus on a single approach I believe blinded us to this exploit, because I do not believe there is a way even in principle to solve these issues while remaining decentralized under the current protocol rules. Extending the Ethscriptions Protocol ESIP-1 was a massive step forward and offers great functionality. I believe there are zero security issues with ESIP-1 *when used correctly*. However, the functionality ESIP-1 offers is not sufficient to enable safe decentralized marketplaces. We need to extend the protocol to enable this. Here are @michaelhirsch’s and my current thoughts. I welcome feedback. The idea is this: contracts cannot validate ethscription ownership. They need to “ask for help.” Under ESIP-1 they can ask for help, but only from trusted third-parties with private keys. What we need is to enable contracts to “ask for help” from the protocol itself. Specifically, when user A tries to withdraw an ethscription, the contract should be able to say not just “transfer this ethscription to A,” but rather “transfer this ethscription to A *if and only if* A is the person who sent it to me. If someone else sent it to me, ignore this request.” The event here could be something like transferEthscriptionFromPreviousOwner( address indexed previousOwner, address indexed recipient, bytes32 indexed id ); A withdrawal request would be transferEthscriptionFromPreviousOwner(msg.sender, msg.sender, ethscriptionId) This would mean that under the protocol, a withdrawal to msg.sender is only valid is msg.sender was the person who deposited the ethscription in the first place If they aren’t the initial depositor, the transfer will be ignored just like any other invalid transfer. Similarly, in the case of a sale, the contract would emit transferEthscriptionFromPreviousOwner(seller, buyer, ethscriptionId) This would ensure that the buyer could not receive any ethscription from the contract unless it was deposited by the seller. Because the buyer is filling an offer from that specific seller, this ensures the behavior will match the buyer’s expectations. This is not a final proposal and will take some work. However, in diving deep into this exploit I believe we’ve achieved a greater level of understanding of what is required to provide a safe and useful trading experience for everyone under the ethscriptions protocol. Next Steps Given our goals, we must remain a trustless marketplace and we are going to make the necessary extensions to the protocol to enable this before relaunching our marketplace. However, there is absolutely nothing wrong with using a trustful marketplace in the meantime. Signature-validated ethscriptions marketplaces can be made completely safe today. A benefit of an open protocol is that users get the choice between different approaches to the same problem. Who was Affected About 123 individual addresses lost a total of about 202 ethscriptions in this exploit. I have spoken to many of you in my DMs and I have appreciated the chance to personally apologize as well as the data you have given me to help in this investigation. You were the earliest adopters of a true “first”—a brand new way to trade digital artifacts on Ethereum. Not only by listing on the marketplace, but by listing in the marketplace’s very first hours. The passion that brought you to the marketplace came alive in our conversations today, which makes me feel even worse for letting you down. This process has also completely changed my perspective on how marketplaces can implement the protocol and I think it will lead to a much healthier ecosystem long-term. I know this doesn’t make up for having your ethscriptions wrongly taken by someone. But I’ve thought about it a lot and I don’t think there is anything we can do. As I said, this was not a protocol issue, this was an issue with our contract. The protocol worked correctly and because it is a decentralized permissionless protocol I do not believe it would be right for me as the protocol creator to not abide by its rules. All I can offer right now is that I will not stop fighting to make sure this does not happen again and for the future of Ethscriptions. Thank you.

@dumbnamenumbers In particular, one of its sub-protocols, mrc-101, also utilizes Ethereum smart contracts to facilitate an atom NFT cross chain protocol.

@dumbnamenumbers If you have concerns about centralization, the OICP protocol I proposed on Ordinals has developed a method to ensure high-dimensional proof-of-ownership that doesn't rely on any centralized indexer. If you're interested, you can take a look at it.

@0xcryptowizard @coolish @lingboweibu319 next big thing

@coolish @lingboweibu319 投票权，应该是建立在惩罚之上，目前在做索引的几家其实是质押了自己的“商誉”，如果他投了错票（给了错误结果），市场给的惩罚就是不再信任。 如果让任何人不加惩罚机制的投票，这是有问题的。

之前提出这个铭文的“激励去中心化索引”想法之后，在很多地方听到dbj @lingboweibu319 提出不同意见，说“不激励的去中心化索引”更好。我觉得这是一个值得探讨思考的问题，所以公开提一个衍生问题： 如果去中心化索引是基于不激励的， 比如有1000个Ordinals爱好者的电脑上无私运行了1000个索引节点程序，假设叫做ordex1.0，那这个网络是否会很脆弱？ 比如任何一个团队甚至个人，把这个索引程序稍作修改，加上激励，叫做ordex1.0 pro，就很可能吸引到更多人来跑这个带激励的pro版本，对原本的1.0索引共识，实现类似于"51%攻击"，夺取原索引网络共识的胜利果实？ 在这个共识人数（节点数或算力占比）决定成王败寇的公开黑暗森林市场上，这个问题怎么考虑？

@evilcos cos前者说的是mrc-101协议吗 hhh

有的人把以太坊 NFT 燃烧后迁移成比特币铭文，有的人把比特币铭文搞到以太坊去交易…

@Juicewh1te sure

@toshtoss 加油 我还是挺喜欢oicp的

A long journey, Alone

@Jasonbecoin 不 按剧本 山的后面是大海

@toshtoss 独自一人征服群山，无敌