Hello,
My apologies, to start with, as I am temporarily unable to reply directly
to the thread. I am remembering this conversation due to a few things:
1) the discussion re. extending the payment protocol with new fields
2) discussions about "long addresses"
3) bitcoin strengthening / decentrali
On Sun, Jan 12, 2014 at 5:33 AM, Jeremy Spilman wrote:
> ...
> Now, you would need to get two pubkeys to the payer, throw in a prefix to
> help standardize it, and end up with addresses that could look like (for
> example):
>
>
> xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3
On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman wrote:
> I think for displaying the payment in the UI after it's been made via
> PP, we have to fully support sending to a new standard address type anyway.
>
Why? Showing an address is meaningless, especially if the user didn't type
it in or see
You can always just extend the payment protocol with the new fields as well, vs making very long addresses. I should have mentioned that as Task #4. Agree it could be an optional extension and backward compatible. I think for displaying the payment in the UI after it's been made via PP, we have to
You can always just extend the payment protocol with the new fields as
well, vs making very long addresses. If this technique can be made to work
well, it would have applicability in both fixed textual address context,
and for a fixed/upload-once payment protocol file. That has the advantage
of bac
> Oh, sorry, I forgot to mention it in my first write-up but you can
> easily make stealth addresses include a second pubkey for the purpose of
> the communication that either isn't used in the scriptPubKey at all, or
> is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> can gi
6 matches
Mail list logo
