|
1881
|
Bitcoin / Development & Technical Discussion / Bug/Issue/Feature Request tracking system
|
on: December 19, 2010, 04:13:41 PM
|
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. |
|
|
|
|
1882
|
Bitcoin / Project Development / Re: Bitcoin Wiki
|
on: December 19, 2010, 03:23:50 AM
|
|
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.
|
|
|
|
|
1883
|
Bitcoin / Development & Technical Discussion / Re: [RFC] reporting addresses, listtransactions/gettransaction
|
on: December 19, 2010, 02:19:03 AM
|
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)"
},
|
|
|
|
|
1884
|
Bitcoin / Technical Support / Re: Multiple Machines
|
on: December 18, 2010, 08:19:02 PM
|
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. |
|
|
|
|
1885
|
Bitcoin / Development & Technical Discussion / [RFC] reporting addresses, listtransactions/gettransaction
|
on: December 18, 2010, 04:27:20 PM
|
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)"
},
|
|
|
|
|
1888
|
Bitcoin / Development & Technical Discussion / Re: svn rev 103/104: listaccounts, listtransactions*, and -rpctimeout
|
on: December 16, 2010, 06:24:05 PM
|
|
... and I just noticed an egregious bug: listtransactions was reporting the receiving address instead of the account name for "receive" transactions. Fix is svn rev 104. Please bang on it and let me know if I screwed anything else up.
While I was committing, I also added "time" to transaction info output, and fixed a little bug reported a while ago (setgenerate true 0 is now the same as setgenerate false).
|
|
|
|
|
1889
|
Bitcoin / Development & Technical Discussion / Re: Getting the address that received funds
|
on: December 16, 2010, 05:46:46 PM
|
Maybe a composite ID would solve the problem, anyway I think that if something is called ID it should be guaranteed to be unique (or collision likelihood should be limited to the probability of a hash collision)
Just use transactionID+account. You've already got the problem that if a customer sends coins from account A to an address that belongs to account B, that is a single, unique transaction that affects two accounts. listtransactions will Do the Right Thing (generate two entries, different accounts, same transaction id). And gettransaction won't lie to you (it doesn't say anything about what accounts were involved, on purpose, for exactly this reason). |
|
|
|
|
1890
|
Bitcoin / Development & Technical Discussion / Re: Getting the address that received funds
|
on: December 16, 2010, 04:29:39 PM
|
So that basically means that if you're relying on listtransactions to track incoming transactions to a web app account you're in deep trouble...
No, only the amount sent to the address associated with the web app's account(s) will be reported in listtransactions. But that's exactly why this is a lot harder than it seems-- we've got to think about weird transactions people might use to try to break websites that use this API. |
|
|
|
|
1892
|
Bitcoin / Development & Technical Discussion / Re: Getting the address that received funds
|
on: December 16, 2010, 02:33:52 PM
|
Outputting the transaction time would be easy. "The address that received funds" is not as obvious as you might think. It is possible to generate transactions that are split and go to several addresses (well, it is possible if you use your own custom client, standard Bitcoin doesn't expose that feature). Some or all of those addresses might be yours, and might be associated with any number of accounts. I see two possible ways of dealing with this: 1. Generate multiple entries for a single transaction. E.g. if you receive a split transactions, where 50 BTC goes to address '1aaa...' and 10 to address '1bbbb...', listtransactions will list that as two separate entries that share the same txid: {
"category" : "receive",
"amount" : 50.00000000,
"txid" : "2c9d43db0142130a9926ef4b1c58abf17e8b4dfd2148bf2072b0df6d2bac8789",
"toaddress" : "1aaa", ... etc, irrelevant fields omitted...
},
{
"category" : "receive",
"amount" : 10.00000000,
"txid" : "2c9d43db0142130a9926ef4b1c58abf17e8b4dfd2148bf2072b0df6d2bac8789",
"toaddress" : "1bbb", ...
},
You can already get two separate entries for one transaction if you send to yourself, so this might be the best answer. And it makes the common case simpler. 2. Or maybe 'toaddress' should be address:amount pairs, like this: {
"category" : "receive",
"amount" : 60.00000000,
"txid" : "2c9d43db0142130a9926ef4b1c58abf17e8b4dfd2148bf2072b0df6d2bac8789",
"toaddress" : { "1aaa" : 50.000000, "1bbb" : 10.000000 }
},
Writing all this down, I'm thinking that listtransactions aught to generate multiple entries, but gettransaction aught to generate address:amount pairs (and still omit category/account, as it does now). |
|
|
|
|
1894
|
Bitcoin / Development & Technical Discussion / svn rev 103/104: listaccounts, listtransactions*, and -rpctimeout
|
on: December 16, 2010, 01:22:50 AM
|
|
I just committed svn rev 103. Changes are:
listaccounts : lists all the accounts in your wallet along with their current balances.
listtransactions : call it with no arguments, or give it '*' as the account name, and it lists the last N (default 10, as before) transactions from all accounts. Part of this change is disallowing '*' as an account name.
-rpctimeout : Thanks to Mt`AwAy who pointed out that, if somebody was allowed to connect to the bitcoin rpc port (via -rpcallowip), then they could connect, do nothing, and hang the connection, causing a denial-of-RPC-service. Now bitcoin's RPC thread will close the connection if it doesn't get the HTTP request within -rpctimeout (default 30) seconds.
|
|
|
|
|
1896
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin Redundancy For Security
|
on: December 15, 2010, 05:40:46 PM
|
Implementing this in a convenient way would be tough, and it would be blocked by IsStandard.
No, implementing it would be easy. Implement it (don't forget the UI), test it on the test network (where it is pretty trivial to get non-IsStandard stuff into blocks), and then lobby for a new 'standard' transaction type. theymos, please stop acting like the current IsStandard test is set in stone. It is not, and, as Satoshi said, new versions of the client are rapidly adopted by a majority of the network, so introducing a new transaction type will not be a big deal. |
|
|
|
|
1897
|
Bitcoin / Bitcoin Discussion / Re: Mining cartel attack
|
on: December 14, 2010, 08:42:27 PM
|
I posted a huge reply to a previous post explaining exactly this...
I also mentioned an attack that hasn't been discussed. If my post was deleted could a mod explain why? And/or let other people know about the attack so it could be discussed as necessary?
I deleted two posts-- one from you that was a quote of ByteCoin's simulation results (and nothing else). And a second from ByteCoin (if I recall correctly), saying essentially "what's up with the empty post?" |
|
|
|
|
1898
|
Bitcoin / Development & Technical Discussion / Re: Risks when publishing 'static' bitcoin addresses on the web
|
on: December 14, 2010, 05:01:24 PM
|
What exactly are you trying to acomplish here ?
To put a donate button on a website that generates a brand new address on demand for everyone who wants to donate, so all the donors don't donate to a common address that can tie everyone together. If there was a language of choice, perhaps it would be Javascript, so it happened all in the browser. Of course there has to be some way to get the generated keypair to the recipient, like e-mail or whatever, but somebody else can figure that out. Simplest way: Call getaccountaddress "charity_name" when you generate the web page. You'll get the same address over and over, until somebody donates. Then you'll get a new address. Then periodically call: getbalance "charity_name" ... and if the balance is greater than zero, call: sendfrom "charity_name" charity_real_bitcoin_address amount ... to send the charity the accumulated coins. If you deal with several charities this way, AND you're bundling up several donations before forwarding the coins to the charity, then it'll be hard to connect donors to particular charities. |
|
|
|
|
1899
|
Bitcoin / Bitcoin Discussion / Re: Mining cartel attack
|
on: December 14, 2010, 04:37:40 PM
|
|
If you're simulating, be sure you're not overlooking the 'opportunity cost' of working on the next-valid-block when you're 'holding back' blocks.
Example:
Cartel finds block N. Instead of releasing it right away, Cartel holds it and starts working on block N+1 (trying to get a head start).
Before Cartel finds block N+1, somebody else finds an alternate block N and announces it.
IF Cartel loses the race to announce, then Cartel has wasted time looking for a block N+1 that will not be accepted.
If they simply announce block N right away, they'll never waste time trying to find a block N+1 that has only a 50% chance of being accepted.
Unless the Cartel can propagate their blocks across the network faster than the whole rest of the network, there is never an advantage to holding back blocks.
|
|
|
|
|
1900
|
Bitcoin / Bitcoin Discussion / Re: Mining cartel attack
|
on: December 14, 2010, 03:53:27 PM
|
I did a simulation of two cartel strategies along the lines of my previous post.
Cartel power Cartel block fraction
......
50% 59.86%
There is something wrong with your simulation. Proof: Imagine a bitcoin world with two Cartels, each with 50% of the power, each following the strategy you outline. It is obvious that they cannot BOTH get 59% of the blocks. |
|
|
|
|
Show Posts
