Jr❤️

:: rune是什么机制呢 只是消息传输层吗，不是的，它是和utxo做绑定，更有利于和二层，闪电绑定的模型 :: 它是如何转移的呢 以PIPE 为例（Rune的升级版），每次转移可以转移任何代币和数量，也可以是混合代币，比如转账100个pipe给a，200个ins给b，200个pipe给c。 这时候需要输出对应的utxo，也就是我们常见的546/330/294，但是它和彩色币不一样，这就不展开arc20的描述 return 它可以在任何位置，但是不在transfer的output里面，output是输出utxo指针的位置，也就是转账对象，它是无符号整数 而经过前面的输出，接下来，接收者a, b,c，他们三个人分别可以对这些进行转移，它不需要经过其他的交易，就像你的 $atom 可以，和你的聪进行绑定（这是是utxo），你可以和ordinals类似的方法进行交易。 但是考虑到你的钱包没有保护，所以不建议和之前钱包一起使用，比如unisat。它应该要有一个属于自己的钱包，或者可以保护它的的钱包，就像早期的ordi需要保护一样。 到这里，前置知识我们了解下 :: 留给我们的思考 我们假设一个问题 我有3000个$pipe, 分别是1000 + 2000，现在我转给一个朋友2500个pipe，这时候，我还剩下一个500 下一次 我要如何消费？ 方式如下，我的utxo全部失效, 重新发起return，重新分配，而接收者不影响（一个utxo，有效值2500） 但是它会很复杂 它应该全部消费，在包含交易里面，也就是消费的时候必须知道当前交易。 但是它也很复杂，因为我不一定知道我的余额，我可能只知道它的大于x，但是我不知道余额具体数值。 所以交易模型应该有一个退回机制，比如最后一个人会接收所有剩余资金，哪怕它的转账余额为零 ----------------- Let's assume a problem I have 3000 $pipe, which are 1000 + 2000. Now I transfer 2500 $pipe to a friend. At this time, I still have 500 left. How do I spend next time? The method is as follows, all my utxo are invalid, re-initiate return, redistribute, and the receiver is not affected (one utxo, valid value 2500) But it will be complicated It should be consumed in full, including transactions, that is, the current transaction must be known when consuming. But it's also very complicated, because I don't necessarily know my balance. I may only know that it is greater than x, but I don't know the specific value of the balance. Therefore, the transaction model should have a return mechanism. For example, the last person will receive all remaining funds, even if its transfer balance is zero. ------------ 对话创始人Benny ------------ 1: Do I need to send the entire balance every time? no, you send what you want to send 2: Can several tokens sent together have the same output? technically yes, but you cannot really add a lot because of size limitations of op_return codes 3: Is it valid to send the UTXO corresponding to the payee directly for the second time? yep ===================== so, as of the specs, it works exactly like the utxo model for sats: you specify how much of a token you want to send in op_return, pointing to the output (to the reciever). then populate the inputs with utxos containing those tokens. example send of 1500 pipe tokens from your utxo that contain combined 1650 pipe tokens: inputs: 0: 500 pipe 1: 750 pipe 2: 300 pipe 3: 0 pipe but enough sats to pay fees the remaining 150 pipe tokens will be sent back as change (just like btc) with an additional quadruple in op_return, pointing to a 2nd output with one of your addresses as change address. @trac_btc #PIPE #RUNE #Ordinals #BTC