Payment codes establish the identity of the payer and allow for simpler
methods for identifying the payee, and automatically provide the payee with
the information they need to send a refund.
If merchants and customers were using payment codes, they would not need
the BIP70 equivalents.
I think t
Could you maybe write a short bit of text comparing this approach to
extending BIP70 and combining it with a simple Subspace style
store-and-forward network?
--
One dashboard for servers and applications across Physical-Vir
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
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
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/
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
6 matches
Mail list logo
