On 01/13/2014 06:56 PM, Pieter Wuille wrote:
I want to avoid the case where a transaction confirms, but the
associated payment is not delivered. If there is a reasonable chance
that this case occurs in normal operation, it means the payment
transmission cannot be relied upon.
I was thinking
On 01/14/2014 11:45 AM, Mike Hearn wrote:
Imagine you get a good offer (payment request) from a merchant. You
would like to accept that offer, however the merchant has changed his
mind.
Usually if the merchant has not delivered, then at that point it's not a
problem and he is
He's probably thinking of fair advertising rules. There are regulations
motivated by consumer protection/advertising standards (prevents merchant
listing attractive prices in media, and then when consumer goes to pay the
merchant says oh actually that doesnt include X and Y, and the minimum
price
On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote:
It's a given this will be implemented for Payment Protocol. The question
is whether it's also usable outside of PP.
I think what stealth addresses is showing is that the concept of an
address being instructions on how to generate
On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
Uh while I'm responding again, what I'd discussed with Peter Todd in
IRC used two EC points in the stealth address. One for the payment and
one for the ECDH. The reason to use two is that it makes delegating
detection
Hello Peter et. al.
As I read more into this stealth discussion I am curious to know what you
think of the background microdonation concept I posted recently.
It is shown in full here
http://sourceforge.net/mailarchive/message.php?msg_id=31837430
Given the lengthy nature of the concept as
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd p...@petertodd.org wrote:
On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping
one of the pubKeys in the OP-RETURN, to prevent a malicious sender from
On Tue, Jan 14, 2014 at 11:12:40AM -0800, Jeremy Spilman wrote:
Maybe you are saying:
byte[] S = EC.DH(e, Q2);
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));
But the payment would have (q2New - q1New) == (Q2 - Q1), so I
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?
Adam
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back a...@cypherspace.org wrote:
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?
Adam
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
Signing a payment request for an individual is easy, anyway, depending on
the kind of ID you want. If you want to sign with an email address, just go
here with a browser like Chrome/Safari/IE that uses the system keystore:
Sorry this is possibly OT, but someone posted this thread to r/bitcoin and
it's gone straight to position 1. People are really enthusiastic about this
feature.
Drak
--
CenturyLink Cloud: The Leader in Enterprise Cloud
12 matches
Mail list logo
