Hi Greg!
After a lot of constructive discussion, feedback and updating, I'm
requesting that you please assign these proposals BIP numbers. It's both
the "Proof of Payment" proposal and the "Proof of Payment URI scheme"
proposal that I'm referring to.
The wikimedia source is available here:
https:
2015-06-16 21:48 GMT+02:00 Pieter Wuille :
> I don't see why existing software could create a 40-byte OP_RETURN but not
> larger? The limitation comes from a relay policy in full nodes, not a
> limitation is wallet software... and PoPs are not relayed on the network.
You are probably right here. T
I don't see why existing software could create a 40-byte OP_RETURN but not
larger? The limitation comes from a relay policy in full nodes, not a
limitation is wallet software... and PoPs are not relayed on the network.
Regarding sharing, I think you're talking about a different use case. Say
you w
You can't avoid sharing the token, and you can't avoid sharing the private
keys used for signing either. If they are single use, you don't lose
anything by sharing them.
Also you are not creating a real transaction. Why does the OP_RETURN
limitation matter?
On Jun 16, 2015 9:22 PM, "Kalle Rosenbau
Thank you for your comments Pieter! Please find my answers below.
2015-06-16 16:31 GMT+02:00 Pieter Wuille :
> On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum wrote:
>>
>> 2015-06-15 12:00 GMT+02:00 Pieter Wuille :
>> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
>> someone
Thank you for the clarification Tom!
/Kalle
2015-06-16 16:05 GMT+02:00 Tom Harding :
> On 6/16/2015 5:12 AM, Kalle Rosenbaum wrote:
>> 2015-06-16 7:26 GMT+02:00 Tom Harding :
>>> Kalle goes to some trouble to describe how merchants need to ensure that
>>> they only accept a PoP provided as a resp
On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum wrote:
> 2015-06-15 12:00 GMT+02:00 Pieter Wuille :
> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> someone with more insight into CoinJoin have some input?
>
Not really. The problem is that you assume a transaction corresp
On 6/16/2015 5:12 AM, Kalle Rosenbaum wrote:
> 2015-06-16 7:26 GMT+02:00 Tom Harding :
>> Kalle goes to some trouble to describe how merchants need to ensure that
>> they only accept a PoP provided as a response to their challenge.
>>
> Do you mean that it will be hard to explain to merchants that
Another thing worth mentioning is that an SPV wallet cannot validate a
PoP without fetching the input transactions of the PoP from an
external (not bitcoin network) source, for example chain.com or some
other trusted full node's API.
The validation of the PoP depends on the external source(s) bein
2015-06-16 7:26 GMT+02:00 Tom Harding :
>
> Kalle goes to some trouble to describe how merchants need to ensure that
> they only accept a PoP provided as a response to their challenge.
>
Do you mean that it will be hard to explain to merchants that they
must check the nonce in the PoP so that it m
Shared wallets were discussed earlier as a feature. If you pay a for
dry cleaning with a shared wallet, a different 1-of-N signer can pick up
the clothes with no physical transfer of a claim check, by proving the
money that paid for the cleaning was his.
Many kinds of vouchers can be eliminated,
2015-06-15 12:00 GMT+02:00 Pieter Wuille :
> I did misunderstand that. That changes things significantly.
>
> However, having paid is not the same as having had access to the input
> coins. What about shared wallets or coinjoin?
Wallets will have the same ability to make PoPs as they have in makin
I did misunderstand that. That changes things significantly.
However, having paid is not the same as having had access to the input
coins. What about shared wallets or coinjoin?
Also, if I understand correctly, there is no commitment to anything you're
trying to say about the sender? So once I ob
Hi all!
I have made the discussed changes and updated my implementation (
https://github.com/kallerosenbaum/poppoc) accordingly. These are the
changes:
* There is now only one output, the "pop output", of value 0.
* The sequence number of all inputs of the PoP must be set to 0. I
chose to set it
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
--
___
Thank you all for the feedback.
I will change the data structure as follows:
* There will be only one output, the "pop output", and no outputs from
T will be copied to the PoP.
* The pop output will have value 0.
* The sequence number of all inputs of the PoP will be set to 0. I
chose to set it t
2015-06-06 18:10 GMT+02:00 Tom Harding :
> On Jun 6, 2015 8:05 AM, "Kalle Rosenbaum" wrote:
>
>> I'm open to changes here.
>
> I suggest:
>
> - Don't include any real outputs. They are redundant because the txid is
> already referenced.
with the nLocktime solution, the copied outputs are not ne
2015-06-06 17:32 GMT+02:00 Peter Todd :
> On Sat, Jun 06, 2015 at 05:23:48PM +0200, Pieter Wuille wrote:
>> On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr wrote:
>>
>> > I also agree with Pieter, that this should *not* be so cleanly compatible
>> > with Bitcoin transactions. If you wish to share code
On Jun 6, 2015 8:05 AM, "Kalle Rosenbaum" 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
>> 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.
On Sat, Jun 06, 2015 at 05:23:48PM +0200, Pieter Wuille wrote:
> On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr 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
On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr 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 mere
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
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
> P
> 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 s
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
actu
26 matches
Mail list logo
