00:10:48	stqism:	stqism is now known as irunbsd-O3-flto-
00:11:02	irunbsd-O3-flto-:	irunbsd-O3-flto- is now known as irunbsd-ansi-flt
00:12:11	irunbsd-ansi-flt:	irunbsd-ansi-flt is now known as irunPlan9
01:44:34	therealnanotube:	therealnanotube is now known as nanotube
05:57:58	dsnrk:	dsnrk has left #bitcoin-wizards
07:18:37	Quanttek_:	Quanttek_ is now known as Quanttek
17:12:19	crescend_:	@BlueMatt sup
17:13:45	BlueMatt:	hi?
17:15:18	crescend_:	ipv6 dnsseeds yo
17:34:10	[BNC]dansmith:	[BNC]dansmith is now known as dansmith_btc
17:56:17	wallet42:	wallet42 is now known as Guest78827
17:56:17	wallet421:	wallet421 is now known as wallet42
19:57:18	irunPlan9:	irunPlan9 is now known as stqism
20:57:43	stqism:	stqism is now known as GNU\stqism
21:02:16	GNU\stqism:	GNU\stqism is now known as stqism
22:11:01	justanotheruser:	Are all these difficulty changing algorithms altcoins have (gravity well, the one that monero uses) an advantage over just changing every 2 weeks?
22:14:23	tacotime:	justanotheruser, not really as far as i can tell.
22:14:50	tacotime:	aside from being able to cope with a large hash rate falling off your network.
22:15:10	justanotheruser:	tacotime: why not? If there is a huge drop in hashrate...
22:15:17	justanotheruser:	yes, that would be the advantage from what I can see
22:15:30	justanotheruser:	Or there could be a huge drop in price
22:15:47	justanotheruser:	then the miners may not have an incentive to mine until the difficulty dropped
22:16:28	justanotheruser:	I may be missing a major flaw in it though
22:18:17	tacotime:	justanotheruser, opens you to a lot of timestamping attacks
22:18:26	tacotime:	kgw use of double opens you to forks too
22:19:24	tacotime:	monero's is comparatively slowly adjusting though
22:20:03	tacotime:	https://wiki.bytecoin.org/wiki/Difficulty
22:20:41	tacotime:	andytoshi has a lot of things to say about network consensus on rapidly adjusting difficulties too
22:31:46	gmaxwell:	justanotheruser: making the difficulty change faster reduces security to isolation.
22:32:03	gmaxwell:	It increases robustness to the hashrate suddenly falling though, as tacotime notes.
22:32:40	gmaxwell:	So basically you can choose to optimize for security when people care about using the coin vs usability when miners care only intermittently.
22:33:52	gmaxwell:	There are perhaps compromises in between. But it feels a bit like hyperoptimizing the color of the shed to me, the hashrate instability are perhaps addressed better with other means.
23:01:06	nshsome:	nshsome is now known as [nsh]
23:47:16	jaekwon:	any thoughts on libswift as a potential protocol for block propagation?
23:48:24	phantomcircuit:	jaekwon, generally speaking generic solutions are going to be vastly suboptimal
23:49:24	phantomcircuit:	jaekwon, the optimal strategy is to send peers only that data which they do not already have, so block headers -> merkle tree -> peer requests transactions they're missing
23:49:38	phantomcircuit:	this is however significantly more complicated than simply asking for 500 blocks at a time
23:49:56	sipa:	zdepends whether you want to optimize for bandwidth or for latency
23:50:14	sipa:	during IBD, typically bandwidth
23:50:21	sipa:	afterwards, typically latency
23:51:42	phantomcircuit:	sipa, im not sure there is actually a meaningful tradeoff to be made there
23:51:43	phantomcircuit:	is there?
23:51:44	sipa:	i don't know swift, but from the short description i read i guess it deals very badly with malicious peers
23:51:48	sipa:	sure
23:52:05	jaekwon:	Maybe I should ask this @ bitcoin-dev. i'm not too familiar with the underlying bitcoin gossip protocol, but based on the protocol specification it looks like, for old blocks, peers asks for blocks with a "getblocks", gets some "invs" in response, then gets whole blocks via "getdata" for each block. Is that right
23:52:16	sipa:	sending tx hashes first means an extra roundtrip
23:52:36	sipa:	an extra roundtrip is easily +100ms
23:52:56	phantomcircuit:	sipa, the last part where the peer request the transactions they're missing is optional though
23:52:58	sipa:	during that time, on a 100 Mbit connection, you can send a full 1Mb block
23:53:03	phantomcircuit:	if you're sure the peer couldn't have them
23:53:04	sipa:	huh?
23:53:20	phantomcircuit:	then you can push the block header -> merkle tree -> transactions you think they dont have
23:53:28	sipa:	if only a single transaction is missing, the extra roundtrip is necessary
23:53:47	sipa:	and you've wasted a good 10-20% of bandwidth on just sending tx hashes
23:53:49	phantomcircuit:	sipa, sure but you can keep track of which transactions you've already sent them
23:54:00	jaekwon:	sipa: really? I figure it deals fine with malicious peers since it's content addressed… hmm right, come to think of it, i haven't read anything on tit-for-tat bandwidth trading.
23:54:24	phantomcircuit:	hmm you're right the merkle tree is fairly large compared to the actual txs
23:54:30	phantomcircuit:	hadn't thought of that
23:54:36	sipa:	phantomcircuit: with the current p2p implementation, it's impossible
23:54:44	sipa:	even if you did send a tx already
23:54:54	sipa:	the peer may have discarded it due to various reasons
23:55:04	sipa:	and removing those reasons would mean trivial dos attacks
23:55:34	sipa:	and you could add a mechanism for warning the sender that you're discarding something
23:55:42	sipa:	but you'll still have race conditions
23:55:56	sipa:	with a serious risk of needing to send an extra transaction in an extra roundtrip
23:58:18	phantomcircuit:	sipa, hmm true
23:59:14	sipa:	with 10 Mb blocks the store is likely different
23:59:25	phantomcircuit:	sipa, tbh i push new blocks out to the entire network all at once pretty much completely blindly
23:59:43	phantomcircuit:	so i guess i shouldn't be commenting on this in the other direction
23:59:43	phantomcircuit:	heh