Hi,
Sorry the late response. Going back to the original message:
> > On 03/10/15 13:42, Jean-Pierre Rupp via bitcoin-dev wrote:
> >> I have been reviewing BIP-45 today. There is a privacy problem with it
> >> that should at least be mentioned in the document.
> >>
> >> When using the same exten
Hi all, is anyone using simulators like Shadow (https://shadow.github.io),
BTCSim (https://github.com/btcsuite/btcsim), etc. to test proposed changes
to Bitcoin? I have a few questions about their capabilities and
limitations.
Byron Gibson
http://mirror.co/
https://keybase.io/byrongibson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Jean Pierre,
This is a problem I've considered before, though I have to say I prefer
your solution.
The problem is, how can a person who restores his wallet from just a
seed restore
all his multi-signature addresses with other parties?
Your pr
I have a possible solution:
Take all public keys encoded in the purpose-specific extended public
keys (m/45') of all cosigners and sort them lexicographically, according
to BIP-45. Serialize this information and calculate its HASH160
(RIPEMD160 ∘ HASH256). Split the output in five 32-bit chunks,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi aj,
On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:
> On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via
> bitcoin-dev wrote:
>> So we need to make the case for two main things: 1) We have
>> applications that need a relative (i
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> So we need to make the case for two main things:
> 1) We have applications that need a relative (instead of absolute CLTV)
> 2) Additionally to RCLTV, we need to implement this via nSequence
> However I don't think we've
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
(Note: Due to being very tired I have issued a correction to my post
below so as to make sure I have not been misunderstood.)
odinn via bitcoin-dev:
> Hello,
>
> Some background on this
>
>
> A very long while ago I posted to the bitcoin-dev
