Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

[Praveen Baratam via bitcoin-dev]

Bryan,

This is very similar to *CoinVault - Secure Depository and Secure Exchange*
technologies that I have shared with you all.
ᐧ

On Wed, Aug 7, 2019 at 7:23 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> I have a proposal for implementing bitcoin vaults in a way that does not
> require any soft-forks or other software upgrades, although it could
> benefit
> from SIGHASH_NOINPUT which I'll describe later.
>
> I call them pre-signed vaults.
>
> Vault definition
> 
>
> Here, a vault is defined as a transaction setup scheme that binds both the
> user
> and the attacker to always using a public observation and delay period
> before a
> weakly-secured hot key is allowed to arbitrarily spend coins. This is the
> same
> definition previously used[1]. During the delay period, there is an
> opportunity
> to initiate recovery/clawback which can either trigger deeper cold storage
> parameters or at least reset the delay period to start over again for the
> same
> keys.
>
> One of the important components of this is the delete-the-key pre-signed
> transaction concept, where only a single transaction is (pre)signed before
> deleting the key. This is basically an emulation of a covenant and
> enforces a
> certain outcome.
>
> Background and motivation
> =
>
> I was looking at Eyal and Sirer's 2016 vaults paper [1], and I saw this
> headscratcher:
>
> > Vault transactions use a delay mechanism. We note that vault transactions
> > cannot be implemented with existing timing mechanisms such as
> > CHECKLOCKTIMEVERIFY opcode or transaction locktime.
>
> This was probably written before the introduction of
> OP_CHECKSEQUENCEVERIFY.
> Still, a viable construction would have more steps than just using OP_CSV.
> They
> were probably not thinking about what those steps might be, because in the
> context of the paper they were proposing a bitcoin vault implemented using
> recursive consensus-enforced covenants via a new opcode, which obviously
> cannot
> be deployed without an upgrade fork. Covenants have been discussed for
> years,
> but require new opcodes or other consensus-enforcement changes.
>
> Relative locktimes are useful here because there is no knowledge as to
> when the
> transactions might be broadcasted in the future. The delays need to be
> relative
> to after the transaction is included in the blockchain, not to setup
> initialization time.
>
> Also, from [2]:
>
> > We show that a [vault transaction] mechanism is currently not possible
> in all
> > cryptocurrencies [...] Bitcoin's scripting language requires support for
> > covenants.
>
> I haven't seen any previous proposal for how to implement recursive bitcoin
> vaults without a fork and without a covenant. After asking around, I am
> pretty
> sure this is somewhat novel. The closest I guess is [3].
>
> Vaults are particularly interesting as a bitcoin cold storage security
> mechanism because they enable a publicly observable delay period during
> which
> time a user could be alerted by a watchtower that a thief might be in the
> process of stealing their coins, and then the user may take some actions to
> place the coins back into the vault before the relative timelock expires.
> There
> seems to be no way to get this notification or observation period without a
> vault construction. It might have been assumed it required a covenant.
>
> Having a vault construction might go a long way to discourage would-be
> attackers, on principle that the attacker might be incapable of recovering
> their cost-of-attack because the recovery mechanism can lock up the coins
> indefinitely. Griefing or denial-of-service would still be possible, of
> course,
> but with multisig there might be some ways to put a halt to that as well.
> I am
> working under the assumption that the attacker knows that the user is a
> vault
> user.
>
> Vaults
> ==
>
> The idea is to have a sequence of pre-generated pre-signed transactions
> that
> are generated in a certain way. The basic components are a vaulting
> transaction
> that locks coins into a vault, a delayed-spend transaction which is the
> only
> way to spend from a vault, and a re-vaulting transaction which can
> recover/clawback coins from the delayed-spend transaction. The security of
> this
> scheme is enforced by pre-signing transactions and deleting private keys,
> or
> with the help of SIGHASH_NOINPUT then there's another scheme where private
> keys
> are provably never known. This enforces that there's only a specific set of
> possible outcomes at every step of the vault.
>
> Some examples of what the set of broadcasted transactions might look like
> in
> regular usage:
>
> coins -> VT -> DST -> exit via hot wallet key
> coins -> VT -> DST -> RVT
> coins -> VT -> DST -> RVT -> DST -> ...
> coins -> VT -> ... -> RVT998 -> nuclear abort
>
> where:
> VT = vault transaction
> DST = delayed-spend transaction
> RVT = 

Re: [bitcoin-dev] Why SegWit Anyway?

[Praveen Baratam via bitcoin-dev]

BIP 140 looks like it solves Tx Malleability with least impact on current
practices. It is still a soft fork though.

Finally, if we were to create an alternative cyptocurrency similar to
Bitcoin, a Normalized Tx ID approach would be a better choice if I get it
right!
ᐧ

On Mon, Nov 20, 2017 at 11:15 PM, Johnson Lau <jl2...@xbt.hk> wrote:

> We can’t “just compute the Transaction ID the same way the hash for
> signing the transaction is computed” because with different SIGHASH flags,
> there are 6 (actually 256) ways to hash a transaction.
>
> Also, changing the definition of TxID is a hardfork change, i.e. everyone
> are required to upgrade or a chain split will happen.
>
> It is possible to use “normalised TxID” (BIP140) to fix malleability
> issue. As a softfork, BIP140 doesn’t change the definition of TxID.
> Instead, the normalised txid (i.e. txid with scriptSig removed) is used
> when making signature. Comparing with segwit (BIP141), BIP140 does not have
> the side-effect of block size increase, and doesn’t provide any incentive
> to control the size of UTXO set. Also, BIP140 makes the UTXO set
> permanently bigger, as the database needs to store both txid and normalised
> txid
>
> On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Bitcoin Noob here. Please forgive my ignorance.
>
> From what I understand, in SegWit, the transaction needs to be serialized
> into a data structure that is different from the current one where
> signatures are separated from the rest of the transaction data.
>
> Why change the format at all? Why cant we just compute the Transaction ID
> the same way the hash for signing the transaction is computed?
>
> --
> Dr. Praveen Baratam
>
> about.me <http://about.me/praveen.baratam>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>


-- 
Dr. Praveen Baratam

about.me <http://about.me/praveen.baratam>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Why SegWit Anyway?

[Praveen Baratam via bitcoin-dev]

Bitcoin Noob here. Please forgive my ignorance.

>From what I understand, in SegWit, the transaction needs to be serialized
into a data structure that is different from the current one where
signatures are separated from the rest of the transaction data.

Why change the format at all? Why cant we just compute the Transaction ID
the same way the hash for signing the transaction is computed?

-- 
Dr. Praveen Baratam

about.me 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev