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 us
Certainly, but I would drop discussion of IsStandard or consensus rules.
On Jun 6, 2015 1:24 AM, "Wladimir J. van der Laan" 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 amo
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
BIP:
Title: Proof of Payment
Author: Kalle Rosenbaum
Status: Draft
Ty
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
BIP:
Title: Proof of Payment URI scheme
Aut
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
> 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
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
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 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 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
>> 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 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
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
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
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
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
--
___
I've updated the draft BIP in two ways:
-Making it clear that sorting is algorithmically agnostic, but should
conform to the output of the example algorithms written in python
-The BIP now handles schemes that create an input/output dependency, such
as SIGHASH_SINGLE:
Handling Input/Output Depende
On Sat, Jun 06, 2015 at 08:06:56PM -0400, Kristov Atlas wrote:
In general I think this is a good idea, and should be implemented; we've
had a depressing number of wallets fail to implement randomization
properly, if at all.
> I've updated the draft BIP in two ways:
> -Making it clear that sorting
18 matches
Mail list logo
