--- Log opened Sun Aug 12 00:00:37 2018
00:03 -!- dcousens [~dcousens@110.140.174.10] has quit [Quit: Ping timeout (120 seconds)]
00:03 -!- dcousens [~dcousens@110.140.174.10] has joined #bitcoin-core-dev
00:11 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Quit: WeeChat 2.2]
00:55 -!- itaseski [~itaseski@213.135.176.192] has joined #bitcoin-core-dev
01:00 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
01:00 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
01:02 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
01:22 -!- Rootsudo [~textual@49.151.151.68] has joined #bitcoin-core-dev
01:29 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
01:31 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
01:46 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
01:47 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
01:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
02:20 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
02:46 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
02:51 < fanquake> wumpus 13938 should be ok to go in
02:57 < fanquake> Also 13808
02:59 < Varunram> is the bot dead?
03:10 -!- hex17or [~hex17or@2a02:8071:ba7:d300:3489:26c1:36dd:7b0e] has joined #bitcoin-core-dev
03:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:17 -!- hex17or [~hex17or@2a02:8071:ba7:d300:3489:26c1:36dd:7b0e] has quit [Ping timeout: 256 seconds]
03:58 < jonasschnelli> gmaxwell, sipa: the new protocol does have encryption optional, therefore the question rises if detecting the key handshake versus a version message is sane
03:58 < jonasschnelli> I guess its acceptable to assume a version message (an not a key) when we detect a message magic and the rest of a legacy header
03:59 < jonasschnelli> I guess it's almost impossible to derive a pubkey with the network magic & version part of the header
03:59 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has quit [Read error: Connection reset by peer]
04:00 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has joined #bitcoin-core-dev
04:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
04:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
04:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:21 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Quit: WeeChat 2.2]
04:22 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
04:30 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Quit: WeeChat 2.2]
04:30 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
04:37 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
04:39 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
05:06 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Read error: Connection reset by peer]
05:06 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
05:07 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev
05:29 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has joined #bitcoin-core-dev
05:32 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Remote host closed the connection]
05:43 -!- pluit [~pluit@sama.kortex.jyu.fi] has joined #bitcoin-core-dev
05:48 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
05:49 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
06:06 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has quit [Read error: Connection reset by peer]
06:08 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has joined #bitcoin-core-dev
06:11 -!- reald0ff1 [02cf1ec4@gateway/web/freenode/ip.2.207.30.196] has joined #bitcoin-core-dev
06:11 < reald0ff1> hi
06:12 < reald0ff1> Can someone please provide me download stats (or at least share in %) of bitcoin core, regarding the different platform versions (Win, Linux, OSX, etc) ?
06:13 < reald0ff1> that would be very helpful for my master thesis
06:15 -!- face [~face@80.72.82.160.coresnet.bg] has joined #bitcoin-core-dev
06:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
06:20 < reald0ff1> would very appreciate it, if someone could help me with that question
06:20 < harding> reald0ff1: I don't know if anyone has that information for BitcoinCore.org, sorry.  In addition, the binaries can also be downloaded from Bitcoin.org (maintained by a different team) or via a torrent (with optional magnet URI) that contains the binaries for all platforms.
06:25 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
06:26 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Remote host closed the connection]
06:26 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
06:30 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
06:33 -!- pluit [~pluit@sama.kortex.jyu.fi] has quit [Quit: pöes]
06:34 < reald0ff1> well thanks for the answer. I think I will try to contact bitcoincore.org via email and bitcoin.org also via email to the website maintainer. Maybe some of them could provide me stats
06:35 < reald0ff1> I developing a security tool for cryptocurrency users and I selected windows as target plattform. I have the feeling that the most users use windows (I am not talking about devs, etc.)
06:36 < reald0ff1> however, would be still nice to have some stats to prove that "feeling"
06:38 -!- pluit [~pluit@gateway/tor-sasl/pluit] has joined #bitcoin-core-dev
06:40 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://www.Quanto.ga/]
06:43 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
06:50 -!- reald0ff1 [02cf1ec4@gateway/web/freenode/ip.2.207.30.196] has quit [Quit: Page closed]
06:57 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
06:59 -!- Rootsudo [~textual@49.151.151.68] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
07:00 -!- Rootsudo [~textual@49.151.151.68] has joined #bitcoin-core-dev
07:00 -!- Rootsudo [~textual@49.151.151.68] has quit [Client Quit]
07:01 -!- Rootsudo [~textual@49.151.151.68] has joined #bitcoin-core-dev
07:01 -!- Rootsudo [~textual@49.151.151.68] has quit [Client Quit]
07:01 -!- Rootsudo [~textual@49.151.151.68] has joined #bitcoin-core-dev
07:02 -!- Rootsudo [~textual@49.151.151.68] has quit [Client Quit]
07:02 -!- devmob [~devmob@31.154.168.166] has joined #bitcoin-core-dev
07:02 -!- Rootsudo [~textual@49.151.151.68] has joined #bitcoin-core-dev
07:03 -!- Rootsudo [~textual@49.151.151.68] has quit [Client Quit]
07:03 < devmob> hi, I'd really like to know how bitcoin does gossip, like how the gossip protocol is implemented 
07:03 < devmob> can someone point me somewhere ?
07:03 -!- Rootsudo [~textual@49.151.151.68] has joined #bitcoin-core-dev
07:03 -!- Rootsudo [~textual@49.151.151.68] has quit [Client Quit]
07:39 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
07:45 -!- devmob [~devmob@31.154.168.166] has quit [Remote host closed the connection]
07:53 -!- promag [~promag@83.223.225.111] has joined #bitcoin-core-dev
08:08 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:09 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
08:18 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
08:25 -!- promag [~promag@83.223.225.111] has quit [Remote host closed the connection]
08:47 < itaseski> devmob: https://en.wikipedia.org/wiki/Gossip_protocol
08:47 < itaseski> is this helpful?
08:48 < itaseski> it is general but it explains how gossip protocols work
08:48 < itaseski> i wasn't able to find anything bitcoin specific ...
08:59 < sipa> he left. also, https://bitcoin.stackexchange.com is your friend
09:31 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitcoin-core-dev
09:38 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
09:40 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
09:50 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
09:50 -!- kelt [~kelt@mobile-166-137-219-103.mycingular.net] has quit [Quit: Leaving]
09:51 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
10:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
10:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
10:02 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
10:05 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
10:06 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
10:19 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev
10:19 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has quit [Client Quit]
10:19 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev
10:29 < gmaxwell> jonasschnelli: we could just discard keys that match the strictest version handshake pattern we can come up with, no biggie
10:30 < gmaxwell> sipa: on the encryption subject, libsodium has avx2 and ssse3 chacha20 implementations: https://github.com/jedisct1/libsodium/tree/1.0.16/src/libsodium/crypto_stream/chacha20/dolbeau
10:31 < gmaxwell> and sse2 poly1305 https://github.com/jedisct1/libsodium/tree/1.0.16/src/libsodium/crypto_onetimeauth/poly1305/sse2
10:43 -!- itaseski [~itaseski@213.135.176.192] has quit [Remote host closed the connection]
10:45 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
10:46 -!- vexbuy [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
10:56 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
10:58 -!- vexbuy [~vexbuy@46.166.142.215] has quit [Read error: Connection reset by peer]
10:59 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
11:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds]
11:12 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds]
11:14 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
11:16 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection]
11:17 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
11:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
11:28 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
11:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
11:35 < jonasschnelli> gmaxwell: about dolbeau's Chacha20 AVX/SSSE implementation: "Beware: those implementations are purely designed for speed on recent Intel architectures (mostly Haswell and newer), and ARMv8 (64 bits) with the crypto extension. They were not verified to be resistant to side channel attacks."
11:36 < jonasschnelli> The later would probably require further analysis since the timing side channel attackes seems to be one of the big benefits of chacha20 (I may be wrong though)
11:36 < jonasschnelli> *attack resistance
11:40 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
11:58 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
12:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
12:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
12:19 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev
12:20 < MarcoFalke> sipa: Wouldn't the stempool make every mempool action half as fast (since everything would have to be done once for the mempool and then for the stempool)
12:20 < MarcoFalke> Also I am not sure about the memory overhead of having the mempool duplicated
12:20 < MarcoFalke> The transactions are shared ptrs, but still...
12:20 < sipa> MarcoFalke: well, dandelion needs some way of dealing with unconfirmed dependencies
12:22 < sipa> MarcoFalke: the reference code the authors posted included a stempool, though i commented on memory usage concerns
12:23 < MarcoFalke> I know that the BIP mentions a stempool
12:23 < MarcoFalke> Agree that we need to handle dependencies
12:24 < MarcoFalke> I was hoping we could do a primitive cache for now and later replace that with https://github.com/bitcoin/bitcoin/pull/13804 (tx pool layer)
12:24 < sipa> an alternative would be to have a 2-tier mempool, where each transaction has a flag whether it's public or not
12:25 < sipa> and accepting a public tx ignores (and kicks out) any nonpublic conflicts
12:26 < MarcoFalke> That sounds like every single line of txmempool.cpp had to be amended with an if(public) else ...
12:27 < sipa> i doubt that, tbh
12:27 < sipa> most of it is just data structurr maintenance which would be unaffected
12:27 < sipa> but i don't think it'd be a trivial change either
12:28 < sipa> the set of non-public transactions in general should be very small
12:29 < sipa> as you expect every non-public tx to become a public one after some time (and the auto fluff after timeout essentially guarantees that after some timeout)
12:30 < sipa> so perhaps the "stempool excluding mempool" can be small and have lower consistency requirements
12:30 -!- harrymm [~harrymm@69.161.195.103] has quit [Ping timeout: 244 seconds]
12:30 < sipa> like, we run ATMP to accept things into it, but don't require it is at all times consistent with the actual mempool
12:30 < sipa> as things expire quickly from the extra set, it can have a tight memory limit and not much avenue for dos
12:31 < MarcoFalke> sipa: The dos protection should happen per edge (peer) and not on the global mempool, no?
12:32 < MarcoFalke> The stempool limit would only be a fallback limit
12:32 < MarcoFalke> We wouldn't want one peer use up all the stempool capacity
12:32 -!- promag [~promag@83.223.225.111] has joined #bitcoin-core-dev
12:32 < sipa> right
12:33 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
12:33 < MarcoFalke> Also, I am certain that we leak information by using the global (shared among all peers) stempool
12:33 < sipa> so perhaps it can even be a per-peer small set of unconfirmed dandelion txn, which you use to do dependency checks for dandelion txn coming from that peer
12:34 < sipa> which has much clearer privacy and dos reasonong
12:34 < MarcoFalke> You'd forward but then later discard dandelion txs
12:34 < sipa> well the combined set of those extra txn is your set of to-fluff things
12:35 < MarcoFalke> So if an attacker send the same dandelion tx twice with a rbf one on another route they can guess part of the route
12:35 < sipa> how so?
12:35 < MarcoFalke> (talking about the shared mempool) Not the per-peer set of txs
12:36 < sipa> i like the per-peer set :)
12:36 < sipa> i think you're right that there is risk in a global stempool
12:36 < sipa> the per-peer set sounds like it wouldn't need much more than a way to pass in an entra map with txn to ATMP
12:37 < MarcoFalke> That would have a compute overhead
12:37 < sipa> hardly, i think
12:38 < MarcoFalke> (re-calculating the set of dependencies for all txs)
12:38 < MarcoFalke> just to check on tx
12:38 < sipa> no no
12:38 < MarcoFalke> why?
12:39 < sipa> just something that feeds into the lookup of utxos being spent logic
12:39 < sipa> "if not found in mempool or chainstate, also look here'
12:40 < sipa> but you don't do complete conflict analysis or replacement or whatever in those extra sets
12:40 < MarcoFalke> So you could send a tx that spends and output and the output that was used to create that output (assuming 1in-1out txs for now)?
12:40 < MarcoFalke> s/and/an
12:41 < sipa> right
12:41 < sipa> perhaps you could even permit double spends inside the extra set
12:41 < MarcoFalke> So a peer could drain your allowance
12:41 < MarcoFalke> for free
12:41 < sipa> what allowance?
12:42 < MarcoFalke> "allowance" = txs your dandelion destinations accept
12:42 < MarcoFalke> num tx/minute or whatever
12:42 < sipa> i'm confused
12:43 < MarcoFalke> I think we just concluded that the "cheap check" (pass in set of previous txs) can lead to thinking an invalid tx is valid
12:43 < MarcoFalke> so we'd forward invalid txs
12:43 < sipa> right
12:44 < sipa> well, not invalid
12:44 < sipa> but conflicting, yes
12:44 < MarcoFalke> They'd never be accepted to a real mempool
12:44 < MarcoFalke> never as is invalid consensus
12:44 < sipa> that depends on the order those extra txn get added to people's mempool
12:44 < sipa> no, you do full consensus validation
12:45 < MarcoFalke> So you need to calculate all mempool dependencies and stuff
12:45 < sipa> how so?
12:46 < sipa> validity is just a) can we find the inputs b) are those inputs not yet spent by another mempool txn c) do scripts validate
12:46 < sipa> i suggest skipping just (b) for dandelion relay
12:47 < MarcoFalke> Though, for a) you use the set of {mempool inputs} OR {prev dandelion txs inputs}
12:47 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds]
12:47 < sipa> right
12:47 < MarcoFalke> so if a dandelion txs spent mempool tx
12:48 < sipa> but whenever the mempool changes, you don't update the extra sets, so they can grow inconsistent with eachother
12:48 < sipa> but i don't think that's a problem; you'll notice when trying to fluff
12:48 < MarcoFalke> hmm, give me a sec
12:48 < MarcoFalke> How do I draw a picture in irc?
12:49 < sipa> haha
12:50 < sipa> we should discuss this on the ML though
12:51 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
12:54 < MarcoFalke> Assume mempool has one output: A. Assume dandelion tx spends this input A and creates output B. We send this dandelion tx. Assume another dandelion tx spends {A,B} and creates output C, which is valid, since we use the set of outputs in the mempool and previous dandelion txs, but the tx itself is consensus invalid. Send this tx. Repeat with {A,C}->D, {A,D}->E ... for free
12:55 < sipa> i see your point.
12:55 < MarcoFalke> I hope you prove me wrong, because I also like the per peer set
12:58 < sipa> is there some rate limiting on dandelion txn per peer?
12:58 < MarcoFalke> In my implementation, yes
12:59 < sipa> is there in the BIP? (i haven't read the latest draft)
12:59 < MarcoFalke> not explicitly mentioned
12:59 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Quit: WeeChat 2.2]
13:00 < MarcoFalke> Maybe there is in the appendix (reference implementation), haven't looked too closely at that, though
13:08 < sipa> if you disallow replacement of dandelion txn, it becomes a lot easier
13:08 < MarcoFalke> yeah, but we don't want to kill rbf for dandelion txs
13:08 < sipa> and perhaps that's not crazy; you can replace, but first need to wait until the dandelion relay has settled into the mempool
13:08 < MarcoFalke> I'd rather enforce rbf
13:09 < MarcoFalke> (which is what my cache is effectively doing, I think)
13:09 < sipa> but you don't support dependencies between dandelion txn, or do you?
13:09 < MarcoFalke> nope
13:10 < MarcoFalke> You'd have to use rbf to "eat up" all dependencies
13:11 -!- promag [~promag@83.223.225.111] has quit [Remote host closed the connection]
13:12 < sipa> replacement generally seems to be something that happens in the scale of hours, and certainly longer than interblock time
13:12 < sipa> both in use cases and incentives
13:13 < sipa> while dependent transactions can be in the scale of seconds
13:13 < sipa> (blobs of interdependent txn)
13:13 -!- promag [~promag@83.223.225.111] has joined #bitcoin-core-dev
13:13 < MarcoFalke> What about the use case of "replacement to avoid a change output-round-trip"
13:14 < MarcoFalke> i.e. avoid long chain of unconfirmed
13:14 < sipa> if you're doing that in a scale of seconds-minutes you should probably just batch better
13:16 < MarcoFalke> hmm, starting to like that idea
13:19 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev
13:24 -!- promag [~promag@83.223.225.111] has quit [Remote host closed the connection]
13:30 < gmaxwell> jonasschnelli: It's somewhat implausable to me that someone managed to make a sidechannel vulnerable chacha20 which was also fast. I'm happy to review them for it.
13:31 < gmaxwell> sipa: two layer mempool sounds hard to now screw up and accidentally leak data.
13:36 < gmaxwell> A per peer stempool (which of course shares the actual tx data itself across all peers) makes sense to me.
13:37 < gmaxwell> it it requires you augment the protocol to route the dependencies along the same path as the parent.
13:37 < gmaxwell> which might have privacy implications. .. I think none of the research on dandelion so far really considered chains of unconfirmed txn.
13:38 < gmaxwell> (I'd _generally_ expect that routing children along the same path as parents would be privacy improving, but there may be factors like leaking out of the stem at different points that have bad effects like reducing the privacy of the whole chain to that of the weakest one)
13:39 < sipa> gmaxwell: read on
13:39 < sipa> ah, you already saw the per-peer idea
13:41 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
13:42 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
13:42 < gmaxwell> I also agree that we don't need to care about stem transactions getting invalidated by mempool txn. But I think we do want to check them against each other. In particular I shouldn't be able to give you 100 distinct spends of the same coin and have you route them all out to the same peer. To send two of them to two different peers would be ducky.
13:44 < sipa> gmaxwell: yeah, if you don't care about replacing txn while they are not in the mempool that sounds easy
13:44 < sipa> it means you don't need the dependency tracking or replacement or whatever logic
13:45 < sipa> just verify against the combined set of chainstate+mempool+ peer-specific set of unconfirmed dandelion txn
13:46 < gmaxwell> right, but again, if dandelion parents are peer spectific, we must endeavor to route children along the same path as parents, or otherwise they'll propagate poorly.
13:47 < sipa> dandelion already does that; it has a per-peer destination peer
13:47 < sipa> so subsequent transactions will go to the same outgoing peer
13:47 < gmaxwell> sipa: it has _two_.
13:47 < sipa> unless there is a shuffle in between
13:47 < sipa> only one per incoming peer
13:47 < sipa> two globally
13:47 < gmaxwell> oh right, okay.
13:47 < MarcoFalke> What is the use case for tx chains of dandelion txs?
13:48 < gmaxwell> MarcoFalke: uh, being able to spend your funds without waiting for a block. 
13:48 < sipa> MarcoFalke: what is the use cade for tx chains in general? :)
13:48 < sipa> same answer
13:48 < MarcoFalke> why block, you can wait for a fluff
13:48 < sipa> that's ~minute or so?
13:49 < gmaxwell> if someone pays you 1 BTC, you spend 0.1 ... now your wallet interface needs to randomly _fail_ and tell you that you can't spend again, until a fluff has happened?
13:49 < sipa> you're right, waiting for a block is not relevant here
13:49 < MarcoFalke> yeah, I mean if we don't allow replacement of dandelion txs, we might as well not allow chains
13:49 < sipa> MarcoFalke: i disagree
13:49 < MarcoFalke> and ask people to batch if the time between spends is ~1minute
13:49 < sipa> there is a different timescale
13:50 < gmaxwell> That would mean that we couldn't use dandelion as the standard way to announce transactions, if that were the decision I'd say we shouldn't bother implementing it at all.
13:50 < sipa> as i said before, i think it's reasonable if replacement only works in a timescale of minutes/hours
13:50 < gmaxwell> Ideally people sould batch, sure, but someone cannot guarentee that they won't need to make another payment 40 seconds after the last.
13:50 < sipa> but dependencies need to work in seconds
13:51 < gmaxwell> Why wouldn't we allow replacements? 
13:51 < MarcoFalke> Would be more expensive to check
13:52 < MarcoFalke> potentially scales with the number of txs in this edges cache (stem)
13:52 < gmaxwell> you don't actually 'replace' the transaction, but you can relay a transaction that conflicts with the peer's stemppool if it would otherwise pass the replacement criteria.
13:52 < sipa> gmaxwell: i think that's an order of magnitude more complex to implement
13:52 < gmaxwell> how so? you have a map of tx parents. It's just like the orphan pool.
13:52 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Quit: WeeChat 2.2]
13:53 < gmaxwell> in any case, I don't see a fundimental reason to not allow replacement... it would probably be fine to skip it for now due to complexity.
13:53 < sipa> gmaxwell: the rules for replacement are a complex piece of policy.. that depends on relay fee, discard fee, mempool size, cyclic dependency checks, ...
13:54 < MarcoFalke> ^
13:54 < sipa> all of those don't really have a direct translation to multiple layers of mempool
13:54 < gmaxwell> so uh, how would we handle a dandelion txn which would be a replacement for something in the mempool?
13:55 < sipa> we shouldn't?
13:55 < MarcoFalke> That works
13:55 < gmaxwell> Then I think it's busted.
13:55 < sipa> heh?
13:55 < MarcoFalke> Of course you can replace mempool txs with dandelion txs
13:55 < sipa> oh, ugh.
13:55 < sipa> of course that needs to work
13:55 < MarcoFalke> I mean, maybe only once, but it works
13:55 < gmaxwell> again: I think we cannot make dandelion the standard way to announce txn we should not deploy it. And if it kills replacement of long ago announced txn, then we can't do that.
13:56 < sipa> right
13:56 < MarcoFalke> agree
13:56 < sipa> i don't think that's an issue though
13:56 < gmaxwell> It's simple in any case, see if ATMP would accept, and if so it's eligable for stem relay if not conflicted in the peers' stem cache.
13:56 < sipa> dandelion tx validation operates on the sum of mempool + extra tzn
13:56 < sipa> but it doesn't need to deal with replacements
13:56 < sipa> just validation against that set
13:57 < gmaxwell> also I think we can also 'support replacement'  by fluffing anything that passes ATMP but conflicts with our stem cache.
13:57 < sipa> MarcoFalke gave an example above where that's busted
13:57 < MarcoFalke> sipa: I said it works
13:58 < MarcoFalke> [16:55] <MarcoFalke> That works
13:58 < sipa> oh? what about your a/b, a/c, a/d example?
13:59 < MarcoFalke> Well, that is what I meant with "I mean, maybe only once, but it works"
13:59 < gmaxwell> I'm not following.
13:59 < MarcoFalke> We fell back to the earlier discussion
13:59 < gmaxwell> okay
14:00 < MarcoFalke> [15:54] <MarcoFalke> Assume mempool has one output: A. Assume dandelion tx spends this input A and creates output B. We send this dandelion tx. Assume another dandelion tx spends {A,B} and creates output C, which is valid, since we use the set of outputs in the mempool and previous dandelion txs, but the tx itself is consensus invalid. Send this tx. Repeat with {A,C}->D, {A,D}->E ... for free
14:00 < sipa> if ATMP needs to do complex replacement checks w.r.t things already in the extra set, it becomes hard
14:00 < sipa> replacement checks against the mempool of the form "would this be accepted to the mempool" are easy
14:01 < gmaxwell> the combination of replacement and chaning is cancer. :(
14:01 < MarcoFalke> jup
14:01 < MarcoFalke> So pick one
14:02 < sipa> however, if replacement within the extra set is not allowed, it's easy enough - discard anything that conflicts with the extra set already
14:02 < gmaxwell> Well we can support replacement for non-chained, and also support chaining.
14:02 < sipa> otherwise, validate against the mempool with full policy check, getting utxos from the extra set as needed
14:02 < gmaxwell> and for the kind of replacement we don't support, I think we could still queue the transaction and not propagate it but fluff it when it times out.
14:02 < sipa> if accepted, put in the extra set (which is limited is size, and automatically ezpires through auto fluffing)
14:03 < gmaxwell> so at least chained replacements work, they just might have worse privacy/propagation.
14:03 < sipa> and fluffing is just implemented as adding to the local mempool... which means that stuff that has been invalidated by intermediate mempool action just gets ignored
14:06 < gmaxwell> so the criteria for going into the extra-set is "doesn't need a parent in the extraset and passes ATMP  OR  it needs a parent in the extraset, doesn't conflict with the extra set and with the parent its consensus valid/standard"
14:06 < gmaxwell> and if you get something that conflicts with the extraset, and doesn't pass ATMP, you throw it in the orphanmap.  It'll get connected once the parents get fluffed.
14:07 < gmaxwell> Then: replacement works, chaining works, and chaining+replacement turns into orphans which still work after the parents fluff.
14:10 < gmaxwell> I totally agree that wallets shoudl be batching and whatnot, but consider: we don't even have a friendly way to do that... There is no dohicky in bitcoin core where you can queue a payment, have it draft it, but not send it, waiting for either more payments it can be bached with, timeout, or shutdown trigger.
14:14 < MarcoFalke> So fluffing a chained dandelion tx also fluffs its parents? (even though one of the parents might still be "traveling" on a stem)
14:15 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev
14:16 < gmaxwell> thats why I was saying 'weakest in the chain' above. :(
14:16 < MarcoFalke> Yeah, so the suggestion would be to avoid chaining, but support it
14:17 < sipa> don't fluff things which have an unfluffed parent?
14:22 < MarcoFalke> You'd be keeping them much longer in the cache/embargo (on average) and thus use more space for chained txs than unchained ones on avg
14:23 < MarcoFalke> A child times out, but you couldn't fluff it because the parent's timeout is in the future
14:25 < sipa> i feel like there should perhaps be something where a dependency in the extra set results in the two txn being merged into a packaga
14:26 < sipa> and then have the timeout for the package become a weighted average of the inout timeouts or so
14:26 < sipa> *input
14:27 < sipa> but... complicated
14:37 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
14:38 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
14:41 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has quit [Read error: Connection reset by peer]
14:42 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has joined #bitcoin-core-dev
15:14 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Quit: WeeChat 2.2]
15:14 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev
15:39 -!- promag [~promag@83.223.225.111] has joined #bitcoin-core-dev
15:58 -!- ken2812221 [~User@1.200.203.30] has quit [Ping timeout: 256 seconds]
16:02 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit []
16:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
16:19 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
16:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
16:28 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:47 -!- unholymachine [~quassel@2601:8c:c003:9f16:28cf:9ccf:ebef:3576] has joined #bitcoin-core-dev
16:51 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev
16:52 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has quit [Read error: Connection reset by peer]
16:53 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has joined #bitcoin-core-dev
17:04 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Quit: WeeChat 2.2]
17:43 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
17:44 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
18:01 -!- promag [~promag@83.223.225.111] has quit [Remote host closed the connection]
18:21 -!- Rootsudo [~textual@49.151.151.68] has joined #bitcoin-core-dev
18:36 -!- phwalkr [~phwalkr@2001:1284:f013:7ef3:8587:888a:6442:d649] has joined #bitcoin-core-dev
18:46 -!- Rootsudo [~textual@49.151.151.68] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
18:50 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has quit [Ping timeout: 265 seconds]
18:59 -!- ken2812221 [~ken281222@1.200.219.221] has joined #bitcoin-core-dev
19:13 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
19:13 -!- bitcoinvolumetra [~bitcoinvo@45.56.151.81] has joined #bitcoin-core-dev
19:15 < bitcoinvolumetra> hey guys have 305,000 coins to liquidate at a discount. satoshi test will be supplied to a wallet of your choice on the grounds the buyer can provide validation of funds. preferably mt199/799 supplied to the sellers bank by the buyers bank. any questions please pm me.
19:18 < sipa> bitcoinvolumetra: go away
19:18 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ
19:23 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has quit [Ping timeout: 252 seconds]
19:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
19:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
19:38 <@sipa> bitcoinvolumetra: this is a development channel, not a marketplace. Also, if you were really selling 2 billion dollars worth of BTC, you wouldn't be ramdomly asking strangers on irc
19:57 -!- Rootsudo [~textual@121.54.44.148] has joined #bitcoin-core-dev
20:11 -!- bitcoinvolumetra [~bitcoinvo@45.56.151.81] has quit [Ping timeout: 260 seconds]
20:13 < midnightmagic> he ain't got no time for your logic
20:15 < gmaxwell> Full Billionare mode.
20:17 <@sipa> *double* billionaire mode
20:24 < luke-jr> XD
20:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
20:25 < luke-jr> sipa: maybe it is at such a large discount that it isn't $2B? :P
20:25  * midnightmagic makes head-exploding motions with hands but nothing happens
20:26 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has joined #bitcoin-core-dev
20:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
20:43 -!- zivl [~zivl@71.235.45.168] has quit [Read error: Connection reset by peer]
20:43 -!- zivl [~zivl@2601:19a:837f:e4e1:91ae:89e9:e3ac:83a8] has joined #bitcoin-core-dev
20:53 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
20:54 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
20:56 < ossifrage> Now that I'm not running out of file descriptors for sockets, I've been auditing my connections and was suprised how many IPs have multiple connections to my node
20:57 < gmaxwell> spys.. they'll probably stop doing that once 0.17 is widely deployed.
20:57 < gmaxwell> since it defeats what they're trying to accomplish.
20:58 < gmaxwell> (by connecting multiple times they effectively speed up how fast transactions are relayed to them, making it easier to determine origins)
20:59 < ossifrage> One 111.6.90.203 has 6 connections, whois says it belongs to chinamobile
20:59 < ossifrage> I wonder if that is actually legit traffic from heavily NATed users?
21:00 < gmaxwell> could be, in some cases.. reasons like that are why we don't outright limit.
21:08 -!- Rootsudo [~textual@121.54.44.148] has quit [Read error: Connection reset by peer]
22:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
22:27 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
22:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
22:47 < wumpus> it's possible though the I'd expect the chance is very low that a bunch of NATed users would connect to your node, of all things, all the same time
22:49 < wumpus> two of them, okay, but six?
22:58 < wumpus> especially if they connected aruond the same time, too, and have the same agent string, it's clear
23:13 < wumpus> did I mention I miss the github merge bot here already
23:15 < luke-jr> wumpus: DNS seeds and how light wallets use them can result in a lot of nodes connecting to a small set of listening nodes sometimes
23:28 < wumpus> luke-jr: that's a fair point, so indeed, I don't see it as impossible just unlikely
23:34 -!- phwalkr [~phwalkr@2001:1284:f013:7ef3:8587:888a:6442:d649] has quit [Remote host closed the connection]
23:34 -!- vexbuy [~vexbuy@89.39.107.201] has joined #bitcoin-core-dev
23:36 -!- phwalkr [~phwalkr@2001:1284:f013:7ef3:8587:888a:6442:d649] has joined #bitcoin-core-dev
23:36 -!- phwalkr [~phwalkr@2001:1284:f013:7ef3:8587:888a:6442:d649] has quit [Remote host closed the connection]
23:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
23:43 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
23:44 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds]
23:53 < gmaxwell> sipa: skip RW locks and go straight to URCU https://lwn.net/Articles/573424/  ? :P
--- Log closed Mon Aug 13 00:00:39 2018