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
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
network.
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
Thanks for the warning; to be clear, the Bitcoin SCI library is this
project?
http://bitfreak.info/index.php?page=toolst=bitsci
On Mon, Oct 28, 2013 at 8:25 AM, Andres Home a86...@outlook.com wrote:
For those developers who are using the Bitcoin SCI library (maybe others
too, I
found two
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]
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
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
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 applicable.
8 matches
Mail list logo
