2015-06-16 21:48 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com:
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
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)
Thank you for the clarification Tom!
/Kalle
2015-06-16 16:05 GMT+02:00 Tom Harding t...@thinlink.com:
On 6/16/2015 5:12 AM, Kalle Rosenbaum wrote:
2015-06-16 7:26 GMT+02:00 Tom Harding t...@thinlink.com:
Kalle goes to some trouble to describe how merchants need to ensure that
they only
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
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
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
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
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
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
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: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
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
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
--
13 matches
Mail list logo
