1 2016-06-14 05:32:02	0|whu|Is there any plan to move from POW to POS for bitcoin ??
  2 2016-06-14 05:35:19	0|helo|by the mentally unsound, whu
  3 2016-06-14 05:36:35	0|whu|So you guys dont see any merit in it ?
  4 2016-06-14 05:37:23	0|helo|#bitcoin is better to discuss trivialities like this
  5 2016-06-14 05:37:51	0|helo|this channel is for nuts-and-bolts dev, not musings
  6 2016-06-14 05:39:22	0|whu|I wanted to know what the core devs thought of it. Could you give me a one line answer on whether it is on the pipeline and I'll vanish.
  7 2016-06-14 05:40:10	0|helo|whu: PoS has been considered as thoroughly and discarded
  8 2016-06-14 05:40:38	0|whu|Thank you...
  9 2016-06-14 06:33:09	0|GitHub116|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/be9711e59707...36b74002f840
 10 2016-06-14 06:33:10	0|GitHub116|13bitcoin/06master 14fa26c42 15MarcoFalke: [qa] util: Move check_fee_amount out of wallet.py
 11 2016-06-14 06:33:10	0|GitHub116|13bitcoin/06master 14fae1d06 15MarcoFalke: [qa] fundrawtransaction: Fix race, assert amounts
 12 2016-06-14 06:33:11	0|GitHub116|13bitcoin/06master 1436b7400 15Wladimir J. van der Laan: Merge #8201: [qa] fundrawtransaction: Fix race, assert amounts...
 13 2016-06-14 06:33:19	0|GitHub6|[13bitcoin] 15laanwj closed pull request #8201: [qa] fundrawtransaction: Fix race, assert amounts (06master...06Mf1606-qaFundraw) 02https://github.com/bitcoin/bitcoin/pull/8201
 14 2016-06-14 06:43:57	0|jonasschnelli|sipa... hm... testnet-seed.bitcoin.jonasschnelli.ch seems to run but doesn't return a result.
 15 2016-06-14 06:44:05	0|jonasschnelli|I'm running master with an old database...
 16 2016-06-14 06:44:13	0|jonasschnelli|I guess i need to delete the database.
 17 2016-06-14 06:44:21	0|jonasschnelli|Had to re-setup the server yesterday.
 18 2016-06-14 06:53:13	0|jonasschnelli|sipa: Okay. testnet-seed.bitcoin.jonasschnelli.ch is up and running again.
 19 2016-06-14 06:53:39	0|jonasschnelli|I missed to install tor (which I used to bypass the malware scanner from my server center operator)
 20 2016-06-14 06:55:21	0|GitHub151|[13bitcoin] 15jonasschnelli closed pull request #8200: [Tests] Fix fundrawtransaction feerate test (06master...062016/06/fix_frt_test) 02https://github.com/bitcoin/bitcoin/pull/8200
 21 2016-06-14 07:02:09	0|jonasschnelli|wumpus: windows gitian builds still broken? https://bitcoin.jonasschnelli.ch/nightlybuilds/2016-06-14/build-win.log (check bottom)
 22 2016-06-14 07:02:20	0|jonasschnelli|checking whether the C++ compiler works... no
 23 2016-06-14 07:08:02	0|GitHub28|13bitcoin/06master 1401a9904 15fanquake: [trivial] Ignore split-debug.sh
 24 2016-06-14 07:08:02	0|GitHub28|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/36b74002f840...8c1d5ebd1706
 25 2016-06-14 07:08:03	0|GitHub28|13bitcoin/06master 148c1d5eb 15Wladimir J. van der Laan: Merge #8197: [trivial] Ignore split-debug.sh...
 26 2016-06-14 07:08:12	0|GitHub102|[13bitcoin] 15laanwj closed pull request #8197: [trivial] Ignore split-debug.sh (06master...06ignore-split-debug) 02https://github.com/bitcoin/bitcoin/pull/8197
 27 2016-06-14 07:14:04	0|GitHub69|13bitcoin/06master 14fa61756 15MarcoFalke: [gitian] set correct PATH for wrappers
 28 2016-06-14 07:14:04	0|GitHub69|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8c1d5ebd1706...cca1c8cff011
 29 2016-06-14 07:14:05	0|GitHub69|13bitcoin/06master 14cca1c8c 15Wladimir J. van der Laan: Merge #8194: [gitian] set correct PATH for wrappers...
 30 2016-06-14 07:14:14	0|GitHub108|[13bitcoin] 15laanwj closed pull request #8194: [gitian] set correct PATH for wrappers (06master...06Mf1606-gitianPath) 02https://github.com/bitcoin/bitcoin/pull/8194
 31 2016-06-14 08:57:24	0|MarcoFalke|jonasschnelli: The windows build should be working now
 32 2016-06-14 08:57:41	0|MarcoFalke|Try the new descriptors from master
 33 2016-06-14 09:31:52	0|jonasschnelli|Okay. Testing now with the new windows descriptor: https://bitcoin.jonasschnelli.ch/pulls/7636/
 34 2016-06-14 09:40:39	0|GitHub13|[13bitcoin] 15laanwj closed pull request #7186: [WIP] Backports for 0.10.5 (updated to 93ca5a3) (060.10...06backports-for-0.10.5) 02https://github.com/bitcoin/bitcoin/pull/7186
 35 2016-06-14 09:45:00	0|GitHub46|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cca1c8cff011...b67a4726dfc3
 36 2016-06-14 09:45:01	0|GitHub46|13bitcoin/06master 14c022e5b 15Jonas Schnelli: [Wallet] use constant for bip32 hardened key limit
 37 2016-06-14 09:45:01	0|GitHub46|13bitcoin/06master 14f190251 15Jonas Schnelli: [Wallet] Add simplest BIP32/deterministic key generation implementation
 38 2016-06-14 09:45:02	0|GitHub46|13bitcoin/06master 1417c0131 15Jonas Schnelli: [Docs] Add release notes and bip update for Bip32/HD wallets
 39 2016-06-14 09:45:06	0|GitHub22|[13bitcoin] 15laanwj closed pull request #8035: [Wallet] Add simplest BIP32/deterministic key generation implementation (06master...062016/05/simplest_hd) 02https://github.com/bitcoin/bitcoin/pull/8035
 40 2016-06-14 09:45:11	0|jonasschnelli|Yes!
 41 2016-06-14 09:50:01	0|GitHub55|13bitcoin/06master 140e209f9 15fanquake: [trivial] Sync ax_pthread with upstream draft
 42 2016-06-14 09:50:01	0|GitHub55|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b67a4726dfc3...520161480eb1
 43 2016-06-14 09:50:02	0|GitHub55|13bitcoin/06master 145201614 15Wladimir J. van der Laan: Merge #8198: [trivial] Sync ax_pthread with upstream draft4...
 44 2016-06-14 09:50:06	0|GitHub4|[13bitcoin] 15laanwj closed pull request #8198: [trivial] Sync ax_pthread with upstream draft4 (06master...06sync-pthread) 02https://github.com/bitcoin/bitcoin/pull/8198
 45 2016-06-14 09:55:03	0|wumpus|jonasschnelli: bah, if this continues we'll have no 0.13 release for windows :p
 46 2016-06-14 09:56:12	0|wumpus|getting all OS builds to work should probably be focus #1 after the feature freeze
 47 2016-06-14 09:57:30	0|wumpus|as well as getting qt 5.6.1 to work
 48 2016-06-14 10:00:47	0|wumpus|I really like the new parallel rpc test launcher
 49 2016-06-14 10:08:45	0|wumpus|anyone recognize this issue with gitian? http://www.hastebin.com/xununifuxa.txt
 50 2016-06-14 10:09:29	0|wumpus|interesting, just repeating the gbuild seems to get past it
 51 2016-06-14 10:10:16	0|wumpus|lxc is weird
 52 2016-06-14 10:17:14	0|btcdrak|wumpus: it happens randomly and you just have to run the command again. It's been like that for as long as i remember
 53 2016-06-14 10:17:17	0|wumpus|it's building the dependencies, this couuld take awhile
 54 2016-06-14 10:17:49	0|wumpus|btcdrak: yes I also remember seeing it before
 55 2016-06-14 10:20:09	0|wumpus|it's half-panic every time, debugging issues with gitian is tiring as everything goes so slow, I use this VM for nothing else to make sure (hopefully) nothing breaks it
 56 2016-06-14 10:21:15	0|wumpus|I wonder why we have no "upgrade gitian base image" step? doing a system upgrade before every build seems... overkill
 57 2016-06-14 10:21:46	0|wumpus|I know apt-cacher is caching the packages so there is no bandwidth overhead but it is still slow
 58 2016-06-14 10:27:35	0|GitHub83|[13bitcoin] 15laanwj closed pull request #7230: BIP-draft:  2mb blocksize step (06master...062015_2mb_blocksize_step) 02https://github.com/bitcoin/bitcoin/pull/7230
 59 2016-06-14 10:33:41	0|wumpus|jonasschnelli: I'm trying to get a bucket of random testnet hosts by looking up testnet-seed.bitcoin.jonasschnelli.ch manually, but none of the node IP returned seem to have port 18333 open, am I doing something wrong?
 60 2016-06-14 10:34:22	0|wumpus|or just incredibly unlucky, one time I even got only ipv6 addresses :)
 61 2016-06-14 10:36:31	0|wumpus|oh it must be the address obfuscation, of course
 62 2016-06-14 10:38:22	0|sipa|address obfuscation? i thought we never adopted that
 63 2016-06-14 10:39:50	0|wumpus|I don't think so either
 64 2016-06-14 10:40:27	0|wumpus|I don't know then - using another seed gave me valid addresses, btw
 65 2016-06-14 10:41:54	0|sipa|maybe all testnet seeds are short lived?
 66 2016-06-14 10:43:07	0|wumpus|well I checked about 30 addresses returned from jonasschnelli's seed, none could connect, the first one I tried from petertodd's seed was a hit
 67 2016-06-14 10:43:25	0|sipa|hmm
 68 2016-06-14 10:46:32	0|wumpus|*yawn* now my testnet node hangs at 40% verification
 69 2016-06-14 10:46:40	0|wumpus|I should go back to bed, everything goes wrong today
 70 2016-06-14 10:46:48	0|sipa|awww
 71 2016-06-14 10:48:00	0|sipa|i see a stream of questions on stackexchange about unconfirmed transactions (mostly created by old software)... i really hope we can get some "fee increase" mechanism in
 72 2016-06-14 10:49:15	0|wumpus|well https://github.com/bitcoin/bitcoin/pull/7865 is tagged for 0.13, but I doubt it is ready yet
 73 2016-06-14 10:49:50	0|wumpus|ugh, why would a node with checklevel=0 hang while doing the initial verification, I don't get it
 74 2016-06-14 10:51:06	0|wumpus|oh of course, let attach gdb, great idea, thanks ubuntu for making it so difficult I first have to become root or enable a flag...
 75 2016-06-14 10:51:36	0|sipa|ha, yes, after doing that a dozen times, i changed the default in sysctl.conf
 76 2016-06-14 10:52:02	0|sipa|my guess is that leveldb is compacting
 77 2016-06-14 10:52:07	0|jonasschnelli|wumpus: I think the windows build works again: https://bitcoin.jonasschnelli.ch/pulls/7636/
 78 2016-06-14 10:52:10	0|wumpus|I forget that every time, normally I just start bitcoind in gdb, but thought I was donig something so trivial now that it would be unnecessary - wrong :p
 79 2016-06-14 10:52:44	0|jonasschnelli|wumpus: re seeder, I started the testnet seeder with a new database this morning. Not sure if the seeder already results enough data.
 80 2016-06-14 10:53:11	0|sipa|jonasschnelli: perhaps you should delete the db and start over?
 81 2016-06-14 10:53:24	0|jonasschnelli|yes. I did this this morning ~9oclock
 82 2016-06-14 10:53:30	0|sipa|ah
 83 2016-06-14 10:53:43	0|jonasschnelli|ah.. wait... I guess it's scanning mainnet. :(
 84 2016-06-14 10:53:49	0|sipa|ha
 85 2016-06-14 10:53:53	0|btcdrak|lmao
 86 2016-06-14 10:54:06	0|wumpus|oh, nm, I was looking at the wrong log
 87 2016-06-14 10:54:09	0|jonasschnelli|fooled by the subdomain. :)
 88 2016-06-14 10:55:26	0|jonasschnelli|Okay. removed the database and started in testnet mode
 89 2016-06-14 10:55:29	0|wumpus|yes, windows build seems to work
 90 2016-06-14 10:55:54	0|jonasschnelli|sipa: [...] i really hope we can get some "fee increase" mechanism in
 91 2016-06-14 10:55:56	0|wumpus|current master: 291be202508e518646116677cc99cb1333739d52e2c4ae7259359b3bd3729e0c  bitcoin-0.12.99-win-unsigned.tar.gz
 92 2016-06-14 10:56:03	0|jonasschnelli|sipa: you could review the bumpfee command.
 93 2016-06-14 10:56:23	0|jonasschnelli|I'm not entirely sure if taking a txid and autobump it is the way to go though.
 94 2016-06-14 10:57:18	0|sipa|if CPFP gets in, there is an easier solution
 95 2016-06-14 10:58:19	0|sipa|jonasschnelli: i don't know how to make this easy to use
 96 2016-06-14 10:58:30	0|wumpus|how is addnode supposed to work? I added a few (seemingly functional) testnet nodes, but they all stay at "connected": false in getaddednodeinfo (testing #8113)
 97 2016-06-14 10:58:35	0|jonasschnelli|I'm planing on extending the HD feature. Importing/starting a wallet with a xpriv key. How should we do that. I guess having a -xpriv= startup argument is very bad.
 98 2016-06-14 10:58:43	0|sipa|wumpus: it cycles every 2 minutes
 99 2016-06-14 10:58:47	0|wumpus|let's first worry about having some mechanism in, and then about making it easy to use
100 2016-06-14 10:59:10	0|sipa|wumpus: and then tries to connect to one of the unconnected addnodes
101 2016-06-14 10:59:18	0|wumpus|there's only two days left before the feature freeze so we need to make some choices
102 2016-06-14 10:59:25	0|wumpus|sipa: okay, thanks
103 2016-06-14 11:02:07	0|jonasschnelli|would ./bitcoin-wallet be a tool where users could create a wallet(.dat) with a xpriv?
104 2016-06-14 11:02:18	0|jonasschnelli|Everything that goes over RPC is somehow not ideal
105 2016-06-14 11:02:56	0|wumpus|that's the eternal question - command line isn't the ideal interface either though, especially if you're not writing shell script
106 2016-06-14 11:04:31	0|wumpus|I think having wallet creation commands on RPC makes some sense, at least once there is multi-wallet support
107 2016-06-14 11:04:57	0|jonasschnelli|wumpus: Yes. But right now, we create the wallet before the RPC is ready.
108 2016-06-14 11:05:10	0|wumpus|yes, right now, I'm sure that needs to be changed
109 2016-06-14 11:05:14	0|wumpus|is there a hurry?
110 2016-06-14 11:05:18	0|jonasschnelli|No hurry.
111 2016-06-14 11:05:34	0|jonasschnelli|Certenly not something for 0.13
112 2016-06-14 11:05:47	0|jonasschnelli|But need some brainfood for afk time. :)
113 2016-06-14 11:05:49	0|wumpus|decoupling the wallet further would mean that node RPC could be ready, before the wallet even starts loading/creating
114 2016-06-14 11:06:06	0|wumpus|especially if the wallet has its own entry point
115 2016-06-14 11:06:15	0|jonasschnelli|yes. I'm working on removine the splash screen and add this state
116 2016-06-14 11:06:47	0|wumpus|removing the splash screen? I'd think we still need it during initial verification
117 2016-06-14 11:07:23	0|jonasschnelli|wumpus: Yes. But you can access the wallet during this time. Get addresses, list transactions, etc.
118 2016-06-14 11:07:27	0|wumpus|there's something to be said for having a wallet as an external tool/library, but the scope for doing that within bitcoin core is very small
119 2016-06-14 11:07:49	0|wumpus|jonasschnelli: I don't think that's a very good idea, even being able to access the wallet during *synchronization* caused a ton of confused users
120 2016-06-14 11:08:34	0|jonasschnelli|wumpus: but decoupling the wallet would result in such states. I guess all SPV wallets allow address/tx access in out-of-sync state.
121 2016-06-14 11:08:35	0|wumpus|e.g. 'I downloaded bitcoin core and sent from *web wallet provider* to a new address, now my transaction doesn't show!'
122 2016-06-14 11:08:42	0|jonasschnelli|Sure, we might want to add a SPV mode first.
123 2016-06-14 11:09:11	0|wumpus|possibly, but I don't think - right now - there is any benefit to removing the splash screen and showing a (mostly dysfunctional) GUI instead
124 2016-06-14 11:09:21	0|jonasschnelli|But its annoying that you need to go through verification/checkblocks if you want to get a new address
125 2016-06-14 11:09:55	0|wumpus|possibly... checkblocks takes too long by default, that's aother issue
126 2016-06-14 11:10:13	0|jonasschnelli|IMO the (wallet)GUI is fully functional during init-verification
127 2016-06-14 11:10:25	0|wumpus|I think validating the last blocks is a good thing, but the default depth setting is overkill
128 2016-06-14 11:10:41	0|jonasschnelli|Yes. But the node (validation) is not tied to the wallet/GUI.
129 2016-06-14 11:10:58	0|wumpus|that's true...
130 2016-06-14 11:11:04	0|jonasschnelli|But right. We need more prominent warnings if the wallet is not in sync
131 2016-06-14 11:11:23	0|wumpus|but it won't start syncing blocks until that part is done, so people will still complain 'why isn't it synching!!!'
132 2016-06-14 11:11:37	0|wumpus|WHHY IS THERE NO BLOCK SOURCE AVAILABLE
133 2016-06-14 11:11:51	0|jonasschnelli|Heh... yes. probably.
134 2016-06-14 11:12:11	0|jonasschnelli|Step by step...
135 2016-06-14 11:12:20	0|jonasschnelli|For 0.14 i'd like to focus more on the UI
136 2016-06-14 11:12:28	0|wumpus|you're right that creating an address can be done without any node functionality, but then, people can't see transactions to the address without it, or being in sync
137 2016-06-14 11:12:49	0|sipa|i think we should disable that feature by default
138 2016-06-14 11:13:06	0|wumpus|which is arguably the part people care about, actually receiving coins
139 2016-06-14 11:13:08	0|sipa|not show a receive address until sync is done
140 2016-06-14 11:13:26	0|wumpus|well for a start it should show a big red warning in the transaction pane when not up to date
141 2016-06-14 11:13:33	0|wumpus|I don't think you need to actually disable it
142 2016-06-14 11:13:45	0|wumpus|but just warn better
143 2016-06-14 11:13:50	0|sipa|perhaps make it greyed out with a button, and if you click it it first asks you "are you aware that you'll only receive once you're synced?"
144 2016-06-14 11:14:04	0|wumpus|there is no indication right now excapt for the extremely toned-down out-of-sync triangles
145 2016-06-14 11:14:27	0|jonasschnelli|Wouldn't this be to much handholding for expert users?
146 2016-06-14 11:14:37	0|jonasschnelli|(not the warning)
147 2016-06-14 11:14:48	0|jonasschnelli|(just the fact that you can't get addresses when you are not in sync)
148 2016-06-14 11:14:58	0|wumpus|yes, i think that's too much babysitting
149 2016-06-14 11:15:25	0|jonasschnelli|IMO even the fact that you need to wait for the init/checks before you can list transactions or get new addresses.
150 2016-06-14 11:15:26	0|wumpus|lots of people do know that, it's just new users that don't, maybe we should add a tutorial mode on first use
151 2016-06-14 11:15:43	0|sipa|right
152 2016-06-14 11:16:03	0|sipa|yes, just thinking through how a first time user sees all this
153 2016-06-14 11:16:56	0|jonasschnelli|This is the difficulty: make it useable for basic/new bitcoin users but also make the experts happy.
154 2016-06-14 11:17:09	0|wumpus|yes
155 2016-06-14 11:17:39	0|wumpus|in any case, adding a warning wouldn't hurt and is easy to do
156 2016-06-14 11:18:07	0|GitHub179|13bitcoin/06master 141c2a1ba 15Francesco 'makevoid' Canessa: Add address label to request payment QR Code (QT)...
157 2016-06-14 11:18:07	0|GitHub179|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/520161480eb1...fb0ac482eee7
158 2016-06-14 11:18:08	0|GitHub179|13bitcoin/06master 14fb0ac48 15Jonas Schnelli: Merge #7636: Add bitcoin address label to request payment QR code...
159 2016-06-14 11:18:12	0|GitHub124|[13bitcoin] 15jonasschnelli closed pull request #7636: Add bitcoin address label to request payment QR code (06master...06request_payment_qrcode_address_label) 02https://github.com/bitcoin/bitcoin/pull/7636
160 2016-06-14 11:20:00	0|wumpus|how exactly is up to the person implementing it, I guess
161 2016-06-14 11:21:07	0|wumpus|there's enough place on the "receive" tab to add a warning, and in the transaction pane I suppose it could show an overlay if there are no transactions yet and it is syncing
162 2016-06-14 11:26:29	0|MarcoFalke|Anyone seeing OOM for gitian builds?
163 2016-06-14 11:26:34	0|MarcoFalke|in main.cpp
164 2016-06-14 11:27:19	0|wumpus|no, though adding of debug symbols in #8167 did increase the memory requirements for gitian a bit
165 2016-06-14 11:28:00	0|MarcoFalke|How does gbuild set up the ram of the vm?
166 2016-06-14 11:28:20	0|MarcoFalke|I could try to increase it, I guess.
167 2016-06-14 11:29:09	0|wumpus|-j5 -m5000  where -j is the parallelism and -m is the memory size in mb
168 2016-06-14 11:31:29	0|wumpus|what is the expected behavior when addnoding a seed?
169 2016-06-14 11:32:34	0|sipa|very fuzzy
170 2016-06-14 11:32:49	0|sipa|i think it won't make any connection if you already have 8 outgoing ones
171 2016-06-14 11:32:58	0|wumpus|for me it works with IPs but not with hostnames
172 2016-06-14 11:33:09	0|sipa|it should work with hostnames
173 2016-06-14 11:33:44	0|sipa|wumpus: is this in #8113?
174 2016-06-14 11:33:55	0|wumpus|the expectation is that it looks up the address for the seed then connect to the first address, I suppose?
175 2016-06-14 11:34:00	0|wumpus|yes
176 2016-06-14 11:34:07	0|sipa|it randonly tries one of the returned ip addtesses every 2 minutes
177 2016-06-14 11:34:18	0|sipa|if one fails, there is another attempt 2 minutes later
178 2016-06-14 11:34:29	0|wumpus|it stays at 'connected': false all the time
179 2016-06-14 11:34:48	0|sipa|do you have 8 outgoing connections already?
180 2016-06-14 11:35:03	0|wumpus|yes
181 2016-06-14 11:35:13	0|wumpus|should I kick some other connections?
182 2016-06-14 11:35:54	0|wumpus|ok disconnected all nodes, let's see what happens
183 2016-06-14 11:36:48	0|sipa|the addnode logic should be integrated into the normal outgoing connection logic, and be protected from eviction
184 2016-06-14 11:37:22	0|wumpus|yes, I suppose so, how badly this works I wonder if anyone was actually using this functionality and whether it makes sense to spend time on it
185 2016-06-14 11:38:54	0|sipa|i think after we have p2p encryption and authentication, we may want to encourage it
186 2016-06-14 11:40:45	0|MarcoFalke|looks like it is using 2000MiB as default. In case the default is no longer enough, it may be worth to adjust https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#build-and-sign-bitcoin-core-for-linux-windows-and-os-x
187 2016-06-14 11:40:51	0|wumpus|I set up a hostname for a known-working testnet node, lets see if it wants to connect to that...
188 2016-06-14 11:42:22	0|wumpus|evicting all other nodes again
189 2016-06-14 11:42:44	0|wumpus|MarcoFalke: yes, I guess so
190 2016-06-14 11:44:08	0|wumpus|it didn't work automatically, though I could force it to connect with "addnode hostname onetry"
191 2016-06-14 11:44:16	0|wumpus|now it shows up in getaddednodeinfo
192 2016-06-14 11:45:09	0|sipa|over long periods of time, it will end up connecring to the addnode nodes when other outgoing connections die
193 2016-06-14 11:45:37	0|wumpus|but I disconnected all other nodes; I don't see why I would have to wait longer than 2 minutes in that case
194 2016-06-14 11:45:57	0|wumpus|in any case I managed to force it to connect and it shows up in getaddednodeinfo correcty
195 2016-06-14 11:47:02	0|wumpus|I still hope Matt can give #8113 a try
196 2016-06-14 11:47:12	0|wumpus|and check it still does whatever he expects from it
197 2016-06-14 12:28:18	0|murch|sipa: Perhaps you remember that we talked about the Coin Selection algorithm a little bit about a month ago. I'm now indeed writing my Master's thesis about that problem. :) I was wondering if someone could confirm or deny my understanding of the current algorithm's behavior.
198 2016-06-14 12:28:23	0|murch|https://github.com/bitcoin/bitcoin/blob/fb0ac482eee761ec17ed2c11df11e054347a026d/src/wallet/wallet.cpp#L1863
199 2016-06-14 12:29:27	0|murch|Do I understand correctly, that this actually uses the sorted list (decreasing) of available UTXO and selects each UTXO with a 50%? That would easily explain the growth of the UTXO set, if I'm not mistaken.
200 2016-06-14 12:30:31	0|sipa|murch: i can't say that i've ever looked at the algorithm in detail
201 2016-06-14 12:32:05	0|sipa|murch: it looks like it does 1000 iterations over all UTXOs twice, stopping when it goes over the maximum
202 2016-06-14 12:33:31	0|murch|sipa: But vValue is sorted in decreasing order by size, and it starts at the front selecting UTXO with a random binary chance. That would significantly increase the chance for large UTXO to be selected as inputs, especially since the maximum should be reached quickly when big inputs are added first.
203 2016-06-14 12:34:26	0|murch|I used to think that it randomly selected from all UTXO with equal chance (that's what I simulated two years ago), but I just realized yesterday, that it doesn't seem to do that (anymore?).
204 2016-06-14 12:35:22	0|murch|Unless I'm jut confused about what's happening there, because that seems like a really easy explanation for the UTXO growth.
205 2016-06-14 12:35:46	0|sipa|murch: it's in increasing value, i think?
206 2016-06-14 12:36:23	0|sipa|CompareValueOnly does a < for the value
207 2016-06-14 12:36:47	0|murch|sipa: sort() puts it in ascending order, and it is reversed afterwards: https://github.com/bitcoin/bitcoin/blob/fb0ac482eee761ec17ed2c11df11e054347a026d/src/wallet/wallet.cpp#L1962
208 2016-06-14 12:37:02	0|sipa|oh, right
209 2016-06-14 12:37:04	0|instagibbs|it used to be a much more ocnfusing rsort....
210 2016-06-14 12:38:08	0|murch|instagibbs: Yeah, I proposed to at least split it in two lines for better readability. :)
211 2016-06-14 12:39:34	0|murch|sipa: Now don't fix it today though, I still want to write my thesis on it! ^^
212 2016-06-14 12:39:53	0|sipa|murch: i'm not going to fix anything; i hope you do :)
213 2016-06-14 12:41:04	0|murch|sipa: But, it would be very helpful to me if you could tell me whether I understood correctly what it does there, and I'm not overlooking something glaringly obvious. Because my next step would be to simulate how much of a difference it would make to pick randomly instead of from the front.
214 2016-06-14 12:41:36	0|murch|Seems like a good idea to check the facts before I spend a bunch of hours on something useless. :)
215 2016-06-14 12:41:51	0|sipa|i think you've looked at it better than i have
216 2016-06-14 12:42:55	0|murch|Yeah, but my overall familiarity with the Bitcoin Core is slightly behind yours. ;) But I guess, I'd count that as an "I haven't seen anything that contradicts Murch". :)
217 2016-06-14 12:43:20	0|murch|Then… coming up next, simulation results, I hope.
218 2016-06-14 12:46:17	0|murch|sipa: Thanks
219 2016-06-14 12:47:14	0|MarcoFalke|murch: Correct
220 2016-06-14 12:47:29	0|murch|MarcoFalke: Thank you
221 2016-06-14 12:47:43	0|MarcoFalke|The first pass is selecting a coin with prob .5 as long as the target is not reached
222 2016-06-14 12:47:43	0|sipa|perhaps you should talk to MarcoFalke instead :)
223 2016-06-14 12:48:06	0|murch|Yeah, I believe we've collaborated on this last time around as well. :)
224 2016-06-14 12:48:08	0|MarcoFalke|The second pass will select anything that is not included as long as the target is not reached
225 2016-06-14 12:48:26	0|NicolasDorier|might be useful to see the votes http://api.qbit.ninja/versionstats
226 2016-06-14 12:48:58	0|MarcoFalke|But in any case it will always "unselect" coins when the target was reached to try to "hit the target better" by trying with smaller coins
227 2016-06-14 12:49:03	0|murch|MarcoFalke: I didn't realize this before, but that approach significantly biases towards selecting large UTXO. Do you remember whether the algorithm used to work differently? That would explain the accelerated growth of the UTXO set, no?
228 2016-06-14 12:49:34	0|murch|Aaah, right. I had forgotten about that.
229 2016-06-14 12:49:54	0|MarcoFalke|I think this is still the way satoshi wrote it
230 2016-06-14 12:50:14	0|MarcoFalke|(you could check git log -S or something)
231 2016-06-14 12:50:49	0|instagibbs|murch, you have to remember that excessive amounts of inputs take longer to verify
232 2016-06-14 12:50:58	0|instagibbs|might be taken into account
233 2016-06-14 12:51:03	0|_anthony_|morning all
234 2016-06-14 12:51:07	0|MarcoFalke|The problem is that zero-fee (free) transaction were more common back then
235 2016-06-14 12:51:33	0|MarcoFalke|Right now transaction with no fee (trying to "pay" with priority) are impossible to get through
236 2016-06-14 12:51:38	0|sipa|if you're not trying to hit the target exactly, i think you can limit yourself to only choosing a certain number of utxos from within a range around the target value (say [0.1*target...3*target]
237 2016-06-14 12:51:41	0|MarcoFalke|but coin selection was not adjusted accordingly
238 2016-06-14 12:52:07	0|murch|instagibbs: I solved that by outsourcing the selection to a binary array that flags selected inputs, instead of directly creating sets. That made it much faster. (or do you mean for confirmation on the network?)
239 2016-06-14 12:52:38	0|instagibbs|murch, signing the txn requires hashing the txn over and over for each input.
240 2016-06-14 12:52:49	0|instagibbs|(pre-segwit)
241 2016-06-14 12:53:49	0|murch|instagibbs: Ah, now I get what you mean. Yes, I'm aware. There are also a bunch of other incentives why you don't want to use too many inputs such as fees, and privacy. I'm working on properly writing up all those constraints and requirements for my thesis. :)
242 2016-06-14 12:53:59	0|_anthony_|I have a question: as far as I can tell, script versioning lets you put arbitrary data in the blockchain (just use an unused version number). Is this right?
243 2016-06-14 12:54:00	0|instagibbs|I'm almost sure it wasn't the original idea though, just saying. As sipa said you can simply make sure it doesn't do that by bounding input size
244 2016-06-14 12:55:28	0|instagibbs|_anthony_, the block cost is still static
245 2016-06-14 12:55:52	0|MarcoFalke|murch, you are welcome to do a presentation on your results during a irc meeting
246 2016-06-14 12:56:01	0|MarcoFalke|they are every thursday
247 2016-06-14 12:56:43	0|_anthony_|hmm, yeah, I guess it isn't really much of an advantage
248 2016-06-14 12:57:26	0|murch|MarcoFalke: Thank you, I'd be happy to. I'll get in touch when I have something to present. Perhaps not this week, but next week.
249 2016-06-14 12:57:36	0|instagibbs|_anthony_, otherwise someone today could send a v16 segwit transaction, and stuff 8GB in it
250 2016-06-14 12:57:40	0|MarcoFalke|no pressure :)
251 2016-06-14 12:58:16	0|murch|MarcoFalke: Well, this time I'm fairly certain that I'll have something to present, as in October, I'll have to present some fifty odd pages of work. :)
252 2016-06-14 12:58:30	0|instagibbs|murch, will it include a PR? ;)
253 2016-06-14 12:58:57	0|MarcoFalke|We should look at the new model first
254 2016-06-14 12:59:12	0|murch|instagibbs: That's the plan, although my advisor scolded me last time that it's not part of my thesis, just an added bonus for myself. :)
255 2016-06-14 12:59:13	0|MarcoFalke|Otherwise the pr will receive no review and bitrot instantly
256 2016-06-14 13:00:01	0|_anthony_|yeah I caught that part....I was thinking of how you could make an altcoin using script versioning, but really it wouldn't provide any advantage over regular anyone-can-spend txes
257 2016-06-14 13:00:21	0|murch|instagibbs: Main goals of the work are a comprehensive overview of the problem, the different parameters and approaches how it could be solved, and an evaluation of said approaches. Whether or not it gets adopted by Bitcoin Core is not part of my thesis, but a personal goal. :)
258 2016-06-14 13:00:32	0|_anthony_|you'd have to have support of >50% of miners or else anyone could spend your altcoins out from under you
259 2016-06-14 13:03:46	0|murch|MarcoFalke: Noted. :)
260 2016-06-14 14:24:24	0|Chris_St1|Is there a reason the user agent inside of a version message would change when connecting to nodes within a 5 second period? On testnet..
261 2016-06-14 14:24:58	0|sipa|the agent you sent send, or receive?
262 2016-06-14 14:25:18	0|wumpus|at least bitcoin core doesn't change the 'user agent' on such conditions, no
263 2016-06-14 14:26:03	0|Chris_St1|I'm sending a version message to a tesnet dns seed, and receiving their version message back. If I do this within a 5 second period I'm getting different versions on that same node
264 2016-06-14 14:26:24	0|wumpus|although you should avoid connecting to nodes too intensively
265 2016-06-14 14:26:41	0|Chris_St1|i.e /Satoshi:0.12.0/ then 5 seconds later /Satoshi:0.11.2/
266 2016-06-14 14:26:48	0|wumpus|'change your user agent' isn't a very useful defense against that
267 2016-06-14 14:27:15	0|wumpus|you're connecting to the seed, as in the DNS name? that resolves to a different host every time
268 2016-06-14 14:27:32	0|Chris_St1|mmm yes that could be it
269 2016-06-14 14:27:42	0|sipa|pretty sure that's it :)
270 2016-06-14 14:28:00	0|Chris_St1|Yep. Doh!
271 2016-06-14 14:28:05	0|Chris_St1|Thansk
272 2016-06-14 14:31:11	0|sipa|no results from x9.testnet-seed.bitcoin.jonasschnelli.ch :(
273 2016-06-14 14:31:58	0|jonasschnelli|sipa: this means no NODE_WITNESS nodes...
274 2016-06-14 14:32:20	0|sipa|indeed.
275 2016-06-14 14:32:22	0|sipa|that's pretty bad
276 2016-06-14 14:32:33	0|sdaftuar|i have one if you want to connect to it
277 2016-06-14 14:32:51	0|instagibbs|sipa, where should ACKs be going for segwit pr
278 2016-06-14 14:32:58	0|jonasschnelli|sipa: I guess in master the dnsseed.dump does not list the service flags?
279 2016-06-14 14:33:02	0|sipa|jonasschnelli: it does
280 2016-06-14 14:33:18	0|jonasschnelli|ah .. yes. second last col
281 2016-06-14 14:33:32	0|sipa|under svcs
282 2016-06-14 14:34:23	0|wumpus|instagibbs: https://github.com/bitcoin/bitcoin/pull/7910
283 2016-06-14 14:35:08	0|instagibbs|wumpus, roger
284 2016-06-14 14:36:30	0|sipa|wumpus, instagibbs: yeah, let's keep everhthing on 7910... thoughit's 8149 that would be merged, i guess
285 2016-06-14 14:37:04	0|instagibbs|that's fine
286 2016-06-14 14:38:43	0|btcdrak|maybe you can put an ACK transfer list in #8149 like was done in #7524
287 2016-06-14 14:40:44	0|jonasschnelli|sipa: Yes. There are no nodes with 00000009
288 2016-06-14 14:41:03	0|jonasschnelli|Could it be because I scan though tor? I guess should result in ~the same when scanning not through tor
289 2016-06-14 14:41:35	0|sipa|i guess there just are very few
290 2016-06-14 14:47:16	0|sdaftuar|i believe there are very few
291 2016-06-14 14:47:52	0|sdaftuar|i hacked my code recently to only connect to witness peers, and let it run for a long time (~hours) without finding anyone
292 2016-06-14 22:53:03	0|GitHub116|[13bitcoin] 15nathaniel-mahieu opened pull request #8203: Clarify documentation for running a tor node (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/8203