How would look multitransaction with several entries of identical addresses with identical amounts? How they will be different for JSON client?
They won't be different-- you will get two entries that are identical. Bitcoin will sum them up for you if you use the getbalance or getreceivedby* RPC commands. |
|
|
|
A blockchain index? Doesn't the vanilla client index the blockchain for itself already?
Yes, that is exactly what the blkindex.dat file is. wallet.dat contains "extended dance mix" versions of all the transactions you care about (all of "your" receives/sends). Those are loaded into memory at startup (and then kept up-to-date as new transactions are seen), so calculating "your" balance is quick (just scan through all wallet transactions in memory and total them up). |
|
|
|
Hi there! I noticed that the NL locale for Bitcoin has some errors (quite some actually)  So i made my corrections, attached is the nl locale .po file. edit: correctly used poedit this timeThanks! Can somebody volunteer to be "translation pull person" for the new git integration repository? The job would be packaging up changes into "pull requests" (if the person doing the work can't or won't use git), giving them a sanity test, and then pulling them into the integration repository. |
|
|
|
Normal send; this one was: sendfrom Test1 mytzSq1rkXzPidP9tHvfhDuzXqDSSvvaCg 100 {
"account" : "Test3",
"address" : "mytzSq1rkXzPidP9tHvfhDuzXqDSSvvaCg",
"category" : "receive",
"amount" : 100.00000000,
"confirmations" : 344,
"txid" : "210ea061bd3664c34349dfa4849b9f33889cfe2117bf02d62fd765cb0ee5b5b0",
"time" : 1292527858,
"comment" : "Test1 to Test3, 100"
},
{
"account" : "Test1",
"address" : "mytzSq1rkXzPidP9tHvfhDuzXqDSSvvaCg",
"category" : "send",
"amount" : -100.00000000,
"fee" : 0.00000000,
"confirmations" : 344,
"txid" : "210ea061bd3664c34349dfa4849b9f33889cfe2117bf02d62fd765cb0ee5b5b0",
"time" : 1292527858,
"comment" : "Test1 to Test3, 100"
},
And a wicked-crazy multisend: sendfrom Test1 to: mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX 3.0 AND mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX 3.3 AND msVM67gJZ4EKMRVdMjMFzwWEU32VzBUnqu 2.0 {
"account" : "Test3",
"address" : "mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX",
"category" : "receive",
"amount" : 3.03000000,
"confirmations" : 342,
"txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
"time" : 1292531730,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test3",
"address" : "mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX",
"category" : "receive",
"amount" : 3.00000000,
"confirmations" : 342,
"txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
"time" : 1292531730,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test2",
"address" : "msVM67gJZ4EKMRVdMjMFzwWEU32VzBUnqu",
"category" : "receive",
"amount" : 2.00000000,
"confirmations" : 342,
"txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
"time" : 1292531730,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test1",
"address" : "mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX",
"category" : "send",
"amount" : -3.03000000,
"fee" : 0.00000000,
"confirmations" : 342,
"txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
"time" : 1292531730,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test1",
"address" : "mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX",
"category" : "send",
"amount" : -3.00000000,
"fee" : 0.00000000,
"confirmations" : 342,
"txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
"time" : 1292531730,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test1",
"address" : "msVM67gJZ4EKMRVdMjMFzwWEU32VzBUnqu",
"category" : "send",
"amount" : -2.00000000,
"fee" : 0.00000000,
"confirmations" : 342,
"txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
"time" : 1292531730,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
Again, multi-sends are non-standard transactions. And no, I won't give you the hacked code I wrote to generate multisend test cases... |
|
|
|
https://github.com/bitcoin/bitcoin/pull/10Three changes to listtransactions: Add address to listtransactions output. "multisends" (non-standard, use one transaction to send to multiple addresses) generate N "category":"send" lines. Bug fix: listtransactions wasn't reporting pay-by-IP-connection receive transactions.
|
|
|
|
Now I remember why I added the option: doesn't the internal miner call CheckWork() if 16 bits are zeroes? ie. this message would be printed a lot for the internal miner, if added unconditionally, right?
That's what I meant when I asked "are there significant costs?" If one of the mining pool folks think this would be useful in a production miner, then I see the value. If it is only really useful if you're trying to debug a remote miner that isn't working quite right... |
|
|
|
Or can be addedd 'address' field to output of 'listtransactions'?
I'm working on that. |
|
|
|
|
I'm with Hal-- do we really need another special-case switch? Are there significant costs to just always printing when pow fails?
|
|
|
|
Because Bitcoin has tremendous value, it's OK to underpromise and overdeliver. It always turns out better that way, in the long run.
If you lie, you only need one prominent journalist to say "I tried it, and it's crap, it doesn't do what they say it does", and the public loses interest.
Well said! Trust is Bitcoin's biggest barrier to success. I don't think there is anything we can do to speed up the process of getting people to trust that bitcoin is solid; it takes time to build trust. However, there is plenty we could do to lose that trust, including overpromising or misrepresenting what bitcoin can do. Bitcoin is beta software; nobody should trust it 100%. Do not invest your life savings in bitcoin-- in fact, do not invest any money you're not willing to lose. Expect more ponzi schemes and fraud. Expect irrational valuation bubbles, and, while the bitcoin economy is small, expect people to try to manipulate the bitcoin markets. |
|
|
|
|
Oh, and RE: extracting private keys from the wallet:
I'm less excited about that idea. What if the private keys are stored in a tamper-proof "trusted security module" hardware doo-hickey, and are impossible to export?
|
|
|
|
|
I like this feature request; I think it will enable even more interesting uses of bitcoin. I created a feature request at github for it.
Example: a store that accepts bitcoins could verify that a customer sending in a question about some transaction actually IS the same person who sent them the bitcoins, by asking the customer to sign their message using one of the same bitcoin addresses they used to sign the coins.
If the "store" is a privacy-focused VPS provider and the question is "Hey, I lost the root password to the virtual server, could you generate a new one and encrypt it with this gpg public key", then tying that message to a bitcoin transactions is extremely useful.
|
|
|
|
As I understand it, every client receives every transaction in the system, so it can check later if transactions are valid. What happens when the number of transactions gets very large?
When that happens, I think most people using bitcoin will not be running always-connected-to-the-bitcoin-network software. I think there will be at least three different sets of people: 1. People who trust a web site to keep their wallet safe more than they trust themselves. They'll use sites like MyBitcoin or MtGox, which give them an online wallet. 2. People who don't or won't trust anybody to keep their wallets safe, but don't have a high-speed, always-on Internet connection. They will use a 'payment gateway', where they submit transactions that are signed by their own computer (they don't have to trust the payment gateway to keep their wallet, the gateway just forwards relevant transactions onto the bitcoin network for the user). This doesn't exist yet, but writing the code to support this isn't terribly hard. 3. People who DO have always-on high-speed network connections; they'll run bitcoin just like they do today. But, assuming the volume of bitcoin transactions continues to increase faster than the cost of network bandwidth declines, that will become increasingly expensive, so I think more and more users will choose option 1 or 2. Does the client have to keep them all in the memory at once? If not, how can the client check if somebody actually owns the coin?
The current bitcoin doesn't keep all transactions in memory at once-- the blkindex.dat and blk0001.dat files in your bitcoin data directory stores them on disk. |
|
|
|
With Satoshi's blessing, and with great reluctance, I'm going to start doing more active project management for bitcoin. Everybody please be patient with me; I've had a lot of project management experience at startups, but this is the first open source project of any size I've been involved with. Anyway, I've created an integration/staging tree at: https://github.com/bitcoin/bitcoin... and am proposing this for a development process: Straw-man plan for Bitcoin development (open source vets, please slap me around and help make this better): Developers work in their own trees, then submit pull requests when they think their feature is ready. Requests get discussed (where? here in the bitcoin forums?) and if there's broad consensus they're a good thing, well written, match coding style, etc. then they're merged into the 'master' branch. master branch is regularly built and tested (by who? need people willing to be quality assurance testers), and periodically pushed to the subversion repo to become the official, stable, released bitcoin. We'll create feature branches if/when there are major new features being worked on by several people. Discussion, feedback, etc, especially from people with experience leading or working on other open source projects, is very welcome. |
|
|
|
Problem with a vote is that it brings bureaucraty in the system. Peole will have to register to github, remember to participate to the votes, check on regular basis for new votes, and so on. I don't like that. Democracy doesn't fit cyberspace well, imo. I very much prefer anarchy.
Umm... there will be no Top Bureaucrat counting votes and telling people what to do. There will still be plenty of anarchy, I promise! Use the voting system to express what is important to YOU. Or not. |
|
|
|
I've created an 'official' Bitcoin bug/issue/feature request tracking system at: https://github.com/bitcoin/bitcoin/issuesThe github issues system has a simple voting system; lets use it! And if you see an issue that you want to work on, use the commenting system to let everybody know you're working on it. I'd like to be open about who is working on what, and what features/bugs/issues people think are important. However... we'll still be very conservative about what changes make it into the official bitcoin client. Bitcoin will be destroyed if people using it lose their trust in it. |
|
|
|
|
Feel free to take anything I've written here on the forums or on the wiki and do whatever you like with it.
And, for what it is worth, I like the new wiki more than the old wiki; the new one is prettier and more powerful.
|
|
|
|
However is category really that necessary? Amount is already + or -. Or is move also in there too?
BTW I don't see any addresses in that output you pasted.
move is its own category (and may be + or -, never has a txid or fees). And the output I pasted is what listtransactions does right now (it doesn't report bitcoin addresses). After some private feedback, I'm now leaning towards listtransactions giving multiple category:send entries (with the same txid) for the multisend case. That matches what is done for the category:receive end. transaction fee... I think I'll do what is easiest to implement which is repeat it in all of them. So the example would look like this, with three receives and three sends: {
"account" : "Test3",
"address" : "1aTest3blahblahblah9d87"
"category" : "receive",
"amount" : 3.03000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test3",
"address" : "1aTest3blahblahblah9d87"
"category" : "receive",
"amount" : 3.00000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test2",
"address" : "1aTest2blahblahblahQ9Qe"
"category" : "receive",
"amount" : 2.00000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test1",
"address" : "1aTest3blahblahblah9d87"
"category" : "send",
"amount" : -3.03000000,
"fee" : 0.00000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test1",
"address" : "1aTest3blahblahblah9d87"
"category" : "send",
"amount" : -3.00000000,
"fee" : 0.00000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test1",
"address" : "1aTest2blahblahblahQ9Qe"
"category" : "send",
"amount" : -2.00000000,
"fee" : 0.00000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
|
|
|
|
So what's all the stuff about NAT translations, etc. Brief summary.
Short answer: you don't have to worry about it. Long answer: if you want to worry about being as network-bandwidth-efficient as possible, run one node normally, and run all the rest with the -noirc -connect=IP.AD.DR.SS flags so they connect only to the one 'master' node. All the network traffic will then go through the master node. |
|
|
|
We're pretty close to being able to duplicate the bitcoin GUI using the RPC. I think the only thing missing is reporting bitcoin addresses in listtransactions. That gets a little sticky with multisends (one transactions that sends coins to multiple recipients); here's what I'm thinking of implementing after doing some brainstorming with theymos/jgarzik/nanotube in IRC chat and running a couple of 'multisend' tests on the test network: "category" : "receive",
"amount" : amount,
"address" : "bitcoinaddress" ... plus the rest of what is reported now (account/txid/confirmations/time/comment). That's the "received on" address, of course. On the send side, I'm leaning towards: "category" : "send",
"amount" : amount,
"fee" : fee,
"toaddress" : { "address" : amount } # or "toaddress" : { "address" : amount, "address" : amount } for a multisend. ... plus the rest of what is reported now (account/txid/confirmations/time/comment). I don't like that the common case looks kind of ugly; I'd much prefer just "address" : "bitcoinaddress" That could be done by having listtransactions report multiple category:send entries for a multisend... except it is not obvious which one should report the fee, if there is a fee. First one? All of them? I'm also a worried that websites might get their accounting wrong if they're not prepared to deal with multisends; making "toaddress" an Object makes it obvious that multisends are possible. The only way a website would get a multisend would be if they allow users to import keys from their local bitcoin wallet, which nobody is doing... yet. Here's how listtransactions currently reports a complex multisend: {
"account" : "Test3",
"category" : "receive",
"amount" : 3.03000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test3",
"category" : "receive",
"amount" : 3.00000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test2",
"category" : "receive",
"amount" : 2.00000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
{
"account" : "Test1",
"category" : "send",
"amount" : -8.03000000,
"fee" : 0.00000000,
"confirmations" : 66,
"txid" :
"36c86ca499275945a3f1805d6e070ac00b2d32e5e16a4c9cf2c83b189a347d88",
"time" : 1292532062,
"comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
},
|
|
|
|
|
Show Posts
