|
Could just rename the (internal) setting name, and have it default to off...
|
|
|
|
|
The HTTP/1.1 improvements aside... the use of Decimal is in fact a regression. Here's why:
It will encourage people to treat bitcoin values as BTC internally, rather than atomic units. Besides being simply wrong, this also creates a problem because according to the current JSON-RPC rules, one end is allowed to send the value "0.999999999" and the other end should process it as 100000000 units (eg, 1 BTC).
Whether the library returns float or Decimal, the application still needs to process all amounts with round(1e8 * amount). Float is more efficient, and clearly discourages bad behaviour, so is a better fit in this particular case.
|
|
|
|
|
round(100000000 * amount) works fine in PHP. The new Wallet protocol will use ints properly, so this should be good enough.
|
|
|
|
It doesn't look like Gavin's change even generated no-fee transactions -- it just accepted them, which is harmless. Just to clarify: 'myFreeTx' is my branch, not Gavin's. He created the pull request for it at my suggestion, because I have been asked numerous times on IRC about that change. I didn't (and won't) create any pull requests on GitHub myself, because their terms of service are draconian and I don't agree to contracts I won't abide by out of principle. |
|
|
|
It works together with my policy changes. I also just pushed a fix so it works by itself. Gavin may wish to reconsider it, based on this new use, but regardless of whether it gets merged or not is irrelevant. Bitcoin isn't a monopolistic centralized proprietary software, it's a community of mostly free software, and miners too are free to run whatever code they wish. I don't understand what you mean by "policy changes." Can you elaborate on that? I just had a look at github, and I didn't see any pull requests along these lines. Do you have a link? See my 'policy' branch at http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git ; fixed 'myFreeTx' is also there. Note that these are my personal branches, not necessarily intended or designed for any mainstream use, possibly not even working (eg, IPv6). You're right, Bitcoin's not proprietary, and you are free to run whatever code you want. But the problem is, the patch that Gavin submitted violates the established protocol. When you generate a transaction that, according to the established protocol would require a transaction fee, but you do not include that fee in your transaction, no other node will accept that transaction. That's why Gavin withdrew the patch. And as I said in the comments for the patch, the patch isn't necessary anyway. If you happen to generate the transaction, you get the transaction fee back and it's free (for you). If someone else generates it, they get the fee. Policies are not protocol. There are miners who accept less (or even none, in some cases) fees. You just have to connect your client to the Free transaction relay network to get across the anti-social clients that refuse to relay anything they wouldn't personally accept. The problem with "simply" collecting your own fee is that someone else can collect it too. Sometimes, you might prefer to WAIT for your own block, rather than MAYBE get the fee if you by unlikely chance generate the next one... No, it just allows the address-controller to decide which other miner is allowed to get the fee. Are we talking about the same patch? I'm referring to the "My free tx" patch submitted by Gavin, and described here: https://github.com/bitcoin/bitcoin/pull/97. That patch does not give you any control over who gets the fee. This was in response to the earlier suggestion for a similar patch, but one which treated a known address (not in the miner's wallet) as "fee", trusting the holder of that address to distribute earnings fairly. |
|
|
|
Then I say in the short term, we deal with JSON's quirks and leave the number as a number (which some languages may treat as a float instead of decimal), but take this into account when designing Bitcoin RPC v2. Exactly: https://en.bitcoin.it/wiki/Wallet_protocol |
|
|
|
It may work, but it doesn't seem to DO anything except keep your transactions from being accepted by any other miner. No, it just allows the address-controller to decide which other miner is allowed to get the fee. |
|
|
|
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="exportedWallet"
--exportedWallet
Content-Type: application/x-ecdsa-private-key
Content-Transfer-Encoding: base64
X-Bitcoin-Network-ID: <network id>
X-Bitcoin-First-Block: <block number>
X-Bitcoin-Txid: f2ed2f6cc779696969690696abababa4ccf185d478aa799eb7d3e561c77b1022
X-Bitcoin-Txid: f2ed2f6cc779696969690696abababa4ccf185d478aa799eb7d338712abff2b3
X-Bitcoin-Start-Block: <last block scanned>
X-Bitcoin-Wallet-Flags: <flags>
X-Bitcoin-Wallet-Label: <label>
X-Bitcoin-Wallet-Comment: <comment>
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--exportedWallet
Content-Type: application/x-ecdsa-private-key
Content-Transfer-Encoding: base64
X-Bitcoin-Network-ID: <network id>
X-Bitcoin-First-Block: <block number>
X-Bitcoin-Txid: f2ed2f6cc779696969690696abababa4ccf185d478aa799eb7d3e561c77b1024
X-Bitcoin-Txid: f2ed2f6cc779696969690696abababa4ccf185d478aa799eb7d338712abff2b4
X-Bitcoin-Start-Block: <last block scanned>
X-Bitcoin-Wallet-Flags: <flags>
X-Bitcoin-Wallet-Label: <label>
X-Bitcoin-Wallet-Comment: <comment>
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--exportedWallet-- |
|
|
|
|
BUT regardless, this is theft. If you damage it (which overclocking is), you should eat the cost.
|
|
|
|
|
I'm encouraging the FreeSWITCH project to accept donations in bitcoin.
|
|
|
|
|
Ever hear of jurisdiction? Not everyone lives in the US.
|
|
|
|
You can potentially choose a specific miner by sending the fee portion directly to their address. This requires miners merge the myFreeTx branch, and may be a reason to reconsider merging it into mainline. It doesn't help create a multi-miner whitelist, though.
Luke, stop pushing the myFreeTx patch. As I posted the other day, it won't work, and Gavin dropped the pull request. You can read the discussion here: https://github.com/bitcoin/bitcoin/pull/97. It works together with my policy changes. I also just pushed a fix so it works by itself. Gavin may wish to reconsider it, based on this new use, but regardless of whether it gets merged or not is irrelevant. Bitcoin isn't a monopolistic centralized proprietary software, it's a community of mostly free software, and miners too are free to run whatever code they wish. |
|
|
|
|
No, they would just have their single "JSON-RPC value to raw bitcoins" function check the type of the argument and react appropriately. However, using strings is even MORE unprofessional than floats.
|
|
|
|
I agree that if you're going to be performing lots of calculations on bitcoin values you need a Decimal type If you're going to be doing *anything* with Bitcoin values, you should be using an int64. |
|
|
|
|
Spesmilo also supports bitcoin: URIs
|
|
|
|
Wow you actually have an ISP that blocks ports....you know that is against the privacy act right? (Blocking a port that has no illegal activity associated to it is classed as an intrusion into your private activities). What privacy act? |
|
|
|
Not sure it makes sense for the wx client to be holding back intentionally. bitcoin URIs are already supported by at least 2 other user interfaces. |
|
|
|
|
You can potentially choose a specific miner by sending the fee portion directly to their address. This requires miners merge the myFreeTx branch, and may be a reason to reconsider merging it into mainline. It doesn't help create a multi-miner whitelist, though.
|
|
|
|
I just dont understand, why use UPnP at all? Whats the problem of the end user surfing to their router administration page and opening up 8333 for their bitcoin client? Its a simple and straightforward process of opening a incoming port in a router. Because they shouldn't have to, and for most people it isn't simple. If Windows is vulnerable without a firewall, then it should simply be banned from the internet. Or ISPs can charge Windows users an extra fee for firewalling service. |
|
|
|
|
Show Posts
