1 2016-10-24T00:36:20  *** Cheeseo has joined #bitcoin-core-dev
  2 2016-10-24T00:38:11  *** Cheeseo has quit IRC
  3 2016-10-24T00:41:37  *** blkdb has quit IRC
  4 2016-10-24T00:41:42  *** blkdb has joined #bitcoin-core-dev
  5 2016-10-24T00:42:17  *** jouke has joined #bitcoin-core-dev
  6 2016-10-24T00:42:18  *** roasbeef_ has joined #bitcoin-core-dev
  7 2016-10-24T00:42:20  *** andytosh1 has joined #bitcoin-core-dev
  8 2016-10-24T00:43:26  *** nickler_ has joined #bitcoin-core-dev
  9 2016-10-24T00:43:38  *** roasbeef has quit IRC
 10 2016-10-24T00:43:40  *** jouke_ has quit IRC
 11 2016-10-24T00:43:40  *** nickler has quit IRC
 12 2016-10-24T00:43:41  *** andytoshi has quit IRC
 13 2016-10-24T00:43:41  *** helo has quit IRC
 14 2016-10-24T00:44:16  *** fengling has quit IRC
 15 2016-10-24T00:44:53  *** jujumax has quit IRC
 16 2016-10-24T00:47:23  *** jujumax has joined #bitcoin-core-dev
 17 2016-10-24T00:49:23  *** e4xit_ has joined #bitcoin-core-dev
 18 2016-10-24T00:49:24  *** helo has joined #bitcoin-core-dev
 19 2016-10-24T00:50:35  *** jl2012_ has joined #bitcoin-core-dev
 20 2016-10-24T00:51:41  *** Giszmo1 has joined #bitcoin-core-dev
 21 2016-10-24T00:53:12  *** jl2012 has quit IRC
 22 2016-10-24T00:53:12  *** e4xit has quit IRC
 23 2016-10-24T00:53:12  *** Giszmo has quit IRC
 24 2016-10-24T00:53:12  *** e4xit_ is now known as e4xit
 25 2016-10-24T00:53:13  *** jl2012_ is now known as jl2012
 26 2016-10-24T00:55:05  *** jtimon has quit IRC
 27 2016-10-24T00:57:29  *** ill has joined #bitcoin-core-dev
 28 2016-10-24T01:04:04  *** isis has quit IRC
 29 2016-10-24T01:07:02  *** DigiByteDev has joined #bitcoin-core-dev
 30 2016-10-24T01:11:44  *** gmaxwell has quit IRC
 31 2016-10-24T01:19:05  *** so has joined #bitcoin-core-dev
 32 2016-10-24T01:24:23  <GitHub14> [bitcoin] gmaxwell opened pull request #9002: Make connect=0 disable automatic outbound connections. (master...connect0) https://github.com/bitcoin/bitcoin/pull/9002
 33 2016-10-24T01:27:05  *** Ylbam has quit IRC
 34 2016-10-24T01:29:39  *** gmaxwell has joined #bitcoin-core-dev
 35 2016-10-24T01:31:50  *** da2ce7_ has quit IRC
 36 2016-10-24T01:31:50  *** kanzure has quit IRC
 37 2016-10-24T01:31:50  *** zxzzt_ has quit IRC
 38 2016-10-24T01:31:50  *** thestringpuller has quit IRC
 39 2016-10-24T01:31:51  *** wolfspraul has quit IRC
 40 2016-10-24T01:31:51  *** eenoch has quit IRC
 41 2016-10-24T01:31:51  *** lesderid has quit IRC
 42 2016-10-24T01:31:58  *** wolfspraul has joined #bitcoin-core-dev
 43 2016-10-24T01:32:27  *** Soligor has quit IRC
 44 2016-10-24T01:32:27  *** jeremyrubin has quit IRC
 45 2016-10-24T01:32:27  *** petertodd has quit IRC
 46 2016-10-24T01:33:05  *** eenoch has joined #bitcoin-core-dev
 47 2016-10-24T01:33:11  *** kanzure has joined #bitcoin-core-dev
 48 2016-10-24T01:33:11  *** thestringpuller has joined #bitcoin-core-dev
 49 2016-10-24T01:33:15  *** zxzzt has joined #bitcoin-core-dev
 50 2016-10-24T01:33:35  *** thestringpuller is now known as Guest16408
 51 2016-10-24T01:33:47  *** petertodd has joined #bitcoin-core-dev
 52 2016-10-24T01:33:52  *** jeremyrubin has joined #bitcoin-core-dev
 53 2016-10-24T01:38:05  *** lesderid has joined #bitcoin-core-dev
 54 2016-10-24T01:39:53  *** da2ce7 has joined #bitcoin-core-dev
 55 2016-10-24T01:40:19  *** ill has quit IRC
 56 2016-10-24T01:43:05  *** ill has joined #bitcoin-core-dev
 57 2016-10-24T01:45:19  *** Soligor has joined #bitcoin-core-dev
 58 2016-10-24T01:47:18  *** ill has quit IRC
 59 2016-10-24T01:54:13  *** jujumax has quit IRC
 60 2016-10-24T01:54:40  *** ill has joined #bitcoin-core-dev
 61 2016-10-24T01:55:11  *** PRab has joined #bitcoin-core-dev
 62 2016-10-24T02:01:00  *** ill has quit IRC
 63 2016-10-24T02:06:11  *** Alopex has quit IRC
 64 2016-10-24T02:07:16  *** Alopex has joined #bitcoin-core-dev
 65 2016-10-24T02:08:30  *** fengling has joined #bitcoin-core-dev
 66 2016-10-24T02:23:38  *** isis has joined #bitcoin-core-dev
 67 2016-10-24T02:29:03  <midnightmagic> :-/
 68 2016-10-24T02:33:05  *** kanzure has quit IRC
 69 2016-10-24T02:33:05  *** kanzure has joined #bitcoin-core-dev
 70 2016-10-24T03:05:28  *** aalex has quit IRC
 71 2016-10-24T03:08:24  *** aalex has joined #bitcoin-core-dev
 72 2016-10-24T03:19:35  *** alpalp has quit IRC
 73 2016-10-24T03:23:32  *** jujumax has joined #bitcoin-core-dev
 74 2016-10-24T03:50:46  *** DigiByteDev has quit IRC
 75 2016-10-24T03:51:37  *** ill has joined #bitcoin-core-dev
 76 2016-10-24T03:58:02  *** Alopex has quit IRC
 77 2016-10-24T03:59:07  *** Alopex has joined #bitcoin-core-dev
 78 2016-10-24T04:11:38  *** DigiByteDev has joined #bitcoin-core-dev
 79 2016-10-24T04:11:55  <luke-jr> does it not do that again? :x
 80 2016-10-24T04:13:53  *** DigiByteDev has quit IRC
 81 2016-10-24T04:15:09  <sipa> do what?
 82 2016-10-24T04:18:30  <luke-jr> sipa: disable outbound connections.
 83 2016-10-24T04:18:52  <luke-jr> it used to do so at least, and seemed to work when I recently did it for testing
 84 2016-10-24T04:27:30  *** ill has quit IRC
 85 2016-10-24T04:29:11  *** Alopex has quit IRC
 86 2016-10-24T04:30:16  *** Alopex has joined #bitcoin-core-dev
 87 2016-10-24T04:32:42  <gmaxwell> My belief is that it used to work, but what it does right now is just loop continually trying to connect to '0' and on my system this manages to connect to myself.
 88 2016-10-24T04:32:58  <gmaxwell> this, indeed, does prevent it from connecting to other parties...
 89 2016-10-24T04:33:01  <luke-jr> O.o
 90 2016-10-24T04:33:22  <gmaxwell> but in a fairly log spammy way (esp with debugging turned up)
 91 2016-10-24T04:34:07  <sipa> any theory why '0' results in a connect to self? :s
 92 2016-10-24T04:34:25  <sipa> that shouldn't even resolve to a valid ip
 93 2016-10-24T04:34:52  <luke-jr> sipa: most integers are a valid IP
 94 2016-10-24T04:35:01  <gmaxwell> I didn't bother checking my belief that it used to behave better.
 95 2016-10-24T04:35:02  <aj> sipa: telnet 0 22 -> -> ssh to localhost
 96 2016-10-24T04:35:07  <gmaxwell> $ telnet 0 8333
 97 2016-10-24T04:35:07  <gmaxwell> Trying
 98 2016-10-24T04:35:10  <gmaxwell> Connected to 0.
 99 2016-10-24T04:35:13  <gmaxwell> Escape character is '^]'.
100 2016-10-24T04:35:16  <gmaxwell> ^]
101 2016-10-24T04:35:19  <gmaxwell> telnet> close
102 2016-10-24T04:35:29  <sipa> well i knew it'd resolve to
103 2016-10-24T04:35:48  <sipa> i'm surprised is a valid thing to connect to
104 2016-10-24T04:35:57  <gmaxwell> This surprised me too. I figured it was some quirk of my system... but in any case, better to just not have the useless thread.
105 2016-10-24T04:36:08  <luke-jr> ping 2130706433
106 2016-10-24T04:36:41  <luke-jr> (this is 0x7f000001)
107 2016-10-24T04:36:42  <aj> means "all ipv4 addresses on the local machine", so seems kinda plausible
108 2016-10-24T04:36:58  <sipa> luke-jr: some browsers even allow much larger integers (up to 2^1000-ish), resolving them modulo 2^32
109 2016-10-24T04:37:07  <luke-jr> >_<
110 2016-10-24T04:38:00  <sipa> as to why anyone ever tbought to support that: i believe a naive decimal-to-uint32 converter will actually behave that way
111 2016-10-24T04:38:26  <gmaxwell> we it would stop at 2^1000 isn't clear. :P
112 2016-10-24T04:39:07  <luke-jr> I should access my KVMoIP by decimal. I don't have DNS on it anyway. :p
113 2016-10-24T04:42:12  *** DigiByteDev has joined #bitcoin-core-dev
114 2016-10-24T04:44:50  <sipa> gmaxwell: ish
115 2016-10-24T04:45:04  <sipa> it's probably just an input buffer size limit
116 2016-10-24T04:51:42  <midnightmagic> 0 is the inaddr_any wildcard/alias address, and in some systems (the ones I'm familiar with) it means "the first interface that was ifconfig'd at boot" -- in other words, it's *not* guaranteed to be
117 2016-10-24T04:52:15  <luke-jr> I would have expected to be a blackhole :/
118 2016-10-24T04:52:39  <luke-jr> midnightmagic: what if you ifconfig the first interface with <.<
119 2016-10-24T04:55:32  <midnightmagic> luke-jr: i dunno, can you ifconfig an interface to
120 2016-10-24T04:55:38  <luke-jr> probably not
121 2016-10-24T04:55:43  <luke-jr> I think that means unconfigure
122 2016-10-24T05:17:24  *** paveljanik has quit IRC
123 2016-10-24T05:28:11  *** Alopex has quit IRC
124 2016-10-24T05:29:16  *** Alopex has joined #bitcoin-core-dev
125 2016-10-24T05:41:25  *** jujumax has quit IRC
126 2016-10-24T05:46:41  *** n1ce has quit IRC
127 2016-10-24T06:15:45  <midnightmagic> or on some machines you get:
128 2016-10-24T06:15:47  <midnightmagic> :dom13:06:14:57 ~# telnet 0 22
129 2016-10-24T06:15:48  <midnightmagic> 0: No address associated with hostname
130 2016-10-24T06:25:09  <wumpus> IP parsing is not guaranteed to parse '0' as '', in this csae it just thinks it's a hostname
131 2016-10-24T06:27:12  <wumpus> any other 0.x.y.z IP seems to give "invalid argument" on linux
132 2016-10-24T06:30:03  <wumpus> anyhow the problem here is that bitcoin core uses the OS's IP parsing, this has resulted in confusion before
133 2016-10-24T06:30:57  <gmaxwell> I don't ~think~ special casing "0" is too ugly, but I am open to that idea. :)
134 2016-10-24T06:31:29  <wumpus> but it's not just 0, some IP parsers will happily parse any int32 into a IPv4
135 2016-10-24T06:32:16  <wumpus> +have other OS/libc specific quirks
136 2016-10-24T06:33:35  <gmaxwell> right, this discussion is inspired by my patch that special cases "0" to disable connect. Which itself was inspired by me getting irritated with my logs being flooded with connects to self after setting connect=0 to disable automatic outbound connections.
137 2016-10-24T06:34:03  <wumpus> yes, the reason to special-case 0 would be for -noconnect
138 2016-10-24T06:34:22  <wumpus> which is fine with me
139 2016-10-24T06:34:42  <gmaxwell> Yes, right now, my PR doesn't handle -noconnect (I believe), good point on that.
140 2016-10-24T06:34:59  <wumpus> noconnect should automatically get converted to connect=0
141 2016-10-24T06:35:21  <wumpus> you shoudln't have to do anything special for that
142 2016-10-24T06:35:37  <wumpus> -noX bcomes X=1 in the low-level arg handling
143 2016-10-24T06:35:43  <wumpus> ehhh X=0
144 2016-10-24T06:36:05  <gmaxwell> Will test.
145 2016-10-24T06:36:13  <wumpus> in any case special-casing 0 makes sense because the argument handling special-cases 0 for 'no'
146 2016-10-24T06:38:42  <wumpus> we do that in plenty of places in init.cpp, and adding one more is not a problem at all. If someone really wants to connect to, let them specify
147 2016-10-24T06:39:13  <wumpus> -noconnect should ideally mean "no outgoing connections"
148 2016-10-24T06:40:13  <wumpus> ooh rowhammer on ARM, we're nowhere safe are we
149 2016-10-24T06:40:43  <gmaxwell> positive news, now that ECC memory will be needed to prevent users from controlling their own devices, we might get ecc memory in more devices.
150 2016-10-24T06:41:15  *** kadoban has quit IRC
151 2016-10-24T06:41:23  <gmaxwell> so I thought about "should it imply nodnsseed" and "what if you are goofy and combine connect=0 and addnode? should it still addnode?".
152 2016-10-24T06:42:02  <gmaxwell> the former seems like a harmless and reasonable thing to do, the latter... I dunno if it should touch the addnode behavior, I think probably not.
153 2016-10-24T06:42:06  <wumpus> I guess it should mean "no automatic connections"
154 2016-10-24T06:42:20  <gmaxwell> Yes. No automatic connections makes sense.
155 2016-10-24T06:42:23  <wumpus> if you really want to force a connection using addnode, I don't see why it should stop it
156 2016-10-24T06:42:44  <gmaxwell> Okay, I'll add the imply on dnsseed.
157 2016-10-24T06:43:06  <wumpus> yes stopping dnsseed is an optimiziation that makes sense
158 2016-10-24T06:43:21  <wumpus> why dnsseed if you're going to ignore the result
159 2016-10-24T06:43:32  <gmaxwell> hardly likely to cause a negative surprise... you won't know if you got seeded or not, with no automatic connections. :)
160 2016-10-24T06:43:51  <gmaxwell> well it's not a total no-op as it does update your peers.dat. If a tree falls in the forrest...
161 2016-10-24T06:44:16  <wumpus> well if you really insist on that you can still override it to true right? I suppose you're using 'soft' parameter interaction?
162 2016-10-24T06:44:23  <gmaxwell> Yep.
163 2016-10-24T06:46:02  <gmaxwell> oh actually any seting of connect already softsets dnsseed to off, even -noconnect.  (also listen too, which is potentially confusing, but historic, and conservative)
164 2016-10-24T06:46:09  <wumpus> re: android I'm happy that these kind of exploits allow full control of the device by their owner, on the other hand, OSes such as android *invite* people to install all kinds of bullshit apps because of their claimed secure sandbox, and all of those can take full control of the device too, that worries me
165 2016-10-24T06:47:03  <wumpus> ah yes that's true
166 2016-10-24T06:50:46  <wumpus> although the DRM-on-IoT thing is perverse, if someone hacks your phone (or toaster) through a rogue app, they will have root, but you can't get control yourself to chase them off again
167 2016-10-24T06:51:58  <wumpus> "how to hand the world to blackhats with one easy trick"
168 2016-10-24T06:53:59  <midnightmagic> wumpus: you're talking about rowhammer?
169 2016-10-24T06:54:21  *** aalex has quit IRC
170 2016-10-24T06:54:25  <gmaxwell> part of the reson we have this problem is due to technical illiteracy-- to Joe Blow, he doesn't know how to control his device in a meaningful way no matter how much root you give him;  so to actually take control from him (even while still accidentally giving it to hackers) doesn't seem like that big of a loss.
171 2016-10-24T06:54:50  <wumpus> yes rowhammer, though it similarly applies to dirty cow, or still-undisclosed-exploit-of-the-day
172 2016-10-24T06:57:28  *** BashCo_ has quit IRC
173 2016-10-24T06:58:30  *** aalex has joined #bitcoin-core-dev
174 2016-10-24T06:59:20  <wumpus> technical illiteracy is certainly part of the problem - another one would be lack of standards in regard to gaining control of a device by someone with technical literacy
175 2016-10-24T06:59:52  <midnightmagic> "It's okay I'm just going to root your phone.." "Uh, okay Jim. Would you like another beer too?"
176 2016-10-24T06:59:52  *** mkarrer has quit IRC
177 2016-10-24T07:00:01  *** mkarrer has joined #bitcoin-core-dev
178 2016-10-24T07:01:21  <wumpus> + stupid laws that disallow circumventing "
179 2016-10-24T07:01:25  <wumpus> security measures"
180 2016-10-24T07:01:41  <wumpus> all to protect mickey mouse, of course
181 2016-10-24T07:06:29  *** d_t has joined #bitcoin-core-dev
182 2016-10-24T07:06:58  <wumpus> "International Journal of Proof-of-Concept or Get The Fuck Out" hah I'd never seen that one written out
183 2016-10-24T07:15:49  <wumpus> -noconnect seems to work fine w/ 9002
184 2016-10-24T07:17:23  *** mkarrer_ has joined #bitcoin-core-dev
185 2016-10-24T07:18:55  <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f08222e882b1...fd29348dbe82
186 2016-10-24T07:18:56  <GitHub101> bitcoin/master 1d8e12b Pavel Janík: Fix doxygen comment: the transaction is returned in txOut
187 2016-10-24T07:18:56  <GitHub101> bitcoin/master fd29348 Wladimir J. van der Laan: Merge #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut...
188 2016-10-24T07:19:10  <GitHub145> [bitcoin] laanwj closed pull request #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut (master...20161021_fix_GetTransaction_comment) https://github.com/bitcoin/bitcoin/pull/8993
189 2016-10-24T07:20:33  *** mkarrer has quit IRC
190 2016-10-24T07:20:40  *** DigiByteDev has quit IRC
191 2016-10-24T07:21:52  *** BashCo has joined #bitcoin-core-dev
192 2016-10-24T07:23:24  *** justan0theruser has quit IRC
193 2016-10-24T07:25:28  *** whphhg has quit IRC
194 2016-10-24T07:31:44  *** whphhg has joined #bitcoin-core-dev
195 2016-10-24T07:39:50  *** Squidicc has joined #bitcoin-core-dev
196 2016-10-24T07:43:01  *** squidicuz has quit IRC
197 2016-10-24T07:47:46  *** Guest16408 is now known as thestringpuller
198 2016-10-24T07:47:54  *** thestringpuller has joined #bitcoin-core-dev
199 2016-10-24T07:50:36  <GitHub87> [bitcoin] unsystemizer opened pull request #9004: Clarify `listenonion` (master...patch-3) https://github.com/bitcoin/bitcoin/pull/9004
200 2016-10-24T07:51:07  *** d_t has quit IRC
201 2016-10-24T08:14:04  *** laurentmt has joined #bitcoin-core-dev
202 2016-10-24T08:14:39  <da2ce7> Hello, is there a overview of this blocksign feature that is being developed?
203 2016-10-24T08:15:36  <gmaxwell> da2ce7: I presume it would be a cut down port of whats in elements alpha.
204 2016-10-24T08:16:12  <da2ce7> I can only suppose it is only to be used for testnet.
205 2016-10-24T08:16:14  <gmaxwell> the motivation is just to have testnets that are less unreliable than a very small pow blockchain for use for testing that doesn't really care about the consensus mechenism.
206 2016-10-24T08:16:24  <gmaxwell> yea, of course.
207 2016-10-24T08:16:34  <gmaxwell> I'm curious where you heard about it where that wasn't clear?
208 2016-10-24T08:16:46  <wumpus> yes, which is the only thing that makes the implementation difficult in practice
209 2016-10-24T08:17:45  *** laurentmt has quit IRC
210 2016-10-24T08:18:15  <wumpus> if you are looking for a proposal to enable it on mainnet, there's none, no chance
211 2016-10-24T08:18:16  <da2ce7> I'm curious as it is similar to a feature that where a miner signs their block with a random key (with the pk fingerprint included in the coin base), where after-the-fact the miner could prove that he/she mined that block.
212 2016-10-24T08:18:51  <gmaxwell> that doesn't make a lot of sense, someone signing something doesn't demonstrate authorship
213 2016-10-24T08:19:16  <gmaxwell> instead, to achieve what you describe needs only a commitment to a public key in the block.
214 2016-10-24T08:19:50  <gmaxwell> Though it's somewhat important to the system that miners operate anonymously, to reduce their exposure to coersion.
215 2016-10-24T08:20:03  <da2ce7> well it dose prove that you own that public key, so it means that I cannot put _your_ public key in my block.
216 2016-10-24T08:21:49  <luke-jr> not necessarily. you could sign the template and ask me to mine it for you :p
217 2016-10-24T08:21:50  <gmaxwell> If the key is random and used once it doesn't really matter.
218 2016-10-24T08:23:26  <da2ce7> however then you would need a mechanism to enforce using a different key eveyblock.  Otherwise, BadMiner could put a GoodMiner public key, and be a nuance.
219 2016-10-24T08:24:10  <gmaxwell> da2ce7: huh? no... if you care about that you just ignore reuse.
220 2016-10-24T08:24:17  <da2ce7> *nuisance
221 2016-10-24T08:24:21  <gmaxwell> same as someone not providing a key at all.
222 2016-10-24T08:27:45  <da2ce7> well anyway, maybe there is no demand (or it isn't a wise thing at all), for there to be a standard way for miners to prove they made a particular block.
223 2016-10-24T08:27:51  *** Ylbam has joined #bitcoin-core-dev
224 2016-10-24T08:29:04  <gmaxwell> Sort of the opposite. I think it's extremely risky for the system for miners to be attaching any kind of identity to blocks at all.
225 2016-10-24T08:29:05  <da2ce7> it could/would make miner/share statistics more reliable if used, again, if that is a wise idea is very debatable.
226 2016-10-24T08:29:28  <gmaxwell> There are ways to do that without any publication of info to the general public though.
227 2016-10-24T08:32:08  <gmaxwell> (presumably we'll see a change to miners self identifying the first time after someone gets sued because someone was unhappy about which transactions they happened to confirm. :( )
228 2016-10-24T08:32:44  <da2ce7> I can imagine that it could be useful in the case the network was under a 51% attack, if miners could attach pseudo-anonymous identities to blocks. However it would be much preferable to never be in such a dystopian state.
229 2016-10-24T08:34:35  <da2ce7> anyway, off-topic.  Blocksign for testnet is good for testing :).
230 2016-10-24T08:38:26  <gmaxwell> yes, centeralizing the system can make it more secure against many kinds of attacks... :)
231 2016-10-24T08:50:12  *** fengling has quit IRC
232 2016-10-24T09:17:33  <GitHub42> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd29348dbe82...ced22d035ac0
233 2016-10-24T09:17:34  <GitHub42> bitcoin/master dfe7906 Matt Corallo: Add missing cs_main lock to ::GETBLOCKTXN processing...
234 2016-10-24T09:17:34  <GitHub42> bitcoin/master ced22d0 Wladimir J. van der Laan: Merge #8995: Add missing cs_main lock to ::GETBLOCKTXN processing...
235 2016-10-24T09:17:43  <GitHub156> [bitcoin] laanwj closed pull request #8995: Add missing cs_main lock to ::GETBLOCKTXN processing (master...2016-10-fix-getblocktxn-locks) https://github.com/bitcoin/bitcoin/pull/8995
236 2016-10-24T09:18:29  *** fengling has joined #bitcoin-core-dev
237 2016-10-24T09:32:08  *** fengling has quit IRC
238 2016-10-24T09:40:15  *** fengling has joined #bitcoin-core-dev
239 2016-10-24T09:45:27  *** gluytium has quit IRC
240 2016-10-24T10:37:11  *** Guyver2 has joined #bitcoin-core-dev
241 2016-10-24T10:44:38  *** aalex has quit IRC
242 2016-10-24T10:47:24  <arubi> wumpus, so specifically re. parsing partial transactions as pre-segwit (#8837), I actually hit this issue in my own toy parser and it shows in core too: http://paste.debian.net/plainh/8c80d8cd  so having some flag would be great
243 2016-10-24T10:47:47  <wumpus> thanks, so I wasn't being overly paranoid about that
244 2016-10-24T10:48:41  *** aalex has joined #bitcoin-core-dev
245 2016-10-24T10:48:46  <arubi> yea those 0 inputs pre segwit are something to think about when fundrawtransaction
246 2016-10-24T10:49:56  <wumpus> please comment on the issue too
247 2016-10-24T10:49:59  <wumpus> ah yes :(
248 2016-10-24T10:50:24  <arubi> well those fivepiece comments are mine :)
249 2016-10-24T10:50:42  <arubi> I'll copy this comment too
250 2016-10-24T10:57:05  *** gluytium has joined #bitcoin-core-dev
251 2016-10-24T11:01:16  *** cdecker has joined #bitcoin-core-dev
252 2016-10-24T11:01:33  *** fengling has quit IRC
253 2016-10-24T11:04:14  <wumpus> does anyone care about DecodeBase58 performance? If so, please review/test https://github.com/bitcoin/bitcoin/pull/8736
254 2016-10-24T11:04:23  *** jannes has joined #bitcoin-core-dev
255 2016-10-24T11:49:21  <jonasschnelli> during IBD, there is "chainActive" like (CChain) object that contains the headers-only chain?
256 2016-10-24T11:49:33  <jonasschnelli> *there is no "chainActive"
257 2016-10-24T11:50:11  <jonasschnelli> It looks like that getchaintips is ripping out the headers-tip from setOrphans
258 2016-10-24T11:54:52  *** Chris_Stewart_5 has joined #bitcoin-core-dev
259 2016-10-24T12:04:53  <jonasschnelli> nm: I think pindexBestHeader is acceptable for my usecase
260 2016-10-24T12:05:15  <wumpus> ok :)
261 2016-10-24T12:06:10  *** cryptapus_afk is now known as cryptapus
262 2016-10-24T12:10:36  *** Chris_Stewart_5 has quit IRC
263 2016-10-24T12:11:55  <jonasschnelli> hmm.. why points pindexBestHeader->pprev to pindexBestHeader?!
264 2016-10-24T12:12:10  <jonasschnelli> looks like it not traversable
265 2016-10-24T12:12:47  <jonasschnelli> again... nm! local issue.
266 2016-10-24T12:36:14  *** mr_burdell has joined #bitcoin-core-dev
267 2016-10-24T12:38:18  *** berndj-blackout has joined #bitcoin-core-dev
268 2016-10-24T12:39:45  *** trippysa1mon has joined #bitcoin-core-dev
269 2016-10-24T12:39:57  *** Pasha has joined #bitcoin-core-dev
270 2016-10-24T12:40:15  *** aj_ has joined #bitcoin-core-dev
271 2016-10-24T12:40:20  *** harding_ has joined #bitcoin-core-dev
272 2016-10-24T12:40:32  *** wolfspra1l has joined #bitcoin-core-dev
273 2016-10-24T12:40:43  *** haakonn_ has joined #bitcoin-core-dev
274 2016-10-24T12:42:47  *** instagibbs_ has joined #bitcoin-core-dev
275 2016-10-24T12:43:20  *** afk11_ has joined #bitcoin-core-dev
276 2016-10-24T12:43:33  *** bad_duck has joined #bitcoin-core-dev
277 2016-10-24T12:44:39  *** laurentmt has joined #bitcoin-core-dev
278 2016-10-24T12:45:20  *** whphhg has quit IRC
279 2016-10-24T12:45:20  *** wolfspraul has quit IRC
280 2016-10-24T12:45:21  *** instagibbs has quit IRC
281 2016-10-24T12:45:21  *** berndj has quit IRC
282 2016-10-24T12:45:21  *** Cory has quit IRC
283 2016-10-24T12:45:21  *** kcud_dab has quit IRC
284 2016-10-24T12:45:21  *** aj has quit IRC
285 2016-10-24T12:45:21  *** BonyM1 has quit IRC
286 2016-10-24T12:45:21  *** trippysalmon has quit IRC
287 2016-10-24T12:45:21  *** Guest13412 has quit IRC
288 2016-10-24T12:45:21  *** Arnavion has quit IRC
289 2016-10-24T12:45:21  *** haakonn has quit IRC
290 2016-10-24T12:45:22  *** afk11 has quit IRC
291 2016-10-24T12:45:22  *** harding has quit IRC
292 2016-10-24T12:46:10  *** laurentmt has quit IRC
293 2016-10-24T12:46:51  *** Pasha is now known as Cory
294 2016-10-24T12:51:42  *** whphhg has joined #bitcoin-core-dev
295 2016-10-24T12:53:37  *** BonyM1 has joined #bitcoin-core-dev
296 2016-10-24T12:59:45  *** aalex has quit IRC
297 2016-10-24T13:03:36  *** aalex has joined #bitcoin-core-dev
298 2016-10-24T13:09:43  *** aalex has quit IRC
299 2016-10-24T13:10:06  *** aalex has joined #bitcoin-core-dev
300 2016-10-24T13:14:26  *** aalex has quit IRC
301 2016-10-24T13:16:59  *** To7 has quit IRC
302 2016-10-24T13:18:22  *** aalex has joined #bitcoin-core-dev
303 2016-10-24T13:18:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
304 2016-10-24T13:23:06  *** jujumax has joined #bitcoin-core-dev
305 2016-10-24T13:24:36  *** aalex has quit IRC
306 2016-10-24T13:37:10  *** fengling has joined #bitcoin-core-dev
307 2016-10-24T13:41:06  *** jtimon has joined #bitcoin-core-dev
308 2016-10-24T13:48:40  *** fengling has quit IRC
309 2016-10-24T14:04:18  *** To7 has joined #bitcoin-core-dev
310 2016-10-24T14:08:49  *** berndj-blackout is now known as berndj
311 2016-10-24T14:19:00  *** bsm1175321 has joined #bitcoin-core-dev
312 2016-10-24T14:24:25  *** Chris_Stewart_5 has quit IRC
313 2016-10-24T14:24:52  *** cjcj_ has joined #bitcoin-core-dev
314 2016-10-24T14:26:54  *** dzijeka has joined #bitcoin-core-dev
315 2016-10-24T14:34:01  *** Arnavion has joined #bitcoin-core-dev
316 2016-10-24T14:38:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
317 2016-10-24T14:46:24  *** bsm1175321 is now known as bsm117532
318 2016-10-24T15:15:03  *** sumit_sethia has joined #bitcoin-core-dev
319 2016-10-24T15:17:38  *** sumit_sethia has quit IRC
320 2016-10-24T15:18:58  *** andytosh1 is now known as andytoshi
321 2016-10-24T15:20:15  *** BashCo has quit IRC
322 2016-10-24T15:20:52  *** BashCo has joined #bitcoin-core-dev
323 2016-10-24T15:25:03  *** BashCo has quit IRC
324 2016-10-24T15:36:02  *** Giszmo1 has quit IRC
325 2016-10-24T15:42:11  *** jujumax has quit IRC
326 2016-10-24T15:45:13  *** paveljanik has joined #bitcoin-core-dev
327 2016-10-24T15:49:51  *** Giszmo has joined #bitcoin-core-dev
328 2016-10-24T15:56:43  *** BashCo has joined #bitcoin-core-dev
329 2016-10-24T16:25:14  <BlueMatt> wait, what?
330 2016-10-24T16:25:52  <BlueMatt> argh, we did break addnode :(
331 2016-10-24T16:26:08  <sipa> how so?
332 2016-10-24T16:26:38  <BlueMatt> i was just trying to use it for fibre and the hostname as both ipv4 and ipv6 but it will only try to connect to one resolved addr even though the other one will work
333 2016-10-24T16:27:06  <sipa> hmm
334 2016-10-24T16:27:10  <BlueMatt> i didnt realize we broke the pick-different-address-if-it-doesnt-connect logic :(
335 2016-10-24T16:28:03  <sipa> i didn't think so either
336 2016-10-24T16:28:38  <BlueMatt> there doesnt seem to be any handling for it
337 2016-10-24T16:29:06  <sipa> ConnectSocketByName should pick a random resolved address for each attempt
338 2016-10-24T16:29:57  <BlueMatt> ThreadOpenAddedConnections does a LooupNumeric before calling OpenNetworkConnection
339 2016-10-24T16:30:51  <BlueMatt> lol, the client in question doesnt even have a v6 default route...bitcoind was trying (and failing) to connect to the v6 host, it seems :/
340 2016-10-24T16:30:52  <sipa> and LookupNuumeric will fail if it's not a x.y.z.w or aaaa::bbbb:ccc or .onion style string
341 2016-10-24T16:30:57  <BlueMatt> ahh
342 2016-10-24T16:31:03  <BlueMatt> hmm, maybe they just didnt wait long enough
343 2016-10-24T16:31:44  <BlueMatt> but it did try to connect to v6, get a network unreachable error, and give up :(
344 2016-10-24T16:32:19  <sipa> it will only retry 2 minutes later, i think
345 2016-10-24T16:32:56  <BlueMatt> yes, it did, and tried again to ipv6
346 2016-10-24T16:33:06  <BlueMatt> though if its random i suppose he could have waited longer and maybe it would have worked
347 2016-10-24T16:33:22  <BlueMatt> though its possible the hosts ipv6-preference logic is bad?
348 2016-10-24T16:33:42  <Lightsword> it’s a fairly standard EC2 ubuntu 16.04 VPS
349 2016-10-24T16:34:12  <sipa> maybe it only resolves to IPv6 addresses for some reason?
350 2016-10-24T16:34:15  <BlueMatt> Lightsword: can you disconnect the ipv4 peer and just addnode the hostname and wait a few sets of 2 minutes?
351 2016-10-24T16:44:30  *** jtimon has quit IRC
352 2016-10-24T16:44:36  <Lightsword> BlueMatt, yeah not seeing any connection
353 2016-10-24T16:44:55  <Lightsword> 2016-10-24 16:40:07.057232 trying connection us-west.fibre.bitcoinrelaynetwork.org lastseen=0.0hrs
354 2016-10-24T16:44:56  <Lightsword> 2016-10-24 16:40:07.237914 connect() to [2607:f0d0:2002:169::2]:8333 failed: Network is unreachable (101)
355 2016-10-24T16:45:20  <BlueMatt> yea, so it seems broken :(
356 2016-10-24T16:46:00  *** Squidicc is now known as squidicuz
357 2016-10-24T16:46:17  <BlueMatt> argh, someone wanna tag https://github.com/bitcoin/bitcoin/issues/9007 0.13.1?
358 2016-10-24T16:49:35  <paveljanik> I can't do so, sorry.
359 2016-10-24T16:52:03  <wumpus> already done
360 2016-10-24T16:53:19  <wumpus> another assert that should be removed, like 1ab21cf344ed0547de5ae679b7e479cb4b1a923b I guess...
361 2016-10-24T16:53:25  *** kadoban has joined #bitcoin-core-dev
362 2016-10-24T16:53:37  <wumpus> should check there's no other weird asserts added
363 2016-10-24T16:53:53  <sipa> is 9007 in 0.13?
364 2016-10-24T16:54:59  <wumpus> yes
365 2016-10-24T16:56:07  <wumpus> https://github.com/bitcoin/bitcoin/blob/0.13/src/net.cpp#L1024
366 2016-10-24T16:56:46  <sipa> ah, caused by feelers?
367 2016-10-24T16:57:28  <wumpus> yes, maxconnections cannot be lower than maxoutbound+maxfeeler, I suppose if he'd just set maxconnections=9 it'd be ok
368 2016-10-24T16:58:12  <gmaxwell> addnode can take you beyond the nMaxOutbound count.
369 2016-10-24T16:58:46  <wumpus> that's not what that assert is checking though
370 2016-10-24T16:59:09  <wumpus> it doesn't look at your actual connections, just the max possible
371 2016-10-24T16:59:26  <gmaxwell> ah, indeed.
372 2016-10-24T16:59:48  <gmaxwell> that should be a return, not an assert, in any case.
373 2016-10-24T16:59:55  * gmaxwell feels stupid for missing that.
374 2016-10-24T17:04:13  <gmaxwell> There was another inappropriate assert added in the same commit, but it was already removed by PR 8944.
375 2016-10-24T17:04:16  <wumpus> well the previous assert based bug was that
376 2016-10-24T17:04:22  <wumpus> right
377 2016-10-24T17:07:43  <gmaxwell> sipa: I can't see how that couldn't be reproduced in rc2.
378 2016-10-24T17:10:22  <gmaxwell> even returning there wouldn't be right.
379 2016-10-24T17:10:56  <gmaxwell> lets say I set -connect= and maxconnections=4 ... I should still be able to accept 3 connections.
380 2016-10-24T17:11:45  *** Cheeseo has joined #bitcoin-core-dev
381 2016-10-24T17:11:49  *** Cheeseo has joined #bitcoin-core-dev
382 2016-10-24T17:11:56  <sipa> if you set -connect, isn't listening disabled by default?
383 2016-10-24T17:12:35  <gmaxwell> its softset off.
384 2016-10-24T17:12:50  <gmaxwell> so if you -connect + listen=1 to be precise.
385 2016-10-24T17:13:15  <sipa> ok
386 2016-10-24T17:14:12  <gmaxwell> I was about to suggest that maxconnections<8 should hard force listen off, because then it would make it easier to troubleshoot why things aren't connecting; then realized that no actually in some configs inbounds should still be working even with low max connections.
387 2016-10-24T17:16:50  <gmaxwell> wait.. what.. is eviction now broken?!
388 2016-10-24T17:18:26  <gmaxwell> okay, its not, just kind of stupid.
389 2016-10-24T17:20:40  <gmaxwell> without the insert, the -noconnect + listen=1 case with maxconnections<8 will continually try evicting a connection and fail.
390 2016-10-24T18:02:44  *** Giszmo has quit IRC
391 2016-10-24T18:06:35  <morcos> sipa: sorry for the annoying questions here..  it appears to me that the dynamic memory usage tracking in CCoinsViewCache assumes that the memory usage of a pruned coins is 0.  i'm guess this is usually the case, but its not guaranteed right?   (depends on capacity = 0)
392 2016-10-24T18:07:16  *** laurentmt has joined #bitcoin-core-dev
393 2016-10-24T18:07:26  <sipa> morcos: i believe we actually always call CCoins::Cleanup()
394 2016-10-24T18:07:45  <sipa> which sets the capacity to 0
395 2016-10-24T18:07:47  <morcos> i was trying to track down some signficant variations between actual usage and the tracked usage that appear in my code.. and am starting by trying to understand why the existing code is correct
396 2016-10-24T18:07:55  <morcos> well it calls a new vector and swaps
397 2016-10-24T18:08:09  <sipa> yes, that was the C++03 trick to set the capacity to 0
398 2016-10-24T18:08:09  <morcos> but from my googling it seems implementation dependent whether a new vector has capacity 0?
399 2016-10-24T18:08:12  *** laurentmt has quit IRC
400 2016-10-24T18:08:39  <sipa> ok, i agree there is in theory a standard-compliant implementations which doesn't have that behaviour
401 2016-10-24T18:08:48  *** cheese_ has joined #bitcoin-core-dev
402 2016-10-24T18:09:03  <morcos> ok..  i noticed that a while ago.. and its probably not the cause of my problem, but just wanted to understand
403 2016-10-24T18:09:11  <morcos> second , kind of unrelated question
404 2016-10-24T18:09:34  <morcos> prevector.resize(0) doesn't seem like the fastest way to clean up a prevector<unsigned char> does it?
405 2016-10-24T18:09:41  <sipa> the c++11 way is std::vector::shrink_to_fit() btw
406 2016-10-24T18:10:13  *** Giszmo has joined #bitcoin-core-dev
407 2016-10-24T18:10:14  <morcos> looking at the resize code, it calls erase, which iterates the elements destructing them
408 2016-10-24T18:10:47  <morcos> but in our case where we're always using unsigned chars and we want to clear the whole thing.. couldn't we do that faster?
409 2016-10-24T18:11:09  <sipa> so there is a question of what prevector should support
410 2016-10-24T18:11:29  <sipa> if it can only contain POD types, i think more complexity can go away
411 2016-10-24T18:11:43  *** Cheeseo has quit IRC
412 2016-10-24T18:12:03  <sipa> but if it's to be value for any movable c++ type (as it does now), it has to call erase (which may still be optimized out, when instanciated for simple types)
413 2016-10-24T18:12:15  <sipa> i thought cfields_ was working on some improvements to prevector?
414 2016-10-24T18:12:41  <cfields_> sipa: one of many things that got to 90% and shelved.
415 2016-10-24T18:13:00  <sipa> s/erase/destructors/
416 2016-10-24T18:13:05  <morcos> maybe.. i'm not sure.   seems like it might be nice to at least optimize that one particular case, would we subtemplate or something that particular call.
417 2016-10-24T18:13:32  <cfields_> sipa: in particular, I was doing a specialiazation for size=1
418 2016-10-24T18:13:43  <sipa> yes, in c++11 you can use templates to figure out whether it's POD, and use a simpler implementation in that case or something
419 2016-10-24T18:13:50  <cfields_> since that's our main use-case, and you can get huge speedups with that assumption
420 2016-10-24T18:14:10  <morcos> ok..   thanks for the thoughts..
421 2016-10-24T18:23:08  *** dermoth has quit IRC
422 2016-10-24T18:31:32  *** cjcj_ has quit IRC
423 2016-10-24T18:36:38  *** MarcoFalke has joined #bitcoin-core-dev
424 2016-10-24T19:07:20  *** laurentmt has joined #bitcoin-core-dev
425 2016-10-24T19:19:21  *** laurentmt has quit IRC
426 2016-10-24T19:32:03  *** roasbeef_ is now known as roasbeef
427 2016-10-24T19:34:35  *** a_meteorite has joined #bitcoin-core-dev
428 2016-10-24T19:52:19  *** Chris_Stewart_5 has quit IRC
429 2016-10-24T20:13:39  <GitHub49> [bitcoin] MarcoFalke opened pull request #9008: [net] Remove assert(nMaxInbound > 0) (master...Mf1610-netAssert) https://github.com/bitcoin/bitcoin/pull/9008
430 2016-10-24T20:21:45  *** davec has quit IRC
431 2016-10-24T20:22:58  *** davec has joined #bitcoin-core-dev
432 2016-10-24T20:29:22  *** laurentmt has joined #bitcoin-core-dev
433 2016-10-24T20:33:24  *** d_t has joined #bitcoin-core-dev
434 2016-10-24T20:34:23  *** instagibbs_ is now known as instagibbs
435 2016-10-24T20:38:25  *** laurentmt has quit IRC
436 2016-10-24T20:48:57  <btcdrak> https://github.com/bitcoin-core/bitcoincore.org/pull/239
437 2016-10-24T21:04:53  *** Alina-malina is now known as alina-malina
438 2016-10-24T21:09:32  *** MarcoFalke has quit IRC
439 2016-10-24T21:24:26  *** Guyver2 has quit IRC
440 2016-10-24T21:39:41  *** cryptapus is now known as cryptapus_afk
441 2016-10-24T21:54:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
442 2016-10-24T21:54:11  *** cryptapus has joined #bitcoin-core-dev
443 2016-10-24T21:54:11  *** cryptapus has joined #bitcoin-core-dev
444 2016-10-24T21:58:44  *** cryptapus has quit IRC
445 2016-10-24T21:58:57  <nibor> Could someone let me know what they think about:  https://gist.github.com/n1bor/d5b0330a9addb0bf5e0f869518883522
446 2016-10-24T21:59:45  <nibor> Is a functioning proof of concept of chainstate only sync. Syncs in about 30mins to a pruned full node state.
447 2016-10-24T22:00:29  <nibor> Obviously need a soft-fork to be any use.
448 2016-10-24T22:08:30  *** midnightmagic has quit IRC
449 2016-10-24T22:09:45  *** justanotheruser has joined #bitcoin-core-dev
450 2016-10-24T22:10:06  <gmaxwell> nibor: it's more frequent than the model I've been thinking of. For security reasons you really don't want to have a case where miners could make a 100 block fork and then forward print themselves a lot of coins. :)  Also it's quite common for nodes to be offline for 1-2 weeks, so if nodes aren't keeping that much in blocks easily available, then security redegrades to SPV history (new chainstat
451 2016-10-24T22:10:12  <gmaxwell> e sync). ... and downloading and syncing a few thousand blocks isn't really slow compared to 100 (relative to current sync times).
452 2016-10-24T22:10:26  <gmaxwell> This is all particular relevant because the snapshot management means that different peers really can't choose their own checking time.
453 2016-10-24T22:10:35  <gmaxwell> I'd been thinking of something that was more like a 3 month interval.
454 2016-10-24T22:11:25  <gmaxwell> Petertodd will protest that requring a particular UTXO set construction will be a hard barrier to even more scalable things like STXO commitments in the future.  I came up with a solution to that which you might want to use:
455 2016-10-24T22:12:30  <gmaxwell> Two softfork rules: (1) if the commitment is present, it must be correct. and (2) the commitment must be present from activation until block XXX.   If halfway to XXX everyone is still happy with the scheme, a new softfork is applied that says the commitment must be presnet until YYY.
456 2016-10-24T22:12:49  <gmaxwell> That way if someothing better comes along, the commitment can eventually be dropped in a smooth and compatible manner.
457 2016-10-24T22:13:06  <gmaxwell> (perhaps making new installs of old software take a long time to sync :) )
458 2016-10-24T22:14:01  <gmaxwell> nibor: the hash chunking thing should use some kind of tree hash, it probably doesn't need to go down to the indivigual entry, but if I fetch chunks from N peers in parallel and one peer gives me garbage, I should be able to tell _which_ peer gave me garbage, otherwise you get DOS attacks.
459 2016-10-24T22:15:21  <nibor> Could not see how tree helped. The snapshot message contains hash of all the chunks. So you know if a node is nasty after the 1st chunk.
460 2016-10-24T22:16:32  <gmaxwell> okay, that potentially makes the snapshot message quite large, the only difference that a tree would make is that the snapshot value is just the single hash in the blockchain, and the chunks give you enough to verify membership.
461 2016-10-24T22:17:12  <nibor> Regarding gap between snapshots problem with going too long is that the chainstate grows quite fast. Keeping snapshot from 300 blocks back makes chainstate 2.4G vs 1.7G with no snapshots.
462 2016-10-24T22:17:13  <gmaxwell> The other important thing about this proposal is that it needs to be very upfront about this being a signficant change to the Bitcoin security model, and justify it.  I believe it is a nessary one.
463 2016-10-24T22:18:19  <gmaxwell> We generally need to engineer for the worst case, so we should probably just assume that they're maximum size even though fancy COW handling could reduce that.
464 2016-10-24T22:18:25  <nibor> Current snapshot message is about 200k and chunks are about 200k each. So msgs small so should scale by factor of 10..
465 2016-10-24T22:18:36  <gmaxwell> reorginizing chainstate into 'old' and 'new' could help with that churn fwiw.
466 2016-10-24T22:19:32  <nibor> Annoyingly the leveldb snapshots are only held in RAM. So with a big gap node would really need to do a bit rewind to check state.
467 2016-10-24T22:19:49  <gmaxwell> yea, I was surprised you got this working using leveldb snapshots.
468 2016-10-24T22:20:08  <nibor> s/bit/big/
469 2016-10-24T22:20:53  <nibor> Not sure I understand your 1st comment though. About miners creating big fork?
470 2016-10-24T22:21:07  <gmaxwell> no rewind should be needed however, you should compute the hash as it goes by, e.g. snapshot at the height as you validate it, then at two blocks after, start computing the hash, and just save it.
471 2016-10-24T22:22:11  <nibor> Sorry - yes you are right. Was thinking of putting hash 20 blocks after chainstate. So have time to compute even when chainstate say 50gig.
472 2016-10-24T22:22:57  <gmaxwell> (50 gb chainstate is likely unworkable with leveldb :(  but thats an aside. :) )
473 2016-10-24T22:23:45  <nibor> Prob ok with 64Gig RAM... In day job just order 2 boxes with 2Tb so not so much..
474 2016-10-24T22:23:52  <gmaxwell> nibor: majority hashpower can make their new commitment say that a million bitcoin that wasn't theirs is now theirs. Then all newly joining nodes will get the new chainstate, and eventually all old nodes will think they've hit a reorg larger than people have blocks available, and so they'll do a chainstate sync too...
475 2016-10-24T22:24:15  <gmaxwell> nibor: we'd like to have a decenteralized system you know, :P
476 2016-10-24T22:26:28  <nibor> With a 100gig download?...
477 2016-10-24T22:26:37  <gmaxwell> nibor: did you understand my "phase out" suggestion? (the line refereincing petertodd)
478 2016-10-24T22:27:29  <gmaxwell> nibor: more people handle a 100 GB download today than have more than 8GB ram available. (in particular hosted systems, VPSes, are often quite ram starved) but we're on a tangent.
479 2016-10-24T22:28:34  <nibor> Not sure I do.. but might in a bit...
480 2016-10-24T22:29:08  <gmaxwell> OKAY.
481 2016-10-24T22:29:12  <gmaxwell> In any case, exciting work
482 2016-10-24T22:29:18  <gmaxwell> Your POC is awesome.
483 2016-10-24T22:29:35  <nibor> Thinking about a 3month interval. That is quite easy. Just copy the whole chainstate to another leveldb. Is not more work than hashing it really.
484 2016-10-24T22:29:35  *** murch has joined #bitcoin-core-dev
485 2016-10-24T22:30:18  <gmaxwell> Or not another leveldb but just a seralized flat blob.
486 2016-10-24T22:30:34  <gmaxwell> It would be faster and more space efficient. And random access is not needed, except to chunks.
487 2016-10-24T22:30:53  <gmaxwell> (could be one file per chunk. Though 8000 chunks is a bit excessive for that.)
488 2016-10-24T22:31:32  <nibor> Not really - leveldb is up to 1000 files.
489 2016-10-24T22:31:38  <gmaxwell> I believe that only needs two snapshots at any time too...
490 2016-10-24T22:32:04  *** jtimon has joined #bitcoin-core-dev
491 2016-10-24T22:32:22  <nibor> Yes - I only had 3 cos was short gap. And did not want a client that took over 100 blocks to download be left with nothing to find.
492 2016-10-24T22:33:16  <nibor> Will think about Petertodd issue to. Is nasty to cause future issues.
493 2016-10-24T22:34:01  <nibor> I guess some of the 100fork issues would be reduced if client back populated blocks over time.
494 2016-10-24T22:34:09  <gmaxwell> There is a longer term proposal that would eliminate the utxo set, effectively, that we don't want to block.
495 2016-10-24T22:34:46  <gmaxwell> nibor: yes, though if we just want the fastest possible start, it could start immediately as SPV, and then back populate.. irrespective of the snapshotting behavior.
496 2016-10-24T22:36:36  <nibor> Thanks for thoughts... am off now. Will see what others think..
497 2016-10-24T22:36:37  <gmaxwell> (just as background for you: the way the utxo set is eliminated, is that there is a small, perhaps fixed size utxo set, and transactions are expired out of it and commited into an insertion ordered hash tree... then when spending one of those outputs the spending transaction must provide a membership and update proof that lets nodes verify it was there and mark the entry as spent)
498 2016-10-24T22:36:43  <gmaxwell> Great!
499 2016-10-24T22:38:25  <murch> Hey gmaxwell, I was missing you at Scaling Bitcoin. :)
500 2016-10-24T22:39:11  <murch> I was curios what you'd say about my coin selection talk after we had chatted here about it.
501 2016-10-24T22:46:10  *** molz has joined #bitcoin-core-dev
502 2016-10-24T22:48:32  <gmaxwell> molz: I was sad to see that wider-match only made a fairly modest improvement!
503 2016-10-24T22:49:02  <sipa> s/molz/murch/
504 2016-10-24T22:49:05  <gmaxwell> oops!
505 2016-10-24T22:49:07  <gmaxwell> murch:
506 2016-10-24T22:49:28  <molz> haha i was scratching my head "what's the wider-match" lol
507 2016-10-24T22:49:45  *** moli has quit IRC
508 2016-10-24T22:50:03  <murch> gmaxwell: After Scaling Bitcoin I came up with a new algorithm. I'm still running experiments on it (and writing my evaluation chapter, thesis is due next week), but it looks pretty promising in all aspects.
509 2016-10-24T22:50:25  <murch> It has a much higher rate of direct matches than the current core coin selection and is less computationally expensive.
510 2016-10-24T22:50:25  <molz> gmaxwell, btw, is there a way to load the ban list into my node or do i have to type each line manually?
511 2016-10-24T22:50:46  <sipa> molz: they're remembered across restarts already
512 2016-10-24T22:50:47  <sipa> bans.dat
513 2016-10-24T22:51:06  <gmaxwell> murch: one thing your framework doesn't consider is patalogical cases, in the past, people actually attacked litecoin wallets by paying them lots of dust, with enough of it, the subset sum solver would come up with solutions so bad that it couldn't transact.
514 2016-10-24T22:51:11  <molz> sipa but i haven't banned any bad nodes
515 2016-10-24T22:51:21  <gmaxwell> They 'solved' this in a really kludgy way just making the wallet ignore payments below a dust threshold.
516 2016-10-24T22:51:40  <gmaxwell> molz: just paste the lines in a sutiable format.
517 2016-10-24T22:52:20  <molz> yea i meant copy and paste, ok thanks
518 2016-10-24T22:52:23  <gmaxwell> murch: so I think SRD would suffer badly from that.  But I think that could be addressed by trying multiple strategies and taking the 'best'.
519 2016-10-24T22:52:44  <gmaxwell> molz: I put up pastbins with the commands in cli format as well as sutiable for pasting into the debug console..
520 2016-10-24T22:52:48  <murch> gmaxwell: Yeah, that's true. My new algorithm uses a two phase approach. First it purposefully looks for direct matches. It will not consider inputs there that have a negative payload (more fees than value), but after that it falls back to random selection, which may spend small inputs over time.
521 2016-10-24T22:53:04  <murch> (Experiment is still running, can't give you good details on the final set composition yet)
522 2016-10-24T22:54:14  <gmaxwell> By direct matches, you mean no change created--but possible 'extra fee', not one-input only, right?
523 2016-10-24T22:54:33  <murch> gmaxwell: yeah, that
524 2016-10-24T22:54:39  <gmaxwell> Good! sounds reasonable to me.
525 2016-10-24T22:54:48  <gmaxwell> Then again lots of things that didn't work sounded reasonable to me.
526 2016-10-24T22:55:41  <murch> Since a change output causes an additional output on creation, then an additional input some time in the future. So I allow up to the cost of one input + one output as a padding for the "exact" match.
527 2016-10-24T22:56:49  <murch> gmaxwell: Is a "flood with dust" attack still reasonable? I thought that transactions with dust outputs are considered non-standard and they'd have a hard time getting confirmed?
528 2016-10-24T22:57:00  <gmaxwell> Good, that is a rational way to set it. (arguably, even more would be justified either on the basis of of fees being higher in the future, or on the basis of that you may get faster confirmation for it... but your approach sounds reasonably conservative)
529 2016-10-24T22:57:51  <gmaxwell> murch: That particular one, perhaps less so (well a miner could do it fine)-- but I meant it more of a concrete example that patalogical cases could be created and it is desirable if the wallet doesn't behave badly in any situation easily setup by an attacker.
530 2016-10-24T22:58:14  <murch> mh.
531 2016-10-24T22:58:26  <murch> I haven't considered that attack scenario too much yet.
532 2016-10-24T22:58:32  <gmaxwell> e.g. if you have one 50 btc input and 200 0.00001 inputs (still above dust threshold!) ... then the random selection would pick a pretty bad solution.
533 2016-10-24T22:58:46  <murch> I was thinking to replace the SDR fall back with 7 random drawings and the median input set size
534 2016-10-24T22:58:51  <murch> or some similar scheme
535 2016-10-24T22:59:06  <gmaxwell> (er my example just now should have also said "and you try to pay 1 btc")
536 2016-10-24T22:59:19  <murch> random drawing should have nice privacy properties though, and generates a wider range of utxos which are beneficial for finding direct matches
537 2016-10-24T22:59:42  <murch> gmaxwell: Yes, of course.
538 2016-10-24T23:00:25  <gmaxwell> I agree, well you don't have data for it too, but I think all cases the selection should try to spend all inputs paid to a particular scriptpubkey to limit linkage graph inflation, but that can be layered right on top of your ideas by treating a input set as an input.
539 2016-10-24T23:00:47  <murch> exactly
540 2016-10-24T23:01:09  <murch> I'm planning to put addresses in my simulation in the future, but right now I'm focusing on writing up what I have. ;)
541 2016-10-24T23:01:19  <murch> I have to print next wednesday. :D
542 2016-10-24T23:01:34  <murch> gmaxwell: https://github.com/Xekyo/CoinSelectionSimulator/blob/master/src/BnBWallet.scala#L59
543 2016-10-24T23:01:48  <murch> This is the new algorithm I have come up with, in case you want to take a look
544 2016-10-24T23:02:40  <murch> gmaxwell: some preliminary results on the same data set I talked about at Scaling Bitcoin: https://docs.google.com/spreadsheets/d/1dzugGnAw2nBNL_BwpFR44jci8rO3RkkF5M9OcP2ESN0/pubhtml
545 2016-10-24T23:02:46  *** jujumax has joined #bitcoin-core-dev
546 2016-10-24T23:03:00  <murch> the perpetrator is "BranchAndBoundWallet"
547 2016-10-24T23:04:20  *** midnightmagic has joined #bitcoin-core-dev
548 2016-10-24T23:04:36  <murch> What I also like is that it has a very low standard deviation in the input set. (Although, as you have pointed out, I have not considered pathological cases yet.)
549 2016-10-24T23:07:28  *** LeMiner has quit IRC
550 2016-10-24T23:07:58  *** michagogo has quit IRC
551 2016-10-24T23:08:23  *** cdecker has quit IRC
552 2016-10-24T23:10:11  *** michagogo has joined #bitcoin-core-dev
553 2016-10-24T23:13:15  *** midnightmagic has quit IRC
554 2016-10-24T23:14:29  *** LeMiner has joined #bitcoin-core-dev
555 2016-10-24T23:15:49  *** jujumax has quit IRC
556 2016-10-24T23:24:21  *** midnightmagic has joined #bitcoin-core-dev
557 2016-10-24T23:24:39  *** laurentmt has joined #bitcoin-core-dev
558 2016-10-24T23:30:07  *** tulip has quit IRC
559 2016-10-24T23:33:43  *** BlueMatt has quit IRC
560 2016-10-24T23:34:00  *** BlueMatt has joined #bitcoin-core-dev
561 2016-10-24T23:34:54  *** laurentmt has quit IRC
562 2016-10-24T23:38:38  *** gijensen92 has joined #bitcoin-core-dev
563 2016-10-24T23:43:32  *** whphhg has quit IRC
564 2016-10-24T23:43:32  *** haakonn_ has quit IRC
565 2016-10-24T23:43:32  *** squidicuz has quit IRC
566 2016-10-24T23:43:32  *** Soligor has quit IRC
567 2016-10-24T23:43:33  *** gmaxwell has quit IRC
568 2016-10-24T23:43:33  *** nickler_ has quit IRC
569 2016-10-24T23:43:33  *** PaulCapestany has quit IRC
570 2016-10-24T23:43:33  *** eragmus has quit IRC
571 2016-10-24T23:43:33  *** mappum has quit IRC
572 2016-10-24T23:43:33  *** CodeShark has quit IRC
573 2016-10-24T23:43:33  *** neha has quit IRC
574 2016-10-24T23:43:34  *** [b__b] has quit IRC
575 2016-10-24T23:43:34  *** GreenIsMyPepper has quit IRC
576 2016-10-24T23:44:25  *** whphhg has joined #bitcoin-core-dev
577 2016-10-24T23:44:25  *** haakonn_ has joined #bitcoin-core-dev
578 2016-10-24T23:44:25  *** squidicuz has joined #bitcoin-core-dev
579 2016-10-24T23:44:25  *** Soligor has joined #bitcoin-core-dev
580 2016-10-24T23:44:25  *** gmaxwell has joined #bitcoin-core-dev
581 2016-10-24T23:44:25  *** nickler_ has joined #bitcoin-core-dev
582 2016-10-24T23:44:25  *** PaulCapestany has joined #bitcoin-core-dev
583 2016-10-24T23:44:25  *** eragmus has joined #bitcoin-core-dev
584 2016-10-24T23:44:25  *** mappum has joined #bitcoin-core-dev
585 2016-10-24T23:44:25  *** CodeShark has joined #bitcoin-core-dev
586 2016-10-24T23:44:25  *** neha has joined #bitcoin-core-dev
587 2016-10-24T23:44:25  *** [b__b] has joined #bitcoin-core-dev
588 2016-10-24T23:44:27  *** GreenIsMyPepper has joined #bitcoin-core-dev
589 2016-10-24T23:44:33  *** AtashiCon has quit IRC
590 2016-10-24T23:44:35  *** Arnavion3 has joined #bitcoin-core-dev
591 2016-10-24T23:44:35  *** gijensen has quit IRC
592 2016-10-24T23:44:37  *** gijensen92 is now known as gijensen
593 2016-10-24T23:44:38  *** Arnavion3 is now known as AtashiCon
594 2016-10-24T23:46:25  *** zmanian____ has quit IRC
595 2016-10-24T23:50:56  *** zmanian____ has joined #bitcoin-core-dev