Published on: 2018-03-05T14:53:16+00:00
In an email conversation, a user named Kalle expressed confusion about the use of graftroot in relation to multisig and freezing. Another user had suggested that using multisig would be simpler than freezing coins, but Kalle pointed out that both methods require both signatories to access the coins, and graftroot can override CLTV. Kalle also noted that graftroot requires a pubkey instead of a p2sh format.Discussions within the bitcoin-dev community are centered around the possibility of a software-only time-lock vault. Concerns have been raised about Graftroot potentially breaking the system if someone signs a time-locked output with a script that has no time-lock. To address this, some propose using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. However, others argue that this defeats the purpose and suggest using multisig instead and skipping the freezing process altogether. Adam Back suggests a method involving a CSV timelock, deleting one private key after broadcasting, and using graftroot and another privkey to spend the coins. But this approach has the drawback of the robber forcing the user to execute a step. It is suggested to include as part of 'freezing' a send to a new ephemeral key as 'initialization'. A simpler model would involve a third party refusing to co-sign until a pre-arranged time, avoiding the need for two on-chain transactions. Some users are seeking an easy way to lock up a significant portion of their coins. A security firm could offer a service where unexpected unfreeze transactions trigger an alarm.In a recent discussion on bitcoin-dev, Kalle proposed a software-only time-lock vault. Another participant mentioned that Root compatibility wouldn't be an issue if the key is deleted and delegated signatures cannot bypass the CSV timeout restriction. However, marking keys as Rootable vs not in a sighash sense could lead to privacy/fungibility loss. One drawback of this proposal is the difficulty in assuring key deletion with HD wallet seeds setup-time backup model.Anthony suggests a simpler model where a third party refuses to co-sign until a pre-arranged time, eliminating the need for two on-chain transactions. With bulletproofs and CT rangeproofs / general ECDL ZKPS, it's possible to prove things about private keys or hidden attributes of public keys without disclosing them. Private key covenants could be used to prove that certain conditions are met without revealing them.To address Kalle's concern about graftroot breaking the time-lock function, Anthony suggests using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. Increasing it to 3-of-3 or 5-of-5 could be even better if multiple independent services support it.A member of the Bitcoin development community has raised concerns about Graftroot potentially allowing someone to sign a time-locked output without a time-lock script. To prevent this, it has been suggested to use a 2-of-2 muSig with an independent third party that only signs CLTV scripts. It may also be possible to increase the number of required signatures to enhance security.Kalle recently proposed the idea of locking up bitcoin with an "OP_CSV" attached to it. The concept involves creating a transaction that spends UTXOs to a P2SH address and then discarding the private keys. To spend the bitcoin, the transaction must be broadcasted and a specified amount of time must pass before using the new txout. Kalle suggests Bitcoin Core could introduce "freeze" and "unfreeze" commands to facilitate this process. The "freeze" command would lock a certain amount of bitcoin for a given number of days, while the "unfreeze" command would list all frozen transactions and allow users to unfreeze specific ones. This locking system could disincentivize potential robbers, but there may be issues with high transaction fees and stuck transactions.In summary, discussions within the bitcoin-dev community revolve around the use of graftroot, multisig, and freezing to enhance security in Bitcoin transactions. There are proposals for a software-only time-lock vault and suggestions for addressing potential issues with graftroot. Additionally, Kalle's idea of locking up bitcoin with an "OP_CSV" has been discussed, along with the introduction of new commands in Bitcoin Core. These developments aim to prevent physical thefts of cryptocurrencies but come with their own challenges.
Updated on: 2023-08-01T22:45:54.958542+00:00