Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z1FnF-0004hG-CE for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 15:13:53 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.218.49 as permitted sender) client-ip=209.85.218.49; envelope-from=pieter.wuille@gmail.com; helo=mail-oi0-f49.google.com; Received: from mail-oi0-f49.google.com ([209.85.218.49]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z1FnE-0001sM-31 for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 15:13:53 +0000 Received: by oiha141 with SMTP id a141so6813917oih.0 for ; Sat, 06 Jun 2015 08:13:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.187.138 with SMTP id l132mr7014977oif.31.1433603626669; Sat, 06 Jun 2015 08:13:46 -0700 (PDT) Received: by 10.60.94.36 with HTTP; Sat, 6 Jun 2015 08:13:46 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Jun 2015 17:13:46 +0200 Message-ID: From: Pieter Wuille To: Kalle Rosenbaum Content-Type: multipart/alternative; boundary=001a113ccf4aea9f300517dadac7 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z1FnE-0001sM-31 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP for Proof of Payment X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 15:13:53 -0000 --001a113ccf4aea9f300517dadac7 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 6, 2015 at 5:05 PM, Kalle Rosenbaum wrote: > > What do you gain by making PoPs actually valid transactions? You could > for > > example change the signature hashing algorithm (prepend a constant > string, > > or add a second hashing step) for signing, rendering the signatures in a > PoP > > unusable for actual transaction, while still committing to the same > actual > > transaction. That would also remove the need for the OP_RETURN to catch > > fees. > > The idea is to simplify implementation. Existing software can be used > as is to sign and validate PoPs. But I do agree that it would be a > cleaner specification if we would make the PoP invalid as a > transaction. I'm open to changes here. I do like the idea to prepend a > constant string. But that would require changes in transaction signing > and validation code, wouldn't it? > Yes, of course. An alternative is adding a 21M BTC output at the end, or bitflipping the txin prevout hashes, or another reversible transformation on the transaction data that is guaranteed to invalidate it. I think that the risk of asking people to sign something that is not an actual transaction, but could be used as one, is very scary. > > Also, I would call it "proof of transaction intent", as it's a > commitment to > > a transaction and proof of its validity, but not a proof that an actual > > transaction took place, nor a means to prevent it from being double > spent. > > > Naming is hard. I think a simpler name that explains what its main > purpose is (prove that you paid for something) is better than a name > that exactly tries to explain what it is. "Proof of Payment" indeed does make me think it's something that proves you paid. But as described, that is not what a PoP does. It proves the ability to create a particular transaction, and committing to it. There is no actual payment involved (plus, payment makes me think you're talking about BIP70 payments, not simple Bitcoin transactions). > "Proof of transaction > intent" does not help me understand what this is about. But I would > like to see more name suggestions. The name does not prevent people > from using it for other purposes, ie internet over telephone network. > I don't understand why something like "Proof of Transaction Intent" would be incompatible with internet over telephone network either... -- Pieter --001a113ccf4aea9f300517dadac7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 6, 2015 at 5:05 PM, Kalle Rosenbaum <kalle@= rosenbaum.se> wrote:
> What = do you gain by making PoPs actually valid transactions? You could for
> example change the signature hashing algorithm (prepend a constant str= ing,
> or add a second hashing step) for signing, rendering the signatures in= a PoP
> unusable for actual transaction, while still committing to the same ac= tual
> transaction. That would also remove the need for the OP_RETURN to catc= h
> fees.

The idea is to simplify implementation. Existing software can be use= d
as is to sign and validate PoPs. But I do agree that it would be a
cleaner specification if we would make the PoP invalid as a
transaction. I'm open to changes here. I do like the idea to prepend a<= br> constant string. But that would require changes in transaction signing
and validation code, wouldn't it?

Y= es, of course. An alternative is adding a 21M BTC output at the end, or bit= flipping the txin prevout hashes, or another reversible transformation on t= he transaction data that is guaranteed to invalidate it.

= I think that the risk of asking people to sign something that is not an act= ual transaction, but could be used as one, is very scary.
=C2= =A0
> Also, I would call it "proof of transaction intent", as it&#= 39;s a commitment to
> a transaction and proof of its validity, but not a proof that an actua= l
> transaction took place, nor a means to prevent it from being double sp= ent.


Naming is hard. I think a simpler name that explains what its main purpose is (prove that you paid for something) is better than a name
that exactly tries to explain what it is.

= "Proof of Payment" indeed does make me think it's something t= hat proves you paid. But as described, that is not what a PoP does. It prov= es the ability to create a particular transaction, and committing to it. Th= ere is no actual payment involved (plus, payment makes me think you're = talking about BIP70 payments, not simple Bitcoin transactions).
=C2=A0
"Proof of transaction
intent" does not help me understand what this is about. But I would like to see more name suggestions. The name does not prevent people
from using it for other purposes, ie internet over telephone network.

I don't understand why something like &q= uot;Proof of Transaction Intent" would be incompatible with internet o= ver telephone network either...

--
Pieter
=C2=A0
--001a113ccf4aea9f300517dadac7--