Thanks! This is great news. Next, we need a python implementation  This is supposed to be funny, right? well.. there is no python implementation. there is only interface to wallet database. it would be nice to have python library for communitcation with p2p network. (although, I do not like python nor going to use it for this =)) There are presently at least 2 independent Python p2p implementations... |
|
|
|
It might be nice to add OP_WHIRLPOOL etc. to Script to ease a switch if one is ever needed. That was my initial thought, but it won't help the fact that the tx and block itself are hashed with SHA-256... |
|
|
|
When the SHA-3 winner is announced, and after some time in real use, would it be a good idea to switch to that? Despite some of the oversimplified solutions earlier in this thread, "switching" to a new hash means creating a new (possibly derived from the existing one) protocol and an entirely new network (possibly based on a genesis block offering BitCoin funds to the SHA-256 addresses that had them outstanding). Back in 2010, there was only a single client, and reinventing everything may have seemed like a simple solution. But beginning with 2011, we are starting to see alternative implementations of BitCoin, and by the time SHA-256 is broken, we will no doubt have many various possibilities. If SHA-3 is due out soon, it might be early enough for all the implementors to agree on reworking the network around it... Not really true, we can define a future switch block, after which a new set of rules applies. If all developers are notified early enough they can make the switch, and allow time for users to make the switch, when the block arrives old implementations will fork off creating their small network, while the new clients take over the main chain (assuming most of users have made the switch). No. As long as SHA-256 is used for any blocks in the chain, the entire chain is compromised by a client forging a new block that can sit in-place of the real one in history. |
|
|
|
|
What if it's PowerPC, ARM, SPARC, etc?
|
|
|
|
When the SHA-3 winner is announced, and after some time in real use, would it be a good idea to switch to that? Despite some of the oversimplified solutions earlier in this thread, "switching" to a new hash means creating a new (possibly derived from the existing one) protocol and an entirely new network (possibly based on a genesis block offering BitCoin funds to the SHA-256 addresses that had them outstanding). Back in 2010, there was only a single client, and reinventing everything may have seemed like a simple solution. But beginning with 2011, we are starting to see alternative implementations of BitCoin, and by the time SHA-256 is broken, we will no doubt have many various possibilities. If SHA-3 is due out soon, it might be early enough for all the implementors to agree on reworking the network around it... |
|
|
|
I had almost working pure perl client, but since I've heard alt clients are not welcomed, i've abandoned that project. I would welcome a Perl implementation of various parts of BitCoin. I also suggest new development try to stick to an abstract 4-piece infrastructure documented on https://en.bitcoin.it/wiki/Infrastructure so end users can choose to run different combinations of wallets/UIs/etc. |
|
|
|
But the time to fix that is when a new API is being written anyway because of some other pressing need. Like right now, in this thread... :p |
|
|
|
|
I'm now offering discounts for the first 10 KB (or however much the originial bitcoind usually allows without a fee) of transactions per block. Instead of 1 TBC (0.00065536 BTC) per Bˢ (512 bytes), discounts are at 1 TBCᵗ (0.00004096 BTC) per Bˢ. This means a low fee of only 0.00005 BTC for most transactions (including microtransactions and non-standard)
|
|
|
|
I'm confused. At first I thought this was a discussion for a new wallet. Do you want to replace JSON-RPC, or essentially create a new client, broken into pieces? The current JSON-RPC needs to be replaced (this thread), before splitting the client (or creating a split one) is even possible. |
|
|
|
So what's your proposal? I'm willing to get behind this. Show us the code. The goal is to create a proposal. What requirements does the development community have for such a protocol? AFAIK, DBUS only works on *nix, and is desktop-only and local-only, so would be a problem running Wallet on a server, and UI on a phone... correct me if I'm wrong. |
|
|
|
Let me know if you want to move it under the bitcoin project to http://gitorious.org/bitcoin/pycoinCan we get a real license on this? Your LICENSE/UNLICENSE files have no legal relevance in any jurisdictions*, thus this code is still under a default/standard copyright which forbids anyone else from copying it. * IANAL and TINLA |
|
|
|
Currently since the JSON RPC returns floats, any library you use will return the values as floats, not strings. So to get the int64 value you need to multiply the float by 10^8 and cast to an int for internal usage. It's one of the many JSON-RPC design flaws. Instead of trying to fix it, I have moved on to working on a new protocol to address all the problems: https://www.bitcoin.org/smf/index.php?topic=3757.0 |
|
|
|
|
As of now, my miner is only accepting transactions with a simple 1 TBC per Bˢ (that's 0.00065536 BTC per 512 bytes) fee minimum. That means you can send amounts less than 0.01 BTC for much less than most miners charge (0.01 BTC)! I am also allowing non-standard transactions, so you can get those in too. The only catch is, ordinary peers will silently discard your transaction, so you need to connect directly to me. You can do that with the original client by specifying -addnode=nat.router.dashjr.org on the command line. Please note you will still need to hack your bitcoin[d] to actually create the transactions. Enjoy!
|
|
|
|
Pull request: https://github.com/bitcoin/bitcoin/pull/85Starting a thread here, since it's not possible to comment on GitHub without agreeing to finance a legal battle when they get sued. Looks good at first glance. Can we brainstorm test cases that we think might cause problems?
E.g. Wallet with (only) available transactions of +1 +2.0001 +3 : Send 6 bitcoins; what happens?
Same wallet, send 2 (I think you'll get a 2.0001+1 spend with 1.0001 change)...
Any other tricky edge cases? In your first case, it should send 6 with a 0.0001 fee (this one is UNavoidable). |
|
|
|
(yes, you'll have to-- horrors! -- use that evil, not 100%-pure-open-source github) Since the GitHub terms of service require me to agree to fund a legal defense of them if they get sued, this is not an economically viable option. tcatm did it, though. |
|
|
|
I modified the patch to format numbers the way they were formatted before: always , for the thousands separator, and . for the decimal point (instead of letting sprintf try to do the right thing). That seems like an internationalization bug. What was wrong with using the correct localization? It would be nice to have BitCoin clients "just work" when LC_NUMERIC=tonal is fixed. Also, especially with this change, it's even more important to merge my bugfix for unnecessary subcent waste/throwaway. That's in the gitorious bitcoin master branch ( git pull git://gitorious.org/bitcoin/bitcoin.git master ) |
|
|
|
Native representation doesn't have to change, we would just be solving the problem now while it is easy. One BTC is merely a nanoBTC * 10^8 (or whatever the factor is). This is a problem for GUIs, not wallets/internals. |
|
|
|
|
Does this still work correctly for 0.1 BTC, or does it expose bitcoind to the problem with representing this amount in binary (which would make it truncated as 0.09999999 BTC)? This fix should at the very least be sure to round at 8 decimal places, if not reading the digits directly into an int64.
|
|
|
|
In light of other major problems with the JSON-RPC protocol, I am abandoning this fix and recommending gavin's half-fix for the short term, and a new protocol for the long term. |
|
|
|
|
Show Posts
