Thanks g.maxwell, your explanation of *why* you can't just generate k
in a way that the verifier can duplicate is really helpful. This also
servers as a great illustration why engineers should never try to
designing their own crypto protocols! I knew enough to know not try
that at least.
Aaron Voi
On Jul 18, 2014 4:56 PM, "Wladimir" wrote:
>
> On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn wrote:
> > The rationale doesn't seem to apply to rule #4, what's so special about
that
> > one?
>
> > 4. Non-push operations in scriptSig Any non-push operation in a
scriptSig invalidates it.
>
> Having no
Ah, good point. For some reason I was thinking the k value was
generated only from the hash being signed, but it's derived from both
the private key and the hash, so as you say there's no way for the
verifier to tell if the scheme is being followed.
Aaron Voisine
breadwallet.com
On Fri, Jul 18
On Fri, Jul 18, 2014 at 4:53 PM, Gavin Andresen wrote:
> Two more half-baked thoughts:
>
> We should be able to assume that the majority of transaction data (except
> for coinbase) has already been propagated. As Jeff said, incentivizing nodes
> to propagate transactions is a very good thing (the
On Fri, Jul 18, 2014 at 9:33 PM, Richard Moore wrote:
> Hey all,
> I'm wondering if anyone can help explain to me tx
> 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d...
A rather timely post. See the other thread on BIP0062. What you're
looking at is an example of a well-known-
On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine wrote:
> Well, you could always create a transaction with a different signature
> hash, say, by changing something trivial like nLockTime, or changing
> the order of inputs or outputs. Is that what you're talking about? Or
> is there some sophistry I'
6 matches
Mail list logo
