关于发送多个transfer 铭文的记账处理和双花攻击

[fxacc]

目前从网站上验证来看，用户发送多个transfer的铭文，最后是以打包交易确认为最终的有效记账，这样的记账存在双花攻击的问题，同时也限制了链上大额交易的可能。

• 然而从ETH的记账经验来看，不管是否链上打包确认，都要求按顺序打包，即ETH的noce的功能
• brc的转账需要先刻录transfer的铭文，天然生成了一个noce, 按照first is first原则排序靠前的transfer 功能铭文应是有效的余额，排序靠后的铭文如果超出了balance不应认为是有效记账。 这样也杜绝了在交易待打包时提高gas的双花攻击。
• 之后是否增加取消上一个transfer的操作，我觉得可以随比特币社区而定，如果大部分钱包支持增加手续费，并不需要取消的功能。

[finian]

请教下 OP，现在的处理方式（transfer 铭文确认有效（3 个区块确认）才可以挂单）好像已经不存在双花攻击了吧？能否描述一下双花攻击的具体场景？

[fxacc]

可以刻两张transfer,当其一张在交易，提交进内存池的时候，第二张铭文转到其他地址，并提高gas抢先确认。这样交易的那张拿不到币。

[finian]

可以刻两张transfer,当其一张在交易，提交进内存池的时候，第二张铭文转到其他地址，并提高gas抢先确认。这样交易的那张拿不到币。

好像不存在你说的这种情况吧。我们假设你说的这种场景：挂单的用户地址有 1000 个 $ordi，他刻了两张 transfer，每张都是 1000，第一张它确认了 3 个区块挂单上去交易（UniSat 必须确认 3 个区块才能挂单），第二张他故意设置低 gas 让它呆在内存池里。在第一张挂单提交进内存池时，他把第二张铭文转到其他地址，并提高 gas 抢先确认（比如使用 CPFP 方法）。但是因为第一张的 transfer 已经是确认过的，所以即便第二张铭文抢先确认，他也是无效的（因为此时用户总共 1000 个 $ordi，available 数量是 0，transferable 数量是 1000，且第二张铭文不在这 1000 个 transferable 数量里）。

你说的双花攻击的前提条件是这两张 transfer 铭文都是未确认的，都在内存池里，那么抢先确认的有效。但在 UniSat 上挂单的已经是确认过的 transfer 铭文了，不会被抢跑，除非挂单者在第一张挂单提交进内存池时，他把第一张 transfer 铭文转到其他地址，并提高 gas 抢先确认（比如使用 RBF 方法），但是这时挂单交易就会失败（因为输入的 UTXO 被花费了），买家收不到币，但他的钱也没被扣，相当于卖家强行取消交易了。

[finian]

我不知道 UniSat 当时出现双花攻击的具体 bug 是啥，猜测要么是 transfer 未确认就能挂单交易？要么是索引 transfer 铭文算法有 bug，只统计有效数量未统计哪张有效？他们是修复了双花攻击 bug 之后重新上线的，按理现在应该是不存在双花问题了。

[fxacc]

未确认的铭文不因该交易这相对容易理解，除了unisat其他平台也在交易，记账是全链的。这个问题缘由是推上有人说在第一个transfer铭文给gas低了又无法加速的情况下，可以另外刻一张transfer进行转账成功，这就是抢跑,第二张铭文的转账即使先确认也不应该记账。不然很不安全

[jiedo]

未确认的铭文不因该交易这相对容易理解，除了unisat其他平台也在交易，记账是全链的。这个问题缘由是推上有人说在第一个transfer铭文给gas低了又无法加速的情况下，可以另外刻一张transfer进行转账成功，这就是抢跑,第二张铭文的转账即使先确认也不应该记账。不然很不安全

这种抢跑操作是被正常允许的，只有确认的transfer才是安全的

[fxacc]

抢跑会出现程序没法判断真实性的问题，每次交易都需要非常专业的人工识别才可以确认真实性，我觉得还是认真考虑一下。

[finian]

抢跑会出现程序没法判断真实性的问题，每次交易都需要非常专业的人工识别才可以确认真实性，我觉得还是认真考虑一下。

「transfer 铭文必须是确认的才有效」，只要程序索引的时候遵循这条规则，就可以避免双花问题。我猜这也是 UniSat 开源索引程序的目的，大家都按这个「最佳实践」来就不会出问题

[fxacc]

并没有不安全，在路上的一直会在路上，没确认就是没到账啊，反观抢跑的操作，如果是两张全额的transfer的铭文，交易其中一张，在内存池的时候马上抢跑另一张。 哪个影响更大显而易见，前者只是没到账，加gas可以解决，后者导致scam. 以后都按这样交易这市场永远做不大，太多人被骗怎么起来。