1 2014-01-03 00:02:26 <nightlingo> phantomcircuit: I was checking the code you sent me. there, the last 1000 transactions are fetched each time (using listtransactions). Do you think there is a chance that too many transactions occur before the next cycle ? that would cause it to miss some transactions
  2 2014-01-03 00:02:51 <phantomcircuit> nightlingo, if you get > 1000 actions per second then yeah it's an issue
  3 2014-01-03 00:02:54 <phantomcircuit> but uh
  4 2014-01-03 00:02:58 <phantomcircuit> yeah right
  5 2014-01-03 00:03:03 <sipa> bitcoin doesn't do more than 7 per second anyway
  6 2014-01-03 00:03:52 <nightlingo> listtransactions lists transactions relevant only to addresses contained to the bitcoind wallet?
  7 2014-01-03 00:04:10 <phantomcircuit> yeah
  8 2014-01-03 00:04:11 <sipa> yes
  9 2014-01-03 00:04:14 <nightlingo> oh cool
 10 2014-01-03 00:28:19 <zapsoda> Is their a way to trigger wallet notify after a certain number of confirms? I got it to trigger a php file which increments the total recieved in the database (For the order with a matching input address) but because that file is triggered when the transaction is first added (i think) coins dont have to be confirmed before they are added to the database
 11 2014-01-03 00:28:37 <sipa> no
 12 2014-01-03 00:28:48 <zapsoda> Damn
 13 2014-01-03 00:28:52 <sipa> it notifies when a transaction is first seen, and when it first confirms
 14 2014-01-03 00:28:56 <sipa> (which may coincide)
 15 2014-01-03 00:29:41 <nightlingo> is there a way to know which address sent coins to an address that belongs to my wallet ?
 16 2014-01-03 00:30:04 <sipa> bitcoin transactions do not have a 'from' address
 17 2014-01-03 00:30:06 <CodeShark> nightlingo: that information is not generally useful
 18 2014-01-03 00:30:21 <nightlingo> aaah ok thanks
 19 2014-01-03 00:30:48 <sipa> if you need to distinguish multiple senders, give them a different payment address
 20 2014-01-03 00:30:50 <zapsoda> So incrementing the database value for recieved (by the amount sent in the transaction) wont help since its going to trigger the script twice somtimes?
 21 2014-01-03 00:31:01 <sipa> yes, you need to actually check
 22 2014-01-03 00:32:43 <nightlingo> I was just trying to see how exchanges, wallets, and gambling games manage their deposits system. I thought the simplest solution would be: 1. create a temporary address and give it to the user. 2. the user deposits to that address. 3. the coins are transfered from that address to a central address where all the coins reside. But this would produce many transaction fees
 23 2014-01-03 00:33:12 <CodeShark> nightlingo: step 3 is unnecessary
 24 2014-01-03 00:33:28 <nightlingo> CodeShark: it would mean easier management
 25 2014-01-03 00:33:30 <CodeShark> step 3 would be done in batch, if anything
 26 2014-01-03 00:33:42 <CodeShark> you wouldn't create a separate transaction for each transfer
 27 2014-01-03 00:33:48 <CodeShark> you'd send multiple at once
 28 2014-01-03 00:34:02 <sipa> nightlingo: why would it be easier to manage?
 29 2014-01-03 00:34:10 <sipa> it's maybe easier for you to think about now
 30 2014-01-03 00:34:12 <CodeShark> and storing all your coins at a single address makes it easier for others to know how much you have
 31 2014-01-03 00:34:22 <CodeShark> so if you care about your own privacy, you might not want to do that
 32 2014-01-03 00:34:32 <sipa> but if you abstract from the idea that addresses hold balances, and accept that coins are held jointly by everything in the wallet, there is no problem
 33 2014-01-03 00:34:35 <nightlingo> sipa: because instead of keeping track of all the possible temporary addresses per user, you only keep a deposit number per user
 34 2014-01-03 00:34:52 <CodeShark> all addresses in bitcoin, in principle, are temporary
 35 2014-01-03 00:34:52 <sipa> nightlingo: and why requires that moving the coins?
 36 2014-01-03 00:34:58 <sipa> yes, you'll have a counter per user
 37 2014-01-03 00:35:20 <sipa> but it can be completely independent from which address the coins are assigned to
 38 2014-01-03 00:35:28 <sipa> you just know that the sum is always right
 39 2014-01-03 00:35:52 <sipa> stop thinking of addresses as things that hold a balance
 40 2014-01-03 00:35:59 <sipa> just see the wallet as a bunch of coins
 41 2014-01-03 00:36:20 <nightlingo> sipa: hmmm
 42 2014-01-03 00:36:35 <nightlingo> sipa: yeah that makes sense :)
 43 2014-01-03 00:36:50 <sipa> you count everything that enters the wallet (=confirms) and count everything that leaves (transactions you create)
 44 2014-01-03 00:37:00 <sipa> the sum is how much you have available
 45 2014-01-03 00:37:06 <sipa> keep that sum now per-user, and you're done
 46 2014-01-03 00:37:29 <nightlingo> sipa: and I don't even need accounts for that right?
 47 2014-01-03 00:37:41 <sipa> ironically, that's exactly what accounts do
 48 2014-01-03 00:37:50 <sipa> but you can implement it better yourself
 49 2014-01-03 00:37:55 <sipa> bitcoind is just not the right place for it
 50 2014-01-03 00:38:02 <CodeShark> but don't use the built-in account system in bitcoind!
 51 2014-01-03 00:38:11 <CodeShark> it's not the right place for it at all
 52 2014-01-03 00:38:18 <nightlingo> CodeShark: o yes I've heard bad things about it :)
 53 2014-01-03 00:38:31 <CodeShark> later on you want to change wallets, you're screwed
 54 2014-01-03 00:38:33 <nightlingo> sipa: and I should use getnewaddress for creating those temporary deposit addresses ?
 55 2014-01-03 00:38:38 <sipa> yes
 56 2014-01-03 00:38:47 <PRab> Is the built-in account system so bad that it should be considered depreciated?
 57 2014-01-03 00:38:48 <sipa> well, if you want to use bitcoind's wallet
 58 2014-01-03 00:38:58 <sipa> PRab: i think many still rely on it, actually
 59 2014-01-03 00:39:05 <sipa> but i wouldn't encourage using it
 60 2014-01-03 00:39:11 <nightlingo> CodeShark: that, and also, they are very slow when the number of transactions X number of accounts increases beyond the thousands
 61 2014-01-03 00:39:25 <sipa> nightlingo: that's absolutely irrelevant
 62 2014-01-03 00:39:33 <sipa> oh,
 63 2014-01-03 00:39:37 <sipa> sorry, i misread!
 64 2014-01-03 00:39:56 <sipa> all that matters is the number of transactions
 65 2014-01-03 00:40:01 <CodeShark> well, the bitcoind wallet generally is not super scalable,,,
 66 2014-01-03 00:40:01 <gribble> Error: "," is not a valid command.
 67 2014-01-03 00:40:07 <CodeShark> well, the bitcoind wallet generally is not super scalable...
 68 2014-01-03 00:40:14 <nightlingo> sipa: so bitcoind is good enough for a scalable system as long as we don't use their accounts system?
 69 2014-01-03 00:40:17 <CodeShark> sorry, gribble,
 70 2014-01-03 00:40:20 <CodeShark> ,,
 71 2014-01-03 00:40:22 <sipa> nightlingo: accounts are irrelevant
 72 2014-01-03 00:40:29 <sipa> the number of transactions is all that counts
 73 2014-01-03 00:40:46 <nightlingo> sipa: so if we have lots of transactions it will still become slow ?
 74 2014-01-03 00:40:50 <sipa> the reason for not using accounts has nothing to do with performance
 75 2014-01-03 00:40:53 <sipa> yes
 76 2014-01-03 00:41:02 <nightlingo> duck...
 77 2014-01-03 00:41:14 <CodeShark> goose
 78 2014-01-03 00:41:16 <sipa> do you really expect to hit 100k transactions soon? :)
 79 2014-01-03 00:41:49 <nightlingo> sipa:  well not so soon to be honest :)
 80 2014-01-03 00:42:54 <nightlingo> sipa: so, you think those exchanges don't use bitcoind at all ?
 81 2014-01-03 00:43:13 <sipa> mtgox doesn't, they have their own wallet implementation
 82 2014-01-03 00:43:19 <sipa> unsure about others
 83 2014-01-03 00:44:20 <nightlingo> sipa: I guess the time-consuming operation for bitcoind would be the "getbalance" operation right?
 84 2014-01-03 00:44:50 <nightlingo> sipa: "listtransactions" should be fast enough... ?
 85 2014-01-03 00:45:01 <sipa> they're both exactly the same speed
 86 2014-01-03 00:45:12 <sipa> as they both iterate all transactions
 87 2014-01-03 00:45:43 <sipa> (with the exception that listtransaction needs to send back much more data)
 88 2014-01-03 00:45:54 <nightlingo> sipa:  why would "listtransactions * 1000"  iterate all transactions. This is just the last 1000 transactions
 89 2014-01-03 01:02:30 <sipa> nightlingo: because they're not indexed by time, internally
 90 2014-01-03 01:02:50 <sipa> and neither are they indexed by account or address
 91 2014-01-03 01:03:19 <nightlingo> sipa: what about -blocknotify?
 92 2014-01-03 01:03:30 <sipa> yes, what about it?
 93 2014-01-03 01:04:00 <nightlingo> sipa: if we simply checked only the newest changed block, for transactions ? wouldnt it be more efficient?
 94 2014-01-03 01:04:20 <sipa> yes, but then you have to implement an entire wallet yourself
 95 2014-01-03 01:04:38 <sipa> ah
 96 2014-01-03 01:05:07 <sipa> you mean using bitcoind's wallet for sending and keeping track of total balance, but use blocknotify to keep your internal database up to date
 97 2014-01-03 01:05:16 <nightlingo> sipa: yes
 98 2014-01-03 01:05:18 <sipa> that may work, if you're not interested in unconfirmed transactions
 99 2014-01-03 01:05:27 <sipa> also, make sure you can handle reorganizations
100 2014-01-03 01:05:33 <nightlingo> sipa: you could only do this when the block has >=6 confirmations
101 2014-01-03 01:06:06 <jcrubino> whats news today bitcoin?
102 2014-01-03 01:06:08 <nightlingo> sipa: a reorganization is what?
103 2014-01-03 01:06:36 <sipa> nightlingo: you may want to read up about bitcoin's internals before trying to build a database interacting with it
104 2014-01-03 01:06:49 <sipa> a reorganization is a switch from one fork to another
105 2014-01-03 01:07:00 <jcrubino> the bitcoind db is full featured
106 2014-01-03 01:07:14 <sipa> jcrubino: ?
107 2014-01-03 01:07:15 <nightlingo> sipa: thanks