Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
Mark Friedenbach m...@friedenbach.org writes: Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... Ah, I forgot about that particular wart. Yech. Implies that you can order inputs or outputs, not both. Something like outputs must be in order, inputs which do not CHECK(MULTI)SIG_(VERIFY) a SIGHASH_SINGLE sig must be in order with respect to each other. But that's much less trivial since it implies script evaluation. In other news, I noticed Kristov Atlas's concurrent proposal just after I posted this (via reddit). He used far more words, but didn't note this issue either AFAICT. Thanks! Rusty. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Meta suggestions for this block size debate
OK... sorry for my confusion. https://github.com/EthanHeilman/BlockSizeDebate it is. p. On Sat, Jun 6, 2015 at 2:37 PM, gabe appleton gapplet...@gmail.com wrote: Please use the one it's originally forked from that Ethan made. I don't want to be the one who sorts through what's valid and what isn't, as I don't have as low-level an understanding as I'd like. I don't feel qualified. On Jun 6, 2015 2:34 AM, Pindar Wong pindar.w...@gmail.com wrote: Thanks Gabe. https://github.com/gappleto97/BlockSizeDebate github's reachable via vpn. p. On Sat, Jun 6, 2015 at 2:28 PM, gabe appleton gapplet...@gmail.com wrote: Yeah. We made a git repo instead, so we don't have to bother with the exclusive-by-default wiki policies. It's linked in this email chain. I'll be getting home tomorrow, so I should be able to start back up on this. A few days from now we should throw this on /r/Bitcoin so we can get some more public comment on it. They already gave me a few leads to chase. On Jun 5, 2015 11:34 PM, Pindar Wong pindar.w...@gmail.com wrote: Gabe, Did you ever get an answer to this? Ill have some time tomorrow to be able to help with some work on this and will need to do it myself anyways since I'm not sure I understand the nuances, where bitcoin XT fits into the scheme of things (or not) etc. I would have thought that there would be a testnet4 by now using 8mb blocks... but hey that's just me. p. On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com wrote: I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman eth...@gmail.com wrote: I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com wrote: Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote: Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over before, you're wasting hundreds of peoples time. Please don't. 2. Be helpful. Suggest alternatives. Just cristizising is just destructive. If you want no change, then say so. Mats -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote: Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... But in that case (unconstrained) randomization can't be used either. This is posed as an alternative to randomization. So in that regard, the proposal still makes sense. I think this move to verifyable, deterministic methods where possible is good. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Meta suggestions for this block size debate
Yeah. We made a git repo instead, so we don't have to bother with the exclusive-by-default wiki policies. It's linked in this email chain. I'll be getting home tomorrow, so I should be able to start back up on this. A few days from now we should throw this on /r/Bitcoin so we can get some more public comment on it. They already gave me a few leads to chase. On Jun 5, 2015 11:34 PM, Pindar Wong pindar.w...@gmail.com wrote: Gabe, Did you ever get an answer to this? Ill have some time tomorrow to be able to help with some work on this and will need to do it myself anyways since I'm not sure I understand the nuances, where bitcoin XT fits into the scheme of things (or not) etc. I would have thought that there would be a testnet4 by now using 8mb blocks... but hey that's just me. p. On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com wrote: I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman eth...@gmail.com wrote: I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com wrote: Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote: Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over before, you're wasting hundreds of peoples time. Please don't. 2. Be helpful. Suggest alternatives. Just cristizising is just destructive. If you want no change, then say so. Mats -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Hey Stephen, Thanks for your feedback On Fri, Jun 5, 2015 at 11:20 PM, Stephen stephencalebmo...@gmail.com wrote: - I think your explanation of sorting could be significantly shortened and clarified by simply saying that the TXIDs of inputs should be compared as uint256 integers. I considered defining the comparison of txids in terms of integers; however, I am concerned that this definition may be ambiguous when applied to a variety of languages and platforms without a similar amount of explanation as currently exists. For example, if a web wallet uses an API to receive transaction information, this is traditionally expressed in terms tx id strings rather than 256-bit integers. My intent is that wallets can implement the algorithm however they wish, but should ensure that their output is compliant with the BIP definition. IMHO the algorithm stated in the BIP should target test cases rather than implementation, and should leave as little room for ambiguity as possible. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Meta suggestions for this block size debate
Please use the one it's originally forked from that Ethan made. I don't want to be the one who sorts through what's valid and what isn't, as I don't have as low-level an understanding as I'd like. I don't feel qualified. On Jun 6, 2015 2:34 AM, Pindar Wong pindar.w...@gmail.com wrote: Thanks Gabe. https://github.com/gappleto97/BlockSizeDebate github's reachable via vpn. p. On Sat, Jun 6, 2015 at 2:28 PM, gabe appleton gapplet...@gmail.com wrote: Yeah. We made a git repo instead, so we don't have to bother with the exclusive-by-default wiki policies. It's linked in this email chain. I'll be getting home tomorrow, so I should be able to start back up on this. A few days from now we should throw this on /r/Bitcoin so we can get some more public comment on it. They already gave me a few leads to chase. On Jun 5, 2015 11:34 PM, Pindar Wong pindar.w...@gmail.com wrote: Gabe, Did you ever get an answer to this? Ill have some time tomorrow to be able to help with some work on this and will need to do it myself anyways since I'm not sure I understand the nuances, where bitcoin XT fits into the scheme of things (or not) etc. I would have thought that there would be a testnet4 by now using 8mb blocks... but hey that's just me. p. On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com wrote: I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman eth...@gmail.com wrote: I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com wrote: Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote: Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over before, you're wasting hundreds of peoples time. Please don't. 2. Be helpful. Suggest alternatives. Just cristizising is just destructive. If you want no change, then say so. Mats -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Meta suggestions for this block size debate
Thanks Gabe. https://github.com/gappleto97/BlockSizeDebate github's reachable via vpn. p. On Sat, Jun 6, 2015 at 2:28 PM, gabe appleton gapplet...@gmail.com wrote: Yeah. We made a git repo instead, so we don't have to bother with the exclusive-by-default wiki policies. It's linked in this email chain. I'll be getting home tomorrow, so I should be able to start back up on this. A few days from now we should throw this on /r/Bitcoin so we can get some more public comment on it. They already gave me a few leads to chase. On Jun 5, 2015 11:34 PM, Pindar Wong pindar.w...@gmail.com wrote: Gabe, Did you ever get an answer to this? Ill have some time tomorrow to be able to help with some work on this and will need to do it myself anyways since I'm not sure I understand the nuances, where bitcoin XT fits into the scheme of things (or not) etc. I would have thought that there would be a testnet4 by now using 8mb blocks... but hey that's just me. p. On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com wrote: I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman eth...@gmail.com wrote: I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com wrote: Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote: Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over before, you're wasting hundreds of peoples time. Please don't. 2. Be helpful. Suggest alternatives. Just cristizising is just destructive. If you want no change, then say so. Mats -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Meta suggestions for this block size debate
Nothing to apologize for. And yes, that's the correct one. On Jun 6, 2015 2:39 AM, Pindar Wong pindar.w...@gmail.com wrote: OK... sorry for my confusion. https://github.com/EthanHeilman/BlockSizeDebate it is. p. On Sat, Jun 6, 2015 at 2:37 PM, gabe appleton gapplet...@gmail.com wrote: Please use the one it's originally forked from that Ethan made. I don't want to be the one who sorts through what's valid and what isn't, as I don't have as low-level an understanding as I'd like. I don't feel qualified. On Jun 6, 2015 2:34 AM, Pindar Wong pindar.w...@gmail.com wrote: Thanks Gabe. https://github.com/gappleto97/BlockSizeDebate github's reachable via vpn. p. On Sat, Jun 6, 2015 at 2:28 PM, gabe appleton gapplet...@gmail.com wrote: Yeah. We made a git repo instead, so we don't have to bother with the exclusive-by-default wiki policies. It's linked in this email chain. I'll be getting home tomorrow, so I should be able to start back up on this. A few days from now we should throw this on /r/Bitcoin so we can get some more public comment on it. They already gave me a few leads to chase. On Jun 5, 2015 11:34 PM, Pindar Wong pindar.w...@gmail.com wrote: Gabe, Did you ever get an answer to this? Ill have some time tomorrow to be able to help with some work on this and will need to do it myself anyways since I'm not sure I understand the nuances, where bitcoin XT fits into the scheme of things (or not) etc. I would have thought that there would be a testnet4 by now using 8mb blocks... but hey that's just me. p. On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com wrote: I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman eth...@gmail.com wrote: I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com wrote: Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote: Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over before, you're wasting hundreds of peoples time. Please don't. 2. Be helpful. Suggest alternatives. Just cristizising is just destructive. If you want no change, then say so. Mats -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
Certainly, but I would drop discussion of IsStandard or consensus rules. On Jun 6, 2015 1:24 AM, Wladimir J. van der Laan laa...@gmail.com wrote: On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote: Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... But in that case (unconstrained) randomization can't be used either. This is posed as an alternative to randomization. So in that regard, the proposal still makes sense. I think this move to verifyable, deterministic methods where possible is good. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for Proof of Payment
On Sat, Jun 6, 2015 at 5:05 PM, Kalle Rosenbaum ka...@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 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for Proof of Payment
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.
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.
On Sat, Jun 6, 2015 at 4:35 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote:
Hi
Following earlier posts on Proof of Payment I'm now proposing the
following BIP (To read it formatted instead, go to
https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP).
Regards,
Kalle Rosenbaum
pre
BIP: BIP number
Title: Proof of Payment
Author: Kalle Rosenbaum ka...@rosenbaum.se
Status: Draft
Type: Standards Track
Created: date created on, in ISO 8601 (-mm-dd) format
/pre
== Abstract ==
This BIP describes how a wallet can prove to a server that it has the
ability to sign a certain transaction.
== Motivation ==
There are several scenarios in which it would be useful to prove that you
have paid for something. For example:
* A pre-paid hotel room where your PoP functions as a key to the door.
* An online video rental service where you pay for a video and watch it on
any device.
* An ad-sign where you pay in advance for e.g. 2 weeks exclusivity. During
this period you can upload new content to the sign whenever you like using
PoP.
* Log in to a pay site using a PoP.
* A parking lot you pay for monthly and the car authenticates itself using
PoP.
* A lottery where all participants pay to the same address, and the winner
is selected among the transactions to that address. You exchange the prize
for a PoP for the winning transaction.
With Proof of Payment, these use cases can be achieved without any
personal information (user name, password, e-mail address, etc) being
involved.
== Rationale ==
Desirable properties:
# A PoP should be generated on demand.
# It should only be usable once to avoid issues due to theft.
# It should be able to create a PoP for any payment, regardless of script
type (P2SH, P2PKH, etc.).
# It should prove that you have enough credentials to unlock all the
inputs of the proven transaction.
# It should be easy to implement by wallets and servers to ease adoption.
Current methods of proving a payment:
* In BIP0070, the PaymentRequest together with the transactions fulfilling
the request makes some sort of proof. However, it does not meet 1, 2 or 4
and it obviously only meets 3 if the payment is made through BIP0070. Also,
there's no standard way to request/provide the proof. If standardized it
would probably meet 5.
* Signing messages, chosen by the server, with the private keys used to
sign the transaction. This could meet 1 and 2 but probably not 3. This is
not standardized either. 4 Could be met if designed so.
If the script type is P2SH, any satisfying script should do, just like for
a payment. For M-of-N multisig scripts, that would mean that any set of M
keys should be sufficient, not neccesarily the same set of M keys that
signed the transaction. This is important because strictly demanding the
same set of M keys would undermine the purpose of a multisig address.
== Specification ==
=== Data structure ===
A proof of payment for a transaction T, here called PoP(T), is used to
prove that one has ownership of the credentials needed to unlock all the
inputs of T. It has the exact same structure as a bitcoin transaction with
the same inputs and outputs as T and in the same order as in T. There is
also one OP_RETURN output inserted at index 0, here called the pop output.
This output must have the following format:
OP_RETURN version txid nonce
{|
! Field!! Size [B] !! Description
|-
| lt;version || 2|| Version, little endian, currently 0x01 0x00
|-
| lt;txid|| 32 || The transaction to prove
|-
| lt;nonce || 6|| Random data
|}
The value of the pop output is set to the same value as the transaction
fee of T. Also, if the outputs of T contains an OP_RETURN output, that
output must not be included in the PoP because there can only be one
OP_RETURN output in a transaction. The value of that OP_RETURN output is
instead added to the value of the pop output.
An illustration of the PoP data structure and its original payment is
shown below.
pre
T
+--+
|inputs | outputs|
| Value | Value Script |
+--+
|input0 1 | 0 pay to A |
|input1 3 | 2 OP_RETURN some data |
Re: [Bitcoin-development] BIP for Proof of Payment
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. If we do decide to make Pops invalid as transactions, there are a lot of ways to do that. I guess the main question is if we should make Pops invalid as transactions or not. So far I prefer to keep them valid for the above reason. 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. I would feel comfortable doing it. It's just a matter of trusting your wallet, which you already do with your ordinary transactions. 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... No, I meant that it's ok to call it Proof of Payment even though people may use it for other stuff. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP for PoP URI scheme
Hi
Following earlier posts on Proof of Payment I'm now proposing the following
BIP for a Proof of Payment URI scheme (To read it formatted instead, go to
https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP).
Regards,
Kalle Rosenbaum
pre
BIP: BIP number
Title: Proof of Payment URI scheme
Author: Kalle Rosenbaum ka...@rosenbaum.se
Status: Draft
Type: Standards Track
Created: date created on, in ISO 8601 (-mm-dd) format
/pre
== Abstract ==
This is a proposal for a URI scheme to be used in the Proof of Payment
process.
== Motivation ==
To make a Proof of Payment, the party that wants the proof needs to
transfer a Proof of Payment request to the wallet software of the
other party. To facilitate that transfer, a new URI scheme
representing the PoP request is proposed. This URI can then be encoded
in QR images or sent over NFC in order to transfer it to the wallet.
== Specification ==
The specification is the same as BIP0021, with the following
differences:
* The URI scheme is ttbtcpop/tt instead of ttbitcoin/tt
* The path component, i.e. the address part, is always empty.
* A mandatory ttp/tt parameter whose value contains the destination for
the PoP. This could for example be a tthttps:/tt URL or a ttmailto:/tt
URI.
* A mandatory ttn/tt parameter representing the nonce, base58 encoded.
* An optional tttxid/tt parameter containing the Base58 encoded hash of
the transaction to prove.
Just as in BIP0021, elements of the query component may contain
characters outside the valid range. These must first be encoded
according to UTF-8, and then each octet of the corresponding UTF-8
sequence must be percent-encoded as described in RFC 3986.
All parameters except ttp/tt and ttn/tt are hints to the
wallet on which transaction to create a PoP for.
The extensibility of BIP0021 applies to this scheme as well. For
example, a ttdate/tt parameter or a tttoaddr/tt parameter
might be useful. ttreq-*/tt parameters are also allowed and obey
the same rules as in BIP0021, clients not supporting a ttreq-*/tt
parameter must consider the URI invalid.
=== Keep URIs short ===
Implementations should keep the URIs as short as possible. This is
because it makes QR decoding more stable. A camera with a scratched
lens or low resolution may run into problems scanning huge QR
codes. This is why the tttxid/tt parameter is encoded in Base58
instead of the classic hex encoded string. We get away with 44
characters instead of 64. Also, the ttnonce/tt parameter is Base58
encoded for the same reason.
== Interpretation ==
=== Transaction hints ===
The wallet processing the URI must use the hints in the PoP request to
filter its transaction set. The ttlabel/tt, ttamount/tt and
ttmessage/tt parameters must, if present in the URI, exactly match
the data associated with the original payment according to the
following table:
{|
| ttbtcpop:/tt URI parameter || ttbitcoin:/tt URI parameter ||
BIP70 PaymentDetails data
|-
| ttlabel/tt || ttlabel/tt ||
ttmerchant_data/tt
|-
| ttamount/tt|| ttamount/tt ||
ttsum of outputs.amount/tt
|-
| ttmessage/tt || ttmessage/tt||
ttmemo/tt
|}
The tttxid/tt parameter value must match the transaction hash of
the payment.
After filtering, the resulting transaction set is displayed to the
user who selects one of them to prove. An implementation could also
automatically select a transaction in the filtered set, but
there must still be a way for the user to select freely among the
matching transactions. If the filtered set is empty, no transaction
fits the hints and a message about that is presented to the user. If
the filtered set contains exactly one transaction, which is
preferable, that transaction can be automatically selected.
As a fallback, there must also be a way for the user to select any
transaction from the wallet regardless of the transaction hints. This
can be useful if the metadata of the wallet is lost, possibly due to a
restore from backup.
=== PoP destination ttp/tt ===
The ttp/tt parameter value is the destination where to send the
PoP to. This destination is typically a tthttps:/tt URL or a
tthttp:/tt URL, but it could be any type of URI, for example
ttmailto:/tt. To keep ttbtcpop:/tt URIs short, users should
not make their ttp/tt parameter unneccesarily long.
tthttp:/tt and tthttps:/tt URLs
Wallet implementations must support the tthttp:/tt and
tthttps:/tt schemes in which case ttPOST/tt method must be
used. The content type of the POST request must be set to
Content-Type: application/bitcoin-pop
Content-Transfer-Encoding: binary
== Examples ==
Send PoP for a transaction with label video 42923 to
tthttps://www.example.com/pop/352/tt, using nonce tt0x73 0xd5
0x1a 0xbb 0xd8 0x9c/tt:
btcpop:?p=https://www.example.com/pop/352n=zgWTm8yHlabel=video 42923
Send PoP through mail using
ttmailto:p...@example.com?subject=pop444/tt, amount is 1337
Re: [Bitcoin-development] BIP for Proof of Payment
On Saturday, June 06, 2015 2:35:17 PM Kalle Rosenbaum wrote: Current methods of proving a payment: * Signing messages, chosen by the server, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either. 4 Could be met if designed so. It's also not secure, since the signed messages only prove ownership of the address associated with the private key, and does not prove ownership of UTXOs currently redeemable with the private key, nor prove past UTXOs spent were approved by the owner of the address. A proof of payment for a transaction T, here called PoP(T), is used to prove that one has ownership of the credentials needed to unlock all the inputs of T. This appears to be incompatible with CoinJoin at least. Maybe there's some clean way to avoid that by using https://github.com/Blockstream/contracthashtool ? It has the exact same structure as a bitcoin transaction with the same inputs and outputs as T and in the same order as in T. There is also one OP_RETURN output inserted at index 0, here called the pop output. I also agree with Pieter, that this should *not* be so cleanly compatible with Bitcoin transactions. If you wish to share code, perhaps using an invalid opcode rather than OP_RETURN would be appropriate. Luke -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP for Proof of Payment
Hi
Following earlier posts on Proof of Payment I'm now proposing the following
BIP (To read it formatted instead, go to
https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP).
Regards,
Kalle Rosenbaum
pre
BIP: BIP number
Title: Proof of Payment
Author: Kalle Rosenbaum ka...@rosenbaum.se
Status: Draft
Type: Standards Track
Created: date created on, in ISO 8601 (-mm-dd) format
/pre
== Abstract ==
This BIP describes how a wallet can prove to a server that it has the
ability to sign a certain transaction.
== Motivation ==
There are several scenarios in which it would be useful to prove that you
have paid for something. For example:
* A pre-paid hotel room where your PoP functions as a key to the door.
* An online video rental service where you pay for a video and watch it on
any device.
* An ad-sign where you pay in advance for e.g. 2 weeks exclusivity. During
this period you can upload new content to the sign whenever you like using
PoP.
* Log in to a pay site using a PoP.
* A parking lot you pay for monthly and the car authenticates itself using
PoP.
* A lottery where all participants pay to the same address, and the winner
is selected among the transactions to that address. You exchange the prize
for a PoP for the winning transaction.
With Proof of Payment, these use cases can be achieved without any personal
information (user name, password, e-mail address, etc) being involved.
== Rationale ==
Desirable properties:
# A PoP should be generated on demand.
# It should only be usable once to avoid issues due to theft.
# It should be able to create a PoP for any payment, regardless of script
type (P2SH, P2PKH, etc.).
# It should prove that you have enough credentials to unlock all the inputs
of the proven transaction.
# It should be easy to implement by wallets and servers to ease adoption.
Current methods of proving a payment:
* In BIP0070, the PaymentRequest together with the transactions fulfilling
the request makes some sort of proof. However, it does not meet 1, 2 or 4
and it obviously only meets 3 if the payment is made through BIP0070. Also,
there's no standard way to request/provide the proof. If standardized it
would probably meet 5.
* Signing messages, chosen by the server, with the private keys used to
sign the transaction. This could meet 1 and 2 but probably not 3. This is
not standardized either. 4 Could be met if designed so.
If the script type is P2SH, any satisfying script should do, just like for
a payment. For M-of-N multisig scripts, that would mean that any set of M
keys should be sufficient, not neccesarily the same set of M keys that
signed the transaction. This is important because strictly demanding the
same set of M keys would undermine the purpose of a multisig address.
== Specification ==
=== Data structure ===
A proof of payment for a transaction T, here called PoP(T), is used to
prove that one has ownership of the credentials needed to unlock all the
inputs of T. It has the exact same structure as a bitcoin transaction with
the same inputs and outputs as T and in the same order as in T. There is
also one OP_RETURN output inserted at index 0, here called the pop output.
This output must have the following format:
OP_RETURN version txid nonce
{|
! Field!! Size [B] !! Description
|-
| lt;version || 2|| Version, little endian, currently 0x01 0x00
|-
| lt;txid|| 32 || The transaction to prove
|-
| lt;nonce || 6|| Random data
|}
The value of the pop output is set to the same value as the transaction fee
of T. Also, if the outputs of T contains an OP_RETURN output, that output
must not be included in the PoP because there can only be one OP_RETURN
output in a transaction. The value of that OP_RETURN output is instead
added to the value of the pop output.
An illustration of the PoP data structure and its original payment is shown
below.
pre
T
+--+
|inputs | outputs|
| Value | Value Script |
+--+
|input0 1 | 0 pay to A |
|input1 3 | 2 OP_RETURN some data |
|input2 4 | 1 pay to B |
| | 4 pay to C |
+--+
PoP(T)
+--+
|inputs | outputs|
| Value | Value Script |
+--+
|input0 1 | 3 OP_RETURN version txid nonce |
|input1 3 | 0 pay to A |
|input2 4 | 1 pay to B |
| | 4 pay to C |
+--+
/pre
The PoP is signed using the same signing process that is used
Re: [Bitcoin-development] BIP for Proof of Payment
On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr l...@dashjr.org wrote: I also agree with Pieter, that this should *not* be so cleanly compatible with Bitcoin transactions. If you wish to share code, perhaps using an invalid opcode rather than OP_RETURN would be appropriate. Using an invalid opcode would merely send funds into the void. It wouldn't invalidate the transaction. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for Proof of Payment
On Jun 6, 2015 8:05 AM, Kalle Rosenbaum ka...@rosenbaum.se wrote: I'm open to changes here. I suggest: - Don't include any real outputs. They are redundant because the txid is already referenced. - Start the proof script, which should be invalid, with a magic constant and include space for future expansion. This makes PoP's easy to identify and extend. - Proof of Potential -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for Proof of Payment
On Saturday, June 06, 2015 9:25:02 PM Kalle Rosenbaum wrote: * The pop output will have value 0. Why not have it be -1 to make it completely invalid as a transaction? Luke -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
