coredao staing BTC & timelock

最新推荐文章于 2024-10-09 10:47:03 发布

dokyer

最新推荐文章于 2024-10-09 10:47:03 发布

阅读量631

点赞数 24

文章标签：区块链

本文链接：https://blog.csdn.net/dokyer/article/details/139685048

版权

BTC Staking – Core DAO

Core DAO 采用CTLV LockTime 的方式将质押的BTC锁定在UTXO中，构建P2SH或者P2WSH的输出地址，无罚没条件，仅达到LockTime所指定的时间戳方可花费。
在这里插入图片描述

质押过程

将至少 0.001BTC （减去交易费之后）作为输入
构建输出，
a. 将输入地址（或者其他地址）构建基于Script的输出地址，并提供LockTime，需要满足 LockTime > 7 days（LockTime timestamp - transaction confirmation timestamp > 7 days）P2WSH 的输出

redeem lock script

<CLTV timelock> OP_CLTV OP_DROP OP_DUP OP_HASH160 <pubKey Hash> OP_EQUALVERIFY OP_CHECKSIG

unlocking script

<sig> <pubKey> <RedeepScript>

b.OP_RETURN 输出格式

{flag}{version}{chainId}{rewardAddress}{validator}{coreFee}{redeemScript}

Satoshi Plus Identifier - (SAT+) 4 bytes
Version - (0x01) 1 byte
Chain ID - (e.g. 1115) 2 bytes
Delegator - The Core address to receive rewards, 20 bytes
Validator - The Core validator address to stake to, 20 bytes
Fee - Fee for relayer, 1 byte, range [0,255], measured in CORE
(optional) RedeemScript
(optional) Timelock - 4 bytes
(3)可选的找零

3.将交易发送至BTC节点，待交易确认后，Core DAO 提供的relayers会将质押信息同步到Core Network
4. 当达到LockTime指定的时间戳，可将输出花费到新地址，解质押完成

Timelocks 时间锁介绍

以下内容来自《精通比特币第二版》

时间锁是只允许在一段时间后才允许花费的交易，比特币从一开始就有一个交易级别的时间锁定功能。它通过交易中的nLocktime实现，在2015年底和2016年中期推出了两个新的时间锁定功能，提供UTXO级别的时间锁定功能。通过CHECKLOCKTIMEVERIFY和CHECKSEQUENCEVERIFY实现。
babylon 采用 CHECKSEQUENCEVERIFY
coredao 采用 CHECKLOCKTIMEVERIFY

交易级别的时间锁 nLocktime

nLockTime 的取值
1.nLockTime < 500,000,000. 值被解释为块高，在指定的块高之前，交易不会被接受
2.nLockTime > 500,000,000. 值被解释为“Unix纪元时间戳”，在指定的时间之前，交易不会被接受
交易级别的时间锁仅现在当前创建的交易，并不能限制UTXO的花费，所以当交易中的UTXO被其他交易所花费，则锁定的交易也会无效。

UTXO级别的时间锁 Check Lock Time Verify (CLTV)

2015年12月，引入了一种新形式的时间锁进行比特币软分叉升级。根据BIP-65中的规范，脚本语言添加了一个名为CHECKLOCKTIMEVERIFY（CLTV）的新脚本操作符。 CLTV是作用于输出的时间锁定，而不是交易的时间锁定，简单来说，通过在输出的锁定脚本中添加CLTV操作码来限制UTXO，并通过将nLocktime 设置为更大或者相等的值，从而达到在指定的时间过后才能使用的目的。

CLTV 时间锁的时间是绝对时间，是指达到指定的时间点或者高度时可以花费

CLTV 操作码将一个参数作为输入，实际设置时应该与nLocktime采取一致的格式（块高或者UNIX时间戳）。将验证结果入栈。

示例
Alice 支付 Bob，约定 3 个月以后Bob才可以花费，那么Alice创建的交易输出脚本如下

CHECKLOCKTIMEVERIFY DROP DUP HASH160 <Bob's Public Key Hash> EQUALVERIFY CHECKSIG

当Bob想要花费该输出时，除了提供签名和公钥外还需要设置nLockTime为等于或者大于Alice设置的锁定时间。

UTXO 级别的时间锁 Check Sequence Verify (CSV)

nSequence字段的设计初心是想让交易能在在内存中修改，使用nSequence这个字段时，如果输入的交易的序列值小于2^32
（0xFFFFFFFF），就表示尚未“确定”的交易。这样的交易将在内存池中保存，直到被另一个交易消耗相同输入并具有较大nSequence值的代替。一旦收到一个交易，其投入的nSequence值为2^32，那么它将被视为“最终确定”并包含在区块内。 nSequence的原始含义从未被正确实现，并且在不利用时间锁定的交易中nSequence的值通常设置为2^32。
对于具有nLocktime或CHECKLOCKTIMEVERIFY的交易，nSequence值必须设置为小于2^32，

以使时间锁定器有效。通常设置为2^32 - 1（0xFFFFFFFE）。”

nSequence作为一个共同执行的相对时间锁定由于BIP-68的激活，新的共识规则适用于任何包含nSequence值小于2^31
的输入的交易（bit1<<31 is not set）。也就是说如果输入的nSequence值小于2^31，那么该输入为启用相对时间锁输入，该交易需要到相对时间后才能被接受

类型标志位在第23位（即 1<< 22），类型标志位用于识别设置的是块高还是时间秒
标志位（1 << 22）设置时，nSequence的值被解释为512秒的倍数，否则nSequence的值被解释为区块高度

当nSequence被解释为相对时间锁定时（即第32位未设置），此时只需要考虑最低16位为时间秒或者区块高度。

CSV 时间锁位相对时间锁，是指从输出被包含在区块内起距离nSequence设置的快高或者时间值。

时间锁计算的时间来源

最初是由矿工设置在区块头中的时间戳，共识规则允许一定的误差来解决分布式节点之间的时钟精度问题，然而，这诱惑了矿工去说谎，以便通过包括还不在范围内的时间交易来赚取额外矿工费。

为了杜绝矿工说谎，加强时间安全性，在相对时间锁的基础上又新增了一个BIP-113“它定义了一个称为“中位时间过去 /（Median-Time-Past）”的新的共识测量机制。通过取最后11个块的时间戳并计算其中位数作为“中位时间过去”的值。这个中间时间值就变成了共识时间，并被用于所有的时间计算。

Median-Time-Past更改了nLocktime，CLTV，nSequence和CSV的时间计算的实现。由
Median-Time-Past计算的共识时间总是大约在当前时间后一个小时。如果创建时间锁交易，
那么要在nLocktime，nSequence，CLTV和CSV中进行编码的估计所需值时，应该考虑它。

也就是说当BIP-133激活后，共识时间会比当前区块头时间戳晚大约一个小时