--- Day changed Sun Apr 24 2016
00:13 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vikracvcxdaisvva] has joined #bitcoin-core-dev
00:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:50 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
00:53 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 240 seconds]
00:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
00:56 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
01:01 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:04 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Disconnected by services]
01:04 -!- Guyver2_ is now known as Guyver2
01:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
01:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
01:26 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 244 seconds]
01:37 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
01:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
01:51 -!- AaronvanW [~ewout@172pc231.sshunet.nl] has joined #bitcoin-core-dev
01:51 -!- AaronvanW [~ewout@172pc231.sshunet.nl] has quit [Changing host]
01:51 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
02:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
02:19 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
02:43 < GitHub119> [bitcoin] pstratem opened pull request #7931: [WIP] Fuzzing framework (master...2016-04-20-fuzzing-framework) https://github.com/bitcoin/bitcoin/pull/7931
02:56 < phantomcircuit> lol wrong year
03:01 < GitHub198> [bitcoin] pstratem closed pull request #7930: CAddrMan::Deserialize Initialize to NULL on insane input. (master...2014-04-23-addrman-deserialize-limits) https://github.com/bitcoin/bitcoin/pull/7930
03:01 < GitHub54> [bitcoin] pstratem opened pull request #7932: CAddrMan::Deserialize handle corrupt serializations better. (master...2016-04-23-addrman-deserialize-limits) https://github.com/bitcoin/bitcoin/pull/7932
03:05 < sipa> phantomcircuit: it is 2016
03:05 < phantomcircuit> sipa, indeed
03:18 < gmaxwell> phantomcircuit: bitcoin-fuzzy should probably be in test/
03:18 < phantomcircuit> gmaxwell, accepting pull requests :P
03:18 < phantomcircuit> (every time i touch the build system things explode)
03:28 < phantomcircuit> lol whoops
03:28 < phantomcircuit> forgot to break!
03:44  * sipa breaks phantomcircuit
03:52 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
04:01 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
04:35 < GitHub137> [bitcoin] pstratem closed pull request #7931: [WIP] Fuzzing framework (master...2016-04-20-fuzzing-framework) https://github.com/bitcoin/bitcoin/pull/7931
04:54 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
04:59 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 246 seconds]
05:00 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
05:00 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
05:10 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
05:13 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
05:35 < sipa> wumpus, jonasschnelli: i'm trying to call uiInterface.ShowProgress from the import thread (to show -reindex progress), but it results in a deadlocked UI
06:52 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
06:52 -!- JackH [~Jack@79-73-185-113.dynamic.dsl.as9105.com] has quit [Quit: Leaving]
07:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:11 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
07:14 -!- fedruantine [fedruantin@2600:3c03::f03c:91ff:fe55:c675] has quit [Quit: ZNC 1.6.1+deb1 - http://znc.in]
07:16 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
07:19 -!- fedruantine [~fedruanti@li394-234.members.linode.com] has joined #bitcoin-core-dev
07:26 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
07:32 -!- dermoth [~thomas@dsl-66-36-157-105.mtl.aei.ca] has joined #bitcoin-core-dev
07:33 < GitHub10> [bitcoin] sipa opened pull request #7933: Fix OOM when deserializing UTXO entries with invalid length (master...fixcompressoroom) https://github.com/bitcoin/bitcoin/pull/7933
07:34 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
08:13 -!- zooko [~user@2601:281:8000:8387:5522:b6ce:1c7a:811d] has joined #bitcoin-core-dev
08:23 -!- dermoth [~thomas@dsl-66-36-157-105.mtl.aei.ca] has quit [Ping timeout: 244 seconds]
08:28 -!- grimescapes [~user@46.166.188.199] has joined #bitcoin-core-dev
08:42 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
08:56 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
08:56 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
09:09 -!- NotAnNSAgent [~NotAnNSAg@gateway/vpn/privateinternetaccess/notannsagent] has joined #bitcoin-core-dev
09:09 < NotAnNSAgent> .
09:09 < NotAnNSAgent> Why is there no boolean flag for each transaction called something like "has_been_dealt_with"?
09:09 < NotAnNSAgent> I must have my own, separate DB table just to store which txids have been dealt with? Or maybe there is? I can't see one.
09:10 < sipa> define "dealt with"
09:11 < sipa> seen? included in the mempool? rejected? relayed? in the utxo set? in the blockchain?
09:11 < NotAnNSAgent> sipa: In my case, "recorded by application logic".
09:12 < NotAnNSAgent> sipa: In the case of a GUI user, such as myself on this desktop computer, it would refer to "having seen it".
09:12 < NotAnNSAgent> sipa: Transactions just come in and I have no idea which ones I've "seen" and "dealt with".
09:12 < NotAnNSAgent> Since Windows 10, the Bitcoin Core client for Windows uses the awful Windows 10 notifications, which I've been forced to turn off globally.
09:13 < NotAnNSAgent> As soon as I enable them, I'm constantly pestered by idiotic notifications.
09:13 < NotAnNSAgent> And it appears to be impossible to enable them only for Bitcoin Core.
09:13 < sipa> file an issue, please
09:14 < NotAnNSAgent> I thought that was what I'm doing right now...
09:14 < NotAnNSAgent> But my main issue is when using the bitcoind through the RCP API.
09:14 < sipa> https://github.com/bitcoin/bitcoin/issues/
09:14 < NotAnNSAgent> Does the bitcoind/wallet.dat really store nothing of this sort?
09:14 < sipa> the wallet remembers all wallet transactions
09:15 < NotAnNSAgent> ?
09:15 < sipa> i'm not sure what kind of notifications you're talking about, as i haven't used windows or the bitcoin core GUI in a long time
09:15 < sipa> but if they're annoying, there should be a way to turn them off
09:16 < NotAnNSAgent> How does my program display only new transactions?
09:16 < NotAnNSAgent> It would have to manually remember which ones have been seen/dealt with.
09:16 < sipa> what is 'your program' ?
09:16 < NotAnNSAgent> Why doesn't the wallet.dat/bitcoind remember which transactions have been "processed" and which ones are new?
09:17 < sipa> if you're talking about the wallet, it does
09:17 < NotAnNSAgent> Is this really the case?
09:17 < NotAnNSAgent> It does?
09:17 < sipa> if you're talking about the verification logic, it does not and this should not matter
09:17 < NotAnNSAgent> What's the API call called for figuring the status out?
09:17 < sipa> can you please tell me what kind of notification you're talking about?
09:18 < NotAnNSAgent> I'm not talking about any notifications...
09:18 < NotAnNSAgent> I'm talking about a FLAG in the API for transactions that can be true or false.
09:18 < NotAnNSAgent> Is there such a thing?
09:18 < NotAnNSAgent> "has_been_processed" or something?
09:19 < NotAnNSAgent> Something I can use to not have to store a separate database just to remember which txids I've processed?
09:21 < sipa> if you're not talking about notification, then what does "has_been_processed" mean?
09:22 < sipa> you're presumably using a polling mechanism to update the state
09:22 < sipa> so the relevant question is whether you have already seen a transaction, not whether bitcoind had
09:22 < sipa> *has
09:26 < NotAnNSAgent> ...
09:26 < NotAnNSAgent> So does this mean no?
09:27 < sipa> i'm afraid i don't understand your question
09:27 < sipa> you're trying to create an application that does something once for every transaction (every wallet transaction, i assume)?
09:30 < sipa> if so, there are 2 possible mechanisms
09:30 < sipa> either a polling-based approach (for example, listtransactions or getreceivedbyaddress RPC)
09:31 < sipa> or a push-based approach (for example, -walletnotify or ZMQ)
09:31 < sipa> in case of a polling approach, you'll only be notified once for each transaction
09:31 < sipa> eh, in case of a push-based approach
09:31 < sipa> in the case of a polling based approach, bitcoind cannot know what you have already seen or not, so there is no way to do what you're asking
09:32 < sipa> but even if you're using ZMQ or -walletnotify, you'll still need to use RPC to sync up in case your application restarted for example
09:37 -!- zooko [~user@2601:281:8000:8387:5522:b6ce:1c7a:811d] has quit [Ping timeout: 268 seconds]
09:45 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
09:46 < NotAnNSAgent> sipa: That's why I don't use "walletnotify" directly.
09:46 < NotAnNSAgent> sipa: I have "handle_new_bitcoin_donations.php" which I execute upon walletnotify (not caring about the %s you can send with it) as well as every hour as a cronjob.
09:46 < NotAnNSAgent> sipa: That script simply grabs the latest 100 transactions and is supposed to "process" (do some application logic) for each new one.
09:47 < NotAnNSAgent> sipa: In the situation I'm in, this is a dedicated server at home which has no SQL database installed/setup.
09:47 < NotAnNSAgent> sipa: I was trying to get around having to set that up just to keep a list of all txids that my script has "processed"/"seen".
09:48 < sipa> there is no solution for that, as bitcoind knows what it has seen, but it can't possibly know what you have seen
09:48 < NotAnNSAgent> sipa: That's why it would be a boolean flag, as I've been trying to say a number of times now.
09:48 < sipa> a boolean flag inside your application, yes
09:48 < NotAnNSAgent> Meaning I would do something like "updateseenflag <txid> true".
09:48 < sipa> bitcoind is not a database
09:48 < NotAnNSAgent> (If it had supported that)
09:49 < sipa> sorry, feature creep :)
09:49 < NotAnNSAgent> sipa: How can you possibly call that feature creep?
09:49 < NotAnNSAgent> It's the very basic associated flag IMO.
09:49 < NotAnNSAgent> I mean, you can't rely on "walletnotify" to send once the txid and expect that the receiving script/server is up and running at that specific time, as you said.
09:50 < NotAnNSAgent> So you have to do the "poll" method.
09:50 < sipa> or use ZMQ, but still poll once at startup or whenever the connection is reset
09:50 < NotAnNSAgent> I mean, as I said, I do use walletnotify, but only to "run the usual script" and not specifically for that txid (which I don't even capture).
09:50 < NotAnNSAgent> What is ZMQ?
09:50 < sipa> google is your friend
09:51 < NotAnNSAgent> No, it's not.
09:51 < sipa> sorry, i'm not your personal assistant
09:51 < sipa> look into ZMQ, it may do what you want
09:52 < sipa> otherwise, you'll need a database (or even just a text file!) in which you record what you've seen already and what you've done with it
09:55 < luke-jr> NotAnNSAgent: your idea breaks down when you have more than 1 program "processing" transactions
09:58 < sipa> despite that, it's open source, so you don't need anyone's permission to add such functionality to the code (for yourself, or present it as patch for including upstream)
10:02 < GitHub188> [bitcoin] sipa opened pull request #7934: Improve rolling bloom filter performance and benchmark (master...benchrollingbloom) https://github.com/bitcoin/bitcoin/pull/7934
10:02 < luke-jr> indeed, the wallet actually has extensibility that you could probably add it in a way that's backward compatible
10:02 < luke-jr> and won't get removed if you accidentally run a non-compatible version
10:26 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 246 seconds]
10:26 -!- dermoth [~thomas@dsl-66-36-157-105.mtl.aei.ca] has joined #bitcoin-core-dev
10:36 < NotAnNSAgent> Hmm @ multiple programs.
10:36 < NotAnNSAgent> How often would you have that? Seems like an odd thing to do.
10:37 < NotAnNSAgent> As for being open source... that's an fallacy. I'm not an expert coder and don't have the ability to sit down and figure out how everything works, much less release my own branch of that software from that point on.
10:39 < sipa> NotAnNSAgent: you can pay someone :)
10:39 < sipa> but it's also a fallacy to think that everyone has the same priorities for the code as you do
10:41 < NotAnNSAgent> No, I can't pay someone.
10:41 < NotAnNSAgent> You'd think this feature would've been thought of for 0.1.0.
10:41 < NotAnNSAgent> Different Core question, about the GUI application. How do you edit labels?
10:43 < luke-jr> 0.1.0 is not 1.0.0
10:44 < luke-jr> and yes, you can pay someone; that's how code gets written typically
10:44 < sipa> NotAnNSAgent: sorry, we're all volunteers here; code gets written that someone spends their time on
10:44 < NotAnNSAgent> If they accept invisible money that I don't have, maybe.
10:44 < NotAnNSAgent> Sure. Just trying to understand the reasoning.
10:45 < NotAnNSAgent> I'll likely go for the text file.
10:45 < NotAnNSAgent> But who knows what happens if it gets corrupted?
10:45 < NotAnNSAgent> Or how slow it becomes after X transactions?
10:45 < luke-jr> NotAnNSAgent: wallets can get corrupted just as easily
10:45 < NotAnNSAgent> :/
10:45 < luke-jr> and bitcoind's wallet is not optimised at all
10:45 < NotAnNSAgent> Optimized?
10:45 < sipa> if you need reliability, you need a backup mechanism
10:46 < sipa> bitcoin core's wallet is design so it only needs a backup every 100 (or whatever you set the keypool size too) transactions
10:46 < sipa> if you're going to put application data inside the wallet, that requirement becomes: for every transaction
10:46 < luke-jr> sipa: well, you need a backup immediately for any metadata changes of course
10:46 < sipa> luke-jr: indeed
10:47 < luke-jr> hm, deadlock in almost-master
10:48 < luke-jr> or not, maybe it's just busy :P
10:48 < luke-jr> invalidateblock far back is slow <.<
10:48 < sipa> luke-jr: haha, yes
10:49 < sipa> it needs to rewind the entire UTXO set
10:49 < sipa> though a lot is due to it trying to keep the mempool in sync
10:49 < sipa> in segwit i have a patch that makes it bypass that
10:51 < NotAnNSAgent> Makes sort of sense.
10:51 < NotAnNSAgent> How do you edit labels in Core GUI?
10:51 < NotAnNSAgent> Maybe it's not possible?
10:51 < sipa> i have no idea, sorry
10:55 < luke-jr> NotAnNSAgent: right click
10:56 < luke-jr> (answering that was what I was trying to do when I realised it was blocked :P)
10:56 < luke-jr> it's common sense though, in most cases
10:56 < luke-jr> the one case that *doesn't* work sanely, is when you're sending via payment protocol
10:57 < luke-jr> in that case, you have to go to the transaction list after you send, and edit it in
10:57 < luke-jr> note that GUI labels aren't really well-supported in the RPC yet
10:58 < sipa> there is a half-and-half overlap between RPC accounts and GUI labels
11:08 < NotAnNSAgent> luke-jr: Right-click only has "Copy label".
11:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
11:15 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
11:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
11:37 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
11:40 < NotAnNSAgent> (This is not a practical problem anymore because I deleted it and created new ones)
11:40 < NotAnNSAgent> But I still wonder what you meant.
11:51 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:52 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
11:54 -!- Don_John [~Don@249-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
11:54 -!- Don_John [~Don@249-223-114-134.nat.resnet.nau.edu] has quit [Client Quit]
12:05 -!- zooko [~user@50.141.119.37] has joined #bitcoin-core-dev
12:08 -!- zooko` [~user@2601:281:8000:8387:5522:b6ce:1c7a:811d] has joined #bitcoin-core-dev
12:11 -!- zooko [~user@50.141.119.37] has quit [Ping timeout: 276 seconds]
12:18 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:19 < NotAnNSAgent> luke-jr, sipa, etc.: What is the "id" that I can send used for?
12:19 < NotAnNSAgent> That is: 'jsonrpc' => '1.0', 'id' => 'curltest', 'method' => 'getbalance'
12:21 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
12:22 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
12:24 < sipa> NotAnNSAgent: it's part of the JSON-RPC specification
12:24 < sipa> i think it's just echoed back in the response
12:41 -!- zooko` [~user@2601:281:8000:8387:5522:b6ce:1c7a:811d] has quit [Ping timeout: 250 seconds]
12:45 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
12:45 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
12:50 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:53 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
13:07 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
13:08 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
13:17 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
13:20 < NotAnNSAgent> sipa: It is, but why?
13:21 < NotAnNSAgent> Also, another question: sendfrom <-- What if I don't know which account (or no account) holds the money I want to send?
13:21 < NotAnNSAgent> Or rather, I didn't assign it to any particular account.
13:25 -!- AaronvanW [~ewout@172pc231.sshunet.nl] has joined #bitcoin-core-dev
13:25 -!- AaronvanW [~ewout@172pc231.sshunet.nl] has quit [Changing host]
13:25 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
13:28 -!- phantomcircuit [~phantomci@192.241.205.97] has quit [Max SendQ exceeded]
13:28 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-dev
13:29 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
13:30 -!- justanot1eruser is now known as yolandivisser
13:31 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds]
13:36 < sipa> NotAnNSAgent: then you're using the "" account
13:37 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Read error: Connection reset by peer]
13:37 < sipa> NotAnNSAgent: for why, i din't know... ask the people who wrote the JSOn-RPC spec :)
13:37 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
13:45 < NotAnNSAgent> Hmm.
13:45 < NotAnNSAgent> sipa: "<amount> is a real and is rounded to 8 decimal places." <-- 0.1 seems to not mean "one tenth of a Bitcoin".
13:45 < NotAnNSAgent> (Thanks for the "" account tip)
13:45 < sipa> yes it does mean that
13:52 -!- yolandiv1sser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
13:53 -!- JackH [~Jack@79-73-185-113.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
13:53 -!- yolandivisser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 268 seconds]
13:54 < NotAnNSAgent> sipa: Hmm. It doesn't seem to take 0.1 away from the balance.
13:54 < NotAnNSAgent> Maybe something weird is happening because I'm not quoting it, and PHP is mangling it or something.
13:56 < NotAnNSAgent> Oh. No. I just interpreted the data wrong. Sorry.
13:56 < NotAnNSAgent> Hmm. I'm somewhat confident that my tests are now ready to be turned live. But that's scary.
13:56 < NotAnNSAgent> I've essentially coded a little "bank" this last week.
13:56 < NotAnNSAgent> Based around a bitcoind-
13:59 < NotAnNSAgent> Have "accounts" existed since the very beginning?
13:59 < NotAnNSAgent> Very useful they are.
14:00 < NotAnNSAgent> Though I wonder how that works out with pre-generated safety addresses which aren't assigned to any account.
14:00 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
14:03 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-nexxmvrvvlvreece] has quit [Quit: Connection closed for inactivity]
14:03 < sipa> NotAnNSAgent: those are not assigned an address until you call getnewaddress
14:03 < sipa> eh, a label
14:03 < sipa> also, accounts are very likely not doing what you think they are
14:04 < NotAnNSAgent> A label?
14:04 < NotAnNSAgent> A label is something different from an account... no? Why did you call accounts labels right now?
14:04 < sipa> and are deprecated and planned to be removed (and just be replaced by address labels)
14:05 < sipa> labels and accounts are effectively the same thing
14:05 < NotAnNSAgent> Are you saying that I've just implemented a deprecated concept?
14:05 < NotAnNSAgent> I've followed this: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
14:05 < NotAnNSAgent> Is this wrong?
14:06 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 244 seconds]
14:06 < sipa> the wiki is full of very olddated information
14:06 < sipa> i suggest using the developer documentation on bitcoin.org
14:07 < NotAnNSAgent> ...
14:07 < NotAnNSAgent> https://bitcoin.org/en/developer-reference#bitcoin-core-apis <-- This page doesn't seem to even display correctly.
14:08 < NotAnNSAgent> And says it has not been reviewed.
14:09 < sipa> pro life tip: thongs that indicate they have shortcomings are often much better than random claims :)
14:09 < sipa> the information on the wiki is so wrong in many places that people stopped bothering to correct it
14:10 < NotAnNSAgent> sipa: That's just swell.
14:10 < NotAnNSAgent> I've been using it as a reference.
14:10 < NotAnNSAgent> And no warnings anywhere.
14:10 < btcdrak> sipa: thongs? o.0
14:10 < NotAnNSAgent> Except a link to that weird documentation.
14:11 < NotAnNSAgent> I find that link very messy.
14:11 < NotAnNSAgent> And I'm not just saying that because I've been using the old one.
14:11 < sipa> help improve it then :)
14:11 < NotAnNSAgent> From what I can tell, the stuff I have works. But what you say about accounts being deprecated sounds insane to me.
14:11 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:11 < NotAnNSAgent> It seems to be a core concept.
14:11 < NotAnNSAgent> Having no "accounts" within a wallet would make it useless.
14:12 < NotAnNSAgent> For anything but academic usage.
14:12 < NotAnNSAgent> I really hope no syntax changes will be necessary.
14:12 < NotAnNSAgent> Preserving backwards compatibility should be of utmost importance.
14:12 < sipa> accounts are pretty much incompatible with backups, for example
14:12 < NotAnNSAgent> ?
14:12 < sipa> as you can't reconstruct account information from the blockchain
14:13 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
14:13 < sipa> if your wallet gets corrupted, you lose your accounting information, which for some businesses may be worse than losing money
14:13 < NotAnNSAgent> Okay. Please listen: we, the users, do not like it when you, the developers, change stuff around. Even if it's stupid, we want a reliable API to use and not have to constantly change our code. We want solid, robust stuff that can be relied upon.
14:14 < sipa> it's been deprecated for years
14:14 < NotAnNSAgent> The wallet.dat still contains it, no?!
14:14 < NotAnNSAgent> I really hope you're just joking or something.
14:14 < sipa> not if your wallet.dat gets corrupted
14:14 < NotAnNSAgent> That's why you have backups of wallet.dat?
14:14 < sipa> are you making a backup after every transaction?
14:14 -!- yolandivisser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
14:14 -!- yolandiv1sser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
14:15 -!- yolandivisser is now known as justanotheruser
14:15 < NotAnNSAgent> No, but often.
14:15 < sipa> not enough, if you use accounts
14:15 < NotAnNSAgent> "sendfrom <fromaccount> <tobitcoinaddress> <amount>" <-- Are you saying that at some point in the near future, I'll upgrade my bitcoind and this will cease to work?
14:15 < sipa> yes
14:15 < NotAnNSAgent> .........
14:15 < NotAnNSAgent> And it's replaced by what exactly?
14:15 < sipa> let me first ask you this
14:16 < sipa> what do you think that RPC does?
14:16 < NotAnNSAgent> Lets me talk to bitcoind.
14:16 < sipa> so far so good
14:16 < belcher> NotAnNSAgent do you have anything online that uses accounts?
14:16 < NotAnNSAgent> belcher: No, but I thought I was ready literally minutes ago.
14:17 < NotAnNSAgent> My test finished successfully, etc.
14:17 < NotAnNSAgent> I just casually mentioned how much I liked accounts, and then I learn that it's deprecated!
14:17 < sipa> NotAnNSAgent: say you have address A1 and address A2, A1 received a transaction paying it 1 BTC, A2 received a transaction paying it 2 BTC
14:17 < belcher> well they are, since before i got interested in bitcoin
14:18 < sipa> NotAnNSAgent: address A1 is associated with account L1, address A2 js associated with account L2
14:18 < sipa> NotAnNSAgent: you do sendfrom L1 someaddress 1.5
14:18 < sipa> what happens?
14:19 < NotAnNSAgent> It fails because it doesn't have enough money? (Assuming they both had 0 initially)
14:19 < sipa> wrong, it succeeds, and L1 goes to -0.5
14:19 < NotAnNSAgent> o_O
14:19 < NotAnNSAgent> Minus?
14:19 < NotAnNSAgent> How is that possible?
14:19 < sipa> because accounts do not do anything near what you think they do
14:20 < sipa> you've read the documentation for a few minutes, and thought they were cool, made assumptions about what they do, and started using them with a few tests
14:20 < sipa> and they are useful, for a few very narrow cases
14:20 < sipa> but almost everybody misunderstands them
14:21 < NotAnNSAgent> Seems like accounts were improperly designed to me. :/
14:21 < NotAnNSAgent> If you can get negative amounts.
14:21 < sipa> and recently we had a problem among developers where we were not even sure what a particular getbalance call was supposed to do wrt accounts
14:21 < NotAnNSAgent> So L1 steals 0.5 BTC from the other accounts in the wallet?
14:21 < sturles> Negative amounts is a feature, if you ask me.
14:22 < gmaxwell> NotAnNSAgent: No, accounts are not wallets. They're accounting records.
14:22 < sipa> NotAnNSAgent: you're making assumptions
14:22 < sipa> NotAnNSAgent: an account just keeps track of how much (in BTC) in a wallet belongs to a particular user
14:22 < gmaxwell> user/use
14:22 < sipa> it does not have anything to do with which transactions or coins
14:22 < NotAnNSAgent> If, in the example, you send more BTC than what exists in the "account" inside the wallet.dat (which contains the two accounts L1 and L2), I certainly hope that that money is taken from some place, or else anyone could generate free Bitcoins.
14:23 < sipa> the coins in your wallet are shared across all accounts
14:23 < NotAnNSAgent> Alright, so I have to redo everything. And I don't even know how.
14:23 < NotAnNSAgent> No accounts...
14:24 < sipa> at least i hope you now understand why they are deprecated: evrryone misunderstands them
14:24 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds]
14:25 < Arnavion> You'd think the nomenclature of having multiple accounts within the same wallet would give a hint that they don't mean what you'd expect
14:25 < NotAnNSAgent> Apparently. I sure did.
14:25 < sipa> in fact, we recently came across some weird behaviour in tje getbalance call, and nobody including developers were even sure what the correct behaviour would be
14:25 < sipa> yes, there is talk about having just multiple wallet simultaneously
14:25 < NotAnNSAgent> But then why does this up-to-date, apparently-official manual mention accounts for the very same API call? https://bitcoin.org/en/developer-reference#sendfrom
14:26 < sipa> nothing official
14:26 < sipa> and it does describe how it works
14:26 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev
14:26 < gmaxwell> I think you're conflating multiple things; regardless of it being consider depricated; it's still there right now and still works as it always has.
14:27 < sipa> NotAnNSAgent: i can tell you that the transition to no accounts anymore will not hapoen instantly, as there are indeed people who rely on them, and use them the way they were intended to be used
14:28 < gmaxwell> It still continues to do what it's described to do; which is not what a lot of people initially think it does. (and often what they think it does isn't actually possible; or is equivilent to multiple wallets, with the overheads that involves)
14:28 < sipa> but it's good to know that we should probably ask the bitcoin.org people to mark those RPCs as deprecated on the site
14:28 < gmaxwell> Just axing out accounts would really screw up my tax reporting; unless they were at least replaced with labels. 
14:29 < sipa> only account balances will go away, you'll still be able to list transactions by label
14:30 < sturles> I use accounts to kepp track of incoming BTC from users.  BTC sold to me via my autobuy service.  When the money has been transfered, I move the BTC to a different account.  This is an extra safety for me, to make sure I have paid for every BTC I use or sell to other people, and in case I lose other records.  I started to use accounts when I missed one payout due to a glitch in my walletnotify
14:30 < sturles> script, and never missed a payout since.  If account balances are lost, this failsafe would be gone. :-(
14:31 < gmaxwell> sturles: the lack of good durability options for bitcoin wallets probably makes that workflow suboptimal. You probably want to have something that lets you send a transaction atomically with making a backup.
14:32 < gmaxwell> I guess we kind of have that possiblity now with walletbroadcast off... e.g. you'd make all your transactions but don't broadcast yet, backup with wallet. Then broadcast.
14:33 < sturles> Would be perfect, but my transaction volume is low enough that I can live with somewhat suboptimal.
14:34 < sturles> I could transfer funds to a different address when paid for, but that would cost transaction fees and block space.
14:35 < NotAnNSAgent> Why was the decision made to make "accounts" behave in this odd, unintuitive manner?
14:35  * sturles doesn't think it is unintuitive..
14:35 < gmaxwell> NotAnNSAgent: it's very sensible for the purpose they were created for. They're an overlay accounting system.
14:36 < NotAnNSAgent> But the syntax is literally: "sendfrom <fromaccount> <tobitcoinaddress> <amount>", even in the current documentation.
14:36 < gmaxwell> They let you tag incoming payments as payments to accounts, outgoing payments as payments from accounts, and let you enter correcting ledger entries. 
14:38 < gmaxwell> There isn't  really any "from" in the design of the bitcoin protocol in any case-- that people often think there is an artifact of the forensic analysis done by block explorers and the presentation of that analysis as 'transactions' in a way that doesn't actually reflect the operation of the bitcoin system.
14:38 < gmaxwell> I think this is why the rate of misunderstanding accounts increased over time, people were expecting there to be "from" in transactions.
14:38 < gmaxwell> and then it looks like the API is setting it.
14:39 < gmaxwell> ( see also: https://iwilcox.me.uk/2014/no-from-address )
14:39 < NotAnNSAgent> Well, the manual I'm looking at, which is the official one unless I'm mistaken, doesn't even mention that this is being deprecated.
14:39 < NotAnNSAgent> https://bitcoin.org/en/developer-reference#sendfrom
14:40 < NotAnNSAgent> Somebody said it's been in "deprecated" state for years already.
14:40 < NotAnNSAgent> And soon will be removed.
14:40 < NotAnNSAgent> But the up-to-date manual doesn't even mention this fact.
14:40 < sipa> Please stop saying official. There is no such thing.
14:40 < sipa> Nobody said they will be removed soo 
14:41 < sipa> They have indeed been deprecated for a long time.
14:41 < NotAnNSAgent> Alright, so if they are, then what do I do in place of "accounts"? And is this outlined nowhere?
14:42 < NotAnNSAgent> Somebody mentioned "labels", but they already exist as "labels" for transactions.
14:42 < NotAnNSAgent> And seem to be local only.
14:42 < gmaxwell> everything is local only.
14:42 < sipa> accounts are also local only
14:42 < NotAnNSAgent> Good point.
14:42 < gmaxwell> At no point have you mentioned what you're trying to accomplish, so no one can answer "what do I do in place".
14:42 < NotAnNSAgent> But labels aren't exactly... um... the labels I'm thinking of are like "Payment for the bicycle from Joe". Not "someservice".
14:43 < NotAnNSAgent> gmaxwell: I'm trying to have one wallet.dat/bitcoind, but deal with multiple "accounts" of money.
14:43 < NotAnNSAgent> Namely for two separate services I run.
14:43 < sipa> so you want multiple wallets, really
14:43 < NotAnNSAgent> They must never share money.
14:43 < sipa> i mean: you want something to behave as if they acted as two separate wallets
14:44 < NotAnNSAgent> That's why I thought "accounts" existed.
14:44 < sipa> bitcoind does not support this; there are other wallets out there that do
14:44 < NotAnNSAgent> Now you're just being ridiculous. Are you saying that every Bitcoin business in the world uses third-party clients because the official one only allows one single wallet?
14:45 < sipa> bitcoind does many things, and a wallet is only one of them
14:45 < gmaxwell> "they must never share money." < Thats multiple wallets that you want. You can run multiple bitcoinds, with pruning each will use a couple gigs of disk space.
14:45 < sipa> its wallet implementation is a reference one, certainly not the most advanced nor the one most development work goes towards
14:45 < NotAnNSAgent> You know, I was really proud an hour ago or so when I had finally finished (I thought) this complex system...
14:46 < gmaxwell> NotAnNSAgent: multiple wallets is very simple... run multiple wallets, connect to the correct one. Done. :)
14:46 < NotAnNSAgent> Why would it require multiple blockchains?
14:46 < gmaxwell> It doesn't, not with pruning.
14:47 < NotAnNSAgent> Pruning is a whole problem in itself.
14:47 < gmaxwell> uh. What?
14:47 < NotAnNSAgent> I'm stuck with 0.11.x and only 0.12.x does it. This is why I went out of my way to make a separate computer to just run Bitcoind.
14:47 < gmaxwell> How are you 'stuck with 0.11.x'?
14:47 < NotAnNSAgent> Because 0.12.x doesn't exist on FreeBSD.
14:48 < sipa> i'm sure you can run a compiler if you use FreeBSD
14:48 < gmaxwell> Sure it does. Do you mean ports hasn't updated to it?
14:48 < NotAnNSAgent> But even if it did, I wouldn't wanna run multiple different instances of bitcoind. That simply cannot be necessary. I refuse to believe that.
14:48 < sipa> it is not necessary
14:48 < NotAnNSAgent> There is no pkg except for 0.11.x, yes.
14:48 < sipa> and it's silly that you can't have two wallets in one bitcoind, i fully agree
14:49 < sipa> bit someone has to do the work to make that happen, someone has to test it, has to review it, has to maintain it
14:49 < sipa> few people have showed up before to do that when there was talk of having multiple wallets
14:49 < gmaxwell> I agree that it's a silly limitation, otoh, it's trivial to work around-- in a very safe and reliable way--, which is part of why no one has stepped up to fix that.
14:50 < gmaxwell> (as running multiple bitcoinds, especially with pruning, is a trival cost-- much cheaper than opening multiple bank accounts. :) )
14:50 < NotAnNSAgent> Trivial to work around? I'd have to run separate blockchains (ridiculous), not to mention it's a nightmare already to attempt to "restart" (kill and relaunch command) my one bitcoind...
14:50 < gmaxwell> And having multiple wallets in one bitcoind is more complex than you might guess at a glance; for example, you don't want to allow any privacy cross linking of them.
14:50 < NotAnNSAgent> And there is no pruning for me as mentioned.
14:51 < gmaxwell> NotAnNSAgent: you're running outdated software which is several releases behind, lacking the latest security and performance fixes...
14:51 < NotAnNSAgent> Tell that to the maintainer who doesn't respond to e-mails and doesn't take his job seriously.
14:52 < sipa> are you paying him.
14:52 < sipa> ?
14:52 < sipa> no? then don't complain about the work of volunteers
14:52 < NotAnNSAgent> Crazy concept: doing something for other reasons than getting paid.
14:52 < gmaxwell> I can try pinging too. But this might be an argument against using freebsd if you're going to depend on packages that don't get updated.
14:53 < gmaxwell> NotAnNSAgent: sure, it would be nice but you can only ask for so much.
14:53 < NotAnNSAgent> I'm told to not use FreeBSD every time I mention a problem I'm having. If it were easy, I would switch.
14:53 < sipa> NotAnNSAgent: for the longest time i was not paid to work on bitcoin, and i still spent weekends and evenings on it. please don't say that money is the only reason to do things
14:53 < NotAnNSAgent> You used it as an argument, though.
14:53 < sipa> NotAnNSAgent: but you don't complain about the work of volunteers
14:53 < gmaxwell> NotAnNSAgent: well I'm not telling you to switch, just pointing out that its a consideration that has to be taken in totality.
14:54 < NotAnNSAgent> And of course nobody is saying that this is easy. I'd never say that.
14:55 < NotAnNSAgent> My experiences especially these last few weeks have really convinced me that Bitcoin has a looooong way to go before it can be implemented by anyone other than hardcore experts.
14:55 < NotAnNSAgent> I shouldn't say "implemented".
14:55 < NotAnNSAgent> More like "deployed".
14:55 < gmaxwell> In any case, 0.12.1 should build cleanly on freebsd without any modifications. If it doesn't we'd love to know about it and fix them for the next release.
14:55 < NotAnNSAgent> gmaxwell: I actually tried to build it on my FreeBSD box. It failed with some requirement of a db4.h or something along those lines.
14:56 < sipa> NotAnNSAgent: use --with-incompatible-bdb
14:56 < NotAnNSAgent> I already had db4-something as an installed package, but that wasn't good enough because it doesn't contain the source code.
14:56 < sipa> ah, yes, you'll need development headers
14:56 < NotAnNSAgent> Incompatible BDB :S
14:56 < gmaxwell> NotAnNSAgent: not that I'd disagree, but you've given yourself some disadavantages:  you're using a less common and less well maintained platform, and you're trying to put two totally seperate uses on a single system, for example.  These are things that _should_ still work well, I agree. But your expirence may not be typical. :)
14:58 < NotAnNSAgent> Even if I wanted to switch right now, I couldn't pick one of the numerous Linux distros. That would simply be impossible for me. And of course I'd have to recode every single script and learn how everything is done in that OS... to me, that is like going through a heart transplant.
14:58 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 244 seconds]
14:59 < sipa> NotAnNSAgent: i must say that i'm somewhat surprised to see someone comment about using bitcoin on both Win10 and FreeBSD :)
14:59 < NotAnNSAgent> At some point, I tried to "give up and just use Bitpay or Coinbase", but both of those require you to send them "proof of business" and a bunch of nonsense like that (which they reveal only after registering, of course).
14:59 < sipa> NotAnNSAgent: not meant in a bad way, just curious
15:00 < NotAnNSAgent> What's so surprising? I don't know if I've mentioned Windows 10, but yes, I run that on the desktop.
15:00 < sipa> 18:12:28 < NotAnNSAgent> Since Windows 10, the Bitcoin Core client for Windows uses the awful Windows 10 notifications, which I've been forced to turn off globally.
15:00 < NotAnNSAgent> Ah. Yes.
15:01 < NotAnNSAgent> When I picked FreeBSD, the year was 2000 or something.
15:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
15:01 < sipa> Ha, that's when I last used Windows (ME!), and switched to Debian :)
15:02 < sipa> NotAnNSAgent: btw, can you file an issue for those notifications?
15:05 < NotAnNSAgent> I'm often told to "file a bug" or "file a PR" etc. for various open source projects. When I try, I never receive a verification e-mail and then I forget about it. I've come to consider such tasks to be real chores that are far worse than carrying heavy objects around in real life.
15:06 < sipa> I can do it for you, but I don't even have any idea what notifications you're talking about
15:07 < sipa> I do understand the burden of registering on github, but the best thing you can do right now to get the problem fixed eventually, is to provide as much information about it on a report.
15:08 < NotAnNSAgent> The notifications thing really is a non-issue in comparison to this.
15:08 < sipa> Doesn't mean it can't get attention, probably by very different people.
15:10 -!- JackH [~Jack@79-73-185-113.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]
15:11 < NotAnNSAgent> Essentially, I hate the Windows 10 notifications but loved the old, pre-Windows 10 balloon tips.
15:11 < NotAnNSAgent> The Win10 ones are flooding me with useless notifications such as "all transfers finished" in FileZilla, making them useless.
15:11 < NotAnNSAgent> Or "Get Office 360 for cheap!"
15:11 < NotAnNSAgent> But the old balloon tips nicely stayed there until I saw them.
15:11 < NotAnNSAgent> And no junk ones.
15:12 < NotAnNSAgent> There is supposedly a way to turn off notifications for all but your chosen "apps", but it doesn't actually seem to work.
15:14 < NotAnNSAgent> What disturbs me the most about all of this is probably that even the current documentation doesn't reflect this MAJOR (IMO) change.
15:14 < NotAnNSAgent> Do you developers have some internal documentation that you use?
15:14 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
15:14 < belcher> i think i found out accounts were deprecated from the bitcoin wiki or something
15:15 < belcher> or maybe when you run help json-rpc
15:15 < NotAnNSAgent> belcher: https://bitcoin.org/en/developer-reference#sendfrom
15:15 < NotAnNSAgent> It's acting as if accounts are alive and well.
15:15 < belcher> whoops wrong channel
15:17 < belcher> if you run 'help getaccount' on json-rpc (or anything accounts related i guess) it tells you they're deprecated
15:17 < molz> belcher, on the wallet qt, if you type in the console "help getaccount", it tells you "DEPRECATED. Returns the account associated with the given address." so i don't think anyone can miss it
15:17 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has quit [Client Quit]
15:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
15:18 < NotAnNSAgent> Yeah, that's totally gonna happen.
15:19 < sipa> that's the only "official" documentation there is, though :)
15:20 < NotAnNSAgent> I don't even know what "run 'help getaccount' on json-rpc" means.
15:20 < NotAnNSAgent> How can you run a "help" command inside an API call?
15:20 < NotAnNSAgent> That sounds like something that would be run on the command line.
15:20 < sipa> you send the 'help' RPC with the name of the command as argument
15:20 < NotAnNSAgent> So... I can't believe I'm asking this, but... how do you *actually* send money?
15:20 < sipa> sendtoaddress
15:20 < NotAnNSAgent> Since the account stuff is false.
15:21 < sipa> or sendmany
15:21 < sipa> or the createrawtransaction / fundrawtransaction / signrawtransaction / sendrawtransaction approach, if you want more low-level control
15:23 < NotAnNSAgent> I think you must be using the same underlying documentation software as Stripe.
15:23 < sipa> ?
15:23 < NotAnNSAgent> Because Stripe also nearly crashes my browser every time I load their documentation pages.
15:23 < NotAnNSAgent> sipa: I'm referring to https://bitcoin.org/en/developer-reference#sendtoaddress
15:24 < sipa> i don't run that site; i just recommended it
15:24 < sipa> works fine here
15:24 < NotAnNSAgent> I mean "you" as in "Bitcoin developers".
15:25 < sipa> Bitcoin developers do not run that site.
15:25 < sipa> at least, not the Bitcoin Core maintainers
15:26 < NotAnNSAgent> Where is the actual manual for Bitcoin?
15:26 < NotAnNSAgent> If Bitcoin.org is unofficial.
15:26 < NotAnNSAgent> I know you don't like the term "official".
15:27 < sipa> the documentation for the RPC interface is available through the 'help' RPC
15:27 < NotAnNSAgent> So in other words, there is no manual? Other than hidden inside RPC API calls?
15:28 < sipa> i wouldn't call it hidden, but if you're looking for a reference, no
15:29 < sipa> the documentation on bitcoin.org is often very good though, and better than what developers would write :)
15:31 < NotAnNSAgent> Except when it fails to mention crucial facts.
15:31 < NotAnNSAgent> Which could only be known to somebody who is very intimately familiar with the Bitcoin development process.
15:32 -!- sipa [~pw@unaffiliated/sipa1024] has left #bitcoin-core-dev []
15:32 < NotAnNSAgent> There is no way I could code another line in this state. Too pissed off and disillusioned.
15:32 < NotAnNSAgent> Must take a long damn nightly walk or something.
15:32 < NotAnNSAgent> BBL.
15:32 -!- NotAnNSAgent [~NotAnNSAg@gateway/vpn/privateinternetaccess/notannsagent] has quit [Quit: NotAnNSAgent]
15:41 < achow101> how is median time past calculated
16:00 -!- grimescapes [~user@46.166.188.199] has quit [Ping timeout: 244 seconds]
16:07 -!- grimescapes [~user@cpe-75-190-181-123.carolina.res.rr.com] has joined #bitcoin-core-dev
16:13 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
16:34 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
16:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
16:37 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has left #bitcoin-core-dev ["Verlassend"]
16:43 -!- grimesca` [~user@178.162.211.213] has joined #bitcoin-core-dev
16:45 -!- grimescapes [~user@cpe-75-190-181-123.carolina.res.rr.com] has quit [Ping timeout: 276 seconds]
16:51 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Quit: ZZZzzz…]
17:06 -!- NotAnNSAgent [~NotAnNSAg@46.166.190.146] has joined #bitcoin-core-dev
17:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
17:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
17:23 < NotAnNSAgent> Sooooooo...
17:24 < NotAnNSAgent> I have to have two separate 75 GB blockchains and separate bitcoind daemons running just to have two accounts. 
17:24 < NotAnNSAgent> Yes, I know what you said about pruning, but remember the circumstances.
17:25 < NotAnNSAgent> Out of curiosity, what was the thinking with the "accounts" that exist and are being killed off now?
17:25 < NotAnNSAgent> To me, it just seems bizarre that if you have not enough money in an "account", it will take money from other "accounts".
17:26 < NotAnNSAgent> Unless you assume that the wallet is literally a wallet and the "accounts" are like... separate credit cards inside the physical wallet.
17:26 < NotAnNSAgent> So I would've liked it better if the initial metaphor wasn't "wallet" and "wallet.dat", but instead "virtual Bitcoin bank" and "bank.dat".
17:26 < NotAnNSAgent> Then, "accounts" would make far more sense.
17:27 < NotAnNSAgent> But the "wallet" idea is also an attractive thing to advertise. Though I think the "wallets" could rather be Bitcoin's own term for an "account", all inside a "Bitcoin bank" (bank.dat).
17:27 < NotAnNSAgent> Do you understand what I mean?
17:28 < phantomcircuit> NotAnNSAgent, what are you trying to accomplish? (the accounts stuff is almost certainly the wrong way to do it, no matter what it is)
17:29 < NotAnNSAgent> phantomcircuit: I don't know if you have followed the conversation, but I know that the accounts are deprecated since a long time.
17:29 < NotAnNSAgent> phantomcircuit: I'm trying to discuss the concept of "accounts" in Bitcoin and why they were made the way they were.
17:29 < NotAnNSAgent> And why Bitcoin forces me to have separate instances and separate blockchains for each "account" I want to have (each "wallet" in your terms).
17:30 < phantomcircuit> NotAnNSAgent, the "accounts" functionality is an attempt to bring standard accounting practices to the reference wallet
17:30 < phantomcircuit> it falls well short of accomplishing this
17:30 < NotAnNSAgent> phantomcircuit: It's standard accounting practice to take money from other accounts if the account that's transferring money doesn't have enough?
17:31 < phantomcircuit> NotAnNSAgent, the "accounts" stuff is completely separate from handling of bitcoin transactions
17:31 < phantomcircuit> except that when you receive a payment it will correctly generate the accounting entry for that
17:31 < NotAnNSAgent> ...
17:32 < phantomcircuit> yes i agree it's not ideal and definitely confusing
17:32 < NotAnNSAgent> Why didn't Bitcoin support multiple "wallets" right away? I have no idea what you mean that "accounts" are supposed to be, still.
17:32 < phantomcircuit> it's much less confusing if you just ignore the accounts stuff
17:32 < NotAnNSAgent> I have to ignore the accounts stuff, because I learned it's practically removed from the Bitcoin software.
17:33 < NotAnNSAgent> (Without the manual being updated to reflect this)
17:33 < phantomcircuit> NotAnNSAgent, in bitcoin terms a "wallet" is just a collection of private keys and the transactions related to those keys in the blockchain
17:33 < NotAnNSAgent> Why is it so hard for Bitcoin to simply support multiple wallets? Why do I have to run entire separate blockchains and instances of the daemon for this?
17:34 < phantomcircuit> NotAnNSAgent, it's in the documentation that the accounts are deprecated
17:34 < phantomcircuit> NotAnNSAgent, why do you want multiple wallets?
17:34 < NotAnNSAgent> phantomcircuit: https://bitcoin.org/en/developer-reference#sendfrom
17:34 < NotAnNSAgent> phantomcircuit: To be able to support Bitcoin donations to one of my services, and to deal with another Bitcoin account for my commercial site.
17:35 < NotAnNSAgent> If I don't have any ability to set the "account" for a given txid, I can't know which "account" it's supposed to be connected with.
17:36 < NotAnNSAgent> Also, when I want to send out money back to my own desktop wallet, I can't select which "account" to send it from.
17:37 < phantomcircuit> NotAnNSAgent, you're right that should be updated, i opened an issue for it on github https://github.com/bitcoin-dot-org/bitcoin.org/issues/1287
17:37 < phantomcircuit> oh we're in the wrong channel for this conversation
17:39 -!- grimesca` [~user@178.162.211.213] has left #bitcoin-core-dev ["ERC (IRC client for Emacs 24.5.1)"]
17:39 < luke-jr> [00:25:28] <NotAnNSAgent> To me, it just seems bizarre that if you have not enough money in an "account", it will take money from other "accounts". <-- it wouldn't.
17:39 < NotAnNSAgent> I can't join that channel.
17:39 < NotAnNSAgent> luke-jr: I thought that was the point of the example one of you showed me earlier.
17:40 < luke-jr> phantomcircuit: the bitcoind concept of accounts is pretty ideal, even if poorly implemented
17:41 < phantomcircuit> NotAnNSAgent, the correct way to do this is to map the receiving address to what it's paying for and then account for that separately
17:41 < luke-jr> phantomcircuit: that's what accounts did :P
17:41 < phantomcircuit> luke-jr, yeah... but poorly
17:43 < NotAnNSAgent> phantomcircuit: My bitcoind is on a different server from my main server. Every hour, it generates 50 receive addresses with the account "X" and the same number for the account "Y". Then it sends those via HTTPS and JSON to my main server. The main server stores them in a database (separate DBs) and shows a unique one for each person who requests to pay.
17:43 < NotAnNSAgent> Then, when a payment is made to one of those receive addresses, my script checks all the unchecked txids.
17:44 < NotAnNSAgent> And then checks what their "account" is to decide what to do.
17:44 < luke-jr> so you just need to skip the account stuff
17:44 < NotAnNSAgent> ?
17:44 < luke-jr> keep track of that in your main server
17:45 < phantomcircuit> NotAnNSAgent, in the database on your main server you're already associating an address with the invoice, correct?
17:45 < phantomcircuit> then you already have all the information you need to do this without the accounts stuff
17:45 < NotAnNSAgent> No... I just store them in a very simple table and pick one to show the user (and then deletes it).
17:45 < phantomcircuit> oh
17:45 < phantomcircuit> dont do that
17:45 < phantomcircuit> associate the address with an invoice
17:46 < phantomcircuit> then check for payments by calling "listtransactions" and looking at the address field
17:46 < NotAnNSAgent> The bitcoind is on a separate server, as mentioned. It has no such database in it.
17:46 < luke-jr> …
17:47 < luke-jr> if you don't know which invoice is paid, what happens when someone doesn't pay?
17:47 < NotAnNSAgent> It doesn't know what to do with the txid.
17:51 < NotAnNSAgent> There are two machines: bitcoind and www. bitcoind is made hourly to generate 50 receive addresses for account X and 50 for account Y. When it's done, it sends those addresses to www which stores it in two databases. A user of one of the services requests to pay, and thus gets one of the prepared receive addresses. When they send money to them, bitcoind will soon react by running the walletnotify script (which I also run every hour as a 
17:51 < NotAnNSAgent> cronjob) which then lists all the recent transactions and checks if they have been processed (by comparing them to entries in a simple text file called processed_txids), and if they haven't, they get an action done to the right service by checking which "account" the txid has.
17:51 < NotAnNSAgent> If I can't have accounts, there is no longer any "label".
17:51 < NotAnNSAgent> So the walletnotify/hourly script has no way to know what to do with the txid.
17:53 < NotAnNSAgent> Unless there is indeed a "label" I can use instead? Like the labels in the graphical client.
17:53 < NotAnNSAgent> But in that case, why also have "accounts"?
18:03 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vikracvcxdaisvva] has quit [Quit: Connection closed for inactivity]
18:26 < luke-jr> accounts tracked a balance
18:26 < luke-jr> labels *should* be usable in bitcoind, but not fully yet IIRC
18:26 < luke-jr> but for receiving, it should work
18:27 < phantomcircuit> luke-jr, i wouldn't use labels either just because it's essentially impossible to do backups in a sane way
18:28 < phantomcircuit> NotAnNSAgent, do you already generate invoices on the www server?
18:31 < NotAnNSAgent> phantomcircuit: I have no concept of invoices.
18:31 < NotAnNSAgent> But that's a detail that can be fleshed out later.
18:32 < phantomcircuit> NotAnNSAgent, then how do you expect to keep track of what a payment was for?
18:32 < NotAnNSAgent> I can store user id, amount, txid.
18:32 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-jauuklmdfarjmiwo] has joined #bitcoin-core-dev
18:32 < NotAnNSAgent> It's simply not relevant to this problem.
18:32 < NotAnNSAgent> Can I set an arbitrary property of my own?
18:32 < NotAnNSAgent> Some sort of label/data?
18:33 < NotAnNSAgent> This is insane. I can't believe I'm having to ask about this on IRC instead of it just being spelled out clearly on the site.
18:33 < NotAnNSAgent> And I was looking at ancient documentation for the duration of my implementation up until today.
18:37 < luke-jr> NotAnNSAgent: as I said, you can set labels for receiving. the backup issue will apply no matter what you do
18:38 < luke-jr> NotAnNSAgent: and, invoices are relevant, since two orders may have the same amount
18:38 < luke-jr> and Bitcoin has no concept of users
18:41 < NotAnNSAgent> I still don't get what you are talking about in terms of backups.
18:43 < NotAnNSAgent> luke-jr: You're all acting as if I had asked you to bake in a full-length movie into each block in the blockchain or something, but all I'm asking for is a way to label my receive addresses in the bitcoind so it stands any chance of knowing which "account" it belongs to.
18:43 < NotAnNSAgent> Why isn't that in every example and the first thing you see?
18:43 < NotAnNSAgent> And how do I actually set and get it?
18:44 < luke-jr> NotAnNSAgent: we're saying you need to label each address individually to know what purchase it's used for
18:44 < NotAnNSAgent> ..............
18:44 < luke-jr> that's how bitcoin works
18:44 < NotAnNSAgent> This has NOTHING to do with the product bought.
18:44 < NotAnNSAgent> I'm talking about the BITCOIND.
18:44 < NotAnNSAgent> Not the WWW server.
18:44 < luke-jr> you don't need it in more than one place
18:44 < NotAnNSAgent> ...
18:45 < NotAnNSAgent> I give up. You won't read anything I type, so it's meaningless to attempt to ask this basic question.
18:48 < midnightmagic> This isn't really the place to ask user questions about bitcoind dude.
18:48 < midnightmagic> It would be like going into the engineering department of a commercial software house and asking support questions.
18:48 < gmaxwell> NotAnNSAgent: I think you need an attutide adjustment. You came here seeking free tech support, and -- people are happy to provide it-- but at every turn you've treated the folks here with disrespect.  This isn't acceptable. Please cut it out.
18:48 < midnightmagic> .. by grabbing the ear of literally the first engineer who's sitting there staring at a wall of text, that you see.
18:50 < gmaxwell> NotAnNSAgent: if all you want to do is attach labels to addresses, you can do that, via the accounts mechenism. As people mentioned the labeling isn't durable across backups; which might or might not be an issue for you. Earlier you weren't looking for labels, you were looking for seperate wallet functionality (which accounts do not provide). If you want to use accounts as labels, you may, but y
18:50 < gmaxwell> ou'll have to take some time to understand the behavior lest you confuse yourself with get balance calls.
18:52 < gmaxwell> NotAnNSAgent: if you're going to be generating hundreds of addresses per hour, you'll want to increase the keybpool size so that you're not invalidting your backups and risking key loss.  The comments above were recommending that you record which user which address belongs to in your front end. This is important for data durability. If you're doing that, you probably do not also need to do the s
18:52 < gmaxwell> ame in bitcoind, though you can if you want.
18:56 < midnightmagic> +1 external address-to-user matching via listunspent queries or equivalent.
19:00 -!- dermoth [~thomas@dsl-66-36-157-105.mtl.aei.ca] has quit [Read error: Connection reset by peer]
19:01 -!- dermoth [~thomas@66.36.157.105] has joined #bitcoin-core-dev
19:04 < NotAnNSAgent> This just keeps on getting more and more complicated.
19:04 < NotAnNSAgent> Also, Bitcoin Core is bitcoind, no?
19:04 < NotAnNSAgent> (Except it also has a GUI client)
19:07 < belcher> the gui client is generally called bitcoin-qt, bitcoin core is the project that includes both of those
19:08 < NotAnNSAgent> I really don't know what to do.
19:08 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:09 < NotAnNSAgent> It feels as if I'm desperately trying to help get some enthusiasm going for Bitcoin as a project, but everyone seems to have sort of given up mentally.
19:09 < luke-jr> midnightmagic: listtransactions or listreceived :x
19:10 < luke-jr> midnightmagic: listunspent is wallet internals; not something normal users should need ever
19:10 < luke-jr> NotAnNSAgent: you can expect many people will "give up" helping when you ignore the advice you're given.
19:12 < NotAnNSAgent> You are the one who ignored what I said, but sure.
19:12 < phantomcircuit> NotAnNSAgent, i already told you
19:12 < NotAnNSAgent> You make about as much sense as the Bitcoin API.
19:12 < phantomcircuit> you want to assign an address to an invoice
19:12 < phantomcircuit> that's it
19:12 -!- NotAnNSAgent [~NotAnNSAg@46.166.190.146] has left #bitcoin-core-dev []
19:35 < phantomcircuit> horray
19:38 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
19:52 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
19:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
20:11 -!- zooko [~user@2601:281:8000:8387:5522:b6ce:1c7a:811d] has joined #bitcoin-core-dev
20:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:30 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
20:38 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
21:05 < midnightmagic>  you think so? 
21:21 < phantomcircuit> im thinking we shouldn't have "assert" in serialization code
21:21 < phantomcircuit> only for maintaining invariants of things in memory
21:21 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
21:22 < cryptocoder> luke-jr, phantomcircuit: saw your comments earlier about using “listtransactions” instead of “listunspent”. wouldn’t the latter make more sense?
21:23 < luke-jr> cryptocoder: no, listunspent makes no sense in that context since it deals with UTXOs and not addresses
21:24 < cryptocoder> I see.  I just wasn’t sure if that’s was your view in general or simply in the context of notannsagent’s use case
21:25 < luke-jr> ah
21:25 < luke-jr> yeah, right tool for the right job kind of thing
21:26 -!- zooko [~user@2601:281:8000:8387:5522:b6ce:1c7a:811d] has quit [Ping timeout: 268 seconds]
21:26 < luke-jr> listunspent makes some sense for some sending use cases; I can't think of any time it'd be useful for receiving
21:29 < cryptocoder> wouldn’t they function similarly enough though?  unless you’re saying that by taking adv of the from+count you get a simpler result set to check against?
21:29 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
21:31 < luke-jr> cryptocoder: not really, no
21:31 < luke-jr> listunspent lists UTXOs, which are unrelated to receiving
21:33 < cryptocoder> oh, I see your point. I get what you mean
21:33 -!- fkhan [weechat@gateway/vpn/mullvad/x-vprqvrwqgiypphjo] has quit [Ping timeout: 250 seconds]
21:50 -!- fkhan [weechat@gateway/vpn/mullvad/x-rhlvsadwfqbvjylk] has joined #bitcoin-core-dev
21:52 -!- droark [~droark@50-202-247-126-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
21:52 -!- droark [~droark@50-202-247-126-static.hfc.comcastbusiness.net] has quit [Client Quit]
21:55 < phantomcircuit> i was going to ask why CDataStream takes a signed integer and then asserts that it's >=0
21:55 < phantomcircuit> but then
21:55 < phantomcircuit> 0a61b0df serialize.h     (s_nakamoto               2010-08-29 16:58:15 +0000 243)         assert(nSize >= 0);
21:55 < phantomcircuit> i guess i'm not going to be asking that
22:01 < luke-jr> XD
22:09 < GitHub66> [bitcoin] luke-jr opened pull request #7935: Versionbits: GBT support (master...gbt_bip9) https://github.com/bitcoin/bitcoin/pull/7935
22:14  * midnightmagic shrugs.
22:14 < midnightmagic> listunspent output requires the least amount of work on my part to build a tx programmatically.
22:15 < midnightmagic> if someone wants to try to involve me in a multisig without my knowledge, they're gonna be waiting a long time for any participation from me.
22:16 < luke-jr> midnightmagic: building a tx = sending :p
22:16 < luke-jr> midnightmagic: also, have you seen fundrawtransaction?
22:16 < midnightmagic> hrm
22:18 < midnightmagic> I think someone pointed me at that before. manual selection of inputs is definitely annoying. :)
22:18 < midnightmagic> ooo look at that it does the change output thing automatically
22:18 < luke-jr> midnightmagic: the GUI for manual input selection is fairly nice too FWIW :P
22:19 < midnightmagic> <3
22:19 < luke-jr> but no way to do complex use cases (multisig, etc) with it
22:40 < luke-jr> versionbits.cpp:11:9: error: expected primary-expression before ‘.’ token
22:40 < luke-jr> why is Travis whining at that PR? :/
22:40  * luke-jr wonders if he is accidentally C++11ing
22:55 < paveljanik> looks so ;-)
22:56 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
22:56 < luke-jr> annoying C++ :P
23:00 -!- dermoth [~thomas@66.36.157.105] has quit [Read error: Connection reset by peer]
23:01 -!- dermoth [~thomas@dsl-66-36-157-105.mtl.aei.ca] has joined #bitcoin-core-dev
23:01 < midnightmagic> :)
23:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-uzgrvgsiwgipcarf] has joined #bitcoin-core-dev
23:19 -!- earlest [~denetrabu@96.93.57.150] has quit [Ping timeout: 268 seconds]
23:20 -!- muuqwaul [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
23:28 -!- muuqwaul [~denetrabu@96.93.57.150] has quit [Ping timeout: 260 seconds]
23:30 -!- muuqwaul [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev