00:10:48stqism:stqism is now known as irunbsd-O3-flto-
00:11:02irunbsd-O3-flto-:irunbsd-O3-flto- is now known as irunbsd-ansi-flt
00:12:11irunbsd-ansi-flt:irunbsd-ansi-flt is now known as irunPlan9
01:44:34therealnanotube:therealnanotube is now known as nanotube
05:57:58dsnrk:dsnrk has left #bitcoin-wizards
07:18:37Quanttek_:Quanttek_ is now known as Quanttek
17:12:19crescend_:@BlueMatt sup
17:15:18crescend_:ipv6 dnsseeds yo
17:34:10[BNC]dansmith:[BNC]dansmith is now known as dansmith_btc
17:56:17wallet42:wallet42 is now known as Guest78827
17:56:17wallet421:wallet421 is now known as wallet42
19:57:18irunPlan9:irunPlan9 is now known as stqism
20:57:43stqism:stqism is now known as GNU\stqism
21:02:16GNU\stqism:GNU\stqism is now known as stqism
22:11:01justanotheruser: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:23tacotime:justanotheruser, not really as far as i can tell.
22:14:50tacotime:aside from being able to cope with a large hash rate falling off your network.
22:15:10justanotheruser:tacotime: why not? If there is a huge drop in hashrate...
22:15:17justanotheruser:yes, that would be the advantage from what I can see
22:15:30justanotheruser:Or there could be a huge drop in price
22:15:47justanotheruser:then the miners may not have an incentive to mine until the difficulty dropped
22:16:28justanotheruser:I may be missing a major flaw in it though
22:18:17tacotime:justanotheruser, opens you to a lot of timestamping attacks
22:18:26tacotime:kgw use of double opens you to forks too
22:19:24tacotime:monero's is comparatively slowly adjusting though
22:20:41tacotime:andytoshi has a lot of things to say about network consensus on rapidly adjusting difficulties too
22:31:46gmaxwell:justanotheruser: making the difficulty change faster reduces security to isolation.
22:32:03gmaxwell:It increases robustness to the hashrate suddenly falling though, as tacotime notes.
22:32:40gmaxwell: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:52gmaxwell: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:06nshsome:nshsome is now known as [nsh]
23:47:16jaekwon:any thoughts on libswift as a potential protocol for block propagation?
23:48:24phantomcircuit:jaekwon, generally speaking generic solutions are going to be vastly suboptimal
23:49:24phantomcircuit: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:38phantomcircuit:this is however significantly more complicated than simply asking for 500 blocks at a time
23:49:56sipa:zdepends whether you want to optimize for bandwidth or for latency
23:50:14sipa:during IBD, typically bandwidth
23:50:21sipa:afterwards, typically latency
23:51:42phantomcircuit:sipa, im not sure there is actually a meaningful tradeoff to be made there
23:51:43phantomcircuit:is there?
23:51:44sipa:i don't know swift, but from the short description i read i guess it deals very badly with malicious peers
23:52:05jaekwon: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:16sipa:sending tx hashes first means an extra roundtrip
23:52:36sipa:an extra roundtrip is easily +100ms
23:52:56phantomcircuit:sipa, the last part where the peer request the transactions they're missing is optional though
23:52:58sipa:during that time, on a 100 Mbit connection, you can send a full 1Mb block
23:53:03phantomcircuit:if you're sure the peer couldn't have them
23:53:20phantomcircuit:then you can push the block header -> merkle tree -> transactions you think they dont have
23:53:28sipa:if only a single transaction is missing, the extra roundtrip is necessary
23:53:47sipa:and you've wasted a good 10-20% of bandwidth on just sending tx hashes
23:53:49phantomcircuit:sipa, sure but you can keep track of which transactions you've already sent them
23:54:00jaekwon: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:24phantomcircuit:hmm you're right the merkle tree is fairly large compared to the actual txs
23:54:30phantomcircuit:hadn't thought of that
23:54:36sipa:phantomcircuit: with the current p2p implementation, it's impossible
23:54:44sipa:even if you did send a tx already
23:54:54sipa:the peer may have discarded it due to various reasons
23:55:04sipa:and removing those reasons would mean trivial dos attacks
23:55:34sipa:and you could add a mechanism for warning the sender that you're discarding something
23:55:42sipa:but you'll still have race conditions
23:55:56sipa:with a serious risk of needing to send an extra transaction in an extra roundtrip
23:58:18phantomcircuit:sipa, hmm true
23:59:14sipa:with 10 Mb blocks the store is likely different
23:59:25phantomcircuit:sipa, tbh i push new blocks out to the entire network all at once pretty much completely blindly
23:59:43phantomcircuit:so i guess i shouldn't be commenting on this in the other direction