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
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
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
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
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
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
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
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:
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
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
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
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
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
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
--
18 matches
Mail list logo
