Yes. A few of us over here in San Diego actually started working on a
format like this a few months ago, but it's been on the back burner
for a while.
Our motivation was to come up with a shared HD wallet format. Say I
would like create a 2-of-3 multisig wallet using my phone, PC, and
hardware key
On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil wrote:
> A MITM can receive the initial broadcast and then spoof it by jamming the
> original. You then only see one.
You are right, of course. There is no way to make Bluetooth 100%
secure, since it is an over-the-air technology. You could try securin
ti-currency, multisignature wallets," is pretty vauge. Also, there
is nothing in this spec that addresses the multisignature use-case.
The BIP 45 spec does a lot of extra work to make multisignature work
smoothly.
I'm not trying to criticize your proposal. I'm just trying to
under
coin usability.
>
> For that reason alone I will say I disagree for a BIP for this.
> - Jona
>
>
> 2015-04-08 16:46 GMT+09:00 William Swanson :
>>
>> It's not really clear why this is better than BIP 44 as it already
>> stands. You have the same fields, but
On Thu, Apr 16, 2015 at 9:12 AM, s7r wrote:
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
The BIP 62 approach to malleability isn't the only option. Another
approach is to sign the transaction
The `n` is the curve order, as shown here:
https://en.bitcoin.it/wiki/Secp256k1
This step is necessary to keep you on the curve. The
secp256k1_ec_privkey_tweak_add function from libsecp256k1 handles this
automatically, but if you use OpenSSL or some non-EC math library, you
probably have to do it
Hello,
I am attempting to write a parser for bip-0021 URI's, including
support for the new bip-0072 payment parameters. My goal is absolute
correctness. Unfortunately, these BIP's have a few ambiguities and
mistakes which ought to be corrected.
First, I would like to point out that internet RFC 39
On Thu, Mar 6, 2014 at 2:59 PM, Mike Hearn wrote:
> Yes please, pull req would be great! I also noticed that escaping doesn't
> seem to be necessary, and the resultant de-escaped QRcodes are certainly
> much nicer! Thanks!
All right, I have submitted the pull request. Hopefully, the specified
beh
8 matches
Mail list logo
