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
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
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
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
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
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, 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
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
8 matches
Mail list logo
