He has already repented in another thread. So he sent them back? |
|
|
|
|
Care to define "serial number"?
|
|
|
|
|
Official binaries can easily be a single feature-set without breaking the ability to compile without it.
|
|
|
|
The Wallet protocol should take care of this by allowing creating transactions without submitting them to the network. So you would do it in three steps: first, ask it to create the transaction; then, check the transaction it returns; finally, give it the okay to sign and transmit it (possibly providing a higher-authority password). |
|
|
|
This introduces a regression, since -settxfee accepts <0.01 right now, and it's sane to do so.
That's intentional, not a regression. It's a regression by definition, because it works today and your patch breaks it. |
|
|
|
|
This introduces a regression, since -settxfee accepts <0.01 right now, and it's sane to do so.
|
|
|
|
|
round(1e8 * value) works in basically any language.
|
|
|
|
|
FWIW, Spesmilo behaves correctly as you describe.
|
|
|
|
Copyleft means not suitable for MIT licensing. |
|
|
|
|
Ok, rewrote my branch to only set locale and hard-code "+0000"; good idea.
|
|
|
|
What is meant by "rather inefficient"? Speed of serializing/deserializing? That also, but my understanding is that python-jsonrpc only supports single-request-per-connection HTTP/1.0, whereas jgarzik's bitcoinrpc supports HTTP/1.1 persistent connections. Why do we even recommend JSON-RPC at all?
It's not even an official library for Python and it isn't very good (uses floats and has no persistent connections). We should only be recommending jgarzik's version. Who recommends it? The proposed summary clearly recommend jgarzik's fork. It is an official library for JSON-RPC. |
|
|
|
Does this wording satisfy everyone? For Python, python-jsonrpc is the official JSON-RPC implementation. It automatically generates Python methods for RPC calls. However, due to its design for supporting old versions of Python, it is also rather inefficient. jgarzik has forked it as Python-BitcoinRPC and optimized it for current versions (at least Python 2.6+, though not 3.x). Generally, this version is recommended.
While BitcoinRPC lacks a few obscure features from jsonrpc, software using only the ServiceProxy class can be written the same to work with either version the user might choose to install: |
|
|
|
|
Correction to my above summary: bitcoind does use gmtime to get the correct UTC time, but the problem was that Windows still tries to put the local timezone for %Z rather than UTC as is being encoded.
Actually, according to the RFC, numeric timezones should be used (not names). So rather than force TZ to UTC, the buffer should be extended and %z used instead of %Z. I do not have any idea if Windows complies with %z better than %Z, so I am leaving the temporarily-set-TZ hack in. Otherwise, my branch now uses %z.
Please note that the timezone is not the only issue here. The locale must also be forced to POSIX to get the usual weekday (Sun-Sat) and month (Jan-Dec) abbreviations, rather than some local variant.
|
|
|
|
|
Someone in #bitcoin-discussion was having problems with JSON-RPC and it turned out to be related to their timezone overflowing the rfc1123Time function's buffer. My 'rfc1123Time_localefix' branch addresses the problem by forcing the locale and timezone to POSIX and UTC for its purposes (and resetting it back later).
git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git rfc1123Time_localefix && git diff 454bc8..FETCH_HEAD && git merge FETCH_HEAD
I suspect the JSON-RPC has other locale problems as well, in case someone wants to look into it further.
|
|
|
|
Oops, misunderstood your original addition. Guess we don't have anyone taking free transactions then. The element listed is my miner, not my relay. |
|
|
|
No, it's just a relay. Miners who want to accept "boycotted" transactions connect to it. People who want to send them connect to it. Theymos, at least, advertises his miner as completely fee-free. Mine's also just a relay, which is why I put it on the same wiki page as yours. If it's just a relay, it shouldn't be listed under "Participating miners"... |
|
|
|
If you restart bitcoind with -addnode=173.242.112.53 it will get into a block eventually. That node will include the ultra-micro transaction even though it includes no fee? No, it's just a relay. Miners who want to accept "boycotted" transactions connect to it. People who want to send them connect to it. Theymos, at least, advertises his miner as completely fee-free. |
|
|
|
|
If you restart bitcoind with -addnode=173.242.112.53 it will get into a block eventually.
|
|
|
|
|
Show Posts
