12016-10-24T00:36:20  *** Cheeseo has joined #bitcoin-core-dev
  22016-10-24T00:38:11  *** Cheeseo has quit IRC
  32016-10-24T00:41:37  *** blkdb has quit IRC
  42016-10-24T00:41:42  *** blkdb has joined #bitcoin-core-dev
  52016-10-24T00:42:17  *** jouke has joined #bitcoin-core-dev
  62016-10-24T00:42:18  *** roasbeef_ has joined #bitcoin-core-dev
  72016-10-24T00:42:20  *** andytosh1 has joined #bitcoin-core-dev
  82016-10-24T00:43:26  *** nickler_ has joined #bitcoin-core-dev
  92016-10-24T00:43:38  *** roasbeef has quit IRC
 102016-10-24T00:43:40  *** jouke_ has quit IRC
 112016-10-24T00:43:40  *** nickler has quit IRC
 122016-10-24T00:43:41  *** andytoshi has quit IRC
 132016-10-24T00:43:41  *** helo has quit IRC
 142016-10-24T00:44:16  *** fengling has quit IRC
 152016-10-24T00:44:53  *** jujumax has quit IRC
 162016-10-24T00:47:23  *** jujumax has joined #bitcoin-core-dev
 172016-10-24T00:49:23  *** e4xit_ has joined #bitcoin-core-dev
 182016-10-24T00:49:24  *** helo has joined #bitcoin-core-dev
 192016-10-24T00:50:35  *** jl2012_ has joined #bitcoin-core-dev
 202016-10-24T00:51:41  *** Giszmo1 has joined #bitcoin-core-dev
 212016-10-24T00:53:12  *** jl2012 has quit IRC
 222016-10-24T00:53:12  *** e4xit has quit IRC
 232016-10-24T00:53:12  *** Giszmo has quit IRC
 242016-10-24T00:53:12  *** e4xit_ is now known as e4xit
 252016-10-24T00:53:13  *** jl2012_ is now known as jl2012
 262016-10-24T00:55:05  *** jtimon has quit IRC
 272016-10-24T00:57:29  *** ill has joined #bitcoin-core-dev
 282016-10-24T01:04:04  *** isis has quit IRC
 292016-10-24T01:07:02  *** DigiByteDev has joined #bitcoin-core-dev
 302016-10-24T01:11:44  *** gmaxwell has quit IRC
 312016-10-24T01:19:05  *** so has joined #bitcoin-core-dev
 322016-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
 332016-10-24T01:27:05  *** Ylbam has quit IRC
 342016-10-24T01:29:39  *** gmaxwell has joined #bitcoin-core-dev
 352016-10-24T01:31:50  *** da2ce7_ has quit IRC
 362016-10-24T01:31:50  *** kanzure has quit IRC
 372016-10-24T01:31:50  *** zxzzt_ has quit IRC
 382016-10-24T01:31:50  *** thestringpuller has quit IRC
 392016-10-24T01:31:51  *** wolfspraul has quit IRC
 402016-10-24T01:31:51  *** eenoch has quit IRC
 412016-10-24T01:31:51  *** lesderid has quit IRC
 422016-10-24T01:31:58  *** wolfspraul has joined #bitcoin-core-dev
 432016-10-24T01:32:27  *** Soligor has quit IRC
 442016-10-24T01:32:27  *** jeremyrubin has quit IRC
 452016-10-24T01:32:27  *** petertodd has quit IRC
 462016-10-24T01:33:05  *** eenoch has joined #bitcoin-core-dev
 472016-10-24T01:33:11  *** kanzure has joined #bitcoin-core-dev
 482016-10-24T01:33:11  *** thestringpuller has joined #bitcoin-core-dev
 492016-10-24T01:33:15  *** zxzzt has joined #bitcoin-core-dev
 502016-10-24T01:33:35  *** thestringpuller is now known as Guest16408
 512016-10-24T01:33:47  *** petertodd has joined #bitcoin-core-dev
 522016-10-24T01:33:52  *** jeremyrubin has joined #bitcoin-core-dev
 532016-10-24T01:38:05  *** lesderid has joined #bitcoin-core-dev
 542016-10-24T01:39:53  *** da2ce7 has joined #bitcoin-core-dev
 552016-10-24T01:40:19  *** ill has quit IRC
 562016-10-24T01:43:05  *** ill has joined #bitcoin-core-dev
 572016-10-24T01:45:19  *** Soligor has joined #bitcoin-core-dev
 582016-10-24T01:47:18  *** ill has quit IRC
 592016-10-24T01:54:13  *** jujumax has quit IRC
 602016-10-24T01:54:40  *** ill has joined #bitcoin-core-dev
 612016-10-24T01:55:11  *** PRab has joined #bitcoin-core-dev
 622016-10-24T02:01:00  *** ill has quit IRC
 632016-10-24T02:06:11  *** Alopex has quit IRC
 642016-10-24T02:07:16  *** Alopex has joined #bitcoin-core-dev
 652016-10-24T02:08:30  *** fengling has joined #bitcoin-core-dev
 662016-10-24T02:23:38  *** isis has joined #bitcoin-core-dev
 672016-10-24T02:29:03  <midnightmagic> :-/
 682016-10-24T02:33:05  *** kanzure has quit IRC
 692016-10-24T02:33:05  *** kanzure has joined #bitcoin-core-dev
 702016-10-24T03:05:28  *** aalex has quit IRC
 712016-10-24T03:08:24  *** aalex has joined #bitcoin-core-dev
 722016-10-24T03:19:35  *** alpalp has quit IRC
 732016-10-24T03:23:32  *** jujumax has joined #bitcoin-core-dev
 742016-10-24T03:50:46  *** DigiByteDev has quit IRC
 752016-10-24T03:51:37  *** ill has joined #bitcoin-core-dev
 762016-10-24T03:58:02  *** Alopex has quit IRC
 772016-10-24T03:59:07  *** Alopex has joined #bitcoin-core-dev
 782016-10-24T04:11:38  *** DigiByteDev has joined #bitcoin-core-dev
 792016-10-24T04:11:55  <luke-jr> does it not do that again? :x
 802016-10-24T04:13:53  *** DigiByteDev has quit IRC
 812016-10-24T04:15:09  <sipa> do what?
 822016-10-24T04:18:30  <luke-jr> sipa: disable outbound connections.
 832016-10-24T04:18:52  <luke-jr> it used to do so at least, and seemed to work when I recently did it for testing
 842016-10-24T04:27:30  *** ill has quit IRC
 852016-10-24T04:29:11  *** Alopex has quit IRC
 862016-10-24T04:30:16  *** Alopex has joined #bitcoin-core-dev
 872016-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.
 882016-10-24T04:32:58  <gmaxwell> this, indeed, does prevent it from connecting to other parties...
 892016-10-24T04:33:01  <luke-jr> O.o
 902016-10-24T04:33:22  <gmaxwell> but in a fairly log spammy way (esp with debugging turned up)
 912016-10-24T04:34:07  <sipa> any theory why '0' results in a connect to self? :s
 922016-10-24T04:34:25  <sipa> that shouldn't even resolve to a valid ip
 932016-10-24T04:34:52  <luke-jr> sipa: most integers are a valid IP
 942016-10-24T04:35:01  <gmaxwell> I didn't bother checking my belief that it used to behave better.
 952016-10-24T04:35:02  <aj> sipa: telnet 0 22 -> 0.0.0.0:22 -> ssh to localhost
 962016-10-24T04:35:07  <gmaxwell> $ telnet 0 8333
 972016-10-24T04:35:07  <gmaxwell> Trying 0.0.0.0...
 982016-10-24T04:35:10  <gmaxwell> Connected to 0.
 992016-10-24T04:35:13  <gmaxwell> Escape character is '^]'.
1002016-10-24T04:35:16  <gmaxwell> ^]
1012016-10-24T04:35:19  <gmaxwell> telnet> close
1022016-10-24T04:35:29  <sipa> well i knew it'd resolve to 0.0.0.0
1032016-10-24T04:35:48  <sipa> i'm surprised 0.0.0.0 is a valid thing to connect to
1042016-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.
1052016-10-24T04:36:08  <luke-jr> ping 2130706433
1062016-10-24T04:36:41  <luke-jr> (this is 0x7f000001)
1072016-10-24T04:36:42  <aj> 0.0.0.0 means "all ipv4 addresses on the local machine", so seems kinda plausible
1082016-10-24T04:36:58  <sipa> luke-jr: some browsers even allow much larger integers (up to 2^1000-ish), resolving them modulo 2^32
1092016-10-24T04:37:07  <luke-jr> >_<
1102016-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
1112016-10-24T04:38:26  <gmaxwell> we it would stop at 2^1000 isn't clear. :P
1122016-10-24T04:39:07  <luke-jr> I should access my KVMoIP by decimal. I don't have DNS on it anyway. :p
1132016-10-24T04:42:12  *** DigiByteDev has joined #bitcoin-core-dev
1142016-10-24T04:44:50  <sipa> gmaxwell: ish
1152016-10-24T04:45:04  <sipa> it's probably just an input buffer size limit
1162016-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 127.0.0.1.
1172016-10-24T04:52:15  <luke-jr> I would have expected 0.0.0.0 to be a blackhole :/
1182016-10-24T04:52:39  <luke-jr> midnightmagic: what if you ifconfig the first interface with 0.0.0.0? <.<
1192016-10-24T04:55:32  <midnightmagic> luke-jr: i dunno, can you ifconfig an interface to 0.0.0.0?
1202016-10-24T04:55:38  <luke-jr> probably not
1212016-10-24T04:55:43  <luke-jr> I think that means unconfigure
1222016-10-24T05:17:24  *** paveljanik has quit IRC
1232016-10-24T05:28:11  *** Alopex has quit IRC
1242016-10-24T05:29:16  *** Alopex has joined #bitcoin-core-dev
1252016-10-24T05:41:25  *** jujumax has quit IRC
1262016-10-24T05:46:41  *** n1ce has quit IRC
1272016-10-24T06:15:45  <midnightmagic> or on some machines you get:
1282016-10-24T06:15:47  <midnightmagic> :dom13:06:14:57 ~# telnet 0 22
1292016-10-24T06:15:48  <midnightmagic> 0: No address associated with hostname
1302016-10-24T06:25:09  <wumpus> IP parsing is not guaranteed to parse '0' as '0.0.0.0', in this csae it just thinks it's a hostname
1312016-10-24T06:27:12  <wumpus> any other 0.x.y.z IP seems to give "invalid argument" on linux
1322016-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
1332016-10-24T06:30:57  <gmaxwell> I don't ~think~ special casing "0" is too ugly, but I am open to that idea. :)
1342016-10-24T06:31:29  <wumpus> but it's not just 0, some IP parsers will happily parse any int32 into a IPv4
1352016-10-24T06:32:16  <wumpus> +have other OS/libc specific quirks
1362016-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.
1372016-10-24T06:34:03  <wumpus> yes, the reason to special-case 0 would be for -noconnect
1382016-10-24T06:34:22  <wumpus> which is fine with me
1392016-10-24T06:34:42  <gmaxwell> Yes, right now, my PR doesn't handle -noconnect (I believe), good point on that.
1402016-10-24T06:34:59  <wumpus> noconnect should automatically get converted to connect=0
1412016-10-24T06:35:21  <wumpus> you shoudln't have to do anything special for that
1422016-10-24T06:35:37  <wumpus> -noX bcomes X=1 in the low-level arg handling
1432016-10-24T06:35:43  <wumpus> ehhh X=0
1442016-10-24T06:36:05  <gmaxwell> Will test.
1452016-10-24T06:36:13  <wumpus> in any case special-casing 0 makes sense because the argument handling special-cases 0 for 'no'
1462016-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 0.0.0.0, let them specify 0.0.0.0
1472016-10-24T06:39:13  <wumpus> -noconnect should ideally mean "no outgoing connections"
1482016-10-24T06:40:13  <wumpus> ooh rowhammer on ARM, we're nowhere safe are we
1492016-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.
1502016-10-24T06:41:15  *** kadoban has quit IRC
1512016-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?".
1522016-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.
1532016-10-24T06:42:06  <wumpus> I guess it should mean "no automatic connections"
1542016-10-24T06:42:20  <gmaxwell> Yes. No automatic connections makes sense.
1552016-10-24T06:42:23  <wumpus> if you really want to force a connection using addnode, I don't see why it should stop it
1562016-10-24T06:42:44  <gmaxwell> Okay, I'll add the imply on dnsseed.
1572016-10-24T06:43:06  <wumpus> yes stopping dnsseed is an optimiziation that makes sense
1582016-10-24T06:43:21  <wumpus> why dnsseed if you're going to ignore the result
1592016-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. :)
1602016-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...
1612016-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?
1622016-10-24T06:44:23  <gmaxwell> Yep.
1632016-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)
1642016-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
1652016-10-24T06:47:03  <wumpus> ah yes that's true
1662016-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
1672016-10-24T06:51:58  <wumpus> "how to hand the world to blackhats with one easy trick"
1682016-10-24T06:53:59  <midnightmagic> wumpus: you're talking about rowhammer?
1692016-10-24T06:54:21  *** aalex has quit IRC
1702016-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.
1712016-10-24T06:54:50  <wumpus> yes rowhammer, though it similarly applies to dirty cow, or still-undisclosed-exploit-of-the-day
1722016-10-24T06:57:28  *** BashCo_ has quit IRC
1732016-10-24T06:58:30  *** aalex has joined #bitcoin-core-dev
1742016-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
1752016-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?"
1762016-10-24T06:59:52  *** mkarrer has quit IRC
1772016-10-24T07:00:01  *** mkarrer has joined #bitcoin-core-dev
1782016-10-24T07:01:21  <wumpus> + stupid laws that disallow circumventing "
1792016-10-24T07:01:25  <wumpus> security measures"
1802016-10-24T07:01:41  <wumpus> all to protect mickey mouse, of course
1812016-10-24T07:06:29  *** d_t has joined #bitcoin-core-dev
1822016-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
1832016-10-24T07:15:49  <wumpus> -noconnect seems to work fine w/ 9002
1842016-10-24T07:17:23  *** mkarrer_ has joined #bitcoin-core-dev
1852016-10-24T07:18:55  <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f08222e882b1...fd29348dbe82
1862016-10-24T07:18:56  <GitHub101> bitcoin/master 1d8e12b Pavel Janík: Fix doxygen comment: the transaction is returned in txOut
1872016-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...
1882016-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
1892016-10-24T07:20:33  *** mkarrer has quit IRC
1902016-10-24T07:20:40  *** DigiByteDev has quit IRC
1912016-10-24T07:21:52  *** BashCo has joined #bitcoin-core-dev
1922016-10-24T07:23:24  *** justan0theruser has quit IRC
1932016-10-24T07:25:28  *** whphhg has quit IRC
1942016-10-24T07:31:44  *** whphhg has joined #bitcoin-core-dev
1952016-10-24T07:39:50  *** Squidicc has joined #bitcoin-core-dev
1962016-10-24T07:43:01  *** squidicuz has quit IRC
1972016-10-24T07:47:46  *** Guest16408 is now known as thestringpuller
1982016-10-24T07:47:54  *** thestringpuller has joined #bitcoin-core-dev
1992016-10-24T07:50:36  <GitHub87> [bitcoin] unsystemizer opened pull request #9004: Clarify `listenonion` (master...patch-3) https://github.com/bitcoin/bitcoin/pull/9004
2002016-10-24T07:51:07  *** d_t has quit IRC
2012016-10-24T08:14:04  *** laurentmt has joined #bitcoin-core-dev
2022016-10-24T08:14:39  <da2ce7> Hello, is there a overview of this blocksign feature that is being developed?
2032016-10-24T08:15:36  <gmaxwell> da2ce7: I presume it would be a cut down port of whats in elements alpha.
2042016-10-24T08:16:12  <da2ce7> I can only suppose it is only to be used for testnet.
2052016-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.
2062016-10-24T08:16:24  <gmaxwell> yea, of course.
2072016-10-24T08:16:34  <gmaxwell> I'm curious where you heard about it where that wasn't clear?
2082016-10-24T08:16:46  <wumpus> yes, which is the only thing that makes the implementation difficult in practice
2092016-10-24T08:17:45  *** laurentmt has quit IRC
2102016-10-24T08:18:15  <wumpus> if you are looking for a proposal to enable it on mainnet, there's none, no chance
2112016-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.
2122016-10-24T08:18:51  <gmaxwell> that doesn't make a lot of sense, someone signing something doesn't demonstrate authorship
2132016-10-24T08:19:16  <gmaxwell> instead, to achieve what you describe needs only a commitment to a public key in the block.
2142016-10-24T08:19:50  <gmaxwell> Though it's somewhat important to the system that miners operate anonymously, to reduce their exposure to coersion.
2152016-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.
2162016-10-24T08:21:49  <luke-jr> not necessarily. you could sign the template and ask me to mine it for you :p
2172016-10-24T08:21:50  <gmaxwell> If the key is random and used once it doesn't really matter.
2182016-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.
2192016-10-24T08:24:10  <gmaxwell> da2ce7: huh? no... if you care about that you just ignore reuse.
2202016-10-24T08:24:17  <da2ce7> *nuisance
2212016-10-24T08:24:21  <gmaxwell> same as someone not providing a key at all.
2222016-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.
2232016-10-24T08:27:51  *** Ylbam has joined #bitcoin-core-dev
2242016-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.
2252016-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.
2262016-10-24T08:29:28  <gmaxwell> There are ways to do that without any publication of info to the general public though.
2272016-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. :( )
2282016-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.
2292016-10-24T08:34:35  <da2ce7> anyway, off-topic.  Blocksign for testnet is good for testing :).
2302016-10-24T08:38:26  <gmaxwell> yes, centeralizing the system can make it more secure against many kinds of attacks... :)
2312016-10-24T08:50:12  *** fengling has quit IRC
2322016-10-24T09:17:33  <GitHub42> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd29348dbe82...ced22d035ac0
2332016-10-24T09:17:34  <GitHub42> bitcoin/master dfe7906 Matt Corallo: Add missing cs_main lock to ::GETBLOCKTXN processing...
2342016-10-24T09:17:34  <GitHub42> bitcoin/master ced22d0 Wladimir J. van der Laan: Merge #8995: Add missing cs_main lock to ::GETBLOCKTXN processing...
2352016-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
2362016-10-24T09:18:29  *** fengling has joined #bitcoin-core-dev
2372016-10-24T09:32:08  *** fengling has quit IRC
2382016-10-24T09:40:15  *** fengling has joined #bitcoin-core-dev
2392016-10-24T09:45:27  *** gluytium has quit IRC
2402016-10-24T10:37:11  *** Guyver2 has joined #bitcoin-core-dev
2412016-10-24T10:44:38  *** aalex has quit IRC
2422016-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
2432016-10-24T10:47:47  <wumpus> thanks, so I wasn't being overly paranoid about that
2442016-10-24T10:48:41  *** aalex has joined #bitcoin-core-dev
2452016-10-24T10:48:46  <arubi> yea those 0 inputs pre segwit are something to think about when fundrawtransaction
2462016-10-24T10:49:56  <wumpus> please comment on the issue too
2472016-10-24T10:49:59  <wumpus> ah yes :(
2482016-10-24T10:50:24  <arubi> well those fivepiece comments are mine :)
2492016-10-24T10:50:42  <arubi> I'll copy this comment too
2502016-10-24T10:57:05  *** gluytium has joined #bitcoin-core-dev
2512016-10-24T11:01:16  *** cdecker has joined #bitcoin-core-dev
2522016-10-24T11:01:33  *** fengling has quit IRC
2532016-10-24T11:04:14  <wumpus> does anyone care about DecodeBase58 performance? If so, please review/test https://github.com/bitcoin/bitcoin/pull/8736
2542016-10-24T11:04:23  *** jannes has joined #bitcoin-core-dev
2552016-10-24T11:49:21  <jonasschnelli> during IBD, there is "chainActive" like (CChain) object that contains the headers-only chain?
2562016-10-24T11:49:33  <jonasschnelli> *there is no "chainActive"
2572016-10-24T11:50:11  <jonasschnelli> It looks like that getchaintips is ripping out the headers-tip from setOrphans
2582016-10-24T11:54:52  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2592016-10-24T12:04:53  <jonasschnelli> nm: I think pindexBestHeader is acceptable for my usecase
2602016-10-24T12:05:15  <wumpus> ok :)
2612016-10-24T12:06:10  *** cryptapus_afk is now known as cryptapus
2622016-10-24T12:10:36  *** Chris_Stewart_5 has quit IRC
2632016-10-24T12:11:55  <jonasschnelli> hmm.. why points pindexBestHeader->pprev to pindexBestHeader?!
2642016-10-24T12:12:10  <jonasschnelli> looks like it not traversable
2652016-10-24T12:12:47  <jonasschnelli> again... nm! local issue.
2662016-10-24T12:36:14  *** mr_burdell has joined #bitcoin-core-dev
2672016-10-24T12:38:18  *** berndj-blackout has joined #bitcoin-core-dev
2682016-10-24T12:39:45  *** trippysa1mon has joined #bitcoin-core-dev
2692016-10-24T12:39:57  *** Pasha has joined #bitcoin-core-dev
2702016-10-24T12:40:15  *** aj_ has joined #bitcoin-core-dev
2712016-10-24T12:40:20  *** harding_ has joined #bitcoin-core-dev
2722016-10-24T12:40:32  *** wolfspra1l has joined #bitcoin-core-dev
2732016-10-24T12:40:43  *** haakonn_ has joined #bitcoin-core-dev
2742016-10-24T12:42:47  *** instagibbs_ has joined #bitcoin-core-dev
2752016-10-24T12:43:20  *** afk11_ has joined #bitcoin-core-dev
2762016-10-24T12:43:33  *** bad_duck has joined #bitcoin-core-dev
2772016-10-24T12:44:39  *** laurentmt has joined #bitcoin-core-dev
2782016-10-24T12:45:20  *** whphhg has quit IRC
2792016-10-24T12:45:20  *** wolfspraul has quit IRC
2802016-10-24T12:45:21  *** instagibbs has quit IRC
2812016-10-24T12:45:21  *** berndj has quit IRC
2822016-10-24T12:45:21  *** Cory has quit IRC
2832016-10-24T12:45:21  *** kcud_dab has quit IRC
2842016-10-24T12:45:21  *** aj has quit IRC
2852016-10-24T12:45:21  *** BonyM1 has quit IRC
2862016-10-24T12:45:21  *** trippysalmon has quit IRC
2872016-10-24T12:45:21  *** Guest13412 has quit IRC
2882016-10-24T12:45:21  *** Arnavion has quit IRC
2892016-10-24T12:45:21  *** haakonn has quit IRC
2902016-10-24T12:45:22  *** afk11 has quit IRC
2912016-10-24T12:45:22  *** harding has quit IRC
2922016-10-24T12:46:10  *** laurentmt has quit IRC
2932016-10-24T12:46:51  *** Pasha is now known as Cory
2942016-10-24T12:51:42  *** whphhg has joined #bitcoin-core-dev
2952016-10-24T12:53:37  *** BonyM1 has joined #bitcoin-core-dev
2962016-10-24T12:59:45  *** aalex has quit IRC
2972016-10-24T13:03:36  *** aalex has joined #bitcoin-core-dev
2982016-10-24T13:09:43  *** aalex has quit IRC
2992016-10-24T13:10:06  *** aalex has joined #bitcoin-core-dev
3002016-10-24T13:14:26  *** aalex has quit IRC
3012016-10-24T13:16:59  *** To7 has quit IRC
3022016-10-24T13:18:22  *** aalex has joined #bitcoin-core-dev
3032016-10-24T13:18:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3042016-10-24T13:23:06  *** jujumax has joined #bitcoin-core-dev
3052016-10-24T13:24:36  *** aalex has quit IRC
3062016-10-24T13:37:10  *** fengling has joined #bitcoin-core-dev
3072016-10-24T13:41:06  *** jtimon has joined #bitcoin-core-dev
3082016-10-24T13:48:40  *** fengling has quit IRC
3092016-10-24T14:04:18  *** To7 has joined #bitcoin-core-dev
3102016-10-24T14:08:49  *** berndj-blackout is now known as berndj
3112016-10-24T14:19:00  *** bsm1175321 has joined #bitcoin-core-dev
3122016-10-24T14:24:25  *** Chris_Stewart_5 has quit IRC
3132016-10-24T14:24:52  *** cjcj_ has joined #bitcoin-core-dev
3142016-10-24T14:26:54  *** dzijeka has joined #bitcoin-core-dev
3152016-10-24T14:34:01  *** Arnavion has joined #bitcoin-core-dev
3162016-10-24T14:38:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3172016-10-24T14:46:24  *** bsm1175321 is now known as bsm117532
3182016-10-24T15:15:03  *** sumit_sethia has joined #bitcoin-core-dev
3192016-10-24T15:17:38  *** sumit_sethia has quit IRC
3202016-10-24T15:18:58  *** andytosh1 is now known as andytoshi
3212016-10-24T15:20:15  *** BashCo has quit IRC
3222016-10-24T15:20:52  *** BashCo has joined #bitcoin-core-dev
3232016-10-24T15:25:03  *** BashCo has quit IRC
3242016-10-24T15:36:02  *** Giszmo1 has quit IRC
3252016-10-24T15:42:11  *** jujumax has quit IRC
3262016-10-24T15:45:13  *** paveljanik has joined #bitcoin-core-dev
3272016-10-24T15:49:51  *** Giszmo has joined #bitcoin-core-dev
3282016-10-24T15:56:43  *** BashCo has joined #bitcoin-core-dev
3292016-10-24T16:25:14  <BlueMatt> wait, what?
3302016-10-24T16:25:52  <BlueMatt> argh, we did break addnode :(
3312016-10-24T16:26:08  <sipa> how so?
3322016-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
3332016-10-24T16:27:06  <sipa> hmm
3342016-10-24T16:27:10  <BlueMatt> i didnt realize we broke the pick-different-address-if-it-doesnt-connect logic :(
3352016-10-24T16:28:03  <sipa> i didn't think so either
3362016-10-24T16:28:38  <BlueMatt> there doesnt seem to be any handling for it
3372016-10-24T16:29:06  <sipa> ConnectSocketByName should pick a random resolved address for each attempt
3382016-10-24T16:29:57  <BlueMatt> ThreadOpenAddedConnections does a LooupNumeric before calling OpenNetworkConnection
3392016-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 :/
3402016-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
3412016-10-24T16:30:57  <BlueMatt> ahh
3422016-10-24T16:31:03  <BlueMatt> hmm, maybe they just didnt wait long enough
3432016-10-24T16:31:44  <BlueMatt> but it did try to connect to v6, get a network unreachable error, and give up :(
3442016-10-24T16:32:19  <sipa> it will only retry 2 minutes later, i think
3452016-10-24T16:32:56  <BlueMatt> yes, it did, and tried again to ipv6
3462016-10-24T16:33:06  <BlueMatt> though if its random i suppose he could have waited longer and maybe it would have worked
3472016-10-24T16:33:22  <BlueMatt> though its possible the hosts ipv6-preference logic is bad?
3482016-10-24T16:33:42  <Lightsword> it’s a fairly standard EC2 ubuntu 16.04 VPS
3492016-10-24T16:34:12  <sipa> maybe it only resolves to IPv6 addresses for some reason?
3502016-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?
3512016-10-24T16:44:30  *** jtimon has quit IRC
3522016-10-24T16:44:36  <Lightsword> BlueMatt, yeah not seeing any connection
3532016-10-24T16:44:55  <Lightsword> 2016-10-24 16:40:07.057232 trying connection us-west.fibre.bitcoinrelaynetwork.org lastseen=0.0hrs
3542016-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)
3552016-10-24T16:45:20  <BlueMatt> yea, so it seems broken :(
3562016-10-24T16:46:00  *** Squidicc is now known as squidicuz
3572016-10-24T16:46:17  <BlueMatt> argh, someone wanna tag https://github.com/bitcoin/bitcoin/issues/9007 0.13.1?
3582016-10-24T16:49:35  <paveljanik> I can't do so, sorry.
3592016-10-24T16:52:03  <wumpus> already done
3602016-10-24T16:53:19  <wumpus> another assert that should be removed, like 1ab21cf344ed0547de5ae679b7e479cb4b1a923b I guess...
3612016-10-24T16:53:25  *** kadoban has joined #bitcoin-core-dev
3622016-10-24T16:53:37  <wumpus> should check there's no other weird asserts added
3632016-10-24T16:53:53  <sipa> is 9007 in 0.13?
3642016-10-24T16:54:59  <wumpus> yes
3652016-10-24T16:56:07  <wumpus> https://github.com/bitcoin/bitcoin/blob/0.13/src/net.cpp#L1024
3662016-10-24T16:56:46  <sipa> ah, caused by feelers?
3672016-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
3682016-10-24T16:58:12  <gmaxwell> addnode can take you beyond the nMaxOutbound count.
3692016-10-24T16:58:46  <wumpus> that's not what that assert is checking though
3702016-10-24T16:59:09  <wumpus> it doesn't look at your actual connections, just the max possible
3712016-10-24T16:59:26  <gmaxwell> ah, indeed.
3722016-10-24T16:59:48  <gmaxwell> that should be a return, not an assert, in any case.
3732016-10-24T16:59:55  * gmaxwell feels stupid for missing that.
3742016-10-24T17:04:13  <gmaxwell> There was another inappropriate assert added in the same commit, but it was already removed by PR 8944.
3752016-10-24T17:04:16  <wumpus> well the previous assert based bug was that
3762016-10-24T17:04:22  <wumpus> right
3772016-10-24T17:07:43  <gmaxwell> sipa: I can't see how that couldn't be reproduced in rc2.
3782016-10-24T17:10:22  <gmaxwell> even returning there wouldn't be right.
3792016-10-24T17:10:56  <gmaxwell> lets say I set -connect=1.2.3.4 and maxconnections=4 ... I should still be able to accept 3 connections.
3802016-10-24T17:11:45  *** Cheeseo has joined #bitcoin-core-dev
3812016-10-24T17:11:49  *** Cheeseo has joined #bitcoin-core-dev
3822016-10-24T17:11:56  <sipa> if you set -connect, isn't listening disabled by default?
3832016-10-24T17:12:35  <gmaxwell> its softset off.
3842016-10-24T17:12:50  <gmaxwell> so if you -connect + listen=1 to be precise.
3852016-10-24T17:13:15  <sipa> ok
3862016-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.
3872016-10-24T17:16:50  <gmaxwell> wait.. what.. is eviction now broken?!
3882016-10-24T17:18:26  <gmaxwell> okay, its not, just kind of stupid.
3892016-10-24T17:20:40  <gmaxwell> without the insert, the -noconnect + listen=1 case with maxconnections<8 will continually try evicting a connection and fail.
3902016-10-24T18:02:44  *** Giszmo has quit IRC
3912016-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)
3922016-10-24T18:07:16  *** laurentmt has joined #bitcoin-core-dev
3932016-10-24T18:07:26  <sipa> morcos: i believe we actually always call CCoins::Cleanup()
3942016-10-24T18:07:45  <sipa> which sets the capacity to 0
3952016-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
3962016-10-24T18:07:55  <morcos> well it calls a new vector and swaps
3972016-10-24T18:08:09  <sipa> yes, that was the C++03 trick to set the capacity to 0
3982016-10-24T18:08:09  <morcos> but from my googling it seems implementation dependent whether a new vector has capacity 0?
3992016-10-24T18:08:12  *** laurentmt has quit IRC
4002016-10-24T18:08:39  <sipa> ok, i agree there is in theory a standard-compliant implementations which doesn't have that behaviour
4012016-10-24T18:08:48  *** cheese_ has joined #bitcoin-core-dev
4022016-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
4032016-10-24T18:09:11  <morcos> second , kind of unrelated question
4042016-10-24T18:09:34  <morcos> prevector.resize(0) doesn't seem like the fastest way to clean up a prevector<unsigned char> does it?
4052016-10-24T18:09:41  <sipa> the c++11 way is std::vector::shrink_to_fit() btw
4062016-10-24T18:10:13  *** Giszmo has joined #bitcoin-core-dev
4072016-10-24T18:10:14  <morcos> looking at the resize code, it calls erase, which iterates the elements destructing them
4082016-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?
4092016-10-24T18:11:09  <sipa> so there is a question of what prevector should support
4102016-10-24T18:11:29  <sipa> if it can only contain POD types, i think more complexity can go away
4112016-10-24T18:11:43  *** Cheeseo has quit IRC
4122016-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)
4132016-10-24T18:12:15  <sipa> i thought cfields_ was working on some improvements to prevector?
4142016-10-24T18:12:41  <cfields_> sipa: one of many things that got to 90% and shelved.
4152016-10-24T18:13:00  <sipa> s/erase/destructors/
4162016-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.
4172016-10-24T18:13:32  <cfields_> sipa: in particular, I was doing a specialiazation for size=1
4182016-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
4192016-10-24T18:13:50  <cfields_> since that's our main use-case, and you can get huge speedups with that assumption
4202016-10-24T18:14:10  <morcos> ok..   thanks for the thoughts..
4212016-10-24T18:23:08  *** dermoth has quit IRC
4222016-10-24T18:31:32  *** cjcj_ has quit IRC
4232016-10-24T18:36:38  *** MarcoFalke has joined #bitcoin-core-dev
4242016-10-24T19:07:20  *** laurentmt has joined #bitcoin-core-dev
4252016-10-24T19:19:21  *** laurentmt has quit IRC
4262016-10-24T19:32:03  *** roasbeef_ is now known as roasbeef
4272016-10-24T19:34:35  *** a_meteorite has joined #bitcoin-core-dev
4282016-10-24T19:52:19  *** Chris_Stewart_5 has quit IRC
4292016-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
4302016-10-24T20:21:45  *** davec has quit IRC
4312016-10-24T20:22:58  *** davec has joined #bitcoin-core-dev
4322016-10-24T20:29:22  *** laurentmt has joined #bitcoin-core-dev
4332016-10-24T20:33:24  *** d_t has joined #bitcoin-core-dev
4342016-10-24T20:34:23  *** instagibbs_ is now known as instagibbs
4352016-10-24T20:38:25  *** laurentmt has quit IRC
4362016-10-24T20:48:57  <btcdrak> https://github.com/bitcoin-core/bitcoincore.org/pull/239
4372016-10-24T21:04:53  *** Alina-malina is now known as alina-malina
4382016-10-24T21:09:32  *** MarcoFalke has quit IRC
4392016-10-24T21:24:26  *** Guyver2 has quit IRC
4402016-10-24T21:39:41  *** cryptapus is now known as cryptapus_afk
4412016-10-24T21:54:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4422016-10-24T21:54:11  *** cryptapus has joined #bitcoin-core-dev
4432016-10-24T21:54:11  *** cryptapus has joined #bitcoin-core-dev
4442016-10-24T21:58:44  *** cryptapus has quit IRC
4452016-10-24T21:58:57  <nibor> Could someone let me know what they think about:  https://gist.github.com/n1bor/d5b0330a9addb0bf5e0f869518883522
4462016-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.
4472016-10-24T22:00:29  <nibor> Obviously need a soft-fork to be any use.
4482016-10-24T22:08:30  *** midnightmagic has quit IRC
4492016-10-24T22:09:45  *** justanotheruser has joined #bitcoin-core-dev
4502016-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
4512016-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).
4522016-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.
4532016-10-24T22:10:35  <gmaxwell> I'd been thinking of something that was more like a 3 month interval.
4542016-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:
4552016-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.
4562016-10-24T22:12:49  <gmaxwell> That way if someothing better comes along, the commitment can eventually be dropped in a smooth and compatible manner.
4572016-10-24T22:13:06  <gmaxwell> (perhaps making new installs of old software take a long time to sync :) )
4582016-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.
4592016-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.
4602016-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.
4612016-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.
4622016-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.
4632016-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.
4642016-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..
4652016-10-24T22:18:36  <gmaxwell> reorginizing chainstate into 'old' and 'new' could help with that churn fwiw.
4662016-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.
4672016-10-24T22:19:49  <gmaxwell> yea, I was surprised you got this working using leveldb snapshots.
4682016-10-24T22:20:08  <nibor> s/bit/big/
4692016-10-24T22:20:53  <nibor> Not sure I understand your 1st comment though. About miners creating big fork?
4702016-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.
4712016-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.
4722016-10-24T22:22:57  <gmaxwell> (50 gb chainstate is likely unworkable with leveldb :(  but thats an aside. :) )
4732016-10-24T22:23:45  <nibor> Prob ok with 64Gig RAM... In day job just order 2 boxes with 2Tb so not so much..
4742016-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...
4752016-10-24T22:24:15  <gmaxwell> nibor: we'd like to have a decenteralized system you know, :P
4762016-10-24T22:26:28  <nibor> With a 100gig download?...
4772016-10-24T22:26:37  <gmaxwell> nibor: did you understand my "phase out" suggestion? (the line refereincing petertodd)
4782016-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.
4792016-10-24T22:28:34  <nibor> Not sure I do.. but might in a bit...
4802016-10-24T22:29:08  <gmaxwell> OKAY.
4812016-10-24T22:29:12  <gmaxwell> In any case, exciting work
4822016-10-24T22:29:18  <gmaxwell> Your POC is awesome.
4832016-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.
4842016-10-24T22:29:35  *** murch has joined #bitcoin-core-dev
4852016-10-24T22:30:18  <gmaxwell> Or not another leveldb but just a seralized flat blob.
4862016-10-24T22:30:34  <gmaxwell> It would be faster and more space efficient. And random access is not needed, except to chunks.
4872016-10-24T22:30:53  <gmaxwell> (could be one file per chunk. Though 8000 chunks is a bit excessive for that.)
4882016-10-24T22:31:32  <nibor> Not really - leveldb is up to 1000 files.
4892016-10-24T22:31:38  <gmaxwell> I believe that only needs two snapshots at any time too...
4902016-10-24T22:32:04  *** jtimon has joined #bitcoin-core-dev
4912016-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.
4922016-10-24T22:33:16  <nibor> Will think about Petertodd issue to. Is nasty to cause future issues.
4932016-10-24T22:34:01  <nibor> I guess some of the 100fork issues would be reduced if client back populated blocks over time.
4942016-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.
4952016-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.
4962016-10-24T22:36:36  <nibor> Thanks for thoughts... am off now. Will see what others think..
4972016-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)
4982016-10-24T22:36:43  <gmaxwell> Great!
4992016-10-24T22:38:25  <murch> Hey gmaxwell, I was missing you at Scaling Bitcoin. :)
5002016-10-24T22:39:11  <murch> I was curios what you'd say about my coin selection talk after we had chatted here about it.
5012016-10-24T22:46:10  *** molz has joined #bitcoin-core-dev
5022016-10-24T22:48:32  <gmaxwell> molz: I was sad to see that wider-match only made a fairly modest improvement!
5032016-10-24T22:49:02  <sipa> s/molz/murch/
5042016-10-24T22:49:05  <gmaxwell> oops!
5052016-10-24T22:49:07  <gmaxwell> murch:
5062016-10-24T22:49:28  <molz> haha i was scratching my head "what's the wider-match" lol
5072016-10-24T22:49:45  *** moli has quit IRC
5082016-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.
5092016-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.
5102016-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?
5112016-10-24T22:50:46  <sipa> molz: they're remembered across restarts already
5122016-10-24T22:50:47  <sipa> bans.dat
5132016-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.
5142016-10-24T22:51:11  <molz> sipa but i haven't banned any bad nodes
5152016-10-24T22:51:21  <gmaxwell> They 'solved' this in a really kludgy way just making the wallet ignore payments below a dust threshold.
5162016-10-24T22:51:40  <gmaxwell> molz: just paste the lines in a sutiable format.
5172016-10-24T22:52:20  <molz> yea i meant copy and paste, ok thanks
5182016-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'.
5192016-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..
5202016-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.
5212016-10-24T22:53:04  <murch> (Experiment is still running, can't give you good details on the final set composition yet)
5222016-10-24T22:54:14  <gmaxwell> By direct matches, you mean no change created--but possible 'extra fee', not one-input only, right?
5232016-10-24T22:54:33  <murch> gmaxwell: yeah, that
5242016-10-24T22:54:39  <gmaxwell> Good! sounds reasonable to me.
5252016-10-24T22:54:48  <gmaxwell> Then again lots of things that didn't work sounded reasonable to me.
5262016-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.
5272016-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?
5282016-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)
5292016-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.
5302016-10-24T22:58:14  <murch> mh.
5312016-10-24T22:58:26  <murch> I haven't considered that attack scenario too much yet.
5322016-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.
5332016-10-24T22:58:46  <murch> I was thinking to replace the SDR fall back with 7 random drawings and the median input set size
5342016-10-24T22:58:51  <murch> or some similar scheme
5352016-10-24T22:59:06  <gmaxwell> (er my example just now should have also said "and you try to pay 1 btc")
5362016-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
5372016-10-24T22:59:42  <murch> gmaxwell: Yes, of course.
5382016-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.
5392016-10-24T23:00:47  <murch> exactly
5402016-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. ;)
5412016-10-24T23:01:19  <murch> I have to print next wednesday. :D
5422016-10-24T23:01:34  <murch> gmaxwell: https://github.com/Xekyo/CoinSelectionSimulator/blob/master/src/BnBWallet.scala#L59
5432016-10-24T23:01:48  <murch> This is the new algorithm I have come up with, in case you want to take a look
5442016-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
5452016-10-24T23:02:46  *** jujumax has joined #bitcoin-core-dev
5462016-10-24T23:03:00  <murch> the perpetrator is "BranchAndBoundWallet"
5472016-10-24T23:04:20  *** midnightmagic has joined #bitcoin-core-dev
5482016-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.)
5492016-10-24T23:07:28  *** LeMiner has quit IRC
5502016-10-24T23:07:58  *** michagogo has quit IRC
5512016-10-24T23:08:23  *** cdecker has quit IRC
5522016-10-24T23:10:11  *** michagogo has joined #bitcoin-core-dev
5532016-10-24T23:13:15  *** midnightmagic has quit IRC
5542016-10-24T23:14:29  *** LeMiner has joined #bitcoin-core-dev
5552016-10-24T23:15:49  *** jujumax has quit IRC
5562016-10-24T23:24:21  *** midnightmagic has joined #bitcoin-core-dev
5572016-10-24T23:24:39  *** laurentmt has joined #bitcoin-core-dev
5582016-10-24T23:30:07  *** tulip has quit IRC
5592016-10-24T23:33:43  *** BlueMatt has quit IRC
5602016-10-24T23:34:00  *** BlueMatt has joined #bitcoin-core-dev
5612016-10-24T23:34:54  *** laurentmt has quit IRC
5622016-10-24T23:38:38  *** gijensen92 has joined #bitcoin-core-dev
5632016-10-24T23:43:32  *** whphhg has quit IRC
5642016-10-24T23:43:32  *** haakonn_ has quit IRC
5652016-10-24T23:43:32  *** squidicuz has quit IRC
5662016-10-24T23:43:32  *** Soligor has quit IRC
5672016-10-24T23:43:33  *** gmaxwell has quit IRC
5682016-10-24T23:43:33  *** nickler_ has quit IRC
5692016-10-24T23:43:33  *** PaulCapestany has quit IRC
5702016-10-24T23:43:33  *** eragmus has quit IRC
5712016-10-24T23:43:33  *** mappum has quit IRC
5722016-10-24T23:43:33  *** CodeShark has quit IRC
5732016-10-24T23:43:33  *** neha has quit IRC
5742016-10-24T23:43:34  *** [b__b] has quit IRC
5752016-10-24T23:43:34  *** GreenIsMyPepper has quit IRC
5762016-10-24T23:44:25  *** whphhg has joined #bitcoin-core-dev
5772016-10-24T23:44:25  *** haakonn_ has joined #bitcoin-core-dev
5782016-10-24T23:44:25  *** squidicuz has joined #bitcoin-core-dev
5792016-10-24T23:44:25  *** Soligor has joined #bitcoin-core-dev
5802016-10-24T23:44:25  *** gmaxwell has joined #bitcoin-core-dev
5812016-10-24T23:44:25  *** nickler_ has joined #bitcoin-core-dev
5822016-10-24T23:44:25  *** PaulCapestany has joined #bitcoin-core-dev
5832016-10-24T23:44:25  *** eragmus has joined #bitcoin-core-dev
5842016-10-24T23:44:25  *** mappum has joined #bitcoin-core-dev
5852016-10-24T23:44:25  *** CodeShark has joined #bitcoin-core-dev
5862016-10-24T23:44:25  *** neha has joined #bitcoin-core-dev
5872016-10-24T23:44:25  *** [b__b] has joined #bitcoin-core-dev
5882016-10-24T23:44:27  *** GreenIsMyPepper has joined #bitcoin-core-dev
5892016-10-24T23:44:33  *** AtashiCon has quit IRC
5902016-10-24T23:44:35  *** Arnavion3 has joined #bitcoin-core-dev
5912016-10-24T23:44:35  *** gijensen has quit IRC
5922016-10-24T23:44:37  *** gijensen92 is now known as gijensen
5932016-10-24T23:44:38  *** Arnavion3 is now known as AtashiCon
5942016-10-24T23:46:25  *** zmanian____ has quit IRC
5952016-10-24T23:50:56  *** zmanian____ has joined #bitcoin-core-dev