1 2016-04-25 00:23:19	0|NotAnNSAgent|Sooooooo...
  2 2016-04-25 00:23:52	0|NotAnNSAgent|I have to have two separate 75 GB blockchains and separate bitcoind daemons running just to have two accounts.
  3 2016-04-25 00:24:01	0|NotAnNSAgent|Yes, I know what you said about pruning, but remember the circumstances.
  4 2016-04-25 00:24:53	0|NotAnNSAgent|Out of curiosity, what was the thinking with the "accounts" that exist and are being killed off now?
  5 2016-04-25 00:25:28	0|NotAnNSAgent|To me, it just seems bizarre that if you have not enough money in an "account", it will take money from other "accounts".
  6 2016-04-25 00:25:49	0|NotAnNSAgent|Unless you assume that the wallet is literally a wallet and the "accounts" are like... separate credit cards inside the physical wallet.
  7 2016-04-25 00:26:18	0|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".
  8 2016-04-25 00:26:33	0|NotAnNSAgent|Then, "accounts" would make far more sense.
  9 2016-04-25 00:27:28	0|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).
 10 2016-04-25 00:27:35	0|NotAnNSAgent|Do you understand what I mean?
 11 2016-04-25 00:28:10	0|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)
 12 2016-04-25 00:28:51	0|NotAnNSAgent|phantomcircuit: I don't know if you have followed the conversation, but I know that the accounts are deprecated since a long time.
 13 2016-04-25 00:29:14	0|NotAnNSAgent|phantomcircuit: I'm trying to discuss the concept of "accounts" in Bitcoin and why they were made the way they were.
 14 2016-04-25 00:29:37	0|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).
 15 2016-04-25 00:30:03	0|phantomcircuit|NotAnNSAgent, the "accounts" functionality is an attempt to bring standard accounting practices to the reference wallet
 16 2016-04-25 00:30:33	0|phantomcircuit|it falls well short of accomplishing this
 17 2016-04-25 00:30:34	0|NotAnNSAgent|phantomcircuit: It's standard accounting practice to take money from other accounts if the account that's transferring money doesn't have enough?
 18 2016-04-25 00:31:07	0|phantomcircuit|NotAnNSAgent, the "accounts" stuff is completely separate from handling of bitcoin transactions
 19 2016-04-25 00:31:23	0|phantomcircuit|except that when you receive a payment it will correctly generate the accounting entry for that
 20 2016-04-25 00:31:35	0|NotAnNSAgent|...
 21 2016-04-25 00:31:58	0|phantomcircuit|yes i agree it's not ideal and definitely confusing
 22 2016-04-25 00:32:03	0|NotAnNSAgent|Why didn't Bitcoin support multiple "wallets" right away? I have no idea what you mean that "accounts" are supposed to be, still.
 23 2016-04-25 00:32:07	0|phantomcircuit|it's much less confusing if you just ignore the accounts stuff
 24 2016-04-25 00:32:33	0|NotAnNSAgent|I have to ignore the accounts stuff, because I learned it's practically removed from the Bitcoin software.
 25 2016-04-25 00:32:48	0|NotAnNSAgent|(Without the manual being updated to reflect this)
 26 2016-04-25 00:33:18	0|phantomcircuit|NotAnNSAgent, in bitcoin terms a "wallet" is just a collection of private keys and the transactions related to those keys in the blockchain
 27 2016-04-25 00:33:34	0|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?
 28 2016-04-25 00:33:39	0|phantomcircuit|NotAnNSAgent, it's in the documentation that the accounts are deprecated
 29 2016-04-25 00:33:59	0|phantomcircuit|NotAnNSAgent, why do you want multiple wallets?
 30 2016-04-25 00:34:02	0|NotAnNSAgent|phantomcircuit: https://bitcoin.org/en/developer-reference#sendfrom
 31 2016-04-25 00:34:31	0|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.
 32 2016-04-25 00:35:12	0|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.
 33 2016-04-25 00:36:08	0|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.
 34 2016-04-25 00:37:11	0|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
 35 2016-04-25 00:37:24	0|phantomcircuit|oh we're in the wrong channel for this conversation
 36 2016-04-25 00:38:56	0|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.
 37 2016-04-25 00:39:00	0|NotAnNSAgent|I can't join that channel.
 38 2016-04-25 00:39:16	0|NotAnNSAgent|luke-jr: I thought that was the point of the example one of you showed me earlier.
 39 2016-04-25 00:39:58	0|luke-jr|phantomcircuit: the bitcoind concept of accounts is pretty ideal, even if poorly implemented
 40 2016-04-25 00:40:45	0|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
 41 2016-04-25 00:41:03	0|luke-jr|phantomcircuit: that's what accounts did :P
 42 2016-04-25 00:41:22	0|phantomcircuit|luke-jr, yeah... but poorly
 43 2016-04-25 00:43:08	0|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.
 44 2016-04-25 00:43:35	0|NotAnNSAgent|Then, when a payment is made to one of those receive addresses, my script checks all the unchecked txids.
 45 2016-04-25 00:43:42	0|NotAnNSAgent|And then checks what their "account" is to decide what to do.
 46 2016-04-25 00:44:25	0|luke-jr|so you just need to skip the account stuff
 47 2016-04-25 00:44:31	0|NotAnNSAgent|?
 48 2016-04-25 00:44:35	0|luke-jr|keep track of that in your main server
 49 2016-04-25 00:44:40	0|phantomcircuit|NotAnNSAgent, in the database on your main server you're already associating an address with the invoice, correct?
 50 2016-04-25 00:45:02	0|phantomcircuit|then you already have all the information you need to do this without the accounts stuff
 51 2016-04-25 00:45:05	0|NotAnNSAgent|No... I just store them in a very simple table and pick one to show the user (and then deletes it).
 52 2016-04-25 00:45:13	0|phantomcircuit|oh
 53 2016-04-25 00:45:16	0|phantomcircuit|dont do that
 54 2016-04-25 00:45:34	0|phantomcircuit|associate the address with an invoice
 55 2016-04-25 00:45:59	0|phantomcircuit|then check for payments by calling "listtransactions" and looking at the address field
 56 2016-04-25 00:46:24	0|NotAnNSAgent|The bitcoind is on a separate server, as mentioned. It has no such database in it.
 57 2016-04-25 00:46:36	0|luke-jr|…
 58 2016-04-25 00:46:47	0|luke-jr|if you don't know which invoice is paid, what happens when someone doesn't pay?
 59 2016-04-25 00:46:49	0|NotAnNSAgent|It doesn't know what to do with the txid.
 60 2016-04-25 00:50:54	0|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.
 61 2016-04-25 00:50:54	0|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
 62 2016-04-25 00:51:05	0|NotAnNSAgent|If I can't have accounts, there is no longer any "label".
 63 2016-04-25 00:51:24	0|NotAnNSAgent|So the walletnotify/hourly script has no way to know what to do with the txid.
 64 2016-04-25 00:52:43	0|NotAnNSAgent|Unless there is indeed a "label" I can use instead? Like the labels in the graphical client.
 65 2016-04-25 00:52:56	0|NotAnNSAgent|But in that case, why also have "accounts"?
 66 2016-04-25 01:26:14	0|luke-jr|accounts tracked a balance
 67 2016-04-25 01:26:27	0|luke-jr|labels *should* be usable in bitcoind, but not fully yet IIRC
 68 2016-04-25 01:26:31	0|luke-jr|but for receiving, it should work
 69 2016-04-25 01:27:32	0|phantomcircuit|luke-jr, i wouldn't use labels either just because it's essentially impossible to do backups in a sane way
 70 2016-04-25 01:28:02	0|phantomcircuit|NotAnNSAgent, do you already generate invoices on the www server?
 71 2016-04-25 01:31:17	0|NotAnNSAgent|phantomcircuit: I have no concept of invoices.
 72 2016-04-25 01:31:36	0|NotAnNSAgent|But that's a detail that can be fleshed out later.
 73 2016-04-25 01:31:43	0|phantomcircuit|NotAnNSAgent, then how do you expect to keep track of what a payment was for?
 74 2016-04-25 01:31:47	0|NotAnNSAgent|I can store user id, amount, txid.
 75 2016-04-25 01:31:53	0|NotAnNSAgent|It's simply not relevant to this problem.
 76 2016-04-25 01:32:15	0|NotAnNSAgent|Can I set an arbitrary property of my own?
 77 2016-04-25 01:32:35	0|NotAnNSAgent|Some sort of label/data?
 78 2016-04-25 01:32:56	0|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.
 79 2016-04-25 01:33:11	0|NotAnNSAgent|And I was looking at ancient documentation for the duration of my implementation up until today.
 80 2016-04-25 01:37:18	0|luke-jr|NotAnNSAgent: as I said, you can set labels for receiving. the backup issue will apply no matter what you do
 81 2016-04-25 01:37:45	0|luke-jr|NotAnNSAgent: and, invoices are relevant, since two orders may have the same amount
 82 2016-04-25 01:38:02	0|luke-jr|and Bitcoin has no concept of users
 83 2016-04-25 01:41:28	0|NotAnNSAgent|I still don't get what you are talking about in terms of backups.
 84 2016-04-25 01:42:50	0|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.
 85 2016-04-25 01:43:16	0|NotAnNSAgent|Why isn't that in every example and the first thing you see?
 86 2016-04-25 01:43:32	0|NotAnNSAgent|And how do I actually set and get it?
 87 2016-04-25 01:43:45	0|luke-jr|NotAnNSAgent: we're saying you need to label each address individually to know what purchase it's used for
 88 2016-04-25 01:43:51	0|NotAnNSAgent|..............
 89 2016-04-25 01:44:04	0|luke-jr|that's how bitcoin works
 90 2016-04-25 01:44:08	0|NotAnNSAgent|This has NOTHING to do with the product bought.
 91 2016-04-25 01:44:13	0|NotAnNSAgent|I'm talking about the BITCOIND.
 92 2016-04-25 01:44:16	0|NotAnNSAgent|Not the WWW server.
 93 2016-04-25 01:44:24	0|luke-jr|you don't need it in more than one place
 94 2016-04-25 01:44:28	0|NotAnNSAgent|...
 95 2016-04-25 01:44:43	0|NotAnNSAgent|I give up. You won't read anything I type, so it's meaningless to attempt to ask this basic question.
 96 2016-04-25 01:47:40	0|midnightmagic|This isn't really the place to ask user questions about bitcoind dude.
 97 2016-04-25 01:47:58	0|midnightmagic|It would be like going into the engineering department of a commercial software house and asking support questions.
 98 2016-04-25 01:48:16	0|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.
 99 2016-04-25 01:48:17	0|midnightmagic|.. by grabbing the ear of literally the first engineer who's sitting there staring at a wall of text, that you see.
100 2016-04-25 01:50:04	0|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
101 2016-04-25 01:50:10	0|gmaxwell|ou'll have to take some time to understand the behavior lest you confuse yourself with get balance calls.
102 2016-04-25 01:52:25	0|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
103 2016-04-25 01:52:31	0|gmaxwell|ame in bitcoind, though you can if you want.
104 2016-04-25 01:55:51	0|midnightmagic|+1 external address-to-user matching via listunspent queries or equivalent.
105 2016-04-25 02:03:49	0|NotAnNSAgent|This just keeps on getting more and more complicated.
106 2016-04-25 02:04:16	0|NotAnNSAgent|Also, Bitcoin Core is bitcoind, no?
107 2016-04-25 02:04:31	0|NotAnNSAgent|(Except it also has a GUI client)
108 2016-04-25 02:07:00	0|belcher|the gui client is generally called bitcoin-qt, bitcoin core is the project that includes both of those
109 2016-04-25 02:07:46	0|NotAnNSAgent|I really don't know what to do.
110 2016-04-25 02:09:01	0|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.
111 2016-04-25 02:09:37	0|luke-jr|midnightmagic: listtransactions or listreceived :x
112 2016-04-25 02:09:50	0|luke-jr|midnightmagic: listunspent is wallet internals; not something normal users should need ever
113 2016-04-25 02:10:33	0|luke-jr|NotAnNSAgent: you can expect many people will "give up" helping when you ignore the advice you're given.
114 2016-04-25 02:12:01	0|NotAnNSAgent|You are the one who ignored what I said, but sure.
115 2016-04-25 02:12:11	0|phantomcircuit|NotAnNSAgent, i already told you
116 2016-04-25 02:12:22	0|NotAnNSAgent|You make about as much sense as the Bitcoin API.
117 2016-04-25 02:12:22	0|phantomcircuit|you want to assign an address to an invoice
118 2016-04-25 02:12:26	0|phantomcircuit|that's it
119 2016-04-25 02:35:34	0|phantomcircuit|horray
120 2016-04-25 04:05:12	0|midnightmagic|you think so?
121 2016-04-25 04:20:44	0|phantomcircuit|im thinking we shouldn't have "assert" in serialization code
122 2016-04-25 04:20:56	0|phantomcircuit|only for maintaining invariants of things in memory
123 2016-04-25 04:22:34	0|cryptocoder|luke-jr, phantomcircuit: saw your comments earlier about using “listtransactions” instead of “listunspent”. wouldn’t the latter make more sense?
124 2016-04-25 04:23:03	0|luke-jr|cryptocoder: no, listunspent makes no sense in that context since it deals with UTXOs and not addresses
125 2016-04-25 04:24:28	0|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
126 2016-04-25 04:24:56	0|luke-jr|ah
127 2016-04-25 04:25:04	0|luke-jr|yeah, right tool for the right job kind of thing
128 2016-04-25 04:26:19	0|luke-jr|listunspent makes some sense for some sending use cases; I can't think of any time it'd be useful for receiving
129 2016-04-25 04:29:15	0|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?
130 2016-04-25 04:31:21	0|luke-jr|cryptocoder: not really, no
131 2016-04-25 04:31:35	0|luke-jr|listunspent lists UTXOs, which are unrelated to receiving
132 2016-04-25 04:32:50	0|cryptocoder|oh, I see your point. I get what you mean
133 2016-04-25 04:55:21	0|phantomcircuit|i was going to ask why CDataStream takes a signed integer and then asserts that it's >=0
134 2016-04-25 04:55:22	0|phantomcircuit|but then
135 2016-04-25 04:55:23	0|phantomcircuit|0a61b0df serialize.h     (s_nakamoto               2010-08-29 16:58:15 +0000 243)         assert(nSize >= 0);
136 2016-04-25 04:55:31	0|phantomcircuit|i guess i'm not going to be asking that
137 2016-04-25 05:01:25	0|luke-jr|XD
138 2016-04-25 05:09:33	0|GitHub66|[13bitcoin] 15luke-jr opened pull request #7935: Versionbits: GBT support (06master...06gbt_bip9) 02https://github.com/bitcoin/bitcoin/pull/7935
139 2016-04-25 05:14:35	0|midnightmagic|listunspent output requires the least amount of work on my part to build a tx programmatically.
140 2016-04-25 05:15:13	0|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.
141 2016-04-25 05:15:59	0|luke-jr|midnightmagic: building a tx = sending :p
142 2016-04-25 05:16:14	0|luke-jr|midnightmagic: also, have you seen fundrawtransaction?
143 2016-04-25 05:16:24	0|midnightmagic|hrm
144 2016-04-25 05:17:55	0|midnightmagic|I think someone pointed me at that before. manual selection of inputs is definitely annoying. :)
145 2016-04-25 05:18:36	0|midnightmagic|ooo look at that it does the change output thing automatically
146 2016-04-25 05:18:38	0|luke-jr|midnightmagic: the GUI for manual input selection is fairly nice too FWIW :P
147 2016-04-25 05:18:40	0|midnightmagic|<3
148 2016-04-25 05:19:02	0|luke-jr|but no way to do complex use cases (multisig, etc) with it
149 2016-04-25 05:39:55	0|luke-jr|versionbits.cpp:11:9: error: expected primary-expression before ‘.’ token
150 2016-04-25 05:40:01	0|luke-jr|why is Travis whining at that PR? :/
151 2016-04-25 05:55:19	0|paveljanik|looks so ;-)
152 2016-04-25 05:56:17	0|luke-jr|annoying C++ :P
153 2016-04-25 06:01:14	0|midnightmagic|:)
154 2016-04-25 07:12:05	0|GitHub136|[13bitcoin] 15pstratem opened pull request #7936: CDataStream::ignore Throw exception instead of assert on negative nSize. (06master...062016-04-24-cdatastream-ignore) 02https://github.com/bitcoin/bitcoin/pull/7936
155 2016-04-25 07:15:52	0|phantomcircuit|luke-jr, -Wall -pedantic will tell you if you're using c++11 isms
156 2016-04-25 07:15:54	0|phantomcircuit|(sometimes)
157 2016-04-25 07:16:06	0|phantomcircuit|it'll also complain about lots of random irrelevant stuff
158 2016-04-25 07:18:54	0|gmaxwell|libsecp256k1 builds completely clean with -Wall -Wextra -std=c89 -pedantic (plus a few more warning flags that aren't turned on by extra). (well, excepting the -Wno-long-long is used so it doesn't whine about use of long long, -Wno-unused-function because pieter didn't like me peppering the code with ifdefs to kill the last unused functions in some builds, and -Wno-overlength-strings to work aro
159 2016-04-25 07:19:00	0|gmaxwell|und a clang bug)
160 2016-04-25 08:32:35	0|wumpus|speaking of c++11, it's Monday, any news from Travis cfields?
161 2016-04-25 08:33:00	0|wumpus|sorry for the impatience <:
162 2016-04-25 08:59:53	0|phantomcircuit|gmaxwell, afl-cmin -C isn't finding any crashes but afl-fuzz reports them in the curses ui
163 2016-04-25 08:59:55	0|phantomcircuit|thoughts?
164 2016-04-25 09:03:06	0|sipa|wumpus: at least wait until the business day is over :)
165 2016-04-25 09:03:24	0|sipa|wumpus: seems travis is baser on germany, so we don't need to wait another 9 hours
166 2016-04-25 09:03:55	0|luke-jr|phantomcircuit: https://www.youtube.com/watch?v=XGM6sHIJuho
167 2016-04-25 09:04:23	0|phantomcircuit|luke-jr, something something florida man?
168 2016-04-25 09:27:47	0|btcdrak|wumpus: it's still not Monday in some parts of the world yet .-.
169 2016-04-25 09:28:57	0|phantomcircuit|btcdrak, it's technically monday where cfields is
170 2016-04-25 09:29:02	0|phantomcircuit|but only in a very technical sense
171 2016-04-25 09:34:47	0|sipa|phantomcircuit: correct, but utterly irrelevant
172 2016-04-25 09:35:05	0|sipa|as the monday eta was given by travis, not cory :)
173 2016-04-25 09:38:33	0|phantomcircuit|oh
174 2016-04-25 09:47:22	0|GitHub179|[13bitcoin] 15laanwj closed pull request #6821: Avoid duplicate getheaders requests (06master...06no-duplicate-getheaders) 02https://github.com/bitcoin/bitcoin/pull/6821
175 2016-04-25 10:46:55	0|GitHub121|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f604bf63211f...f9c2ac72327e
176 2016-04-25 10:46:56	0|GitHub121|13bitcoin/06master 1474f7b12 15Wladimir J. van der Laan: dbwrapper: Remove throw keywords in function signatures...
177 2016-04-25 10:46:56	0|GitHub121|13bitcoin/06master 14878bf48 15Wladimir J. van der Laan: dbwrapper: Remove CDBWrapper::GetObfuscateKeyHex...
178 2016-04-25 10:46:58	0|GitHub121|13bitcoin/06master 14b69836d 15Wladimir J. van der Laan: dbwrapper: Pass parent CDBWrapper into CDBBatch and CDBIterator...
179 2016-04-25 10:47:06	0|GitHub160|[13bitcoin] 15laanwj closed pull request #7927: Minor changes to dbwrapper to simplify support for other databases (06master...062016_04_dbwrapper_modernization) 02https://github.com/bitcoin/bitcoin/pull/7927
180 2016-04-25 11:31:41	0|GitHub158|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f9c2ac72327e...c4e8390047a1
181 2016-04-25 11:31:42	0|GitHub158|13bitcoin/06master 14182bec4 15Wladimir J. van der Laan: contrib: remove hardcoded version from verify.sh...
182 2016-04-25 11:31:42	0|GitHub158|13bitcoin/06master 14c907f4d 15Wladimir J. van der Laan: doc: Update release process...
183 2016-04-25 11:31:43	0|GitHub158|13bitcoin/06master 14f154470 15MarcoFalke: [contrib] Remove reference to sf and add doc to verify.sh
184 2016-04-25 11:31:49	0|GitHub161|[13bitcoin] 15laanwj closed pull request #7881: Update release process (06master...062016_04_update_release_process) 02https://github.com/bitcoin/bitcoin/pull/7881
185 2016-04-25 11:49:47	0|NotAnNSAgent|This is obviously going to offend you, but I have to ask... Is the not only poor, but grossly *misleading* documentation deliberately so? I mean, maybe you don't want Bitcoin to be easy to implement to ensure job security or something? I've seriously begun asking myself if that could be the case. Again, though, I understand that this is both very difficult stuff, and you can't change things directly as individuals without first talking
186 2016-04-25 11:49:47	0|NotAnNSAgent|to a bunch of people, but still. The documentation just seems... nonexistent in practice?
187 2016-04-25 11:50:46	0|NotAnNSAgent|(It's worth adding that I feel the same thing about Let's Encrypt and many other projects.)
188 2016-04-25 11:51:11	0|NotAnNSAgent|I eventually figured out how to use LE, though.
189 2016-04-25 11:51:29	0|wumpus|have you seen https://bitcoin.org/en/developer-documentation ? I think it's pretty okay
190 2016-04-25 11:51:59	0|wumpus|note that no one is being paid to write documentation, so if you want to spend time contributing on improving the documenttion you're very welcome
191 2016-04-25 11:52:42	0|wumpus|if not I suggest you leave, this is an open source project, there is no customer support and complaining won't get you anywhere
192 2016-04-25 11:56:02	0|assder|This looks very good for those wanting to start developing: https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_1):_Overview. Haven't checked it out in depth myself.
193 2016-04-25 11:57:39	0|wumpus|interesting
194 2016-04-25 11:58:35	0|assder|wumpus: Is there a big difference in the architecture of Core between 0.11 and 0.12, such that one should wait until that gets updated to start studying it?
195 2016-04-25 11:58:52	0|wumpus|assder: no, it's still the same on a high level
196 2016-04-25 12:01:44	0|wumpus|the P2P code and initialization didn't change much since then
197 2016-04-25 12:02:17	0|wumpus|the RPC server changed quite a lot from 0.11 to master (e.g. switching from boost::asio to libevent, amongst other things) but I see that page isn't even there
198 2016-04-25 12:06:02	0|NotAnNSAgent|wumpus: I'm talking about the API to talk to bitcoind. Which seems to be explained (messily) at https://bitcoin.org/en/developer-reference#bitcoin-core-apis , but that documentation is full of dangerously outdated information.
199 2016-04-25 12:06:14	0|NotAnNSAgent|And has "not been reviewed by Bitcoin developers", which makes no sense to me.
200 2016-04-25 12:06:18	0|instagibbs|NotAnNSAgent, bitcoin-cli help ?
201 2016-04-25 12:06:27	0|wumpus|NotAnNSAgent: the best documentation for the API is in bitcoind itself, using bitcoin-cli help
202 2016-04-25 12:06:30	0|wumpus|right, as instagibbs says
203 2016-04-25 12:06:43	0|NotAnNSAgent|That is the same as sending "help" as an RPC call, right?
204 2016-04-25 12:06:49	0|NotAnNSAgent|(I don't have bitcoin-cli binary)
205 2016-04-25 12:07:06	0|wumpus|yes, help with an optional method name
206 2016-04-25 12:07:31	0|wumpus|how do you manage to not get the bitcoin-cli binary?
207 2016-04-25 12:09:41	0|da2ce7_mobile|hello, I wish to copy the blocks from one PC to another, what is the minimum I need to copy? It If I just copy the blk0xxx files it overwrites the files.  If I include the rev00xxx files bitcoin throws an assertion. I suppose it has something to do with the chainstate obfuscation.
208 2016-04-25 12:10:07	0|da2ce7_mobile|I'm using Bitcoin 0.12.1
209 2016-04-25 12:10:27	0|wumpus|you want to copy just the block data or also the databases?
210 2016-04-25 12:10:42	0|wumpus|the minimum is copying just blk*.dat then running -reindex
211 2016-04-25 12:10:56	0|wumpus|the other option is to copy blocks/ and chainstate/ entirely
212 2016-04-25 12:11:15	0|sipa|or either of them separately, as long as the result is a chainstate/ that is not ahead of blocks/
213 2016-04-25 12:11:18	0|wumpus|which will be faster as you don't need a reindex. Be sure to do that while bitcoind is not running.
214 2016-04-25 12:11:37	0|da2ce7_mobile|ahh. so it won't automatically detect without -reindex.
215 2016-04-25 12:11:38	0|da2ce7_mobile|ok.
216 2016-04-25 12:11:43	0|sipa|it will
217 2016-04-25 12:11:51	0|sipa|you can copy the blocks, and delete the chainstate
218 2016-04-25 12:11:59	0|sipa|in which case it will rebuild it
219 2016-04-25 12:12:10	0|sipa|(though due to a bug, that's currently much slower than just reindexing)
220 2016-04-25 12:12:53	0|da2ce7_mobile|I will try again, I was seeing a different result.
221 2016-04-25 12:13:35	0|wumpus|don't include the revXXXX files if you don't copy the chainstate though, they're undo files for the chainstate and have no use without it
222 2016-04-25 12:16:15	0|da2ce7_mobile|Ok, I have just the blkXXX files, and a wallet.dat file. Will load bitcoin.
223 2016-04-25 12:16:26	0|wumpus|(although I don't understand why you'd get an assertion error, they should just be ignored on reindex)
224 2016-04-25 12:16:34	0|sipa|best is to start with -reindex in that case
225 2016-04-25 12:16:55	0|sipa|it will only work without -reindex if you also have blocks/index/ already
226 2016-04-25 12:17:09	0|da2ce7_mobile|ahh ok.
227 2016-04-25 12:17:15	0|da2ce7_mobile|that explains the result.
228 2016-04-25 12:17:19	0|sipa|blocks/ > blocks/index/ > chainstate/
229 2016-04-25 12:17:30	0|sipa|(> meaning 'must be ahead of')
230 2016-04-25 12:17:36	0|sipa|i guess >= is a better symbol
231 2016-04-25 12:17:51	0|wumpus|right
232 2016-04-25 12:19:04	0|da2ce7_mobile|ok. I get the expected result now "reindexing blocks on disk"; thank! :)
233 2016-04-25 12:19:51	0|GitHub61|[13bitcoin] 15laanwj closed pull request #7792: depends: mac deploy Py3 compatibility (fixes macosx gitian build) (06master...062016_04_fix_macosx_gitian) 02https://github.com/bitcoin/bitcoin/pull/7792
234 2016-04-25 12:26:21	0|NotAnNSAgent|Okay, so at least the "help blabla" stuff mentions "DEPRECATED" in the output, but it still lists <account> and all that.
235 2016-04-25 12:26:47	0|NotAnNSAgent|wumpus: I manage to not get the bitcoin-cli binary because I only installed bitcoin-daemon because why would I want the -cli thing?
236 2016-04-25 12:27:20	0|NotAnNSAgent|I searched the online manual for "label", but found no way to set/get this. How is it set/get?
237 2016-04-25 12:27:37	0|wumpus|you still have to use the account API for that right now
238 2016-04-25 12:27:42	0|NotAnNSAgent|That is, any label I need for my own reference to know which "account" (not the deprecated Bitcoin concept of "accounts") it belongs to.
239 2016-04-25 12:28:27	0|wumpus|this is the label API that will replace it: https://github.com/bitcoin/bitcoin/pull/7729  ... note that this is mostly just a subset of the account functionality, the only thing that will disappear is the account balance
240 2016-04-25 12:28:28	0|NotAnNSAgent|wumpus: Are you saying that the "account" concept is deprecated and about to be removed, and the "label" concept is so new it's not implemented properly?
241 2016-04-25 12:28:53	0|wumpus|that's why it's deprecated, not removed
242 2016-04-25 12:29:12	0|NotAnNSAgent|So I have to use "account" for now, then closely follow the project and change my code when the service is actually in production to reflect the "label" concept?
243 2016-04-25 12:29:13	0|wumpus|feel free to help testing the label API pull request
244 2016-04-25 12:29:23	0|wumpus|in general there is very little interest in that part of the code, so any help is welcome
245 2016-04-25 12:29:24	0|NotAnNSAgent|Why not just keep the account concept, then?
246 2016-04-25 12:29:36	0|wumpus|because it is broken in multiple ways
247 2016-04-25 12:29:48	0|NotAnNSAgent|There is very little interest in making it possible to have any idea who owns a given address in a "Bitcoin bank" (wallet)?
248 2016-04-25 12:29:50	0|wumpus|I suggest you read https://github.com/bitcoin/bitcoin/issues/3816
249 2016-04-25 12:30:41	0|wumpus|no, using accounts to group addresses is fine, but the account balance functionality (as well as the 'move' call) will be removed
250 2016-04-25 12:31:10	0|NotAnNSAgent|Confusing part: "Users are used to seemingly-odd practices of transferring imaginary money from a dummy account, to eliminate a negative number in some cases."
251 2016-04-25 12:31:19	0|NotAnNSAgent|Hmm.
252 2016-04-25 12:31:39	0|NotAnNSAgent|wumpus: Where were you yesterday? :O)
253 2016-04-25 12:32:14	0|wumpus|I expect the account calls, even after adding the label API and remvoing account balances, will be kept as aliases for the *label* RPCs for backwards compatiblity for some time
254 2016-04-25 12:32:24	0|wumpus|on sunday?
255 2016-04-25 12:32:38	0|NotAnNSAgent|wumpus: When you say it's "fine" to use accounts to "group" addresses, are you saying that it will be easy for me to just change some string later when the accounts are removed, or that the syntax will be kept (but not documented/encouraged) in the future, allowing me to keep running it like that?
256 2016-04-25 12:32:39	0|wumpus|well, doing other stuff at least :p
257 2016-04-25 12:32:53	0|wumpus|NotAnNSAgent: probably.
258 2016-04-25 12:33:14	0|NotAnNSAgent|Quite a bit, actually.
259 2016-04-25 12:33:17	0|wumpus|NotAnNSAgent: there are no guarantees for anything in the future, especially not regarding thewallet, and for every *major* release you should read the release notes carefully
260 2016-04-25 12:33:47	0|NotAnNSAgent|Yes, but how many people actually do that? It's like reading EULAs.
261 2016-04-25 12:34:00	0|wumpus|bitcoin core is not something you should upgrade without paying attention, especially if you use it in production and there's actual money involved
262 2016-04-25 12:34:11	0|sipa|NotAnNSAgent: if you're running your bank using, i think it may make sense to actually do it
263 2016-04-25 12:34:15	0|NotAnNSAgent|I didn't even read the entire PHP 7 announcement, even though I'm heavily invested in PHP and the change from 5.6 to 7 felt like a major surgery.
264 2016-04-25 12:34:45	0|NotAnNSAgent|Hmm. I guess.
265 2016-04-25 12:35:02	0|sipa|NotAnNSAgent: we also maintain bugfixes for the previous major release, and critical bugfixes for the one before
266 2016-04-25 12:35:17	0|sipa|so it's not like an API change will hit you without resort
267 2016-04-25 12:35:48	0|wumpus|you're taking a risk by not doing so, you can decide for yourself whether it's acceptable, but most serious companies have careful upgrade practices (like running parallel servers with a new version for a while) for anything that directly affects their bottom line
268 2016-04-25 12:36:15	0|NotAnNSAgent|Backwards compatibility should be of utmost importance in this context, though.
269 2016-04-25 12:36:30	0|wumpus|backwards priority is a concern, but you don't decide our priorities, sorry
270 2016-04-25 12:36:44	0|wumpus|compatibility*
271 2016-04-25 12:36:47	0|sipa|NotAnNSAgent: that's why accounts haven't been removed outright, and there is a long discussion going on about it
272 2016-04-25 12:37:08	0|wumpus|right, they've been deprecated for ages, it's not as if it was removed from one version to the other
273 2016-04-25 12:37:23	0|wumpus|but the RPC API can change in non-backwards compatible ways between *major* releases
274 2016-04-25 12:38:19	0|sipa|also, i thought you had realized that accounts were not what you needed?
275 2016-04-25 12:46:55	0|GitHub91|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c4e8390047a1...46880ed2fd96
276 2016-04-25 12:46:56	0|GitHub91|13bitcoin/06master 1446880ed 15Wladimir J. van der Laan: Merge #7688: List solvability in listunspent output and improve help...
277 2016-04-25 12:46:56	0|GitHub91|13bitcoin/06master 14c3932b3 15Pieter Wuille: List solvability in listunspent output and improve help
278 2016-04-25 12:47:00	0|GitHub66|[13bitcoin] 15laanwj closed pull request #7688: List solvability in listunspent output and improve help (06master...06helpspendsolv) 02https://github.com/bitcoin/bitcoin/pull/7688
279 2016-04-25 12:48:26	0|MarcoFalke|wumpus, I think it makes sense to merge https://github.com/bitcoin/bitcoin/pull/7811#issuecomment-212380135 now
280 2016-04-25 12:49:04	0|wumpus|MarcoFalke: ok, go ahead :)
281 2016-04-25 12:54:40	0|phantomcircuit|NotAnNSAgent, you've been unbanned from #bitcoin please move your discussion there
282 2016-04-25 13:00:17	0|GitHub46|[13bitcoin] 15MarcoFalke closed pull request #7811: [0.12.2] qa Backports (060.12...06Mf1604-qa012) 02https://github.com/bitcoin/bitcoin/pull/7811
283 2016-04-25 13:00:20	0|GitHub133|[13bitcoin] 15MarcoFalke pushed 12 new commits to 060.12: 02https://github.com/bitcoin/bitcoin/compare/9779e1e1f320...89ae85484c8b
284 2016-04-25 13:00:21	0|GitHub133|13bitcoin/060.12 14ad8c743 15MarcoFalke: [qa] Extend tests...
285 2016-04-25 13:00:21	0|GitHub133|13bitcoin/060.12 14d89fbfe 15MarcoFalke: [qa] rpc-test: Normalize assert()...
286 2016-04-25 13:00:22	0|GitHub133|13bitcoin/060.12 146aae129 15MarcoFalke: [qa] wallet: Print maintenance...
287 2016-04-25 13:33:03	0|Chris_Stewart_5|Why does the public key in this test case fail? http://pastebin.com/eR9ZHyRF
288 2016-04-25 13:33:22	0|Chris_Stewart_5|Is it becuse it is not properly encoded as per https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L202
289 2016-04-25 13:37:26	0|NotAnNSAgent|Alright.
290 2016-04-25 13:37:28	0|jl2012|the public key is 0
291 2016-04-25 13:38:43	0|Chris_Stewart_5|is the 'first public key is invalid' i'm guesing that refers to them being consumed off of the top of the stack?
292 2016-04-25 13:39:19	0|sipa|0 is a correctly-encoded but invalid public key
293 2016-04-25 13:39:26	0|NotAnNSAgent|Just one more note, since sipa isn't in ##bitcoin: yes, I learned what "accounts" actually are in Bitcoin, but I also learned that the labels stuff is not stable/finished either, and that I can use "accounts" as a form of label until things stabilize, but I cannot use them to segregate money in the way I first thought was possible.
294 2016-04-25 13:39:55	0|sipa|NotAnNSAgent: aye, indeed, thanks for clearing that up
295 2016-04-25 13:40:48	0|sipa|Chris_Stewart_5: as the checkmultisig requires 2 valid signatures, but it only gets one, the checkmultisig fails, the NOT after is inverts that result
296 2016-04-25 13:41:36	0|Chris_Stewart_5|sipa: That seems to directly contradict the comments  "2-of-2 CHECKMULTISIG NOT with the first pubkey invalid, and both signatures validly encoded."
297 2016-04-25 13:42:16	0|sipa|seems correct to me
298 2016-04-25 13:42:38	0|Chris_Stewart_5|Also, how could 0 be a validly encoded public key, doesn't it trivially fail this https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L66
299 2016-04-25 13:43:34	0|sipa|Chris_Stewart_5: nope, https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L189
300 2016-04-25 13:43:49	0|sipa|eh, i'm confusing pubkeys with signatures
301 2016-04-25 13:43:53	0|sipa|let me re-read what you said
302 2016-04-25 13:43:54	0|Chris_Stewart_5|sipa: You said "requires 2 valid signatures, but only gets one" - the comment says "both signatures validly encoded". Are you talking about being the correct key?
303 2016-04-25 13:45:12	0|sipa|right... so there are 2 correctly-encoded signatures there, and a valid and an invalid pubkey
304 2016-04-25 13:45:30	0|sipa|pubkeys are not subject to any encoding rules
305 2016-04-25 13:45:58	0|sipa|(except when STRICTENC is on, but that's only for mempool validation, not in blocks)
306 2016-04-25 13:46:27	0|Chris_Stewart_5|So "CheckPubKeyEncoding" is a misnomer? :-)
307 2016-04-25 13:46:33	0|sipa|no
308 2016-04-25 13:46:43	0|sipa|it just only has an effect when STRICTENC is on
309 2016-04-25 13:48:05	0|Chris_Stewart_5|I don't think that is only relevant inside of the mempool - https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L940
310 2016-04-25 13:48:16	0|Chris_Stewart_5|But like you said, it would trivially pass if STRICTENC is not set
311 2016-04-25 13:49:18	0|sipa|STRICTENC is only set when inside the mempool
312 2016-04-25 13:49:24	0|sipa|we don't use two separate interpreters
313 2016-04-25 13:49:51	0|Chris_Stewart_5|Oh, interesting. Didn't realize that.
314 2016-04-25 13:50:25	0|sipa|it's even documented: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.h#L38
315 2016-04-25 13:50:34	0|sipa|not used or intended as a consensus rule
316 2016-04-25 13:51:08	0|sipa|DERSIG is a subset of STRICTENC, which is set when BIP66 is active
317 2016-04-25 13:51:29	0|Chris_Stewart_5|Is DERSIG
318 2016-04-25 13:53:23	0|Chris_Stewart_5|Interesting, I never really understood the difference between the two - or why we have two flags
319 2016-04-25 13:54:06	0|sipa|STRICTENC is much older, and is just policy to prevent stupid encodings of data
320 2016-04-25 13:54:21	0|sipa|but STRICTENC may not be something we want in consensus code, as it can change over time
321 2016-04-25 13:55:00	0|GitHub177|[13bitcoin] 15MarcoFalke opened pull request #7938: [0.12.2] Backports (060.12...06Mf1604-012backp) 02https://github.com/bitcoin/bitcoin/pull/7938
322 2016-04-25 13:55:07	0|Chris_Stewart_5|sipa: So is strictenc in a certain way part of relay policy? and just to be crystal clear, DERSIG is absolutely consensus critical correct?
323 2016-04-25 13:55:20	0|sipa|yes
324 2016-04-25 13:57:08	0|Chris_Stewart_5|Thanks :-)
325 2016-04-25 14:02:47	0|phantomcircuit|NotAnNSAgent, you've been unbanned from #bitcoin please move your discussion there
326 2016-04-25 14:05:20	0|GitHub25|[13bitcoin] 15laanwj opened pull request #7939: qt: Make it possible to show details for multiple transactions (06master...062016_04_qt_multiple_transaction_details) 02https://github.com/bitcoin/bitcoin/pull/7939
327 2016-04-25 14:58:27	0|NotAnNSAgent|phantomcircuit: Thanks. As mentioned, I only said that to sipa because he asked a question to me in here and he isn't in there.
328 2016-04-25 14:58:33	0|NotAnNSAgent|(Or wasn't when I sent the message.)
329 2016-04-25 15:16:48	0|arubi|why are the expansions of op_cltv and op_csv done in different ways in 'script.h'?  https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h#L165-L168
330 2016-04-25 15:22:34	0|GitHub117|[13bitcoin] 15pstratem opened pull request #7940: [WIP] Fuzzing framework (06master...062016-04-20-fuzzing-framework) 02https://github.com/bitcoin/bitcoin/pull/7940
331 2016-04-25 15:33:36	0|Chris_Stewart_5|arubi: Guessing it was just happen stance, I don't think there is any functional difference
332 2016-04-25 15:37:15	0|sipa|agree
333 2016-04-25 15:39:45	0|arubi|doesn't seem like there is, just wanted to make sure.  thanks.
334 2016-04-25 16:10:19	0|GitHub173|[13bitcoin] 15Christewart opened pull request #7941: Fixing comment in script_test.json test case (06master...06fix_script_test_comment) 02https://github.com/bitcoin/bitcoin/pull/7941
335 2016-04-25 21:09:57	0|kanzure|how often should testnet nodes be receiving pings?
336 2016-04-25 21:10:07	0|kanzure|er, from a well-behaving peer node
337 2016-04-25 21:57:47	0|Guest32930|kanzure: bitcoin core at most pings once per minute, i think
338 2016-04-25 21:58:11	0|kanzure|have a strange peer doing it once a second.. they seem really eager to know if this node vanishes.
339 2016-04-25 21:59:24	0|sipa_|kanzure: what is the user agent?
340 2016-04-25 21:59:47	0|kanzure|/bitcoinj:0.15-SNAPSHOT/
341 2016-04-25 22:05:43	0|sipa_|kanzure: i think bitcoinj has always had insane ping frequency
342 2016-04-25 22:05:59	0|kanzure|weird.
343 2016-04-25 22:06:02	0|kanzure|thanks.
344 2016-04-25 22:25:44	0|achow101|what does the hex of the version for the upcoming soft fork look like?
345 2016-04-25 22:27:22	0|sipa_|02000001
346 2016-04-25 22:29:17	0|achow101|thanks