1 2016-07-12 01:51:42	0|phantomcircuit|fyi there's someone repeatedly connecting and disconnecting from a narrow ip range
 2 2016-07-12 01:51:43	0|phantomcircuit|2016-07-12 01:47:04.455787 receive version message: /bitcoinj:0.14.1/: version 70001, blocks=0, us=127.0.0.1:8333, peer=40824, peeraddr=37.97.164.230:60893
 3 2016-07-12 01:52:41	0|phantomcircuit|37.97.164.159
 4 2016-07-12 01:52:44	0|phantomcircuit|37.97.164.160
 5 2016-07-12 01:52:47	0|phantomcircuit|37.97.164.230
 6 2016-07-12 01:52:48	0|phantomcircuit|37.97.164.231
 7 2016-07-12 02:19:28	0|Chris_Stewart_5|Can you receive messages on the p2p network from a non standard port? ie not 8333/18333
 8 2016-07-12 02:19:48	0|Chris_Stewart_5|if I send a version message with the non standard port?
 9 2016-07-12 02:30:00	0|sipa|yes
10 2016-07-12 02:30:16	0|sipa|but nodes strongly prefer connecting to nodes on the standard port
11 2016-07-12 02:30:38	0|sipa|they will pretty much only choose nodes with nonstandard ports if they have no other option
12 2016-07-12 02:33:30	0|dgenr8|good news. we don't have to worry too much that time-locked transactions could be delayed by 30 days by evil miners https://github.com/bitcoinxt/bitcoinxt/pull/142#issuecomment-231918519
13 2016-07-12 03:29:12	0|GitHub136|[13bitcoin] 15dcousens opened pull request #8332: semi trivial: clarify witness branches in transaction.h serialization (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8332
14 2016-07-12 04:11:14	0|gmaxwell|dgenr8: uh. you realize that when you have .5 or more non-honest miners sustained, the existance of an honest blocks is purely their choice, right?  So that graph doesn't make a lot of sense.
15 2016-07-12 04:12:06	0|gmaxwell|yet again you have another negligently wrong security analysis, where you report 50% as absolutely safe, when in fact it's a guarenteed failure (assuming dedicated attackers)
16 2016-07-12 04:16:44	0|dgenr8|indeed, a 51% attack is a far greater threat than a blocktime slowdown, you get it
17 2016-07-12 04:18:42	0|gmaxwell|what? your analysis is just obviously broken on its face.
18 2016-07-12 04:19:12	0|gmaxwell|it claims that 80% dishonest mining is unable to slew the time.
19 2016-07-12 04:20:05	0|gmaxwell|This is obviously untrue, so you've make some obvious mistake-- if you have any result that isn't 100% at 50% hashpower.
20 2016-07-12 04:23:16	0|gmaxwell|And, what the heck is  "a 51% attack" -- Bitcoin exists as a confluence of incentives, one part of it is that even a user who buys up large amounts of hashpower for a brief period only gains the ability to reorganize recent transactions, which is difficult to profitably exploit at any scale-- which users can protect themselves from by waiting for additional confirmations.  Under the security mod
21 2016-07-12 04:23:22	0|gmaxwell|el change that you propose (and incorportated into your software without an adequate disclosure because you (based on the prior conversation) weren't actually aware of the implications,  miners that achieve a large amount (unclear how much but a majority is clearly sufficient) can add huge amounts of coins to themselves without any chain reorg and without even making a purchase.
22 2016-07-12 04:25:36	0|gmaxwell|(re obviously didn't understand, I'm referring to your prior claim that 100% hashpower and control over the user's clock was needed.)
23 2016-07-12 04:26:31	0|dgenr8|you read that statement completely wrong
24 2016-07-12 04:28:54	0|gmaxwell|K. Did I misunderstand that this was shipped out in XT without a release note pointing out the security model change; to a user community that obsesses over even minor softforks as taking away validation?
25 2016-07-12 04:34:09	0|gmaxwell|am I misreading your graph showing that a miner with 79% hashpower has a non-unity probablity of success at moving the timestamp back?
26 2016-07-12 04:34:59	0|dgenr8|XT, unlike core, would warn loudly as that 51% attack slowed the generation rate
27 2016-07-12 04:35:27	0|gmaxwell|Did I miss the fact that this whole design is just an insecure rip off of the proposal from this channel to use 30 days of _work_ at the current tip, as a gate on signature checks?
28 2016-07-12 04:36:31	0|gmaxwell|dgenr8: there is no need for the generation rate to slow significantly enough to trigger any warning that doesn't false positive constantly.
29 2016-07-12 04:41:37	0|dgenr8|the reason XT exists is that a few people cannot abide the choices you are making. it's too bad. for a while, folks worked together pretty well.
30 2016-07-12 04:41:49	0|dgenr8|you view the loss of talented people like gavin, jgarzik, and hearn as positve, and seek to utterly discredit others. but i'm OT
31 2016-07-12 04:42:10	0|gmaxwell|dgenr8: You are going to get some people robbed blind with this kind of sloppyness; it's a risk to our entire industry.
32 2016-07-12 04:45:42	0|gmaxwell|I don't have to do anything to discredit you (not to mention other people)-- you do so _yourself_; by shipping software to users that you don't even understand and being continually antagonistic to people who would otherwise help you avoid danger.
33 2016-07-12 04:47:10	0|dgenr8|Perhaps try again to manipulate the timestamp on testnet. Any hashing that sets timestamps correctly has a huge advantage though.
34 2016-07-12 04:47:36	0|gmaxwell|dgenr8: you didn't even notice the successful attack on testnet against classic then, I guess.
35 2016-07-12 04:48:32	0|dgenr8|i did see it was pushed it back a few days
36 2016-07-12 04:49:17	0|gmaxwell|A few days ago you seemed to be arguing that using the _miner provided_ timestamps on blocks to decide to bother validating the block or not would require 100% hashpower and control of the users local clock to exploit-- functionality you added without even adding a _release note_ to Bitcoin XT.  Your response to this being pointed out was to again repeat accusations that I backdoored your softwa
37 2016-07-12 04:49:23	0|gmaxwell|re. After having your mistaken understanding thrust on you; you've gone away and come back with another obviously broken misunderstanding; again radically overstating the security of this 'optimization'.
38 2016-07-12 04:50:07	0|gmaxwell|The only reason I even knew that XT and classic had incorporated this ill advised security change is because of people bragging about how much faster it synced. Yea, it's faster when you don't check 95% of the signautures, blindly...
39 2016-07-12 04:51:06	0|gmaxwell|So if you think you're going to make a war for node operation a war about who can make the most insecure software-- the stuff with the most tail risk of total failure, then hell yes I'm going to call that out. And you should be thankful that I've taken the concerns directly to you,  and not-- like other people in your community-- gone straight to the press with them.
40 2016-07-12 04:51:36	0|gmaxwell|(Especially when it's so easy to demonstrate the exploit on a live network)
41 2016-07-12 04:53:16	0|dgenr8|hmm. i think this whole display is for the benefit of third parties. anyhow i disagree on the degree of risk, but that's not to say the regular checkpoints couldn't come back or that the default selection could even change. but that belongs to a rational discussion we're not having
42 2016-07-12 04:53:39	0|gmaxwell|Fair enough.
43 2016-07-12 04:55:23	0|dgenr8|my concern with your thin blocks change was not that it made it to XT briefly.  it was that you removed the thin blocks functionality from core users.
44 2016-07-12 04:56:36	0|gmaxwell|I'm sorry for being such a dick on this. I do really think that the blockheader based skipping validation is a race to the bottom-- who can provide the worst security (for the fastest performance), to hell with the consequences (and no one adequately disclosing it).  It doesn't help that a much better way of doing the same thing was already proposed in Core; and to me it seems like pure NIH to i
45 2016-07-12 04:56:42	0|gmaxwell|mplement a much riskier version.
46 2016-07-12 04:58:35	0|gmaxwell|dgenr8: I had no idea that it had any impact there, hell, the change was actually motivated by a complaint you made about the behavior (which, since you didn't disclose, I didn't know it was due to the prior limit of 1000 breaking mike's thinblocks). I didn't even initially use the bloom filter until wumpus and pieter beat me down on the memory usage.  And ultimately since there was _no_ reliabl
47 2016-07-12 04:58:41	0|gmaxwell|e mechenism to request transactions that were already in a block (an observation we made on that approach in 2013), mike's way of doing it couldn't have been reliable.
48 2016-07-12 04:59:12	0|gmaxwell|I also explained this previously, but you seem even more insistant on assuming bad faith on my part than I am on seeing you as a fool. :)
49 2016-07-12 05:00:44	0|gmaxwell|Seriously, if I wanted to 'backdoor' your software, the avenues available are far more profound-- your response has made me profoundly uncomfortable with the continued existance of Bitcoin XT-- you'll continue to copy code from Core, and when the inevitable errors that happen from interactions which I could never have anticiapted; you've shown that you'll accuse me of unethical or even criminal
50 2016-07-12 05:00:50	0|gmaxwell|conduct.
51 2016-07-12 05:02:26	0|gmaxwell|s/blockheader based/blockheader timestamp based/  to be more clear. the earlier proposal of using total work instead of timestamps, is much more appealing.
52 2016-07-12 05:03:35	0|dgenr8|whoa slow down ... the map size problem I found had nothing to do with thin blocks, which is why i was eager to copy your fix for it
53 2016-07-12 05:04:29	0|gmaxwell|dgenr8: I thought (after trying to figure out why you even copied the change) the reason you commented on the map size is because with thinblocks the small map meant the far end had no idea that you had most of the transactions you already had, then sent redundant stuff.
54 2016-07-12 05:04:51	0|dgenr8|no, i found it while looking at some other core PR
55 2016-07-12 05:05:33	0|gmaxwell|then why did you even assume I was trying to screw up your thinblocks stuff?  I don't believe I had _any_ idea XT was even screwing with that at that time.
56 2016-07-12 05:06:11	0|gmaxwell|(I wouldn't have assumed it because the patch mike had was so obviously junk-- handling it in the ping handler, no way to cope with missing transactions except praying that they were still in the relay cache)
57 2016-07-12 05:06:18	0|dgenr8|if you recall that effect was found independently weeks later by Peter Tschipper
58 2016-07-12 05:06:51	0|dgenr8|its all irrelevant now anyway
59 2016-07-12 05:07:27	0|gmaxwell|in any case, indeed it broke the thin block stuff completely; then you merged it, and released a new version with it and the initial release of that thinblock stuff--- meaning you hadn't even tested it for basic functionality; which is basically terrifying from my perspective.
60 2016-07-12 05:07:42	0|gmaxwell|You can't deny that the commit message was scream loud totally clear about _exactly_ what the change did.
61 2016-07-12 05:08:35	0|dgenr8|it went to master, not a release.  please don't put 'backdoor' in quotes as I never said that word and as I said, that was not my concern
62 2016-07-12 05:08:35	0|gmaxwell|and so how the hell can I defend myself against bad testing on your part?  I made a very very clearly described change, which you didn't comment on, integrated so it broke your stuff totally, then claimed misconduct on my part. Thats seriously bad mojo.
63 2016-07-12 05:11:37	0|gmaxwell|that was certantly what people extracted from your comments, https://www.reddit.com/r/bitcoinxt/comments/43jgtt/blockstream_engineers_maxwell_and_wuille_caught/
64 2016-07-12 05:12:17	0|gmaxwell|Though indeed, I guess you only use the words "your sneak attack" and not "backdoor" yourself.
65 2016-07-12 05:19:14	0|gmaxwell|and "Here we have Blockstream actively fighting scaling improvements"   (and not to mention misrepresentation the that change was to avoid a one in a million false positive, when the chance happens for every txn indpendantly, so after seeing just 10k txn the chance is 1%.)
66 2016-07-12 05:29:46	0|gmaxwell|XT v0.11E appears to contain the setinventory known and 'thinblock' change; but now looking at it I see you left it probablistically screwing over spv clients.
67 2016-07-12 05:30:10	0|eragmus|gmaxwell: Why are you wasting your precious time with a dgenr8 like him? :) Or, at least, maybe charge him and the others by the minute for this consulting.
68 2016-07-12 05:30:14	0|gmaxwell|I wonder how many bitcoins will be lost by people throwing out wallets that look empty but arn't. :(
69 2016-07-12 05:31:02	0|eragmus|dgenr8: Btw, you should be careful before making everyone laugh so much -- "the loss of talented people like gavin, jgarzik, and hearn" -- I nearly choked. I might have to bill you for any potential hospital expenses.
70 2016-07-12 05:32:07	0|gmaxwell|eragmus: (1) because software that silently downgrades security then promotes itself as faster is a risk to the continued viability and value of Bitcoin, which I care about. .. and because he attacks me by claiming that I've acted unethically, which if left unchallenged ends up recycled as accepted truth in places like the NYT where it can cause me lifelong harm.
71 2016-07-12 05:33:55	0|wumpus|PSA: this channel is about bitcoin core development, XT and classic and certainly non-technical drama around them are very off-topic
72 2016-07-12 05:37:28	0|phantomcircuit|indeed wumpus is right, possibly this could move to #bitcoin
73 2016-07-12 05:38:02	0|phantomcircuit|wumpus, fyi you might find this interesting https://github.com/bitcoin/bitcoin/issues/8333
74 2016-07-12 05:38:55	0|dgenr8|gmaxwell: breadwallet already detects the condition and corrects it by reconnecting
75 2016-07-12 05:41:08	0|wumpus|phantomcircuit: in what world is 31.87ms slow, I mean, I've seen logs in where validation took that *per txin* :)
76 2016-07-12 05:43:08	0|phantomcircuit|wumpus, in a world where i can mess with settings and have an average block validate in 30ms
77 2016-07-12 05:43:19	0|phantomcircuit|thanks to my 8GiB sigcache and 16GiB dbcache
78 2016-07-12 05:43:33	0|phantomcircuit|(and a hack that loads the entire utxo into cache on start)
79 2016-07-12 05:44:40	0|gmaxwell|wumpus: he's optimizing mining overheads, some of them are harder to address than bitcoind behavior. :)  (e.g. cannot decrease the radius of the earth :P )
80 2016-07-12 05:44:59	0|wumpus|phantomcircuit: anyhow to say more about it we
81 2016-07-12 05:45:06	0|wumpus|'d need detailed profiling of that step
82 2016-07-12 05:46:36	0|phantomcircuit|gmaxwell, im working on that, i have a plan to drill down and around the mantle
83 2016-07-12 05:46:44	0|phantomcircuit|i only need a few trillion dollars
84 2016-07-12 05:47:47	0|gmaxwell|/msg phantomcircuit has the patent issued yet for the neutrion based transciever yet?
85 2016-07-12 05:49:29	0|wumpus|gmaxwell: yes can only get as close as possible to the physical limit
86 2016-07-12 05:52:47	0|gmaxwell|wumpus: there are a number of things that aren't the physical limits but are still harder to speedup than core, also at least as long as validation is in the relay critical path, any part of validation adds up as the node count increases. Though thats probably better fixed by getting validation out of the critcial path for relay to other full nodes.
87 2016-07-12 06:02:52	0|wumpus|gmaxwell: what kind of things, optimizing the P2P protocol? network infrastructure?
88 2016-07-12 06:04:50	0|wumpus|as long as any part of validation is the bottleneck, optimizing that is still part of 'speeding up core'
89 2016-07-12 06:07:01	0|wumpus|if validation is out of the critical part all that is left is the network, where the random P2P network isn't the most efficient structure for propagating something around the world quickly
90 2016-07-12 06:09:23	0|wumpus|(but that's what the relay network is for)
91 2016-07-12 06:37:13	0|sipa|phantomcircuit: it's good to see that part of the logic becoming measurable :)
92 2016-07-12 06:38:22	0|sipa|phantomcircuit: it would be nice if you could see if the two PRs i referenced on your issue affect that number
93 2016-07-12 09:47:22	0|GitHub97|13bitcoin/06master 144831a16 15Wladimir J. van der Laan: qt: periodic translation update...
94 2016-07-12 09:47:22	0|GitHub97|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/4831a16223dbb42da3091e616c47eeb01f53f73b
95 2016-07-12 10:54:52	0|GitHub74|[13bitcoin] 15kholbekj opened pull request #8335: update inline copyright notices (06master...06update-inline-copyright) 02https://github.com/bitcoin/bitcoin/pull/8335
96 2016-07-12 11:57:22	0|GitHub72|[13bitcoin] 15jonasschnelli closed pull request #8335: update inline copyright notices (06master...06update-inline-copyright) 02https://github.com/bitcoin/bitcoin/pull/8335