Topic: "John Dillon" We can leak things too you trolling piece of shit - page 2. (Read 10304 times)

Not following, to be honest.

My guess is that Conformal Systems does have what it takes to create a proper reimplementation. They just lack the PR that Dark Wallet is getting.

That project needs a lot more attention.

Because, regardless of who he is, we can appreciate some of the positions of John Dillon.

Sorry to shift the tide of this drama but we still want to discuss what should be in a so-called Dark Wallet. Hopefully the leaked chain doesn't cause much of a fuss among what we assume are relatively tough-skinned individuals. We'd like to get on with this business already.

Can someone easily explain what is going on here?

That text about libbitcoin was posted by myself on the foundation forums; I just thought jdillon would find it interesting.

Wow, interesting revelations. I always knew the dev team was divided, but this runs a special sort of deep.

Very intrigued by the revelations about libbitcoin, always was concerned about that just didn't know why. They have the chance to turn the tides but it seems they are getting on the wrong train. That's a shame.

As a matter of fact, user BCB was caught tracking in the same thread jdillon was posting in, so there is your first nugget.

Jdillon a fed with something to hide, this could be very bad for you. Please be safe.

Looks like his computer was compromised, including his PGP key; those are all private emails.

In two instances people have tried to use webbugs on this forum, as well as the foundation forum, in discussions about blacklists - I took that as a sign that people are resorting to some pretty ugly tactics. This just confirmed my suspicions.

John had expressed concerns to me about the safety of himself and his family, which I guess I might as well quote given it is one of the leaked emails:


So who knows, maybe this is more to do with him than anything else. Regardless I'm taking it as a sign that we need to be more careful about our computer security - though I dunno, I always had the impression that John was a very smart man who understood crypto and computer security well, yet he still got hacked.

Part 2:


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.

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.

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.

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.

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.

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.

Where Dark Wallet goes wrong

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.

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

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.

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.

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.

--
'peter'[:-1]@petertodd.org
000000000000000a00cb71e41c03f547da5a382ab122ec7d2dcb4b6ff7e3e532
gpg: Signature made Sun 03 Nov 2013 01:34:34 AM GMT using RSA key ID A5F091FB
gpg: Good signature from "Peter Todd <[email protected]>"
gpg:                 aka "[jpeg image of size 5220]"

gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 02, 2013 at 09:34:35PM -0400, Peter Todd wrote:
> Posted to the foundation forum,
> https://bitcoinfoundation.org/forum/index.php?/topic/483-bitcoin-dark-wal=
let/page__st__20#entry5410
>=20
> Dunno if you have a membership or not.

Sorry, forgot formatting. Heck, post this elsewhere if you want.


[quote name=3D'Saivann Carignan' timestamp=3D'1383429407' post=3D'5408']
Patrick Murck said it in simple terms: The use of Bitcoin will (and is) reg=
ulated, not the Bitcoin protocol itself..
[/quote]

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.

The first problem is ASICs, specifically the huge gulf in performance per u=
nit cost between commodity hardware, or even hardware possible to create on=
 a small scale with FPGAs, and ASICs. The nature of IC manufacturing is suc=
h 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 t=
o support a diverse IC manufacturing industry at the current level of techn=
ological sophistication.

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 th=
ey process capable of doing Bitcoin mining must include additional circuits=
 that let the US government control how, and by whom, they are used. This i=
s a problem in gene=
ral with computing, but controlling the manufacture of a special-purp=
ose ASIC is far easier and simpler, both technologically and politically, t=
han controlling the availability of general purpose computing hardware. For=
tunately it is possible to create proof-of-work algorithms where custom ASI=
Cs have less of an advantage over general purpose hardware, but Bitcoin its=
elf isn't going to change the algorithm.

The second problem is bandwidth: the Bitcoin protocol has atrocious scalabi=
lity 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 poi=
nt you will have increased it to the level where you can no longer mine ano=
nymously and then regulating miners directly becomes possible. Unfortunatel=
y while technological improvements have made non-anonymous bandwidth more p=
lentiful, for anonymous bandwidth - or even just censorship resistant bandw=
idth - 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 en=
emy rather than the much larger banking industry. (and government in genera=
l) 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 figure=
d out yet how to upgrade Bitcoin itself with those improvements.

What's interesting is with good cryptography we've figured out ways to at l=
east detect if miners are violating every other aspect of the Bitcoin proto=
col: some relatively small and backwards compatible changes to the protocol=
 allow auditing everything miners do with peicewise audits done on low-band=
width 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 q=
uickly approaches zero.

But auditing can only detect if miners fail to follow the rules of the Bitc=
oin protocol; it can't force miners to decide to include your blacklisted t=
ransactions 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 B=
itcoin protocol by fiat, then what? Suppose the Federal Reserve or equivale=
nt decides that the deflation of Bitcoin is bad for the economy, and the co=
in 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 majori=
ty of hashing power to follow new rules, and while you're wallet software m=
ay detect that fraud and shutdown, what alternative do you have but to "upg=
rade" it to accept the new rules? If you're transactions aren't protected b=
y the majority of hashing power, you're transaction aren't secure.

Where Dark Wallet goes wrong

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-impl=
ementation of Bitcoin is fundementally flawed, both from an engineering poi=
nt 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 sui=
cide 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 everyt=
hing that isn't directly related to that core consensus protocol, and turne=
d it into an easy to use library. Only then should they have built a wallet=
/node implementation around that core, unchanging, protocol.

Where Amir Taaki and the rest of the Dark Wallet team go so very wrong is t=
hey don't understand that the Bitcoin specification is the consensus=
-critical part of the Satoshi source code. Instead they are pursuing a grou=
nd-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 d=
etails right, no significant amount of hashing power is going to ever use t=
heir node implementation to mine with - what pool wants to lose thousands o=
f dollars of profit just because yet another libbitcoin consensus bug was f=
ound? Of course, with no-one using their code to mine, they have no politic=
al power - Gavin and the Bitcoin Foundation's ability to control the core B=
itcoin protocol is entirely based on the fact that almost all the hashing p=
ower uses the source code at ht=
tps://github.com/bitcoin/bitcoin

On the other hand, if even just a quarter of the hashing power used the Dar=
k Wallet node implementation, and could trust it because the !@#$ thing act=
ually implemented the Satoshi protocol properly by using that protocol's so=
urce code, changing that protocol in fundemental ways would be far harder -=
 Dark Wallet would have a lot more genuine political weight. With hashing p=
ower using that implementation, they would be able to implement their own r=
ules for relaying transactions. For instance while much of the community co=
mplained violently about the 0.8.2 dust rule, which made it far harder to g=
et "dust" outputs mined, if the Dark Wallet team decided they didn't like t=
hat rule and had hashing power that trusted their node implementation[/i=
], they could make the rule irrelevant. They could even come up with a anyt=
hing-goes mechanism with no rules at all governing what transactions got re=
layed, and let individual miners make those decisions.

If I were the US Government and had co-opted the "core" Bitcoin dev team, y=
ou know what I'd do? I'd encourage ground-up alternate implementations know=
ing 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 the=
y 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 p=
rocess 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 i=
nvolve those alternate implementations in some IETF-like standards process =
for show, but all I would have to do to keep them marginalized and the majo=
rity of hashing power using the approved official implementation is slip th=
e odd consensus bug into their code; remember how it was recently leaked th=
at the NSA spends $250 million a year on efforts to insert flaws into encry=
ption standards and commercial products. With changes every six months the =
alts will never keep up. Having accomplished political control, the next st=
ep is pushing the development of the Bitcoin core protocol in ways that fur=
ther my goals, such as scalability solutions that at best allow for auditin=
g, rather waiting until protocols are developed, tested, and accepted by th=
e community that support fully decentralized mining.

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.

--=20
'peter'[:-1]@petertodd.org
00000000000000046b70994c073df60d4c0926a6d6c7864f3a036fa98718cd6f
gpg: Signature made Sun 03 Nov 2013 01:42:00 AM GMT using RSA key ID A5F091FB
gpg: Good signature from "Peter Todd <[email protected]>"
gpg:                 aka "[jpeg image of size 5220]"

gpg: anonymous recipient; trying secret key 2636188F ...
gpg: anonymous recipient; trying secret key 38254DA8 ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with RSA key, ID 00000000
Excellent observations with dark wallet. I like the concept of the "political
science of crypto-currencies"

But don't burn any bridges please. The dark wallet people are writing real
code, you are not. If you can nudge them in the right technical directions you
could do a lot of good.
gpg: Signature made Wed 13 Nov 2013 07:41:32 PM GMT using RSA key ID 2636188F
gpg: Good signature from "John Dillon <[email protected]>"

gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
On Mon, Aug 19, 2013 at 02:53:32AM +0000, John Dillon wrote:

You sound more pissed off than usual...

You realize this DoS attack stuff has ignited some pretty serious debate
and desperate work to get things fixed right?

Letting things cool down a bit would help - best not to draw more attack
attention for a bit you know.

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Aug 19, 2013 at 12:59 AM, Gavin Andresen
> <[email protected]> wrote:
> > Peter said:
> > "In any case given that SPV peers don't contribute back to the network
> > they should obviously be heavily deprioritized and served only with
> > whatever resources a node has spare."
> >
> > This seems very much like a "cut off your nose to spite your face" solution.
> >
> > SPV peers are INCREDIBLY IMPORTANT to the growth of Bitcoin; much more
> > important than nodes that have the bandwidth and disk I/O capability of
> > being a full node.  Bitcoin will be just fine if there are never more than
> > 10,000 big, beefy, full nodes forming the backbone of the network, but will
> > be NOTHING if we don't support tens of millions of lightweight SPV devices.
> >
> > Ok, that's an exaggeration, Bitcoin would be just fine in an Electrum model
> > where tens of millions of lightweight devices rely 100% on a full node to
> > operate. But I would prefer the more decentralized, less-trust-required SPV
> > model.
>
> So tell us how is your "vision" of 10,000 big beefy full nodes with SPV peers
> any different from the Electrum model? These days Electrum clients have block
> headers and verify that transactions have merkle paths to the block headers.
> The only difference I see is that SPV uses bloom filtering and Electrum can
> query by transaction. But Mike wants to add querying by transaction to full
> nodes anyway, and one of the purported advantages of this UTXO proof stuff is
> that you can query servers for UTXO's by address, so I see no difference at
> all. A patch to do bloom filtering on Electrum would be amusing to me.
>
> Here you have Peter talking about clever ways to actually get decentralization
> by having SPV peers donate back to the network with spare bandwidth, like
> relaying blocks, not to mention his partial UTXO set ideas, and you completely
> ignore that. But I guess that would raise ugly questions when people realize
> they can't now contribute back to Bitcoin, because the blocksize is a gigabyte
> of microtransactions... It may also raise ugly questions with regulators that
> may find the idea of "full node == data chokepoint == regulatory chokepoint" an
> attractive notion. Why are there not any competent people other than Peter who
> really have the guts to bring up these proposals? I've little luck getting
> proof-of-concepts built for money anyway. Maybe we just have a darth of smart
> competent people in this space.
>
> You do a good job of signaling your priorities Gavin. The payment protocol
> includes no notion that you may want to pay anyone but a SSL certified
> merchant. Yes I know the crypto can be upgraded, but it says volumes that you
> pushed for that first, without even the slightest token effort to allow
> individuals to participate in any way. Sad given you have made things *less*
> secure because there is no safe way to get money *into* my wallet with the
> payment protocol, but could have been.
>
> Tell me, when my decentralization pull-req is voted on, which way are you
> planning on voting?
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBCAAGBQJSEYg/AAoJEEWCsU4mNhiPQBIH/A2cef0NDzu72CY0+N1HdPO+
> fdixwncAg1ok6YdJj5WALjHbkhJ+QRVEZoRr6rHPxxxTywI+HiPN1oaopIrq3StP
> bNpvouaWXLyw6xHMrMYefVOluHNZg3lu1akLdGuYA7rDHLwP/RhlF1FFzXSxKFsp
> ANcw4WW7U5r5nfBHYc/a9xo8S6THI7Nv2NDW6WaRQO4X9sbSKSdwanoe75CLsRzE
> E2cPNvwG4WA/MUgkl3Ao6dMsEPPa8dJK98LaS4BE/m9iFWQiV8t35/FQ0GAFQoJo
> PQUs8aAWiI0caAxI0vddxKQ+YlwPw2m1QH6h19wUO7+KLKOtxMFmWoDu/OLdTRM=
> =IfkA
> -----END PGP SIGNATURE-----
>

--
'peter'[:-1]@petertodd.org
gpg: Signature made Mon 19 Aug 2013 03:14:26 AM GMT using RSA key ID A5F091FB
gpg: Good signature from "Peter Todd <[email protected]>"
gpg:                 aka "[jpeg image of size 5220]"

gpg: encrypted with 4096-bit RSA key, ID 0753963A, created 2013-07-03
      "[email protected] <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
Content-Type: multipart/signed;
   boundary="Apple-Mail=_A1B46601-BBCC-40F3-8BD0-722BD938097E";
   protocol="application/pgp-signature";
   micalg=pgp-sha1


--Apple-Mail=_A1B46601-BBCC-40F3-8BD0-722BD938097E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
   charset=us-ascii

Well said, John.

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Aug 19, 2013, at 4:53 AM, John Dillon wrote:

> So tell us how is your "vision" of 10,000 big beefy full nodes with =
SPV peers
> any different from the Electrum model? These days Electrum clients =
have block
> headers and verify that transactions have merkle paths to the block =
headers.
> The only difference I see is that SPV uses bloom filtering and =
Electrum can
> query by transaction. But Mike wants to add querying by transaction to =
full
> nodes anyway, and one of the purported advantages of this UTXO proof =
stuff is
> that you can query servers for UTXO's by address, so I see no =
difference at
> all. A patch to do bloom filtering on Electrum would be amusing to me.
>=20
> Here you have Peter talking about clever ways to actually get =
decentralization
> by having SPV peers donate back to the network with spare bandwidth, =
like
> relaying blocks, not to mention his partial UTXO set ideas, and you =
completely
> ignore that. But I guess that would raise ugly questions when people =
realize
> they can't now contribute back to Bitcoin, because the blocksize is a =
gigabyte
> of microtransactions... It may also raise ugly questions with =
regulators that
> may find the idea of "full node =3D=3D data chokepoint =3D=3D =
regulatory chokepoint" an
> attractive notion. Why are there not any competent people other than =
Peter who
> really have the guts to bring up these proposals? I've little luck =
getting
> proof-of-concepts built for money anyway. Maybe we just have a darth =
of smart
> competent people in this space.
>=20
> You do a good job of signaling your priorities Gavin. The payment =
protocol
> includes no notion that you may want to pay anyone but a SSL certified
> merchant. Yes I know the crypto can be upgraded, but it says volumes =
that you
> pushed for that first, without even the slightest token effort to =
allow
> individuals to participate in any way. Sad given you have made things =
*less*
> secure because there is no safe way to get money *into* my wallet with =
the
> payment protocol, but could have been.
>=20
> Tell me, when my decentralization pull-req is voted on, which way are =
you
> planning on voting?


--Apple-Mail=_A1B46601-BBCC-40F3-8BD0-722BD938097E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
   filename=signature.asc
Content-Type: application/pgp-signature;
   name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)

iQIcBAEBAgAGBQJSEkb7AAoJECAN2ykHU5Y660IQAID2HES1qjA/MBUvkK2pLXV1
LYdXMxysz+TB5JHUOeMVfc5Dhw+bPH4my/IeyQI7zrupqAIffkTplJZq0+Cazj4x
aPcH8DZfdUrX5rUeK0uzl7JdbWj6mf5jbw/cKRUD87+Hv6lprFJ7z6qBK8YywqdQ
rSo+Oy4oLomuhfjpPOrFVGxdvIgvFSQ55bmVCH9qUna495G7pN7et6uO0H3Ty8i0
dRAGs3vukm2ZqNInpuS2mmKA9IUzbjXNQIox/MP9vPmjH2X3GLWOKhjLsqMpJoo5
2Nz32wmaw1CRvISSsBDf1FYbDdJ3vS9n9dgEot5atKoHkxMVIpJ081FWz2cQBKKM
n7tya1TBAngOI8KwQqj6o/V3lDJBau4YgsSlosBZvINff6qKxI+Qd0W3H7sbYvoW
BnRdHWrEeHTgnqiREwmiZrz2ziij09if59Cmai/crl+wbb5DXjRqf69U2rMmrISR
OzczRa3nULLmezq+Km/oLIUX+qye6BRb/DPiAxkCbz2YHsrn21eZLGoKhs1iA/LV
8hZMidGOF8lsoUV+19CBRz/70Ox56MjvbuVBCVLWxJxLo2qen/9xQL8nlzwMYV/u
DOKpz+IcNivEwRFl1vIvfgxgKCxRlOOj3s5ykJW6RTvFE6FbSsypvKkLTVpbMZIG
5mp7at7boB0c3meObznG
=N8do
-----END PGP SIGNATURE-----

--Apple-Mail=_A1B46601-BBCC-40F3-8BD0-722BD938097E--

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
Get in touch with me before you decide to offer a reward or anything for
actually making an attack happen... You have the support of a core dev
FWIW, I'm sure you can guess who. Warren of Litecoin says he believes
you as well, and asks you try the attack on a smaller alt-coin.

Strategy would be good here, especially because the same attack(s) can
be used to take down the whole network too, but we more want to show how
SPV specifically is bad. Implementing a darknet to resist network-wide
attack is easily done, and it looks like doing peer prioritization will
help for those for whome darknets aren't a good option. Some testing of
the latter prior to an attack would be good.

--
'peter'[:-1]@petertodd.org
0000000000000062f418c8caf7a1e2058f4e2aa9a045ef807ef569faf92528c5
gpg: Signature made Sun 21 Jul 2013 05:49:33 AM GMT using RSA key ID A5F091FB
gpg: Good signature from "Peter Todd <[email protected]>"
gpg:                 aka "[jpeg image of size 5220]"

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
On Sun, Jul 14, 2013 at 07:05:26PM +0000, John Dillon wrote:

Speaking of, check out this tx:
8e8b01b99048ee68bfe378dd7eb7fc8c1d5b1864aa74a76f4dc97ed38fbfe15e

Yup, we don't check that the dummy value is OP_0 at all...

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> As you all know keeping the size of the UTXO set small is critical, and more
> recently we've also had problems with distasteful data being added to the UTXO
> set. (http://garzikrants.blogspot.se/2013_04_01_archive.html) Gregory Maxwell
> has an excellent solution to the distasteful data problem in the form of P2SH^2
> (http://comments.gmane.org/gmane.comp.bitcoin.devel/1996) and Peter Todd
> pointed out how we can implement it with the existing P2SH form. We're also
> going to be implementing some kind of OP_RETURN soon which handles the
> timestamping and similar use-cases, again without UTXO impact.

--
'peter'[:-1]@petertodd.org
0000000000000089969afa63b9c652aa7ca624f6082f46e1c3399bd669051ce9
gpg: Signature made Sun 21 Jul 2013 10:12:59 AM GMT using RSA key ID A5F091FB
gpg: Good signature from "Peter Todd <[email protected]>"
gpg:                 aka "[jpeg image of size 5220]"

gpg: anonymous recipient; trying secret key 2636188F ...
gpg: anonymous recipient; trying secret key 38254DA8 ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with 2048-bit ELG-E key, ID F0F0B355, created 1999-11-27
      "Gregory Maxwell <[email protected]>"
gpg: encrypted with RSA key, ID 00000000
Hi Gregory,

I apologise for my tardiness, but here is the 5.11BTC I promised for the
CoinJoin effort.

It is great news to see blockchain.info implement it! I used it myself. Are
you giving them a token reward? They are a for profit venture, but all the same
a thank you recognition of some kind seems worthwhile to me.

I note that Peter Wuille still hasn't PGP signed his address...

Yours,

1BDSZMaUvrbTjWsSgLA4XqYUK4dDzxREEV
KxG9HMgaaMQKWGnht7U1gZW1iWxxNQunTa78gMkvMYSEDHbvKFuS
gpg: Signature made Sat 26 Oct 2013 05:20:28 AM GMT using RSA key ID 2636188F
gpg: Good signature from "John Dillon <[email protected]>"[/size][/quote]

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.

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.


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.
gpg: Signature made Tue 14 May 2013 02:35:14 AM GMT using RSA key ID 2636188F
gpg: Good signature from "John Dillon <[email protected]>"

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
On Tue, May 14, 2013 at 02:36:10AM +0000, John Dillon wrote:
> Interesting message I got from Gavin.

Huh, yeah he sent me a similar one, but aimed at "what should I tell
people asking to hire developers?"

Obviously he's taking you seriously - a good thing I think. That post by
Mike Hern about putting you on his ignore list is similar really...

> Regarding my schedule I'll be back in contact for sure two weeks after the
> conference. As I say below you do what you feel is right with replace-by-fee.
> I'm looking forward to seeing the video! You will see some more support from me
> in the future with it too. My bitcoins aren't accessible right now due to some
> travel, but you can say in the forums you have gotten another 1BTC from me
> today. I will make good on that promise.

Thanks! Yeah, no rush about actual funds, I've got cheap rates on my
line-of-credit.

re: replace-by-fee I think I'll do a version that "solves" the DoS
problem by simply not replacing transactions that have been re-spent, a
good half measure in any case that again further reduces harm. I'll
implement that right after the conference.

The code for it is also easier too, so it's more likely to get accepted
by miners.

--
'peter'[:-1]@petertodd.org
00000000000000ed82fe4ffbf5677d6fc1ee304186288eb13358cf32418d0c31
gpg: Signature made Tue 14 May 2013 03:08:29 AM GMT using RSA key ID A5F091FB
gpg: Good signature from "Peter Todd <[email protected]>"
gpg:                 aka "[jpeg image of size 5220]"

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
> ./bitcoin-qt -salvagewallet
>
> Doesn't work when there isn't a wallet at all.
>
> Good to get your name in the Bitcoin sourecode credits I think - adds
> some credibility.

Thanks. I'll look into that.
gpg: Signature made Tue 28 May 2013 04:57:44 AM GMT using RSA key ID 2636188F
gpg: Good signature from "John Dillon <[email protected]>"

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 28, 2013 at 04:58:16AM +0000, John Dillon wrote:
> > ./bitcoin-qt -salvagewallet
> >=20
> > Doesn't work when there isn't a wallet at all.
> >=20
> > Good to get your name in the Bitcoin sourecode credits I think - adds
> > some credibility.
>=20
> Thanks. I'll look into that.

Also, on decentralizing mining, I had the idea of adding a UDP method
for very fast distribution of block headers and tiny full blocks. The
idea here is the moment a new block is created, every miner should
immediately start working on a block that would orphan that block with
only the coinbase TX in it.

This punishes blocks that take a long time to propegate, particularly
for miners behind low-bandwidth links. It'll be a nice natural incentive
towards smaller blocks, although I do worry a bit about how the idea
could be latched onto as "well obviously we *can* increase the blocksize
now!"

--=20
'peter'[:-1]@petertodd.org
00000000000001027c8b5ae04fce5ccf3948a15e137dab152e62450fd998c3ae
gpg: Signature made Tue 28 May 2013 05:22:58 AM GMT using RSA key ID A5F091FB
gpg: Good signature from "Peter Todd <[email protected]>"
gpg:                 aka "[jpeg image of size 5220]"

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit ELG-E key, ID F0F0B355, created 1999-11-27
      "Gregory Maxwell <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
> I was talking with Gregory Maxwell about decentralizing mining at the
> conference. He came up with the idea of tightly integrating mining
> functionality into the client using Luke Dashjr's getblocktemplate
> protocol; the existing getwork is not compatible with ASICs. The idea
> would be to make solo-mining as easy as possible, and further more to
> move pools to a structure where the pool's function is to co-ordinate
> share payments, not block construction. Essentially hashers would become
> true miners, doing transaction selection on their own, and then pools
> would credit them for their shares and do the accounting. In this model
> all a pool can do is defraud miners rather than harm to the whole
> network.

Smart idea.
 
> It's also nice because by doing so we make the dangers of a large block
> size very clear by making large numbers of miners see immediately how it
> makes it difficult for them to operate. We also make changing the size
> more difficult in general because the decision then becomes one that
> hundreds or even thousands of miners need to make individually, greatly
> slowing down any possible change. Of course, I didn't say any of that...

Why not go ahead and say it? You know that Mike and similar will counter-argue
that mining needs to be done by "responsible" central authority figures running
pools, so let them make that bogus argument. I've seen Gavin criticising you
for not working on making mining decentralized too, so go ahead and force him
into a position of arguing against that.

People criticise you for your motivations all the time. Don't give them more
ammo. Being totally upfront about why you are pushing decentralized mining is a
good thing. In my opinion what you are doing is obvious anyway.


Regarding your idea for fast block header propagation, and delibrate orphaning
by miners, I like it and I too worry that it could be seen as an excuse to
increase the blocksize. Maybe keep that one secret for now, but look into the
infrastructure to make it possible? It would make sense to have a UDP-based
block header distribution channel for a lot of things, like you keep saying
with blockheaders over twitter and other fun. The system doesn't need to be
able to propagate whole blocks in UDP packets however technically possible it
is.

Regarding rational, also point out that mining ontop of a block that you have
not verified fully is always unacceptable due to attacks. Reducing your block
size to zero transactions just makes sense in terms of rational miner behavior.
Why work on something that you know has a high chance of not propegating fast
enough to win the race?

> I think the devs should direct the 10BTC donation you made a few months
> ago to this effort - would you and your partners be willing to commit
> some more funds? I can throw in some BTC myself. Greg, Luke and I have
> talked about possibly doing this an a public assurance contract. Keep in
> mind that you lot have created a fair bit of controversy - donating
> towards something less controversial than replace-by-fee and my video
> could help out.

I do not donate funds with strings attached, but if the dev team needs any
guidance of what to do with that 10BTC, I think this is an excellent project to
use it with.

We can donate further funds, but show me the concrete proposal first with scope
etc. Your keepbitcoinfree-announce post seemed to say you were going to post to
troll-talk, do so.

Speaking of donations, I saw someone with ~180BTC made a 10BTC donation to your
address. Good work! I also finally got a chance to see the video after dealing
with Monday obligations. It is excellent work and very professional. I heard
too through the grapevine about the response you got a the developer round
table at the conference. I would say Peter Vanesse seems way out of touch with
regard to privacy, and good that you got a small crowd after the discussion
talking about decentralization.

I'd be interested in slides of your talk if you have them. Do you know when
video is going to be made available by the foundation?
 
> In addition a video advocating to miners to run the software would be
> good too. The idea is non-political enough - at first glance - that the
> Bitcoin Foundation may be willing to help fund it through one of their
> grants. (the next cycle's deadline is june, probably too early, but the
> one after that isn't far away)

If you take my suggestion of being up-front about the decentralization reasons
for doing this, it will be interesting to see the response of the Foundation,
or for that matter, integrating those changes in the reference client anyway.
gpg: Signature made Tue 28 May 2013 05:43:38 AM GMT using RSA key ID 2636188F
gpg: Good signature from "John Dillon <[email protected]>"

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
> What are your thoughts on scamcoins?

Everything but namecoin and maybe litecoin is a scamcoin and they deserve to
die.

> I might have a project for you...


gpg: Signature made Sun 07 Jul 2013 11:24:50 PM GMT using RSA key ID 2636188F
gpg: Good signature from "John Dillon <[email protected]>"

gpg: encrypted with 4096-bit RSA key, ID 0753963A, created 2013-07-03
      "[email protected] <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
Content-Type: multipart/signed;
   boundary="Apple-Mail=_76C11B8F-5F49-418B-93E5-8B41E8442FE7";
   protocol="application/pgp-signature";
   micalg=pgp-sha1


--Apple-Mail=_76C11B8F-5F49-418B-93E5-8B41E8442FE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
   charset=us-ascii

[resending in case you didn't get this; have been having Mail trouble -- =
my GPG key is on the keyserver]

Hi John,

I saw Peter Todd's post recently that he received funding from you for =
work on replace-by-fee, and of course I've also seen your various =
rewards and bounties placed elsewhere. As I am also interested in =
helping to fund some of this work, I thought perhaps we could get to =
know each other and join forces as appropriate?

On my side we are working on Hive, which is a user-friendly Bitcoin =
wallet for OS X (and eventually Android). Most of my interests lie in =
speed and reliability rather than cutting-edge features. I saw your =
campaign Keep Bitcoin Free!... If you don't mind my asking, what else =
are you working on?

Cheers John,
-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411


--Apple-Mail=_76C11B8F-5F49-418B-93E5-8B41E8442FE7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
   filename=signature.asc
Content-Type: application/pgp-signature;
   name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)

iQIcBAEBAgAGBQJR9Y+JAAoJECAN2ykHU5Y6BnkQAKF3fDXXC9ST10W0jPRBASXT
GYUpeCZfEq54hinkGhVbOqrl0bChZ1kxtbgmXAbYjZ8Qp+UirR9eQQHL7Gea5frl
7I066/29cz8jDeguVXTEPaQIgFaWgQPMlmVctFdYHgX+HA3yH/e5Vufj3z+g3t8c
haP8Kk5wLs/UQ3SKigJe9hIl22ho/+kQuzM9E+RSGYTgOMf0ar+RtAwMIlz3un8H
jmSHBAqZq/1EaOeG/dP4SQ3UIx3V1sLOfSSOJftPSkJa5dmwkWdFIDQ3+NT6sYHv
yWbdfLC1oiomTJQbhMNvKP/rrDgVblk44WJR+6yaO3XuzTuOojVIiwoRzOMVnIwl
rP9SKIMojOj+iZiZImgH6mlD2ldO97B78Jn3R7sMwlVayI+dh4+SimJmzNawyZds
xV6xcvK6jAUmYfM0ooZJoP6T+yovBjv6EA4dubb4Di5PRvlYQYAyS54VgrAoCopE
xIrre8nX7JGHHroLYvO2iSq4ZSAq3imR8yK/biS1iw9/aJBWYanZcXCEa/suU4q1
K77hrcSvTfYEIdXNZzrBGSP+Vm7DIhO1dtZxyZqkUx+UZeMhjWgW1YE5Mm5zwD6h
rUdBEFgOSNikWL+XHrDjnQ/+Hni45HeujZ2TyX9ZAcsCS4UXEA50N9aJk/bQPqwM
Zkongxmjc/Ty4Cwp8OcP
=b8B6
-----END PGP SIGNATURE-----

--Apple-Mail=_76C11B8F-5F49-418B-93E5-8B41E8442FE7--

gpg: encrypted with 4096-bit RSA key, ID 0753963A, created 2013-07-03
      "[email protected] <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
If you could, please use the "inline" mode for PGP. I know it is a bit
old-fashioned, but it is easier for me to use given that I use the gmail web
interface directly. Do keep using encryption though!

> Hi John,
>
> I saw Peter Todd's post recently that he received funding from you for =
> work on replace-by-fee, and of course I've also seen your various =
> rewards and bounties placed elsewhere. As I am also interested in =
> helping to fund some of this work, I thought perhaps we could get to =
> know each other and join forces as appropriate?

Good idea.
 
> On my side we are working on Hive, which is a user-friendly Bitcoin =
> wallet for OS X (and eventually Android). Most of my interests lie in =
> speed and reliability rather than cutting-edge features. I saw your =
> campaign Keep Bitcoin Free!... If you don't mind my asking, what else =
> are you working on?

To clarify Keep Bitcoin Free! is Peter's project, not mine. I only contributed
funds and offered to let him use my name publicly as a supporter.

To be frank I have a lot of commitments in life between work and family, I
apologise for how I can only really reply on weekends at best, but I have been
following Bitcoin for years and consider it one of the most important
cryptography projects out there. I also am very concerned with the long-term
viability of Bitcoin with regard to preserving its decentralization and
privacy. (you may have seen my pull-request to add decentraliztion to the
foundation bylaws:
https://github.com/pmlaw/The-Bitcoin-Foundation-Legal-Repo/pull/4) Keeping
Bitcoin fast, reliable and accesible for your average user is definitely an
important part of my goals.

What are your thoughts on SPV/partial mode? Myself I would much prefer to see
the latter implemented than the former, you may have seen myself and Peter
talking about the DoS attack risks for SPV nodes. Where are you at with regards
to hiring a developer? I'll point out that Pieter Wuille is doing some of the
initial work required, and should be involved in some way. (doesn't have to be
financial) I noticed that Pieter was involving Peter in the discussion on IRC
about his initial steps.

Beyond partial mode I am also interested in seeing node-to-node encryption and
authentication, IE SSL for peer communications, an important feature for
preserving privacy against attackers who can wiretap. For instance right now
even if you have a node that you trust, maybe your server at your house, there
isn't a good way to have your wallet on your phone or laptop connect to that
server because the connection is completely unauthenticated and unencrypted.

FWIW adding SSL to the protocol is a fairly relatively non-invasive change. It
might be worthwhile to implement that first as a means to test the developers
you wish to hire to later implement partial mode. Thoughts?
gpg: Signature made Mon 05 Aug 2013 04:32:45 AM GMT using RSA key ID 2636188F
gpg: Good signature from "John Dillon <[email protected]>"

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
Private IRC chat:

11:11 Everyone knows John and I "know" each other, if anything I'd like my PGP signature on his key to
                  make the nature of that relationship understood.
11:11 good point
11:12 (I think half the people think you and John are the same person. )
11:12 ha, I know, I'll admit he kinda creeps me out a bit sometimes... he's admitted he reads all my
                  posts religiously
11:12 I keep thinking that maybe there is some crypto magic thing we can do to reduce the problem, but I
                 never seem to find one.
11:12 yours too BTW
11:13 it's like... "For fucks sake, can't you promote someone *elses* ideas for once?"
11:13 ugh
11:13 some kind of thing like ring signatures of all the signing parties for tokens of trust.
11:13 But then again, he's got money so...
11:14 I think part of the problem is just Bitcoin is solidly a hobby for him, and he sounds like he has
                  very little time, so he's picked a "cause" to champion, and has focused on it.

Though seriously, branch out a bit! I know time is an issue for you, but
still; I really do mean this in the nicest way.

--
'peter'[:-1]@petertodd.org
0000000000000082d95acaae7770435e04d7543252d2a62a414614c8882fd9e4
gpg: Signature made Tue 30 Jul 2013 05:22:49 PM GMT using DSA key ID 7F6D868C
gpg: Good signature from "Peter Todd (low security key) <[email protected]>"

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
On Tue, Jul 30, 2013 at 01:22:49PM -0400, Peter Todd wrote:

Also gavin too:

05:32 talked with gavin
05:32 he seems entirely uninterested in the connection exhaustion issue
05:32 doesn't think it's real
05:33 He also claims to not know of any more serious DoS issue enabled by bloom
05:33 and he wants to know where I heard of it
05:33 I told him I don't have permission to reveal that.
10:19 lol, awesome
10:19 bit of a joke there
14:37 what part is a joke?
14:45 oh
14:45 he also thinks jdillon and you are the same person!?
14:47 or rather a "sock puppet"
15:43 lol, I'm not surprised - I was talking about that with gmaxwell earlier too

Sheesh.

I'm going to write a tool to exploit the connections/bloom io thing BTW, so
don't go and offer any rewards for it please... Lets see what the reaction of
those involved is without any further drama. FWIW gmaxwell was pointing out
recently that by seeming to attack Mike you'll give him more political sway,
not less, by letting him hide behind that rather than address tech issues;
gmaxwell's opinion is that Mike doesn't have any political sway anyway.

--
'peter'[:-1]@petertodd.org
0000000000000078b07150e0992a84dcd45866d5d998f67181b8faabd04d23da
gpg: Signature made Thu 01 Aug 2013 10:35:56 PM GMT using DSA key ID 7F6D868C
gpg: Good signature from "Peter Todd (low security key) <[email protected]>"

gpg: encrypted with 2048-bit RSA key, ID 0FBEF185, created 2012-04-25
      "Peter Todd <[email protected]>"
gpg: encrypted with 2048-bit RSA key, ID 38254DA8, created 2012-05-31
      "John Dillon <[email protected]>"
> On Tue, Jul 30, 2013 at 01:22:49PM -0400, Peter Todd wrote:
>
> Also gavin too:
>
> 05:32 talked with gavin
> 05:32 he seems entirely uninterested in the connection exhaustion issue
> 05:32 doesn't think it's real
> 05:33 He also claims to not know of any more serious DoS issue enabled by bloom
> 05:33 and he wants to know where I heard of it
> 05:33 I told him I don't have permission to reveal that.
> 10:19 lol, awesome
> 10:19 bit of a joke there
> 14:37 what part is a joke?
> 14:45 oh
> 14:45 he also thinks jdillon and you are the same person!?
> 14:47 or rather a "sock puppet"
> 15:43 lol, I'm not surprised - I was talking about that with gmaxwell earlier too
>
> Sheesh.