On Mon, Aug 12, 2019 at 09:09:43PM -0500, Bryan Bishop wrote:
> > > Multisig gated by ECDSA pubkey recovery for provably-unknown keys
> > > =
> > >
> > > A group can participate in a multisig scheme with provably-unknown ECDSA
> > keys
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 vaul
On Mon, Aug 12, 2019 at 10:01 AM Peter Todd wrote:
> The key difference being it's not important that this be a *public*
> notification: that the public can see just happens to be an (unfortunate)
> implementation detail. For example, you could imagine a system where the
> "prepare to spend" tx i
On Wed, Aug 07, 2019 at 08:48:06AM -0500, Bryan Bishop via bitcoin-dev 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 c
Good morning Sergio,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, August 8, 2019 10:09 AM, Sergio Demian Lerner via bitcoin-dev
wrote:
> Seems to be comparable to the proposed "Tick Method" from 2013:
> https://bitcointalk.org/index.php?topic=307211.msg3308
Seems to be comparable to the proposed "Tick Method" from 2013:
https://bitcointalk.org/index.php?topic=307211.msg3308565#msg3308565
However I remember that someone told me the tick method had a flaw..
On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev <
bitcoin-dev@lists.linuxfounda
Replying to two emails below.
On Wed, Aug 7, 2019 at 7:27 PM ZmnSCPxj wrote:
> > - Re-vaulting transaction. This is where the magic happens. The
> re-vaulting
> > transaction is signed during transaction tree setup, before
> constructing the
> > delayed-spend transaction for the parent
Good morning Bryan,
> - Re-vaulting transaction. This is where the magic happens. The re-vaulting
> transaction is signed during transaction tree setup, before constructing
> the
> delayed-spend transaction for the parent vault. The re-vaulting
> transaction is
> broadcasted when s
Does revaulting vault up with the same keys, or new ones?
Are they new derivation paths on the same key?
Would love some expanded explanation on how you’re proposing this would
work.
Thanks,
Dustin
On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.o
Hi,
One of the biggest problems with the vault scheme (besides all of the
setup data that has to be stored for a long time) is an attacker that
silently steals the hot wallet private key and waits for the vault's
owner to make a delayed-spend transaction to initiate a withdrawal
from the vault. If
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
11 matches
Mail list logo
