Oh, no, sorry, it also covers bip62.
On Fri, Apr 24, 2015 at 10:55 AM, Jorge Timón wrote:
> s7r you may be interested in this video explaining several aspects of
> malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs
> It is pre BIP62, but I believe it is very relevant and will hopefully
> c
s7r you may be interested in this video explaining several aspects of
malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs
It is pre BIP62, but I believe it is very relevant and will hopefully
clear some of your doubts.
The signer of TX1 will always be able to change the signature and thus
the
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
On Fri, Apr 24, 2015 at 7:58 PM, William Swanson wrote:
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
This link contains an RFC for a new type of Bitcoin address called a
"payment code"
Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
addresses w
On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier
wrote:
> https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
>
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
>
> Payment codes are SPV-friendly alternatives to DarkWallet-style stea
On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell
wrote:
> So this requires making dust payments to a constantly reused address
> in order to (ab)use the blockchain as a messaging layer.
>
> Indeed, this is more SPV compatible; but it seems likely to me that
> _in practice_ it would almost comple
I have pushed an updated version of the proposal which incorporates some of
the received feedback and adds a note about the consequences of sharing a
payment code-enabled walled on multiple devices:
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
https://github.com/
Taking the hash of the secret would then require an extra step to make sure
the hash is valid for secp256k1.
Using the x value directly avoids the need for that check.
On Fri, Apr 24, 2015 at 10:35 PM, Patrick Mccorry (PGR) <
patrick.mcco...@newcastle.ac.uk> wrote:
> When computing the diffie H
On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell wrote:
> On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier
> wrote:
> > Taking the hash of the secret would then require an extra step to make
> sure
> > the hash is valid for secp256k1.
>
> The x value may not be a valid member of the group, effec
10 matches
Mail list logo
