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 Serv
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:
>
>
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back 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
>
Thanks for re
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, 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), s
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd 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
>> triggering false posi
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 presen
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
> > detecti
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 genera
Maybe even pay to (address derived from) contract hash has a hole: it
assumes the merchant cashes the funds (or cashes then reimburses via the
refund address). There is another rational (though abusive) move for the
merchant: let the buyers funds sit in limbo. Then the buyer has the onus to
go in
On Mon, Jan 13, 2014 at 03:20:15PM -0800, Jeremy Spilman wrote:
> On Mon, 13 Jan 2014 13:27:52 -0800, Peter Todd wrote:
>
> >There is a catch however: if you need the prefix to be against
> >H(scriptPubKey) rather than scriptPubKey directly the sender needs to
> >grind the OP_RETURN output at 2^l
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 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
>
> 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 allowed to change his mind. It's only if they change
t
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 thinki
15 matches
Mail list logo
