-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Oct 26, 2013 at 3:31 AM, Gregory Maxwell wrote:
> One limitation of the payment protocol as speced is that there is no
> way for a hidden service site to make use of its full authentication
> capability because they are unable to get SSL cer
Categories that make sense to me:
1) protocol related problems
1.a) failed to deserialize transaction
2) core principle violations
2.a) script evaluation fail (only owner is allowed to spend)
2.b) outputs larger than inputs (no creation of new money)
2.c) outputs not found/already spent (no double
On Sunday, October 27, 2013 10:52:25 PM Gavin Andresen wrote:
> If anybody has strong feelings about what the reject categories should be,
> then please take the time to write a specific list, I can't read your
> mind
It might make sense to use the rejection reasons from BIP 22 where applicabl
Any reason not to use actual HTTP codes? I'm not aware of any major
deficiency in them. Most of them won't apply to us, which is fine, they
don't seem to apply to HTTP either. We can extend the scheme on our own
if we find a good reason to.
That implies 16 bits, or a varint. I would avoid
RE: use HTTP-like status codes:
Okey dokey, I'll add a one-byte machine-readable HTTP-like status code.
Unless y'all want a 32-bit status code. Or maybe a varint. Or a
three-character numeric string. I really and truly don't care, but I am
writing this code right now so whatever you want, decide
That's correct.
There's no source control so I've mirrored the weak functions.
The MiniKey function:
http://pastie.org/8435726
The PrivKey function:
http://pastie.org/8435731
> Date: Mon, 28 Oct 2013 08:46:34 +1000
> Subject: Re: [Bitcoin-development] A
Thanks for the warning; to be clear, "the Bitcoin SCI library" is this
project?
http://bitfreak.info/index.php?page=tools&t=bitsci
On Mon, Oct 28, 2013 at 8:25 AM, Andres Home wrote:
> For those developers who are using the Bitcoin SCI library (maybe others
> too, I
> found two total and coul
For those developers who are using the Bitcoin SCI library (maybe others too, I
found two total and could only make contact with one), I would advise that you
review how your software handles private key creation.
Up until today, the Bitcoin SCI library used the Mersenne Twister PRNG or the
GMP li
These nodes are much more likely to just be broken than malicious, but
without any way to diagnose why they are dropping a transaction it's hard
to find out what's really going on.
Anyway, yes, I need to spend time adding timeouts and all kinds of other
things, although of course if the transactio
On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote:
> Currently bitcoinj gets a small but steady stream of bug reports of the form
> "my transaction did not propagate". It's flaky because the library picks one
> peer to send the transaction to, and then watches it propagate across the
> networ
Yeah, something like HTTP would work well.
I'm really looking forward to this. Currently bitcoinj gets a small but
steady stream of bug reports of the form "my transaction did not
propagate". It's flaky because the library picks one peer to send the
transaction to, and then watches it propagate ac
11 matches
Mail list logo
