Pastebin launched a little side project called HostCabi.net, check it out ;-)Don't like ads? PRO users don't see any ads ;-)
Public Pastes
Guest

Untitled

By: a guest on Nov 16th, 2013  |  syntax: None  |  size: 95.04 KB  |  hits: 930  |  expires: Never
download  |  raw  |  embed  |  report abuse  |  print
Text below is selected. Please press Ctrl+C to copy to your clipboard. (⌘+C on Mac)
  1. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  2.       "Peter Todd <pete@petertodd.org>"
  3. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  4.       "John Dillon <john.dillon892@googlemail.com>"
  5. That's a fair point. I'll increase the reward to $1000USD.
  6.  
  7. Glad to hear about your progress! Keep me updated.
  8. gpg: Signature made Tue 23 Apr 2013 12:11:05 PM GMT using RSA key ID 2636188F
  9. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  10.  
  11. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  12.       "Peter Todd <pete@petertodd.org>"
  13. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  14.       "John Dillon <john.dillon892@googlemail.com>"
  15. Speaking of surprising people, I heard back from a site that they'd
  16. really like another month before anything happens with replacement, so
  17. all the more reason to not sweat it.
  18.  
  19. Wouldn't be a bad idea to mention it on the forums.
  20.  
  21. --
  22. 'peter'[:-1]@petertodd.org
  23. 0000000000000060acb759e42502fa08143a91796f9720b67813d77d879d1d28
  24. gpg: Signature made Sun 05 May 2013 08:30:47 PM GMT using RSA key ID A5F091FB
  25. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  26. gpg:                 aka "[jpeg image of size 5220]"
  27.  
  28. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  29.       "Peter Todd <pete@petertodd.org>"
  30. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  31.       "John Dillon <john.dillon892@googlemail.com>"
  32. Just a request, could you sign my PGP key?
  33.  
  34. As you have probably guessed my intent is to stay anonymous. This is my real
  35. name, but not my usual email, so the usual PGP web of trust procedures don't
  36. really apply.
  37.  
  38. Basically, when you get down to it the question is if this PGP key corresponds
  39. to my identity, and that identity is Bitcoin John Dillon right now.
  40.  
  41. Thanks,
  42.  
  43. John Dillon (whomever that may be)
  44. gpg: Signature made Mon 29 Apr 2013 03:03:15 AM GMT using RSA key ID 2636188F
  45. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  46.  
  47. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  48.       "Peter Todd <pete@petertodd.org>"
  49. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  50.       "John Dillon <john.dillon892@googlemail.com>"
  51. On Mon, Apr 29, 2013 at 03:04:30AM +0000, John Dillon wrote:
  52. > Just a request, could you sign my PGP key?
  53. >
  54. > As you have probably guessed my intent is to stay anonymous. This is my real
  55. > name, but not my usual email, so the usual PGP web of trust procedures don't
  56. > really apply.
  57. >
  58. > Basically, when you get down to it the question is if this PGP key corresponds
  59. > to my identity, and that identity is Bitcoin John Dillon right now.
  60.  
  61. Hmm... Yeah, I think you have a good point; I'll sign it. I mentioned
  62. the exact same issue with Satoshi's PGP key actually in a pull-req with
  63. regard to the foundation bylaws. (they referenced his key by the
  64. insecure 32-bit keyid)
  65.  
  66. Nice job with the PGP keys... maybe it's all the better that we have
  67. people like you making that kind of "dirty work" happen and
  68. demonstrating attacks in a relatively controlled way. Personally I'm of
  69. the opinion that *if* the 1MB blocksize is kept the way it is, allowing
  70. data in the chain isn't a disaster. ~57GB a year is a lot sure, but it's
  71. a managable problem.
  72.  
  73. --
  74. 'peter'[:-1]@petertodd.org
  75. gpg: Signature made Mon 29 Apr 2013 03:14:13 AM GMT using RSA key ID A5F091FB
  76. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  77. gpg:                 aka "[jpeg image of size 5220]"
  78.  
  79. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  80.       "Peter Todd <pete@petertodd.org>"
  81. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  82.       "John Dillon <john.dillon892@googlemail.com>"
  83. I hope that helped you guys, but sadly I think you are up against people who
  84. simply have an axe to grind. Still let me know if I can help in the future.
  85.  
  86. Looks like I am going to have some substantial commitments around the time of
  87. the conference. Not sure exactly when but I'll likely be out of email contact
  88. for two or three weeks. You might want to do the same sometimes too you know,
  89. at least when it comes to forums and github. Focus is good sometimes.
  90.  
  91. Just a suggestion...
  92.  
  93. > Can you write something reasonable here?
  94. gpg: Signature made Wed 01 May 2013 02:56:43 AM GMT using RSA key ID 2636188F
  95. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  96.  
  97. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  98.       "Peter Todd <pete@petertodd.org>"
  99. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  100.       "John Dillon <john.dillon892@googlemail.com>"
  101. FWIW I have Jabber chat on pete@petertodd.org
  102.  
  103. Use off-the-record encryption, passphrase verification word 195618d5
  104.  
  105. --
  106. 'peter'[:-1]@petertodd.org
  107. 0000000000000195618d5c4434d24ac955acbc265c4f3b15ecc2c47c572a1b7e
  108. gpg: Signature made Thu 02 May 2013 03:35:58 AM GMT using RSA key ID A5F091FB
  109. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  110. gpg:                 aka "[jpeg image of size 5220]"
  111.  
  112. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  113.       "Peter Todd <pete@petertodd.org>"
  114. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  115.       "John Dillon <john.dillon892@googlemail.com>"
  116. Here's my new section. What do you think?
  117.  
  118. Section 2.2     Transact on Their Own Terms: The Corporation recognizes the decentralized, consensus-based nature of the Bitcoin technology. The Corporation will seek to protect and promote decentralization through legal and technical means, including, but not limited to, the fungibility of individual Bitcoins, the ability of individuals to participate fully in Bitcoin by running full validating nodes, the ability of individuals to operate a full validating node anonymously, and the ability to chose what level of privacy their transactions will have, including anonymously.
  119. gpg: Signature made Fri 03 May 2013 02:59:57 AM GMT using RSA key ID 2636188F
  120. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  121.  
  122. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  123.       "Peter Todd <pete@petertodd.org>"
  124. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  125.       "John Dillon <john.dillon892@googlemail.com>"
  126. That's a fair point. I'll increase the reward to $1000USD.
  127.  
  128. Glad to hear about your progress! Keep me updated.
  129. gpg: Signature made Tue 23 Apr 2013 12:11:05 PM GMT using RSA key ID 2636188F
  130. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  131.  
  132. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  133.       "Peter Todd <pete@petertodd.org>"
  134. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  135.       "John Dillon <john.dillon892@googlemail.com>"
  136. Speaking of surprising people, I heard back from a site that they'd
  137. really like another month before anything happens with replacement, so
  138. all the more reason to not sweat it.
  139.  
  140. Wouldn't be a bad idea to mention it on the forums.
  141.  
  142. --
  143. 'peter'[:-1]@petertodd.org
  144. 0000000000000060acb759e42502fa08143a91796f9720b67813d77d879d1d28
  145. gpg: Signature made Sun 05 May 2013 08:30:47 PM GMT using RSA key ID A5F091FB
  146. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  147. gpg:                 aka "[jpeg image of size 5220]"
  148.  
  149. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  150.       "Peter Todd <pete@petertodd.org>"
  151. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  152.       "John Dillon <john.dillon892@googlemail.com>"
  153. Speaking of surprising people, I heard back from a site that they'd
  154. really like another month before anything happens with replacement, so
  155. all the more reason to not sweat it.
  156.  
  157. Wouldn't be a bad idea to mention it on the forums.
  158.  
  159. --
  160. 'peter'[:-1]@petertodd.org
  161. 0000000000000060acb759e42502fa08143a91796f9720b67813d77d879d1d28
  162. gpg: Signature made Sun 05 May 2013 08:30:47 PM GMT using RSA key ID A5F091FB
  163. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  164. gpg:                 aka "[jpeg image of size 5220]"
  165.  
  166. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  167.       "Peter Todd <pete@petertodd.org>"
  168. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  169.       "John Dillon <john.dillon892@googlemail.com>"
  170. Speaking of surprising people, I heard back from a site that they'd
  171. really like another month before anything happens with replacement, so
  172. all the more reason to not sweat it.
  173.  
  174. Wouldn't be a bad idea to mention it on the forums.
  175.  
  176. --
  177. 'peter'[:-1]@petertodd.org
  178. 0000000000000060acb759e42502fa08143a91796f9720b67813d77d879d1d28
  179. gpg: Signature made Sun 05 May 2013 08:30:47 PM GMT using RSA key ID A5F091FB
  180. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  181. gpg:                 aka "[jpeg image of size 5220]"
  182.  
  183. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  184.       "Peter Todd <pete@petertodd.org>"
  185. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  186.       "John Dillon <john.dillon892@googlemail.com>"
  187. Just a request, could you sign my PGP key?
  188.  
  189. As you have probably guessed my intent is to stay anonymous. This is my real
  190. name, but not my usual email, so the usual PGP web of trust procedures don't
  191. really apply.
  192.  
  193. Basically, when you get down to it the question is if this PGP key corresponds
  194. to my identity, and that identity is Bitcoin John Dillon right now.
  195.  
  196. Thanks,
  197.  
  198. John Dillon (whomever that may be)
  199. gpg: Signature made Mon 29 Apr 2013 03:03:15 AM GMT using RSA key ID 2636188F
  200. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  201.  
  202. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  203.       "Peter Todd <pete@petertodd.org>"
  204. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  205.       "John Dillon <john.dillon892@googlemail.com>"
  206. On Mon, Apr 29, 2013 at 03:04:30AM +0000, John Dillon wrote:
  207. > Just a request, could you sign my PGP key?
  208. >
  209. > As you have probably guessed my intent is to stay anonymous. This is my real
  210. > name, but not my usual email, so the usual PGP web of trust procedures don't
  211. > really apply.
  212. >
  213. > Basically, when you get down to it the question is if this PGP key corresponds
  214. > to my identity, and that identity is Bitcoin John Dillon right now.
  215.  
  216. Hmm... Yeah, I think you have a good point; I'll sign it. I mentioned
  217. the exact same issue with Satoshi's PGP key actually in a pull-req with
  218. regard to the foundation bylaws. (they referenced his key by the
  219. insecure 32-bit keyid)
  220.  
  221. Nice job with the PGP keys... maybe it's all the better that we have
  222. people like you making that kind of "dirty work" happen and
  223. demonstrating attacks in a relatively controlled way. Personally I'm of
  224. the opinion that *if* the 1MB blocksize is kept the way it is, allowing
  225. data in the chain isn't a disaster. ~57GB a year is a lot sure, but it's
  226. a managable problem.
  227.  
  228. --
  229. 'peter'[:-1]@petertodd.org
  230. gpg: Signature made Mon 29 Apr 2013 03:14:13 AM GMT using RSA key ID A5F091FB
  231. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  232. gpg:                 aka "[jpeg image of size 5220]"
  233.  
  234. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  235.       "Peter Todd <pete@petertodd.org>"
  236. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  237.       "John Dillon <john.dillon892@googlemail.com>"
  238. I hope that helped you guys, but sadly I think you are up against people who
  239. simply have an axe to grind. Still let me know if I can help in the future.
  240.  
  241. Looks like I am going to have some substantial commitments around the time of
  242. the conference. Not sure exactly when but I'll likely be out of email contact
  243. for two or three weeks. You might want to do the same sometimes too you know,
  244. at least when it comes to forums and github. Focus is good sometimes.
  245.  
  246. Just a suggestion...
  247.  
  248. > Can you write something reasonable here?
  249. gpg: Signature made Wed 01 May 2013 02:56:43 AM GMT using RSA key ID 2636188F
  250. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  251.  
  252. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  253.       "Peter Todd <pete@petertodd.org>"
  254. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  255.       "John Dillon <john.dillon892@googlemail.com>"
  256. FWIW I have Jabber chat on pete@petertodd.org
  257.  
  258. Use off-the-record encryption, passphrase verification word 195618d5
  259.  
  260. --
  261. 'peter'[:-1]@petertodd.org
  262. 0000000000000195618d5c4434d24ac955acbc265c4f3b15ecc2c47c572a1b7e
  263. gpg: Signature made Thu 02 May 2013 03:35:58 AM GMT using RSA key ID A5F091FB
  264. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  265. gpg:                 aka "[jpeg image of size 5220]"
  266.  
  267. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  268.       "Peter Todd <pete@petertodd.org>"
  269. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  270.       "John Dillon <john.dillon892@googlemail.com>"
  271. Here's my new section. What do you think?
  272.  
  273. Section 2.2     Transact on Their Own Terms: The Corporation recognizes the decentralized, consensus-based nature of the Bitcoin technology. The Corporation will seek to protect and promote decentralization through legal and technical means, including, but not limited to, the fungibility of individual Bitcoins, the ability of individuals to participate fully in Bitcoin by running full validating nodes, the ability of individuals to operate a full validating node anonymously, and the ability to chose what level of privacy their transactions will have, including anonymously.
  274. gpg: Signature made Fri 03 May 2013 02:59:57 AM GMT using RSA key ID 2636188F
  275. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  276.  
  277. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  278.       "Peter Todd <pete@petertodd.org>"
  279. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  280.       "John Dillon <john.dillon892@googlemail.com>"
  281. This is going to be the text of my pull-req. What do you think?
  282.  
  283.  
  284. Satoshi didn't create Bitcoin because he wanted another way to pay people over the internet. If that was all he wanted to do, he could have done it via conventional, legal means. Setup some company, hire some lawyers, navigate regulation.
  285.  
  286. What is special about Bitcoin is that it is a technology, not an organization. As Satoshi said:
  287.  
  288. > Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.
  289.  
  290. Bitcoin is an idea, expressed in code, and a group of people who chose to accept and value that idea. The Bitcoin idea places as little trust in others as possible, and for what remains, the valid transactions placed into the blockchain, the decision is made by a democratic vote among everyone who possesses hashing power. It is decentralization that makes the Bitcoin idea valuable, and what makes it so fundamentally revolutionary compared to what came before it.
  291.  
  292. Without decentralization Bitcoin is just another way to pay people over the internet. A Bitcoin where only a select few can participate in that democratic vote is simply not the Bitcoin Satoshi created, and is no different from the centralized systems that came before it.
  293.  
  294. Anonymity is a key part of true decentralized decision making. Without anonymity you can-not make decisions freely, decisions like what transactions you accept as valid Bitcoins, and what transactions you place into the blocks you mine. It is notable that Satoshi himself wisely decided to use a pseudonym rather than his real identity, allowing him to make choices about Bitcoin free of interference from authorities.
  295.  
  296. While the blockchain technology will always be public to some degree, we must not promote further encroachment on the ability of individuals to transact and mine with the privacy that they desire, be it fully anonymous, or no privacy at all. User-defined privacy must continue to remain a part of Bitcoin and the Foundation should promote and develop technologies that expand upon the options available, and make the whole spectrum of privacy options easier to access by all users.
  297.  
  298. Finally, pragmatically speaking, the Foundation has been repeatedly attacked by those who see it as contrary to that decentralized nature of Bitcoin. To some extent those people are right: like it or not the Foundation has a significant amount of control over the direction of Bitcoin by employing Gavin and funding development. There are very real social reasons why that control exists. By making a clear statement of purpose that includes decentralization, the foundation can help meet those concerns.
  299.  
  300. Of course the Foundation is not Bitcoin. If the Foundation does not support these goals and values, the only honest thing to do is make it clear what goals and values the Foundation does have, so people can make an informed decision about whether they want to support it, or some other group.
  301. gpg: Signature made Fri 03 May 2013 04:00:32 AM GMT using RSA key ID 2636188F
  302. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  303.  
  304. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  305.       "Peter Todd <pete@petertodd.org>"
  306. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  307.       "John Dillon <john.dillon892@googlemail.com>"
  308. Posted to the forums.
  309.  
  310. I don't have a reddit account, but I'll make one and do the post early tomorrow
  311. morning.
  312. gpg: Signature made Fri 03 May 2013 04:18:19 AM GMT using RSA key ID 2636188F
  313. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  314.  
  315. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  316.       "Peter Todd <pete@petertodd.org>"
  317. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  318.       "John Dillon <john.dillon892@googlemail.com>"
  319. Posted: http://www.reddit.com/r/Bitcoin/comments/1dlw10/the_bitcoin_foundation_doesnt_have_keeping/
  320. gpg: Signature made Fri 03 May 2013 07:27:52 AM GMT using RSA key ID 2636188F
  321. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  322.  
  323. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  324.       "Peter Todd <pete@petertodd.org>"
  325. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  326.       "John Dillon <john.dillon892@googlemail.com>"
  327. On Thu, May 09, 2013 at 12:44:47AM +0000, John Dillon wrote:
  328. > > Posted: http://www.reddit.com/r/Bitcoin/comments/1dlw10/the_bitcoin_foundation_doesnt_have_keeping/
  329.  
  330. > I think you sent me the wrong attachment
  331.  
  332. I appear to have deleted it.
  333.  
  334. Anyway I was replying to your replacement message and said that yes I think you
  335. have a good idea with releasing, so go ahead and do that. Setup say 5 servers
  336. on EC2 for testnet for the testing.
  337.  
  338. We will say you have the money at this point to discourage others who may be
  339. less ethical about their release schedule. Let me know when the servers are
  340. ready and I will make a bigger post.
  341.  
  342. > --
  343. > 'peter'[:-1]@petertodd.org
  344. > 0000000000000000c2154168bfc477ce1efee8eb40ed63534ab5933ac419b072
  345.  
  346. What is this?
  347. gpg: Signature made Thu 09 May 2013 01:06:06 AM GMT using RSA key ID 2636188F
  348. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  349.  
  350. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  351.       "Peter Todd <pete@petertodd.org>"
  352. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  353.       "John Dillon <john.dillon892@googlemail.com>"
  354. On Wed, May 08, 2013 at 09:26:15PM -0400, Peter Todd wrote:
  355.  
  356. We're good to go. The branch is:
  357. https://github.com/petertodd/bitcoin/tree/replace-by-fee
  358.  
  359. People can -addnode=testnet-replace-by-fee.bitcoin.petertodd.org to use
  360. it. Point out the usual stuff about why doesn't do recursion, or have
  361. any additional features.
  362.  
  363. I setup about 25 micro servers, that's like $60-$100 a month or
  364. something? I'll see how it goes - fun to play around re: relaying.
  365.  
  366. --
  367. 'peter'[:-1]@petertodd.org
  368. 000000000000012cce84b6cc078aedd7ee93a8ceb65e29e6ed3225505dae87fb
  369. gpg: Signature made Thu 09 May 2013 09:34:38 AM GMT using RSA key ID A5F091FB
  370. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  371. gpg:                 aka "[jpeg image of size 5220]"
  372.  
  373. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  374.       "Peter Todd <pete@petertodd.org>"
  375. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  376.       "John Dillon <john.dillon892@googlemail.com>"
  377. Gavin really pissed me off here: https://bitcointalk.org/index.php?topic=196138.msg2113288#msg2113288
  378.  
  379. I'm thinking of posting to the -development email list asking the developers
  380. point blank about why they don't challenge him on that stuff. I'll mention the
  381. distributed hash tables thing he was saying earlier for solving mining
  382. scalability too.
  383.  
  384. He knows you aren't that stupid.
  385.  
  386.  
  387. Anyway, I'll try to be at the conference. If I can get in a situation where we
  388. can chat securely I'll use the code-word "powpos dht proof" in conjunction with
  389. "john dillon" to let you know you are actually talking to me. No guarantees
  390. I'll make it out though.
  391. gpg: Signature made Sat 11 May 2013 07:27:30 PM GMT using RSA key ID 2636188F
  392. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  393.  
  394. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  395.       "Peter Todd <pete@petertodd.org>"
  396. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  397.       "John Dillon <john.dillon892@googlemail.com>"
  398. Ok, I replied on the forums instead.
  399.  
  400. The SPV attack is a good idea! Lets do it, and lets do it anonymously. Tell me
  401. what your priorities are for after-conf work.
  402.  
  403. I'll think further about the identity thing. I will say I have been very
  404. careful to date. Possibly satoshi-level careful?
  405.  
  406. The bitcoincard people posted BTW. You would like my comment: https://bitcointalk.org/index.php?topic=202558.msg2118675#msg2118675
  407. gpg: Signature made Sun 12 May 2013 06:28:26 AM GMT using RSA key ID 2636188F
  408. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  409.  
  410. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  411.       "Peter Todd <pete@petertodd.org>"
  412. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  413.       "John Dillon <john.dillon892@googlemail.com>"
  414. On Sun, May 12, 2013 at 06:29:20AM +0000, John Dillon wrote:
  415. > 2013/5/12 Peter Todd <pete@petertodd.org>:
  416. > >
  417.  
  418. > Ok, I replied on the forums instead.
  419. >
  420. > The SPV attack is a good idea! Lets do it, and lets do it anonymously. Tell me
  421. > what your priorities are for after-conf work.
  422.  
  423. 1) replace-by-fee: we need to make this usable. So incorporate wallet
  424. fixes so using it doesn't mess your wallet up, then add the "try to
  425. undo" and "change fees" features.
  426.  
  427. 2) P2P network messaging with hashcash anti-DDoS. Make this a general
  428. thing, with specific message types. The hashcash will be used for
  429. priority ordering.
  430.  
  431. 3) Trust-free mix system on top of the P2P thing. Figuring out how to
  432. handle change will be hard... I should do a write-up and post it to
  433. bitcoin-development email list and get the ball rolling there.
  434.  
  435. SPV attack - lets be more clever about it... why actually do it when we
  436. can start a fake company offering the service?
  437.  
  438. > I'll think further about the identity thing. I will say I have been very
  439. > careful to date. Possibly satoshi-level careful?
  440.  
  441. Good. Remember that your choices are limited when you have to think
  442. about the legality of your actions.
  443.  
  444. > The bitcoincard people posted BTW. You would like my comment: https://bitcointalk.org/index.php?topic=202558.msg2118675#msg2118675
  445.  
  446. Nice! Tracking them down at the conf is on my todo list.
  447.  
  448. --
  449. 'peter'[:-1]@petertodd.org
  450. 000000000000005d1d1546621ac84fe648875e58eac79e17e8be3e30bbe37a0c
  451. gpg: Signature made Mon 13 May 2013 03:06:30 AM GMT using RSA key ID A5F091FB
  452. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  453. gpg:                 aka "[jpeg image of size 5220]"
  454.  
  455. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  456.       "Peter Todd <pete@petertodd.org>"
  457. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  458.       "John Dillon <john.dillon892@googlemail.com>"
  459. Interesting message I got from Gavin.
  460.  
  461. Regarding my schedule I'll be back in contact for sure two weeks after the
  462. conference. As I say below you do what you feel is right with replace-by-fee.
  463. I'm looking forward to seeing the video! You will see some more support from me
  464. in the future with it too. My bitcoins aren't accessible right now due to some
  465. travel, but you can say in the forums you have gotten another 1BTC from me
  466. today. I will make good on that promise.
  467.  
  468.  
  469. [quote author=Gavin Andresen link=action=profile;u=224 date=1368456071]
  470. Hey John:
  471.  
  472. Are you running a bitcoin-based business? What's your background?
  473. [/quote]
  474.  
  475. Nope. I and my partners are all involved with Bitcoin as investors. Nothing fancy, just an small group who care deeply about financial freedom and privacy and are investing what we can afford to lose. I think I'm still the only one who has become active with the community.
  476.  
  477. I haven't been a programmer for awhile, the usual management career track got me, but math and computer science theory hasn't exactly changed.
  478.  
  479. [quote author=Gavin Andresen link=action=profile;u=224 date=1368456071]
  480. And will I get a chance to meet/talk with you at the conference this weekend?
  481. [/quote]
  482.  
  483. Unfortunately not. I have a few weeks of other commitments starting very soon. I probably won't even be looking at my email. Peter will be handling replace-by-fee. I fully trust his judgement about how to proceed.
  484. gpg: Signature made Tue 14 May 2013 02:35:14 AM GMT using RSA key ID 2636188F
  485. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  486.  
  487. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  488.       "Peter Todd <pete@petertodd.org>"
  489. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  490.       "John Dillon <john.dillon892@googlemail.com>"
  491. On Tue, May 14, 2013 at 02:36:10AM +0000, John Dillon wrote:
  492. > Interesting message I got from Gavin.
  493.  
  494. Huh, yeah he sent me a similar one, but aimed at "what should I tell
  495. people asking to hire developers?"
  496.  
  497. Obviously he's taking you seriously - a good thing I think. That post by
  498. Mike Hern about putting you on his ignore list is similar really...
  499.  
  500. > Regarding my schedule I'll be back in contact for sure two weeks after the
  501. > conference. As I say below you do what you feel is right with replace-by-fee.
  502. > I'm looking forward to seeing the video! You will see some more support from me
  503. > in the future with it too. My bitcoins aren't accessible right now due to some
  504. > travel, but you can say in the forums you have gotten another 1BTC from me
  505. > today. I will make good on that promise.
  506.  
  507. Thanks! Yeah, no rush about actual funds, I've got cheap rates on my
  508. line-of-credit.
  509.  
  510. re: replace-by-fee I think I'll do a version that "solves" the DoS
  511. problem by simply not replacing transactions that have been re-spent, a
  512. good half measure in any case that again further reduces harm. I'll
  513. implement that right after the conference.
  514.  
  515. The code for it is also easier too, so it's more likely to get accepted
  516. by miners.
  517.  
  518. --
  519. 'peter'[:-1]@petertodd.org
  520. 00000000000000ed82fe4ffbf5677d6fc1ee304186288eb13358cf32418d0c31
  521. gpg: Signature made Tue 14 May 2013 03:08:29 AM GMT using RSA key ID A5F091FB
  522. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  523. gpg:                 aka "[jpeg image of size 5220]"
  524.  
  525. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  526.       "Peter Todd <pete@petertodd.org>"
  527. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  528.       "John Dillon <john.dillon892@googlemail.com>"
  529. > ./bitcoin-qt -salvagewallet
  530. >
  531. > Doesn't work when there isn't a wallet at all.
  532. >
  533. > Good to get your name in the Bitcoin sourecode credits I think - adds
  534. > some credibility.
  535.  
  536. Thanks. I'll look into that.
  537. gpg: Signature made Tue 28 May 2013 04:57:44 AM GMT using RSA key ID 2636188F
  538. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  539.  
  540. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  541.       "Peter Todd <pete@petertodd.org>"
  542. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  543.       "John Dillon <john.dillon892@googlemail.com>"
  544. Content-Type: text/plain; charset=us-ascii
  545. Content-Disposition: inline
  546. Content-Transfer-Encoding: quoted-printable
  547.  
  548. On Tue, May 28, 2013 at 04:58:16AM +0000, John Dillon wrote:
  549. > > ./bitcoin-qt -salvagewallet
  550. > >=20
  551. > > Doesn't work when there isn't a wallet at all.
  552. > >=20
  553. > > Good to get your name in the Bitcoin sourecode credits I think - adds
  554. > > some credibility.
  555. >=20
  556. > Thanks. I'll look into that.
  557.  
  558. Also, on decentralizing mining, I had the idea of adding a UDP method
  559. for very fast distribution of block headers and tiny full blocks. The
  560. idea here is the moment a new block is created, every miner should
  561. immediately start working on a block that would orphan that block with
  562. only the coinbase TX in it.
  563.  
  564. This punishes blocks that take a long time to propegate, particularly
  565. for miners behind low-bandwidth links. It'll be a nice natural incentive
  566. towards smaller blocks, although I do worry a bit about how the idea
  567. could be latched onto as "well obviously we *can* increase the blocksize
  568. now!"
  569.  
  570. --=20
  571. 'peter'[:-1]@petertodd.org
  572. 00000000000001027c8b5ae04fce5ccf3948a15e137dab152e62450fd998c3ae
  573. gpg: Signature made Tue 28 May 2013 05:22:58 AM GMT using RSA key ID A5F091FB
  574. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  575. gpg:                 aka "[jpeg image of size 5220]"
  576.  
  577. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  578.       "Peter Todd <pete@petertodd.org>"
  579. gpg: encrypted with 2048-bit ELG-E key, ID F0F0B355, created 1999-11-27
  580.       "Gregory Maxwell <gmaxwell@gmail.com>"
  581. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  582.       "John Dillon <john.dillon892@googlemail.com>"
  583. > I was talking with Gregory Maxwell about decentralizing mining at the
  584. > conference. He came up with the idea of tightly integrating mining
  585. > functionality into the client using Luke Dashjr's getblocktemplate
  586. > protocol; the existing getwork is not compatible with ASICs. The idea
  587. > would be to make solo-mining as easy as possible, and further more to
  588. > move pools to a structure where the pool's function is to co-ordinate
  589. > share payments, not block construction. Essentially hashers would become
  590. > true miners, doing transaction selection on their own, and then pools
  591. > would credit them for their shares and do the accounting. In this model
  592. > all a pool can do is defraud miners rather than harm to the whole
  593. > network.
  594.  
  595. Smart idea.
  596.  
  597. > It's also nice because by doing so we make the dangers of a large block
  598. > size very clear by making large numbers of miners see immediately how it
  599. > makes it difficult for them to operate. We also make changing the size
  600. > more difficult in general because the decision then becomes one that
  601. > hundreds or even thousands of miners need to make individually, greatly
  602. > slowing down any possible change. Of course, I didn't say any of that...
  603.  
  604. Why not go ahead and say it? You know that Mike and similar will counter-argue
  605. that mining needs to be done by "responsible" central authority figures running
  606. pools, so let them make that bogus argument. I've seen Gavin criticising you
  607. for not working on making mining decentralized too, so go ahead and force him
  608. into a position of arguing against that.
  609.  
  610. People criticise you for your motivations all the time. Don't give them more
  611. ammo. Being totally upfront about why you are pushing decentralized mining is a
  612. good thing. In my opinion what you are doing is obvious anyway.
  613.  
  614.  
  615. Regarding your idea for fast block header propagation, and delibrate orphaning
  616. by miners, I like it and I too worry that it could be seen as an excuse to
  617. increase the blocksize. Maybe keep that one secret for now, but look into the
  618. infrastructure to make it possible? It would make sense to have a UDP-based
  619. block header distribution channel for a lot of things, like you keep saying
  620. with blockheaders over twitter and other fun. The system doesn't need to be
  621. able to propagate whole blocks in UDP packets however technically possible it
  622. is.
  623.  
  624. Regarding rational, also point out that mining ontop of a block that you have
  625. not verified fully is always unacceptable due to attacks. Reducing your block
  626. size to zero transactions just makes sense in terms of rational miner behavior.
  627. Why work on something that you know has a high chance of not propegating fast
  628. enough to win the race?
  629.  
  630. > I think the devs should direct the 10BTC donation you made a few months
  631. > ago to this effort - would you and your partners be willing to commit
  632. > some more funds? I can throw in some BTC myself. Greg, Luke and I have
  633. > talked about possibly doing this an a public assurance contract. Keep in
  634. > mind that you lot have created a fair bit of controversy - donating
  635. > towards something less controversial than replace-by-fee and my video
  636. > could help out.
  637.  
  638. I do not donate funds with strings attached, but if the dev team needs any
  639. guidance of what to do with that 10BTC, I think this is an excellent project to
  640. use it with.
  641.  
  642. We can donate further funds, but show me the concrete proposal first with scope
  643. etc. Your keepbitcoinfree-announce post seemed to say you were going to post to
  644. troll-talk, do so.
  645.  
  646. Speaking of donations, I saw someone with ~180BTC made a 10BTC donation to your
  647. address. Good work! I also finally got a chance to see the video after dealing
  648. with Monday obligations. It is excellent work and very professional. I heard
  649. too through the grapevine about the response you got a the developer round
  650. table at the conference. I would say Peter Vanesse seems way out of touch with
  651. regard to privacy, and good that you got a small crowd after the discussion
  652. talking about decentralization.
  653.  
  654. I'd be interested in slides of your talk if you have them. Do you know when
  655. video is going to be made available by the foundation?
  656.  
  657. > In addition a video advocating to miners to run the software would be
  658. > good too. The idea is non-political enough - at first glance - that the
  659. > Bitcoin Foundation may be willing to help fund it through one of their
  660. > grants. (the next cycle's deadline is june, probably too early, but the
  661. > one after that isn't far away)
  662.  
  663. If you take my suggestion of being up-front about the decentralization reasons
  664. for doing this, it will be interesting to see the response of the Foundation,
  665. or for that matter, integrating those changes in the reference client anyway.
  666. gpg: Signature made Tue 28 May 2013 05:43:38 AM GMT using RSA key ID 2636188F
  667. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  668.  
  669. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  670.       "Peter Todd <pete@petertodd.org>"
  671. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  672.       "John Dillon <john.dillon892@googlemail.com>"
  673. > What are your thoughts on scamcoins?
  674.  
  675. Everything but namecoin and maybe litecoin is a scamcoin and they deserve to
  676. die.
  677.  
  678. > I might have a project for you...
  679.  
  680. ???
  681. gpg: Signature made Sun 07 Jul 2013 11:24:50 PM GMT using RSA key ID 2636188F
  682. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  683.  
  684. gpg: encrypted with 4096-bit RSA key, ID 0753963A, created 2013-07-03
  685.       "w@grabhive.com <w@grabhive.com>"
  686. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  687.       "John Dillon <john.dillon892@googlemail.com>"
  688. Content-Type: multipart/signed;
  689.         boundary="Apple-Mail=_76C11B8F-5F49-418B-93E5-8B41E8442FE7";
  690.         protocol="application/pgp-signature";
  691.         micalg=pgp-sha1
  692.  
  693.  
  694. --Apple-Mail=_76C11B8F-5F49-418B-93E5-8B41E8442FE7
  695. Content-Transfer-Encoding: quoted-printable
  696. Content-Type: text/plain;
  697.         charset=us-ascii
  698.  
  699. [resending in case you didn't get this; have been having Mail trouble -- =
  700. my GPG key is on the keyserver]
  701.  
  702. Hi John,
  703.  
  704. I saw Peter Todd's post recently that he received funding from you for =
  705. work on replace-by-fee, and of course I've also seen your various =
  706. rewards and bounties placed elsewhere. As I am also interested in =
  707. helping to fund some of this work, I thought perhaps we could get to =
  708. know each other and join forces as appropriate?
  709.  
  710. On my side we are working on Hive, which is a user-friendly Bitcoin =
  711. wallet for OS X (and eventually Android). Most of my interests lie in =
  712. speed and reliability rather than cutting-edge features. I saw your =
  713. campaign Keep Bitcoin Free!... If you don't mind my asking, what else =
  714. are you working on?
  715.  
  716. Cheers John,
  717. -wendell
  718.  
  719. grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
  720.  
  721.  
  722. --Apple-Mail=_76C11B8F-5F49-418B-93E5-8B41E8442FE7
  723. Content-Transfer-Encoding: 7bit
  724. Content-Disposition: attachment;
  725.         filename=signature.asc
  726. Content-Type: application/pgp-signature;
  727.         name=signature.asc
  728. Content-Description: Message signed with OpenPGP using GPGMail
  729.  
  730. -----BEGIN PGP SIGNATURE-----
  731. Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
  732.  
  733. iQIcBAEBAgAGBQJR9Y+JAAoJECAN2ykHU5Y6BnkQAKF3fDXXC9ST10W0jPRBASXT
  734. GYUpeCZfEq54hinkGhVbOqrl0bChZ1kxtbgmXAbYjZ8Qp+UirR9eQQHL7Gea5frl
  735. 7I066/29cz8jDeguVXTEPaQIgFaWgQPMlmVctFdYHgX+HA3yH/e5Vufj3z+g3t8c
  736. haP8Kk5wLs/UQ3SKigJe9hIl22ho/+kQuzM9E+RSGYTgOMf0ar+RtAwMIlz3un8H
  737. jmSHBAqZq/1EaOeG/dP4SQ3UIx3V1sLOfSSOJftPSkJa5dmwkWdFIDQ3+NT6sYHv
  738. yWbdfLC1oiomTJQbhMNvKP/rrDgVblk44WJR+6yaO3XuzTuOojVIiwoRzOMVnIwl
  739. rP9SKIMojOj+iZiZImgH6mlD2ldO97B78Jn3R7sMwlVayI+dh4+SimJmzNawyZds
  740. xV6xcvK6jAUmYfM0ooZJoP6T+yovBjv6EA4dubb4Di5PRvlYQYAyS54VgrAoCopE
  741. xIrre8nX7JGHHroLYvO2iSq4ZSAq3imR8yK/biS1iw9/aJBWYanZcXCEa/suU4q1
  742. K77hrcSvTfYEIdXNZzrBGSP+Vm7DIhO1dtZxyZqkUx+UZeMhjWgW1YE5Mm5zwD6h
  743. rUdBEFgOSNikWL+XHrDjnQ/+Hni45HeujZ2TyX9ZAcsCS4UXEA50N9aJk/bQPqwM
  744. Zkongxmjc/Ty4Cwp8OcP
  745. =b8B6
  746. -----END PGP SIGNATURE-----
  747.  
  748. --Apple-Mail=_76C11B8F-5F49-418B-93E5-8B41E8442FE7--
  749.  
  750. gpg: encrypted with 4096-bit RSA key, ID 0753963A, created 2013-07-03
  751.       "w@grabhive.com <w@grabhive.com>"
  752. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  753.       "John Dillon <john.dillon892@googlemail.com>"
  754. If you could, please use the "inline" mode for PGP. I know it is a bit
  755. old-fashioned, but it is easier for me to use given that I use the gmail web
  756. interface directly. Do keep using encryption though!
  757.  
  758. > Hi John,
  759. >
  760. > I saw Peter Todd's post recently that he received funding from you for =
  761. > work on replace-by-fee, and of course I've also seen your various =
  762. > rewards and bounties placed elsewhere. As I am also interested in =
  763. > helping to fund some of this work, I thought perhaps we could get to =
  764. > know each other and join forces as appropriate?
  765.  
  766. Good idea.
  767.  
  768. > On my side we are working on Hive, which is a user-friendly Bitcoin =
  769. > wallet for OS X (and eventually Android). Most of my interests lie in =
  770. > speed and reliability rather than cutting-edge features. I saw your =
  771. > campaign Keep Bitcoin Free!... If you don't mind my asking, what else =
  772. > are you working on?
  773.  
  774. To clarify Keep Bitcoin Free! is Peter's project, not mine. I only contributed
  775. funds and offered to let him use my name publicly as a supporter.
  776.  
  777. To be frank I have a lot of commitments in life between work and family, I
  778. apologise for how I can only really reply on weekends at best, but I have been
  779. following Bitcoin for years and consider it one of the most important
  780. cryptography projects out there. I also am very concerned with the long-term
  781. viability of Bitcoin with regard to preserving its decentralization and
  782. privacy. (you may have seen my pull-request to add decentraliztion to the
  783. foundation bylaws:
  784. https://github.com/pmlaw/The-Bitcoin-Foundation-Legal-Repo/pull/4) Keeping
  785. Bitcoin fast, reliable and accesible for your average user is definitely an
  786. important part of my goals.
  787.  
  788. What are your thoughts on SPV/partial mode? Myself I would much prefer to see
  789. the latter implemented than the former, you may have seen myself and Peter
  790. talking about the DoS attack risks for SPV nodes. Where are you at with regards
  791. to hiring a developer? I'll point out that Pieter Wuille is doing some of the
  792. initial work required, and should be involved in some way. (doesn't have to be
  793. financial) I noticed that Pieter was involving Peter in the discussion on IRC
  794. about his initial steps.
  795.  
  796. Beyond partial mode I am also interested in seeing node-to-node encryption and
  797. authentication, IE SSL for peer communications, an important feature for
  798. preserving privacy against attackers who can wiretap. For instance right now
  799. even if you have a node that you trust, maybe your server at your house, there
  800. isn't a good way to have your wallet on your phone or laptop connect to that
  801. server because the connection is completely unauthenticated and unencrypted.
  802.  
  803. FWIW adding SSL to the protocol is a fairly relatively non-invasive change. It
  804. might be worthwhile to implement that first as a means to test the developers
  805. you wish to hire to later implement partial mode. Thoughts?
  806. gpg: Signature made Mon 05 Aug 2013 04:32:45 AM GMT using RSA key ID 2636188F
  807. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  808.  
  809. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  810.       "Peter Todd <pete@petertodd.org>"
  811. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  812.       "John Dillon <john.dillon892@googlemail.com>"
  813. Private IRC chat:
  814.  
  815. 11:11 <petertodd> Everyone knows John and I "know" each other, if anything I'd like my PGP signature on his key to
  816.                   make the nature of that relationship understood.
  817. 11:11 <petertodd> good point
  818. 11:12 <gmaxwell> (I think half the people think you and John are the same person. :P )
  819. 11:12 <petertodd> ha, I know, I'll admit he kinda creeps me out a bit sometimes... he's admitted he reads all my
  820.                   posts religiously
  821. 11:12 <gmaxwell> I keep thinking that maybe there is some crypto magic thing we can do to reduce the problem, but I
  822.                  never seem to find one.
  823. 11:12 <petertodd> yours too BTW
  824. 11:13 <petertodd> it's like... "For fucks sake, can't you promote someone *elses* ideas for once?"
  825. 11:13 <petertodd> ugh
  826. 11:13 <gmaxwell> some kind of thing like ring signatures of all the signing parties for tokens of trust.
  827. 11:13 <petertodd> But then again, he's got money so...
  828. 11:14 <petertodd> I think part of the problem is just Bitcoin is solidly a hobby for him, and he sounds like he has
  829.                   very little time, so he's picked a "cause" to champion, and has focused on it.
  830.  
  831. Though seriously, branch out a bit! I know time is an issue for you, but
  832. still; I really do mean this in the nicest way.
  833.  
  834. --
  835. 'peter'[:-1]@petertodd.org
  836. 0000000000000082d95acaae7770435e04d7543252d2a62a414614c8882fd9e4
  837. gpg: Signature made Tue 30 Jul 2013 05:22:49 PM GMT using DSA key ID 7F6D868C
  838. gpg: Good signature from "Peter Todd (low security key) <pete@petertodd.org>"
  839.  
  840. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  841.       "Peter Todd <pete@petertodd.org>"
  842. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  843.       "John Dillon <john.dillon892@googlemail.com>"
  844. On Tue, Jul 30, 2013 at 01:22:49PM -0400, Peter Todd wrote:
  845.  
  846. Also gavin too:
  847.  
  848. 05:32 <warren> talked with gavin
  849. 05:32 <warren> he seems entirely uninterested in the connection exhaustion issue
  850. 05:32 <warren> doesn't think it's real
  851. 05:33 <warren> He also claims to not know of any more serious DoS issue enabled by bloom
  852. 05:33 <warren> and he wants to know where I heard of it
  853. 05:33 <warren> I told him I don't have permission to reveal that.
  854. 10:19 <petertodd> lol, awesome
  855. 10:19 <petertodd> bit of a joke there
  856. 14:37 <warren> what part is a joke?
  857. 14:45 <warren> oh
  858. 14:45 <warren> he also thinks jdillon and you are the same person!?
  859. 14:47 <warren> or rather a "sock puppet"
  860. 15:43 <petertodd> lol, I'm not surprised - I was talking about that with gmaxwell earlier too
  861.  
  862. Sheesh.
  863.  
  864. I'm going to write a tool to exploit the connections/bloom io thing BTW, so
  865. don't go and offer any rewards for it please... Lets see what the reaction of
  866. those involved is without any further drama. FWIW gmaxwell was pointing out
  867. recently that by seeming to attack Mike you'll give him more political sway,
  868. not less, by letting him hide behind that rather than address tech issues;
  869. gmaxwell's opinion is that Mike doesn't have any political sway anyway.
  870.  
  871. --
  872. 'peter'[:-1]@petertodd.org
  873. 0000000000000078b07150e0992a84dcd45866d5d998f67181b8faabd04d23da
  874. gpg: Signature made Thu 01 Aug 2013 10:35:56 PM GMT using DSA key ID 7F6D868C
  875. gpg: Good signature from "Peter Todd (low security key) <pete@petertodd.org>"
  876.  
  877. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  878.       "Peter Todd <pete@petertodd.org>"
  879. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  880.       "John Dillon <john.dillon892@googlemail.com>"
  881. > On Tue, Jul 30, 2013 at 01:22:49PM -0400, Peter Todd wrote:
  882. >
  883. > Also gavin too:
  884. >
  885. > 05:32 <warren> talked with gavin
  886. > 05:32 <warren> he seems entirely uninterested in the connection exhaustion issue
  887. > 05:32 <warren> doesn't think it's real
  888. > 05:33 <warren> He also claims to not know of any more serious DoS issue enabled by bloom
  889. > 05:33 <warren> and he wants to know where I heard of it
  890. > 05:33 <warren> I told him I don't have permission to reveal that.
  891. > 10:19 <petertodd> lol, awesome
  892. > 10:19 <petertodd> bit of a joke there
  893. > 14:37 <warren> what part is a joke?
  894. > 14:45 <warren> oh
  895. > 14:45 <warren> he also thinks jdillon and you are the same person!?
  896. > 14:47 <warren> or rather a "sock puppet"
  897. > 15:43 <petertodd> lol, I'm not surprised - I was talking about that with gmaxwell earlier too
  898. >
  899. > Sheesh.
  900.  
  901. Sorry about that, if you think I've been following you too closely and pushing
  902. your ideas too much I can back off. Thanks for letting me know this stuff
  903. quickly though. In all honesty I don't give a damn about what the general
  904. Bitcoin community thinks of me other than to the extent that is helps my goals
  905. when it comes to decentralization and privacy, but that doesn't absolve me from
  906. playing a bit of politics all the same.
  907.  
  908. > I'm going to write a tool to exploit the connections/bloom io thing BTW, so
  909. > don't go and offer any rewards for it please... Lets see what the reaction of
  910. > those involved is without any further drama. FWIW gmaxwell was pointing out
  911. > recently that by seeming to attack Mike you'll give him more political sway,
  912. > not less, by letting him hide behind that rather than address tech issues;
  913. > gmaxwell's opinion is that Mike doesn't have any political sway anyway.
  914.  
  915. Ok, I'll keep bloom io on the down low then. Gregory makes a good point there,
  916. I'll take his advice then.
  917.  
  918. What's with Gavin's pull-req on your CVE? Sounded nasty the way he didn't even
  919. mention why it was changing things. I read Sergio's blog post, sounded like it
  920. wasn't a big deal, and what you said about the limits of what the dev team can
  921. do at the present time sounded reasonable to me.
  922.  
  923. Just so you know this stuff about Tor has me worried... Please don't make this
  924. public, but my day job involves intelligence, and I'm in a relatively high
  925. position. You know, I went into the job years ago with very different thoughts
  926. about it than I do now. The last, well, decade really has changed a lot of
  927. minds in this field, in totally different ways. Myself I am on the side of
  928. Snowden and Assange, but... lets just say when you have a family your
  929. willingness to be a martyr diminishes. The same is true of many of my
  930. colleagues. Hopefully my support for Bitcoin can help undo some of the damage
  931. we've done, but I do have to be careful and it's tough to take all the
  932. precautions I need to to be able to communicate. If it was found out that I was
  933. involved with Bitcoin that way I have been, let's just say there would be
  934. consequences...
  935. gpg: Signature made Mon 05 Aug 2013 04:51:27 AM GMT using RSA key ID 2636188F
  936. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  937.  
  938.  
  939. gpg: encrypted with RSA key, ID 00000000
  940. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  941.       "John Dillon <john.dillon892@googlemail.com>"
  942. On Mon, Aug 05, 2013 at 04:52:10AM +0000, John Dillon wrote:
  943. > Just so you know this stuff about Tor has me worried... Please don't make this
  944. > public, but my day job involves intelligence, and I'm in a relatively high
  945. > position. You know, I went into the job years ago with very different thoughts
  946. > about it than I do now. The last, well, decade really has changed a lot of
  947. > minds in this field, in totally different ways. Myself I am on the side of
  948. > Snowden and Assange, but... lets just say when you have a family your
  949. > willingness to be a martyr diminishes. The same is true of many of my
  950. > colleagues. Hopefully my support for Bitcoin can help undo some of the damage
  951. > we've done, but I do have to be careful and it's tough to take all the
  952. > precautions I need to to be able to communicate. If it was found out that I was
  953. > involved with Bitcoin that way I have been, let's just say there would be
  954. > consequences...
  955.  
  956. In addition to what I said earlier, I mentioned your status to a friend
  957. of mine who is a former spook and well aware of the dangers of the
  958. business to anyone with a sense of ethics.
  959.  
  960. He told me to tell you this, word for word: "An old crow strongly
  961. advises you to consider the risks to yourself and your family, and stop
  962. what you are doing." I trust his judgement, and just as importantly, his
  963. ethics.
  964.  
  965. Be careful. Myself, I suggest you think hard about whether or not what
  966. you are doing has had enough of an impact on your goals to be worth it -
  967. I can't answer that question for you.
  968.  
  969. --
  970. 'peter'[:-1]@petertodd.org
  971. gpg: Signature made Wed 21 Aug 2013 08:50:31 AM GMT using RSA key ID A5F091FB
  972. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  973. gpg:                 aka "[jpeg image of size 5220]"
  974.  
  975. gpg: encrypted with 2048-bit ELG-E key, ID C162FB4C, created 2004-01-12
  976.       "Dan Libby (aka danda) <dan@osc.co.cr>"
  977. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  978.       "John Dillon <john.dillon892@googlemail.com>"
  979. Hi JD.
  980.  
  981. Do you know me?
  982.  
  983. If so, we have some catching up to do.   If not, my mistake.
  984.  
  985. --
  986. Dan Libby
  987.  
  988. Open Source Consulting
  989. San Jose, Costa Rica
  990. http://osc.co.cr
  991. phone: 011 506 2223 7382
  992. Fax: 011 506 2223 7359
  993.  
  994. gpg: Signature made Mon 29 Jul 2013 05:20:33 AM GMT using DSA key ID 94E9CC1A
  995. gpg: Good signature from "Dan Libby (aka danda) <dan@osc.co.cr>"
  996. gpg: WARNING: This key is not certified with a trusted signature!
  997. gpg:          There is no indication that the signature belongs to the owner.
  998. Primary key fingerprint: 5C0E F833 79CB 892F 3FC9  1519 744D D69B 94E9 CC1A
  999.  
  1000. gpg: encrypted with 2048-bit ELG-E key, ID C162FB4C, created 2004-01-12
  1001.       "Dan Libby (aka danda) <dan@osc.co.cr>"
  1002. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1003.       "John Dillon <john.dillon892@googlemail.com>"
  1004. > Hi JD.
  1005. >
  1006. > Do you know me?
  1007. >
  1008. > If so, we have some catching up to do.   If not, my mistake.
  1009.  
  1010. Sorry, remind me again where I would have known you from?
  1011. gpg: Signature made Mon 05 Aug 2013 04:54:35 AM GMT using RSA key ID 2636188F
  1012. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  1013.  
  1014. gpg: anonymous recipient; trying secret key 2636188F ...
  1015. gpg: anonymous recipient; trying secret key 38254DA8 ...
  1016. gpg: okay, we are the anonymous recipient.
  1017. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  1018.       "Peter Todd <pete@petertodd.org>"
  1019. gpg: encrypted with RSA key, ID 00000000
  1020. Peter,
  1021.  
  1022. Could I please borrow just over 5.1BTC from you?
  1023.  
  1024. I'm away from my coins and I could really use some for the CoinJoin bounty.
  1025. Amir's ridiculous attempt to grab the bounty has gotten me rather pissed off,
  1026. and I have a statement to make.
  1027.  
  1028. The BTC is so I can quite clearly write that I am the largest single donator to
  1029. the fund. Perhaps silly, but statements are worth making.
  1030.  
  1031. You know I will pay you back.
  1032.  
  1033. This email isn't signed, because I don't have my PGP key with me. Thus pay the
  1034. funds to the address in my encrypted message to Gregory Maxwell in the coinjoin
  1035. thread. You'll note that I also encrypted it to you. I hope that is sufficient
  1036. to convince you that this is really me.
  1037.  
  1038. Thank you,
  1039.  
  1040. John Dillon
  1041.  
  1042. On Thu, Aug 29, 2013 at 02:08:39AM +0000, John Dillon wrote:
  1043.  
  1044. Dear Nigerian Prince,
  1045.  
  1046. It was great to hear from you! My bank account details are...
  1047.  
  1048.  
  1049. Tell you what, given you do all your transactions in the shadows anyway,
  1050. for the record you can say you've donated the money and I'll settle the
  1051. difference with Gregory Maxwell as required.
  1052.  
  1053. I'm not terribly impressed with Amir either - I suspect he's introduced
  1054. a security hole by how he passes data to the command line without
  1055. escaping. You should mention that in whatever you are going to write...
  1056.  
  1057. --
  1058. 'peter'[:-1]@petertodd.org
  1059. gpg: Signature made Thu 29 Aug 2013 02:24:11 AM GMT using RSA key ID A5F091FB
  1060. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  1061. gpg:                 aka "[jpeg image of size 5220]"
  1062.  
  1063. gpg: encrypted with RSA key, ID 00000000
  1064. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1065.       "John Dillon <john.dillon892@googlemail.com>"
  1066. Warren keeps asking about some email he sent you... and you still owe
  1067. me.
  1068.  
  1069. --
  1070. 'peter'[:-1]@petertodd.org
  1071. gpg: Signature made Sat 21 Sep 2013 10:34:54 PM GMT using RSA key ID A5F091FB
  1072. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  1073. gpg:                 aka "[jpeg image of size 5220]"
  1074.  
  1075. gpg: anonymous recipient; trying secret key 2636188F ...
  1076. gpg: anonymous recipient; trying secret key 38254DA8 ...
  1077. gpg: okay, we are the anonymous recipient.
  1078. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  1079.       "Peter Todd <pete@petertodd.org>"
  1080. gpg: encrypted with RSA key, ID 00000000
  1081. > Warren keeps asking about some email he sent you... and you still owe
  1082. > me.
  1083.  
  1084. Sorry, with the silk road and that NSA document on Tor and other things I
  1085. decided to take a break. The atmosphere has been rather tense and paranoid in
  1086. my industry lately.
  1087.  
  1088. I'll send Gregory Maxwell the funds ASAP and reply to Warren.
  1089.  
  1090. Best wishes
  1091. gpg: Signature made Sat 26 Oct 2013 04:44:55 AM GMT using RSA key ID 2636188F
  1092. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  1093.  
  1094. gpg: anonymous recipient; trying secret key 2636188F ...
  1095. gpg: anonymous recipient; trying secret key 38254DA8 ...
  1096. gpg: okay, we are the anonymous recipient.
  1097. gpg: encrypted with RSA key, ID 00000000
  1098. gpg: encrypted with 2048-bit ELG-E key, ID F0F0B355, created 1999-11-27
  1099.       "Gregory Maxwell <gmaxwell@gmail.com>"
  1100. gpg: encrypted with RSA key, ID 00000000
  1101. Hi Gregory,
  1102.  
  1103. I apologise for my tardiness, but here is the 5.11BTC I promised for the
  1104. CoinJoin effort.
  1105.  
  1106. It is great news to see blockchain.info implement it! I used it myself. :) Are
  1107. you giving them a token reward? They are a for profit venture, but all the same
  1108. a thank you recognition of some kind seems worthwhile to me.
  1109.  
  1110. I note that Peter Wuille still hasn't PGP signed his address...
  1111.  
  1112. Yours,
  1113.  
  1114. 1BDSZMaUvrbTjWsSgLA4XqYUK4dDzxREEV
  1115. KxG9HMgaaMQKWGnht7U1gZW1iWxxNQunTa78gMkvMYSEDHbvKFuS
  1116. gpg: Signature made Sat 26 Oct 2013 05:20:28 AM GMT using RSA key ID 2636188F
  1117. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  1118.  
  1119. gpg: encrypted with 8192-bit RSA key, ID 668709D4, created 2013-06-29
  1120.       "Warren Togami (2013) <wtogami@gmail.com>"
  1121. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1122.       "John Dillon <john.dillon892@googlemail.com>"
  1123. Hi Warren,
  1124.  
  1125. I see that Peter Todd recently completed his audit report, even writing a small
  1126. patch for Litecoin.
  1127.  
  1128. Could you comment a bit on how that process went? I and someone else may want
  1129. to hire him directly, as opposed to the bounties I've offered before, to
  1130. implement some Bitcoin features and we want to get a sense of how it all went.
  1131. I know the tasks aren't exactly similar, but workmanship, timeliness and
  1132. professionalism apply to both all the same.
  1133.  
  1134. Thank you,
  1135.  
  1136. John Dillon
  1137. gpg: Signature made Mon 05 Aug 2013 04:24:22 AM GMT using RSA key ID 2636188F
  1138. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  1139.  
  1140. gpg: encrypted with 8192-bit RSA key, ID 668709D4, created 2013-06-29
  1141.       "Warren Togami (2013) <wtogami@gmail.com>"
  1142. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1143.       "John Dillon <john.dillon892@googlemail.com>"
  1144. Hi John,
  1145.  
  1146. Sorry about the extremely late reply.
  1147.  
  1148. To be entirely honest, Peter Todd does excellent work, but perhaps not in a
  1149. timely manner.  He seems to be easily distracted from tasks and fell behind
  1150. stated deadlines a few times.  It all worked out fine in the end.
  1151.  
  1152. I saw and appreciate your bounties on the list.  We have been similarly
  1153. trying to encourage Gavin to take security more seriously with little
  1154. success.  He commented this in #bitcoin-dev today:
  1155.  
  1156. <gavinandresen> [17:09:29] (I've started to suspect jdillon is a very
  1157. sophisticated troll with the ulterior motive of destroying bitcoin)
  1158.  
  1159. Our team is considering funding future work to add more DoS protection
  1160. to the default Bitcoin implementation, as Litecoin has exactly the same
  1161. security issues.  
  1162.  
  1163. https://github.com/litecoin-project/litecoin/commits/master-0.8
  1164. Note that Litecoin HEAD goes further than  Bitcoin in guarding against
  1165. problem of bloom and related risks. We are unable to explain the true
  1166. nature of these patches in public because they guard against absolutely
  1167. terrible DoS exploits that can take down ANY Bitcoin node.  So instead
  1168. we called it, "Minor efficiency improvement in block peer request handling."
  1169. which is somewhat true of the patch.
  1170.  
  1171. http://blog.litecoin.org
  1172. Please watch our blog in the next week.  We are starting a 501(c)(6)
  1173. which is an industry trade/professional org with the mission to advance
  1174. decentralized consensus technologies.  The chief project is Litecoin,
  1175. and we submit suggested changes to Bitcoin.  Some were already accepted
  1176. others were rejected due to our philosophical or design differences.
  1177. For example, NODE_BLOOM and the poorly explained petertodd patches
  1178. in 0.8.4.1 were proposed and rejected by Gavin.
  1179.  
  1180. Other projects that we have already supported include p2pool as it is
  1181. the ONLY pooling method that does not create systemic risk through
  1182. centralization.  We also want to support timestamping and other clever
  1183. non-financial uses of the blockchain as long as they do NOT cause
  1184. blockchain bloat.  Furthermore, we already have an amazingly experienced
  1185. corporate attorney to serve as General Counsel, and he wants to publish
  1186. policy whitepapers on various topics including:
  1187.  
  1188. * What is business friendly, appropriate regulation?
  1189. * Establish the difference between responsible and irresponsible coins.
  1190.  
  1191. I am curious, are you interested in supporting any of these goals with
  1192. either development or financial support?
  1193.  
  1194. Warren Togami
  1195. wtogami@gmail.com
  1196. 808-479-6297
  1197. gpg: Signature made Fri 30 Aug 2013 04:23:41 AM GMT using RSA key ID 347DC10D
  1198. gpg: Good signature from "Warren Togami (2013) <wtogami@gmail.com>"
  1199.  
  1200. gpg: anonymous recipient; trying secret key 2636188F ...
  1201. gpg: anonymous recipient; trying secret key 38254DA8 ...
  1202. gpg: okay, we are the anonymous recipient.
  1203. gpg: encrypted with 8192-bit RSA key, ID 668709D4, created 2013-06-29
  1204.       "Warren Togami (2013) <wtogami@gmail.com>"
  1205. gpg: encrypted with RSA key, ID 00000000
  1206. > Hi John,
  1207. >
  1208. > Sorry about the extremely late reply.
  1209.  
  1210. Same here.
  1211.  
  1212. Had to take a break for a bit for a variety of reasons.
  1213.  
  1214. > To be entirely honest, Peter Todd does excellent work, but perhaps not in a
  1215. > timely manner.  He seems to be easily distracted from tasks and fell behind
  1216. > stated deadlines a few times.  It all worked out fine in the end.
  1217.  
  1218. That's my experience as well with my replace-by-fee bounty. Unfortunate flaw of
  1219. him, but not one I haven't seen before in smart people. The worst though it how
  1220. he doesn't at least publish. I saw some chatter about "TXO commitments" in the
  1221. bitcointalk and other places, but only see Gregory writing up a description!
  1222. Without publishing others aren't even going to do the work that you're too
  1223. flakey to actually do! Waste of a good mind in my opinion.
  1224.  
  1225. > I saw and appreciate your bounties on the list.  We have been similarly
  1226. > trying to encourage Gavin to take security more seriously with little
  1227. > success.  He commented this in #bitcoin-dev today:
  1228. >
  1229. > <gavinandresen> [17:09:29] (I've started to suspect jdillon is a very
  1230. > sophisticated troll with the ulterior motive of destroying bitcoin)
  1231.  
  1232. I suspect the same of Gavin sometimes. Oh well.
  1233.  
  1234. The Peter/Gavin exchange with this fee estimation business is even more
  1235. bizzare. Peter had a perfectly good point in the pull-req that the estimation
  1236. was imperfect, so the first version should be done with caution in a do no harm
  1237. fashion. Gavin's response to me seems to be one of putting down Peter's ideas
  1238. at all costs, even with what are lies. Or perhaps Gavin is just getting overly
  1239. emotional about this.
  1240.  
  1241. Fundementally though if Peter doesn't do the work, Gavin will succeed...
  1242.  
  1243. > Our team is considering funding future work to add more DoS protection
  1244. > to the default Bitcoin implementation, as Litecoin has exactly the same
  1245. > security issues.  
  1246.  
  1247. Good to hear!
  1248.  
  1249. > Other projects that we have already supported include p2pool as it is
  1250. > the ONLY pooling method that does not create systemic risk through
  1251. > centralization.  We also want to support timestamping and other clever
  1252. > non-financial uses of the blockchain as long as they do NOT cause
  1253. > blockchain bloat.  Furthermore, we already have an amazingly experienced
  1254. > corporate attorney to serve as General Counsel, and he wants to publish
  1255. > policy whitepapers on various topics including:
  1256. >
  1257. > * What is business friendly, appropriate regulation?
  1258. > * Establish the difference between responsible and irresponsible coins.
  1259. >
  1260. > I am curious, are you interested in supporting any of these goals with
  1261. > either development or financial support?
  1262.  
  1263. Before I respond, got an update on this effort? I googled around and haven't
  1264. seen anything.
  1265. gpg: Signature made Mon 28 Oct 2013 05:21:40 AM GMT using RSA key ID 2636188F
  1266. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  1267.  
  1268. gpg: anonymous recipient; trying secret key 2636188F ...
  1269. gpg: anonymous recipient; trying secret key 38254DA8 ...
  1270. gpg: okay, we are the anonymous recipient.
  1271. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  1272.       "Peter Todd <pete@petertodd.org>"
  1273. gpg: encrypted with RSA key, ID 00000000
  1274. I see that you forgot to encrypt. Bad user-interface there. Your email client
  1275. should have easy options to let emails be forced to be encrypted in cases.
  1276.  
  1277. On Tue, Nov 12, 2013 at 6:44 PM, Peter Todd <pete@petertodd.org> wrote:
  1278. > Dunno if you're actually a member, but this thread hidden away on the
  1279. > bitcoin foundation website worries me a lot:
  1280.  
  1281. I feel the same way.
  1282.  
  1283. > Anyway, blacklists is going to fuck up CoinJoin and other stuff we
  1284. > *need* for privacy. I'm sick of going up against Mike; maybe you aren't?
  1285. > I figure, post this to reddit, make it clear that we have foundation
  1286. > discussion pushing coin taint behind everyone's backs, and how it'll
  1287. > fuck up privacy in the future. The response should be loud and clear
  1288. > that coin taint is unacceptable, and fungibility must be preserved.
  1289. >
  1290. > If you need it, I can get you a copy of the whole page.
  1291.  
  1292. Those are all excellent points. Please send the whole thing.
  1293.  
  1294. The timing of this story is odd: http://www.forbes.com/sites/kashmirhill/2013/11/13/sanitizing-bitcoin-coin-validation/
  1295.  
  1296. I'll write up a post for reddit for tomorrow morning, EST. Are you around later
  1297. today to proof it for me?
  1298. gpg: Signature made Wed 13 Nov 2013 07:38:47 PM GMT using RSA key ID 2636188F
  1299. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  1300.  
  1301. gpg: encrypted with RSA key, ID 00000000
  1302. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1303.       "John Dillon <john.dillon892@googlemail.com>"
  1304. Posted to the foundation forum,
  1305. https://bitcoinfoundation.org/forum/index.php?/topic/483-bitcoin-dark-wallet/page__st__20#entry5410
  1306.  
  1307. Dunno if you have a membership or not.
  1308.  
  1309.  
  1310. [quote name='Saivann Carignan' timestamp='1383429407' post='5408']
  1311.  
  1312. Patrick Murck said it in simple terms: The use of Bitcoin will (and is) regulated, not the Bitcoin protocol itself..
  1313. [/quote]
  1314.  
  1315. He's right, but the way he's right is not at all the way you probably think he's right: Bitcoin mining can and almost certainly will be regulated, and by regulating mining you regulate all use of the Bitcoin protocol.
  1316.  
  1317. The first problem is ASICs, specifically the huge gulf in performance per unit cost between commodity hardware, or even hardware possible to create on a small scale with FPGAs, and ASICs. The nature of IC manufacturing is such that a very small number of companies, about two to three, can afford the immense capital costs required to operate top-of-the-line chip fabrication facilities. Put another way, the entire world's economy is unable to support a diverse IC manufacturing industry at the current level of technological sophistication.
  1318.  
  1319. Control those chip fabs and you control mining. It would be extremely easy for the US government to tell Intel and TSMC that from now on any wafers they process capable of doing Bitcoin mining must include additional circuits that let the US government control how, and by whom, they are used. This is a problem in general with computing, but controlling the manufacture of a special-purpose ASIC is far easier and simpler, both technologically and politically, than controlling the availability of general purpose computing hardware. Fortunately it is possible to create proof-of-work algorithms where custom ASICs have less of an advantage over general purpose hardware, but Bitcoin itself isn't going to change the algorithm.
  1320.  
  1321. The second problem is bandwidth: the Bitcoin protocol has atrocious scalability in that to mine blocks you must keep up with the bandwidth used by all transactions. The current 1MB blocksize is small enough to make this not a major problem yet, but if you increase that (with a hardfork!) at some point you will have increased it to the level where you can no longer mine anonymously and then regulating miners directly becomes possible. Unfortunately while technological improvements have made non-anonymous bandwidth more plentiful, for anonymous bandwidth - or even just censorship resistant bandwidth - the options are much more limited. Jurisdiction hopping is an option, but even for the likes of The Pirate Bay it's proved to be a huge pain in the ass, and they only had the relatively small media industry as their enemy rather than the much larger banking industry. (and government in general) It does appear that you could make a crypto-currency with better core scalability - as opposed to the well understood and already-used ways to fairly securely transfer funds off-chain - but no-one's quite yet figured out yet how to upgrade Bitcoin itself with those improvements.
  1322.  
  1323. What's interesting is with good cryptography we've figured out ways to at least detect if miners are violating every other aspect of the Bitcoin protocol: some relatively small and backwards compatible changes to the protocol allow auditing everything miners do with peicewise audits done on low-bandwidth connections. If your wallet randomly audits 0.1% of every block, and there are a few thousand like you, the chance of fraud not being detected quickly approaches zero.
  1324.  
  1325. But auditing can only detect if miners fail to follow the rules of the Bitcoin protocol; it can't force miners to decide to include your blacklisted transactions in a block. If a majority of hashing power is under government control, there's no way we can prevent them from blacklisting whatever they want. Secondly, if the government does decide to change the rules of the Bitcoin protocol by fiat, then what? Suppose the Federal Reserve or equivalent decides that the deflation of Bitcoin is bad for the economy, and the coin distribution schedule needs to be changed. Or perhaps the courts decide that some stolen Bitcoins, that were subsequently lost, are to be returned to their former owners in an invalid transaction. They can order the majority of hashing power to follow new rules, and while you're wallet software may detect that fraud and shutdown, what alternative do you have but to "upgrade" it to accept the new rules? If you're transactions aren't protected by the majority of hashing power, you're transaction aren't secure.
  1326.  
  1327. Where Dark Wallet goes wrong
  1328.  
  1329. This is what bothers me about their efforts: I see no reason to think they understand any of the above. They're approach of making a ground-up re-implementation of Bitcoin is fundementally flawed, both from an engineering point of view, as well as a political point of view. What they should be doing is latching on to the notion that the core Bitcoin protocol is a fixed suicide pact that must only be changed with the true consent of all users. As step #1 they should have taken the Satoshi source code, stripped out everything that isn't directly related to that core consensus protocol, and turned it into an easy to use library. Only then should they have built a wallet/node implementation around that core, unchanging, protocol.
  1330.  
  1331. Where Amir Taaki and the rest of the Dark Wallet team go so very wrong is they don't understand that the Bitcoin specification is the consensus-critical part of the Satoshi source code. Instead they are pursuing a ground-up re-implementation, and like it or not, they're just not smart enough to get all the details right - nobody is. Because they haven't gotten the details right, no significant amount of hashing power is going to ever use their node implementation to mine with - what pool wants to lose thousands of dollars of profit just because yet another libbitcoin consensus bug was found? Of course, with no-one using their code to mine, they have no political power - Gavin and the Bitcoin Foundation's ability to control the core Bitcoin protocol is entirely based on the fact that almost all the hashing power uses the source code at https://github.com/bitcoin/bitcoin
  1332.  
  1333. On the other hand, if even just a quarter of the hashing power used the Dark Wallet node implementation, and could trust it because the !@#$ thing actually implemented the Satoshi protocol properly by using that protocol's source code, changing that protocol in fundemental ways would be far harder - Dark Wallet would have a lot more genuine political weight. With hashing power using that implementation, they would be able to implement their own rules for relaying transactions. For instance while much of the community complained violently about the 0.8.2 dust rule, which made it far harder to get "dust" outputs mined, if the Dark Wallet team decided they didn't like that rule and had hashing power that trusted their node implementation, they could make the rule irrelevant. They could even come up with a anything-goes mechanism with no rules at all governing what transactions got relayed, and let individual miners make those decisions.
  1334.  
  1335. If I were the US Government and had co-opted the "core" Bitcoin dev team, you know what I'd do? I'd encourage ground-up alternate implementations knowing damn well that the kind of people dumb enough to work on them expecting to create a viable competitor anytime soon aren't going to succeed. Every time anyone tried mining with one, I'd use my knowledge of all the ways they are incompatible to fork them, making it clear they can't be trusted for mining. Then I'd go a step further and "for the good of Bitcoin" create a process by which regular soft-forks and hard-forks happened so that Bitcoin can be "improved" in various ways, maybe every six months. Of course, I'd involve those alternate implementations in some IETF-like standards process for show, but all I would have to do to keep them marginalized and the majority of hashing power using the approved official implementation is slip the odd consensus bug into their code; remember how it was recently leaked that the NSA spends $250 million a year on efforts to insert flaws into encryption standards and commercial products. With changes every six months the alts will never keep up. Having accomplished political control, the next step is pushing the development of the Bitcoin core protocol in ways that further my goals, such as scalability solutions that at best allow for auditing, rather waiting until protocols are developed, tested, and accepted by the community that support fully decentralized mining.
  1336.  
  1337. Dark Wallet has the opportunity to make the very idea of the "core" Bitcoin dev team irrelevant. But sadly Amir's lot seem to understand the art of PR a lot better than the political science of decentralized consensus systems.
  1338.  
  1339. --
  1340. 'peter'[:-1]@petertodd.org
  1341. 000000000000000a00cb71e41c03f547da5a382ab122ec7d2dcb4b6ff7e3e532
  1342. gpg: Signature made Sun 03 Nov 2013 01:34:34 AM GMT using RSA key ID A5F091FB
  1343. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  1344. gpg:                 aka "[jpeg image of size 5220]"
  1345.  
  1346. gpg: encrypted with RSA key, ID 00000000
  1347. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1348.       "John Dillon <john.dillon892@googlemail.com>"
  1349. Content-Type: text/plain; charset=us-ascii
  1350. Content-Disposition: inline
  1351. Content-Transfer-Encoding: quoted-printable
  1352.  
  1353. On Sat, Nov 02, 2013 at 09:34:35PM -0400, Peter Todd wrote:
  1354. > Posted to the foundation forum,
  1355. > https://bitcoinfoundation.org/forum/index.php?/topic/483-bitcoin-dark-wal=
  1356. let/page__st__20#entry5410
  1357. >=20
  1358. > Dunno if you have a membership or not.
  1359.  
  1360. Sorry, forgot formatting. Heck, post this elsewhere if you want.
  1361.  
  1362.  
  1363. [quote name=3D'Saivann Carignan' timestamp=3D'1383429407' post=3D'5408']
  1364. Patrick Murck said it in simple terms: The use of Bitcoin will (and is) reg=
  1365. ulated, not the Bitcoin protocol itself..
  1366. [/quote]
  1367.  
  1368. He's right, but the way he's right is not at all the way you probably think=
  1369.  he's right: Bitcoin mining can and almost certainly will be regulated, and=
  1370.  by regulating mining you regulate [i]all[/i] use of the Bitcoin protocol.
  1371.  
  1372. The first problem is ASICs, specifically the huge gulf in performance per u=
  1373. nit cost between commodity hardware, or even hardware possible to create on=
  1374.  a small scale with FPGAs, and ASICs. The nature of IC manufacturing is suc=
  1375. h that a very small number of companies, about two to three, can afford the=
  1376.  immense capital costs required to operate top-of-the-line chip fabrication=
  1377.  facilities. Put another way, [i]the entire world's economy[/i] is unable t=
  1378. o support a diverse IC manufacturing industry at the current level of techn=
  1379. ological sophistication.
  1380.  
  1381. Control those chip fabs and you control mining. It would be extremely easy =
  1382. for the US government to tell Intel and TSMC that from now on any wafers th=
  1383. ey process capable of doing Bitcoin mining must include additional circuits=
  1384.  that let the US government control how, and by whom, they are used. This i=
  1385. s a [url=3D"http://boingboing.net/2012/01/10/lockdown.html"]problem in gene=
  1386. ral with computing[/url], but controlling the manufacture of a special-purp=
  1387. ose ASIC is far easier and simpler, both technologically and politically, t=
  1388. han controlling the availability of general purpose computing hardware. For=
  1389. tunately it is possible to create proof-of-work algorithms where custom ASI=
  1390. Cs have less of an advantage over general purpose hardware, but Bitcoin its=
  1391. elf isn't going to change the algorithm.
  1392.  
  1393. The second problem is bandwidth: the Bitcoin protocol has atrocious scalabi=
  1394. lity in that to mine blocks you must keep up with the bandwidth used by all=
  1395.  transactions. The current 1MB blocksize is small enough to make this not a=
  1396.  major problem yet, but if you increase that (with a hardfork!) at some poi=
  1397. nt you will have increased it to the level where you can no longer mine ano=
  1398. nymously and then regulating miners directly becomes possible. Unfortunatel=
  1399. y while technological improvements have made non-anonymous bandwidth more p=
  1400. lentiful, for anonymous bandwidth - or even just censorship resistant bandw=
  1401. idth - the options are much more limited. Jurisdiction hopping is an option=
  1402. , but even for the likes of The Pirate Bay it's proved to be a huge pain in=
  1403.  the ass, and they only had the relatively small media industry as their en=
  1404. emy rather than the much larger banking industry. (and government in genera=
  1405. l) It does appear that you could make [i]a[/i] crypto-currency with better =
  1406. core scalability - as opposed to the well understood and already-used ways =
  1407. to fairly securely transfer funds off-chain - but no-one's quite yet figure=
  1408. d out yet how to upgrade Bitcoin itself with those improvements.
  1409.  
  1410. What's interesting is with good cryptography we've figured out ways to at l=
  1411. east detect if miners are violating every other aspect of the Bitcoin proto=
  1412. col: some relatively small and backwards compatible changes to the protocol=
  1413.  allow auditing everything miners do with peicewise audits done on low-band=
  1414. width connections. If your wallet randomly audits 0.1% of every block, and =
  1415. there are a few thousand like you, the chance of fraud not being detected q=
  1416. uickly approaches zero.
  1417.  
  1418. But auditing can only detect if miners fail to follow the rules of the Bitc=
  1419. oin protocol; it can't force miners to decide to include your blacklisted t=
  1420. ransactions in a block. If a majority of hashing power is under government =
  1421. control, there's no way we can prevent them from blacklisting whatever they=
  1422.  want. Secondly, if the government does decide to change the rules of the B=
  1423. itcoin protocol by fiat, then what? Suppose the Federal Reserve or equivale=
  1424. nt decides that the deflation of Bitcoin is bad for the economy, and the co=
  1425. in distribution schedule needs to be changed. Or perhaps the courts decide =
  1426. that some stolen Bitcoins, that were subsequently lost, are to be returned =
  1427. to their former owners in an invalid transaction. They can order the majori=
  1428. ty of hashing power to follow new rules, and while you're wallet software m=
  1429. ay detect that fraud and shutdown, what alternative do you have but to "upg=
  1430. rade" it to accept the new rules? If you're transactions aren't protected b=
  1431. y the majority of hashing power, you're transaction aren't secure.
  1432.  
  1433. [u][b]Where Dark Wallet goes wrong[/b][/u]
  1434.  
  1435. This is what bothers me about their efforts: I see no reason to think they =
  1436. understand any of the above. They're approach of making a ground-up re-impl=
  1437. ementation of Bitcoin is fundementally flawed, both from an engineering poi=
  1438. nt of view, as well as a political point of view. What they should be doing=
  1439.  is latching on to the notion that the core Bitcoin protocol is a fixed sui=
  1440. cide pact that must only be changed with the true consent of all users. As =
  1441. step #1 they should have taken the Satoshi source code, stripped out everyt=
  1442. hing that isn't directly related to that core consensus protocol, and turne=
  1443. d it into an easy to use library. Only then should they have built a wallet=
  1444. /node implementation around that core, unchanging, protocol.
  1445.  
  1446. Where Amir Taaki and the rest of the Dark Wallet team go so very wrong is t=
  1447. hey don't understand that the Bitcoin specification [i]is[/i] the consensus=
  1448. -critical part of the Satoshi source code. Instead they are pursuing a grou=
  1449. nd-up re-implementation, and like it or not, they're just not smart enough =
  1450. to get all the details right - nobody is. Because they haven't gotten the d=
  1451. etails right, no significant amount of hashing power is going to ever use t=
  1452. heir node implementation to mine with - what pool wants to lose thousands o=
  1453. f dollars of profit just because yet another libbitcoin consensus bug was f=
  1454. ound? Of course, with no-one using their code to mine, they have no politic=
  1455. al power - Gavin and the Bitcoin Foundation's ability to control the core B=
  1456. itcoin protocol is entirely based on the fact that almost all the hashing p=
  1457. ower uses the source code at [url=3D"https://github.com/bitcoin/bitcoin"]ht=
  1458. tps://github.com/bitcoin/bitcoin[/url]
  1459.  
  1460. On the other hand, if even just a quarter of the hashing power used the Dar=
  1461. k Wallet node implementation, and could trust it because the !@#$ thing act=
  1462. ually implemented the Satoshi protocol properly by using that protocol's so=
  1463. urce code, changing that protocol in fundemental ways would be far harder -=
  1464.  Dark Wallet would have a lot more genuine political weight. With hashing p=
  1465. ower using that implementation, they would be able to implement their own r=
  1466. ules for relaying transactions. For instance while much of the community co=
  1467. mplained violently about the 0.8.2 dust rule, which made it far harder to g=
  1468. et "dust" outputs mined, if the Dark Wallet team decided they didn't like t=
  1469. hat rule [i]and had hashing power that trusted their node implementation[/i=
  1470. ], they could make the rule irrelevant. They could even come up with a anyt=
  1471. hing-goes mechanism with no rules at all governing what transactions got re=
  1472. layed, and let individual miners make those decisions.
  1473.  
  1474. If I were the US Government and had co-opted the "core" Bitcoin dev team, y=
  1475. ou know what I'd do? I'd encourage ground-up alternate implementations know=
  1476. ing damn well that the kind of people dumb enough to work on them expecting=
  1477.  to create a viable competitor anytime soon aren't going to succeed. Every =
  1478. time anyone tried mining with one, I'd use my knowledge of all the ways the=
  1479. y are incompatible to fork them, making it clear they can't be trusted for =
  1480. mining. Then I'd go a step further and "for the good of Bitcoin" create a p=
  1481. rocess by which regular soft-forks and hard-forks happened so that Bitcoin =
  1482. can be "improved" in various ways, maybe every six months. Of course, I'd i=
  1483. nvolve those alternate implementations in some IETF-like standards process =
  1484. for show, but all I would have to do to keep them marginalized and the majo=
  1485. rity of hashing power using the approved official implementation is slip th=
  1486. e odd consensus bug into their code; remember how it was recently leaked th=
  1487. at the NSA spends $250 million a year on efforts to insert flaws into encry=
  1488. ption standards and commercial products. With changes every six months the =
  1489. alts will never keep up. Having accomplished political control, the next st=
  1490. ep is pushing the development of the Bitcoin core protocol in ways that fur=
  1491. ther my goals, such as scalability solutions that at best allow for auditin=
  1492. g, rather waiting until protocols are developed, tested, and accepted by th=
  1493. e community that support fully decentralized mining.
  1494.  
  1495. Dark Wallet has the opportunity to make the very idea of the "core" Bitcoin=
  1496.  dev team irrelevant. But sadly Amir's lot seem to understand the art of PR=
  1497.  a lot better than the political science of decentralized consensus systems.
  1498.  
  1499. --=20
  1500. 'peter'[:-1]@petertodd.org
  1501. 00000000000000046b70994c073df60d4c0926a6d6c7864f3a036fa98718cd6f
  1502. gpg: Signature made Sun 03 Nov 2013 01:42:00 AM GMT using RSA key ID A5F091FB
  1503. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  1504. gpg:                 aka "[jpeg image of size 5220]"
  1505.  
  1506. gpg: anonymous recipient; trying secret key 2636188F ...
  1507. gpg: anonymous recipient; trying secret key 38254DA8 ...
  1508. gpg: okay, we are the anonymous recipient.
  1509. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  1510.       "Peter Todd <pete@petertodd.org>"
  1511. gpg: encrypted with RSA key, ID 00000000
  1512. Excellent observations with dark wallet. I like the concept of the "political
  1513. science of crypto-currencies"
  1514.  
  1515. But don't burn any bridges please. The dark wallet people are writing real
  1516. code, you are not. If you can nudge them in the right technical directions you
  1517. could do a lot of good.
  1518. gpg: Signature made Wed 13 Nov 2013 07:41:32 PM GMT using RSA key ID 2636188F
  1519. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
  1520.  
  1521. gpg: encrypted with RSA key, ID 00000000
  1522. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1523.       "John Dillon <john.dillon892@googlemail.com>"
  1524. On Mon, Aug 19, 2013 at 02:53:32AM +0000, John Dillon wrote:
  1525.  
  1526. You sound more pissed off than usual...
  1527.  
  1528. You realize this DoS attack stuff has ignited some pretty serious debate
  1529. and desperate work to get things fixed right?
  1530.  
  1531. Letting things cool down a bit would help - best not to draw more attack
  1532. attention for a bit you know.
  1533.  
  1534. > -----BEGIN PGP SIGNED MESSAGE-----
  1535. > Hash: SHA256
  1536. >
  1537. > On Mon, Aug 19, 2013 at 12:59 AM, Gavin Andresen
  1538. > <gavinandresen@gmail.com> wrote:
  1539. > > Peter said:
  1540. > > "In any case given that SPV peers don't contribute back to the network
  1541. > > they should obviously be heavily deprioritized and served only with
  1542. > > whatever resources a node has spare."
  1543. > >
  1544. > > This seems very much like a "cut off your nose to spite your face" solution.
  1545. > >
  1546. > > SPV peers are INCREDIBLY IMPORTANT to the growth of Bitcoin; much more
  1547. > > important than nodes that have the bandwidth and disk I/O capability of
  1548. > > being a full node.  Bitcoin will be just fine if there are never more than
  1549. > > 10,000 big, beefy, full nodes forming the backbone of the network, but will
  1550. > > be NOTHING if we don't support tens of millions of lightweight SPV devices.
  1551. > >
  1552. > > Ok, that's an exaggeration, Bitcoin would be just fine in an Electrum model
  1553. > > where tens of millions of lightweight devices rely 100% on a full node to
  1554. > > operate. But I would prefer the more decentralized, less-trust-required SPV
  1555. > > model.
  1556. >
  1557. > So tell us how is your "vision" of 10,000 big beefy full nodes with SPV peers
  1558. > any different from the Electrum model? These days Electrum clients have block
  1559. > headers and verify that transactions have merkle paths to the block headers.
  1560. > The only difference I see is that SPV uses bloom filtering and Electrum can
  1561. > query by transaction. But Mike wants to add querying by transaction to full
  1562. > nodes anyway, and one of the purported advantages of this UTXO proof stuff is
  1563. > that you can query servers for UTXO's by address, so I see no difference at
  1564. > all. A patch to do bloom filtering on Electrum would be amusing to me.
  1565. >
  1566. > Here you have Peter talking about clever ways to actually get decentralization
  1567. > by having SPV peers donate back to the network with spare bandwidth, like
  1568. > relaying blocks, not to mention his partial UTXO set ideas, and you completely
  1569. > ignore that. But I guess that would raise ugly questions when people realize
  1570. > they can't now contribute back to Bitcoin, because the blocksize is a gigabyte
  1571. > of microtransactions... It may also raise ugly questions with regulators that
  1572. > may find the idea of "full node == data chokepoint == regulatory chokepoint" an
  1573. > attractive notion. Why are there not any competent people other than Peter who
  1574. > really have the guts to bring up these proposals? I've little luck getting
  1575. > proof-of-concepts built for money anyway. Maybe we just have a darth of smart
  1576. > competent people in this space.
  1577. >
  1578. > You do a good job of signaling your priorities Gavin. The payment protocol
  1579. > includes no notion that you may want to pay anyone but a SSL certified
  1580. > merchant. Yes I know the crypto can be upgraded, but it says volumes that you
  1581. > pushed for that first, without even the slightest token effort to allow
  1582. > individuals to participate in any way. Sad given you have made things *less*
  1583. > secure because there is no safe way to get money *into* my wallet with the
  1584. > payment protocol, but could have been.
  1585. >
  1586. > Tell me, when my decentralization pull-req is voted on, which way are you
  1587. > planning on voting?
  1588. >
  1589. > -----BEGIN PGP SIGNATURE-----
  1590. > Version: GnuPG v1.4.11 (GNU/Linux)
  1591. >
  1592. > iQEcBAEBCAAGBQJSEYg/AAoJEEWCsU4mNhiPQBIH/A2cef0NDzu72CY0+N1HdPO+
  1593. > fdixwncAg1ok6YdJj5WALjHbkhJ+QRVEZoRr6rHPxxxTywI+HiPN1oaopIrq3StP
  1594. > bNpvouaWXLyw6xHMrMYefVOluHNZg3lu1akLdGuYA7rDHLwP/RhlF1FFzXSxKFsp
  1595. > ANcw4WW7U5r5nfBHYc/a9xo8S6THI7Nv2NDW6WaRQO4X9sbSKSdwanoe75CLsRzE
  1596. > E2cPNvwG4WA/MUgkl3Ao6dMsEPPa8dJK98LaS4BE/m9iFWQiV8t35/FQ0GAFQoJo
  1597. > PQUs8aAWiI0caAxI0vddxKQ+YlwPw2m1QH6h19wUO7+KLKOtxMFmWoDu/OLdTRM=
  1598. > =IfkA
  1599. > -----END PGP SIGNATURE-----
  1600. >
  1601.  
  1602. --
  1603. 'peter'[:-1]@petertodd.org
  1604. gpg: Signature made Mon 19 Aug 2013 03:14:26 AM GMT using RSA key ID A5F091FB
  1605. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  1606. gpg:                 aka "[jpeg image of size 5220]"
  1607.  
  1608. gpg: encrypted with 4096-bit RSA key, ID 0753963A, created 2013-07-03
  1609.       "w@grabhive.com <w@grabhive.com>"
  1610. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1611.       "John Dillon <john.dillon892@googlemail.com>"
  1612. Content-Type: multipart/signed;
  1613.         boundary="Apple-Mail=_A1B46601-BBCC-40F3-8BD0-722BD938097E";
  1614.         protocol="application/pgp-signature";
  1615.         micalg=pgp-sha1
  1616.  
  1617.  
  1618. --Apple-Mail=_A1B46601-BBCC-40F3-8BD0-722BD938097E
  1619. Content-Transfer-Encoding: quoted-printable
  1620. Content-Type: text/plain;
  1621.         charset=us-ascii
  1622.  
  1623. Well said, John.
  1624.  
  1625. -wendell
  1626.  
  1627. grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
  1628.  
  1629. On Aug 19, 2013, at 4:53 AM, John Dillon wrote:
  1630.  
  1631. > So tell us how is your "vision" of 10,000 big beefy full nodes with =
  1632. SPV peers
  1633. > any different from the Electrum model? These days Electrum clients =
  1634. have block
  1635. > headers and verify that transactions have merkle paths to the block =
  1636. headers.
  1637. > The only difference I see is that SPV uses bloom filtering and =
  1638. Electrum can
  1639. > query by transaction. But Mike wants to add querying by transaction to =
  1640. full
  1641. > nodes anyway, and one of the purported advantages of this UTXO proof =
  1642. stuff is
  1643. > that you can query servers for UTXO's by address, so I see no =
  1644. difference at
  1645. > all. A patch to do bloom filtering on Electrum would be amusing to me.
  1646. >=20
  1647. > Here you have Peter talking about clever ways to actually get =
  1648. decentralization
  1649. > by having SPV peers donate back to the network with spare bandwidth, =
  1650. like
  1651. > relaying blocks, not to mention his partial UTXO set ideas, and you =
  1652. completely
  1653. > ignore that. But I guess that would raise ugly questions when people =
  1654. realize
  1655. > they can't now contribute back to Bitcoin, because the blocksize is a =
  1656. gigabyte
  1657. > of microtransactions... It may also raise ugly questions with =
  1658. regulators that
  1659. > may find the idea of "full node =3D=3D data chokepoint =3D=3D =
  1660. regulatory chokepoint" an
  1661. > attractive notion. Why are there not any competent people other than =
  1662. Peter who
  1663. > really have the guts to bring up these proposals? I've little luck =
  1664. getting
  1665. > proof-of-concepts built for money anyway. Maybe we just have a darth =
  1666. of smart
  1667. > competent people in this space.
  1668. >=20
  1669. > You do a good job of signaling your priorities Gavin. The payment =
  1670. protocol
  1671. > includes no notion that you may want to pay anyone but a SSL certified
  1672. > merchant. Yes I know the crypto can be upgraded, but it says volumes =
  1673. that you
  1674. > pushed for that first, without even the slightest token effort to =
  1675. allow
  1676. > individuals to participate in any way. Sad given you have made things =
  1677. *less*
  1678. > secure because there is no safe way to get money *into* my wallet with =
  1679. the
  1680. > payment protocol, but could have been.
  1681. >=20
  1682. > Tell me, when my decentralization pull-req is voted on, which way are =
  1683. you
  1684. > planning on voting?
  1685.  
  1686.  
  1687. --Apple-Mail=_A1B46601-BBCC-40F3-8BD0-722BD938097E
  1688. Content-Transfer-Encoding: 7bit
  1689. Content-Disposition: attachment;
  1690.         filename=signature.asc
  1691. Content-Type: application/pgp-signature;
  1692.         name=signature.asc
  1693. Content-Description: Message signed with OpenPGP using GPGMail
  1694.  
  1695. -----BEGIN PGP SIGNATURE-----
  1696. Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
  1697.  
  1698. iQIcBAEBAgAGBQJSEkb7AAoJECAN2ykHU5Y660IQAID2HES1qjA/MBUvkK2pLXV1
  1699. LYdXMxysz+TB5JHUOeMVfc5Dhw+bPH4my/IeyQI7zrupqAIffkTplJZq0+Cazj4x
  1700. aPcH8DZfdUrX5rUeK0uzl7JdbWj6mf5jbw/cKRUD87+Hv6lprFJ7z6qBK8YywqdQ
  1701. rSo+Oy4oLomuhfjpPOrFVGxdvIgvFSQ55bmVCH9qUna495G7pN7et6uO0H3Ty8i0
  1702. dRAGs3vukm2ZqNInpuS2mmKA9IUzbjXNQIox/MP9vPmjH2X3GLWOKhjLsqMpJoo5
  1703. 2Nz32wmaw1CRvISSsBDf1FYbDdJ3vS9n9dgEot5atKoHkxMVIpJ081FWz2cQBKKM
  1704. n7tya1TBAngOI8KwQqj6o/V3lDJBau4YgsSlosBZvINff6qKxI+Qd0W3H7sbYvoW
  1705. BnRdHWrEeHTgnqiREwmiZrz2ziij09if59Cmai/crl+wbb5DXjRqf69U2rMmrISR
  1706. OzczRa3nULLmezq+Km/oLIUX+qye6BRb/DPiAxkCbz2YHsrn21eZLGoKhs1iA/LV
  1707. 8hZMidGOF8lsoUV+19CBRz/70Ox56MjvbuVBCVLWxJxLo2qen/9xQL8nlzwMYV/u
  1708. DOKpz+IcNivEwRFl1vIvfgxgKCxRlOOj3s5ykJW6RTvFE6FbSsypvKkLTVpbMZIG
  1709. 5mp7at7boB0c3meObznG
  1710. =N8do
  1711. -----END PGP SIGNATURE-----
  1712.  
  1713. --Apple-Mail=_A1B46601-BBCC-40F3-8BD0-722BD938097E--
  1714.  
  1715. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  1716.       "Peter Todd <pete@petertodd.org>"
  1717. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1718.       "John Dillon <john.dillon892@googlemail.com>"
  1719. Get in touch with me before you decide to offer a reward or anything for
  1720. actually making an attack happen... You have the support of a core dev
  1721. FWIW, I'm sure you can guess who. Warren of Litecoin says he believes
  1722. you as well, and asks you try the attack on a smaller alt-coin. :P
  1723.  
  1724. Strategy would be good here, especially because the same attack(s) can
  1725. be used to take down the whole network too, but we more want to show how
  1726. SPV specifically is bad. Implementing a darknet to resist network-wide
  1727. attack is easily done, and it looks like doing peer prioritization will
  1728. help for those for whome darknets aren't a good option. Some testing of
  1729. the latter prior to an attack would be good.
  1730.  
  1731. --
  1732. 'peter'[:-1]@petertodd.org
  1733. 0000000000000062f418c8caf7a1e2058f4e2aa9a045ef807ef569faf92528c5
  1734. gpg: Signature made Sun 21 Jul 2013 05:49:33 AM GMT using RSA key ID A5F091FB
  1735. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  1736. gpg:                 aka "[jpeg image of size 5220]"
  1737.  
  1738. gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
  1739.       "Peter Todd <pete@petertodd.org>"
  1740. gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
  1741.       "John Dillon <john.dillon892@googlemail.com>"
  1742. On Sun, Jul 14, 2013 at 07:05:26PM +0000, John Dillon wrote:
  1743.  
  1744. Speaking of, check out this tx:
  1745. 8e8b01b99048ee68bfe378dd7eb7fc8c1d5b1864aa74a76f4dc97ed38fbfe15e
  1746.  
  1747. Yup, we don't check that the dummy value is OP_0 at all...
  1748.  
  1749. > -----BEGIN PGP SIGNED MESSAGE-----
  1750. > Hash: SHA256
  1751. >
  1752. > As you all know keeping the size of the UTXO set small is critical, and more
  1753. > recently we've also had problems with distasteful data being added to the UTXO
  1754. > set. (http://garzikrants.blogspot.se/2013_04_01_archive.html) Gregory Maxwell
  1755. > has an excellent solution to the distasteful data problem in the form of P2SH^2
  1756. > (http://comments.gmane.org/gmane.comp.bitcoin.devel/1996) and Peter Todd
  1757. > pointed out how we can implement it with the existing P2SH form. We're also
  1758. > going to be implementing some kind of OP_RETURN <data> soon which handles the
  1759. > timestamping and similar use-cases, again without UTXO impact.
  1760.  
  1761. --
  1762. 'peter'[:-1]@petertodd.org
  1763. 0000000000000089969afa63b9c652aa7ca624f6082f46e1c3399bd669051ce9
  1764. gpg: Signature made Sun 21 Jul 2013 10:12:59 AM GMT using RSA key ID A5F091FB
  1765. gpg: Good signature from "Peter Todd <pete@petertodd.org>"
  1766. gpg:                 aka "[jpeg image of size 5220]"
  1767.  
  1768. gpg: anonymous recipient; trying secret key 2636188F ...
  1769. gpg: anonymous recipient; trying secret key 38254DA8 ...
  1770. gpg: okay, we are the anonymous recipient.
  1771. gpg: encrypted with RSA key, ID 00000000
  1772. gpg: encrypted with 2048-bit ELG-E key, ID F0F0B355, created 1999-11-27
  1773.       "Gregory Maxwell <gmaxwell@gmail.com>"
  1774. gpg: encrypted with RSA key, ID 00000000
  1775. Hi Gregory,
  1776.  
  1777. I apologise for my tardiness, but here is the 5.11BTC I promised for the
  1778. CoinJoin effort.
  1779.  
  1780. It is great news to see blockchain.info implement it! I used it myself. :) Are
  1781. you giving them a token reward? They are a for profit venture, but all the same
  1782. a thank you recognition of some kind seems worthwhile to me.
  1783.  
  1784. I note that Peter Wuille still hasn't PGP signed his address...
  1785.  
  1786. Yours,
  1787.  
  1788. 1BDSZMaUvrbTjWsSgLA4XqYUK4dDzxREEV
  1789. KxG9HMgaaMQKWGnht7U1gZW1iWxxNQunTa78gMkvMYSEDHbvKFuS
  1790. gpg: Signature made Sat 26 Oct 2013 05:20:28 AM GMT using RSA key ID 2636188F
  1791. gpg: Good signature from "John Dillon <john.dillon892@googlemail.com>"
create a new version of this paste RAW Paste Data