Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.80 as permitted sender)
	client-ip=62.13.149.80; envelope-from=pete@petertodd.org;
	helo=outmail149080.authsmtp.com; 
Date: Sun, 30 Jun 2013 06:12:39 -0400
From: Peter Todd <pete@petertodd.org>
To: John Dillon <john.dillon892@googlemail.com>
Message-ID: <20130630101239.GA1142@savin>
References: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com>
	<CAAS2fgTka6Dw94V0-vHBHxG=zadu9EmhKmfVm7Y_dQUUgrTf6w@mail.gmail.com>
	<CANEZrP2gv2qus1CKTTSFMYcNQDbrSctKmA03YE_eZFDTQsQhXw@mail.gmail.com>
	<CAPaL=UV6vhVK6W0FiVoqM+=9C9TAUXVKwbuynq3NZYFzFR8TTQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF"
Content-Disposition: inline
In-Reply-To: <CAPaL=UV6vhVK6W0FiVoqM+=9C9TAUXVKwbuynq3NZYFzFR8TTQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop
 client on bitcoin.org
Precedence: list


--h31gzZEtNLTqOjlF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 28, 2013 at 10:09:16AM +0000, John Dillon wrote:
> true transaction origins. Which reminds me, again, we need node-to-node
> connections to be encrypted to at least protect against network-wide
> passive sniffiing.

Agreed.

Speaking of, I may have missed it but as far as I can tell Bitmessage
doesn't encrypt node-to-node communications, a serious oversight. Any
attacker that can sniff a large fraction of the network, like the NSA,
can easily use this to track down the originating node of any message,
just like they can do with Bitcoin.

> For what it is worth I ran a double-spend generator a month or so ago
> against the replace-by-fee node that Peter setup and I found that a
> small number of the double-spends did in fact appear to be mined under
> replace-by-fee rules.

Ah! I had a feeling that might be you. Were you the person who was
creating the 1BTC fee transactions as well?

> Though possibly just an artifact of unusually slow transaction
> propagation it appeared that about 0.25% of hashing power was following
> replace-by-fee rules. (not including transactions involving gambling, I
> know Eligius and perhaps others block such transactions from their
> mempools making double-spends easy to accomplish by including
> Satoshidice outputs)

I just got an email from someone saying they had a few Avalons with that
patch installed actually; that was probably them.

> I'm actually surprised by that figure myself given Peter Todd and I
> haven't made a serious attempt yet to get miners to use replace-by-fee
> rules. An interesting experiment would be to advertise that money is
> being given away by such a tx generator in the mining forum, although I
> would prefer to see solid mempool support for the "scorched-earth"
> double-spend countermeasure first; Peter sounds like he has some great
> ideas there, although as usual I am seeing very little in the way of
> code. :)

Keep in mind it's not just the mempool that needs changing - the network
protocol semantics need to change too. For the "scorched-earth" strategy
to work you need nodes tell their peers about the total fees a
transaction has attached in addition tot he tx hash. Essentially you are
advertising to your peers what would right now be an orphan, and your
peers need to recursively get dependencies; I'm sure there's a bunch of
edge cases there that would be need to thought out carefully. It's
useful for a lot of things though, for instance when a zero-fee,
zero-priority tx is given to a merchant who now wants to tell miners to
mine it anyway due to a child tx.

What I'd recommend actually for the nearer term is just adding recursive
fee evaluation with a depth*breadth anti-DoS limit, adding the rpc and
GUI adjfee and canceltx commands, adding better wallet support for
conflicts, (someone is already workng on this) and adding a service bit
with preferential peering.

By preferential peering I mean you set aside a portion of your outgoing
peer slots for peers with certain bits set and only fill those slots
with those peers. In addition you can have DNS seeds return peers with
specified service bits set: x0000000000000003.v1.seed.petertodd.org
could be nodes with the first and second bits set. (we might want to
define the upper 8 service bits as a service bit version field so we can
redefine the other 56 in the far off future if required)

--=20
'peter'[:-1]@petertodd.org
00000000000000b2b1f2ca2a2f937c2d93c41a5d089e1d3d4fe6bb663dd25db5

--h31gzZEtNLTqOjlF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJR0ASXAAoJECSBQD2l8JH7JbUH/3M849jw72EpVW4xwvcWs+kI
JeY6i3uXMwFZqwRomT5sbQ96EVnK/sdpFFce4gWmsJzehWF2quIc3E60kPHr8pLu
JAnsSPY3PwcTbMgYad5oYMujNt7YcXa24WIHR3WNZCYQVeh9B3I42k97er9evAtB
JsAUqs0ZFfvQ2l+zHGJegXd5A/uB4ReXQ8Zt9Jr4auoitHaJFuxVzqZMuynJwr5s
PDSCax/tuGk074+Ljlbp3KwQDXm4pP4zmqZ//tJyz3DO/nPcDKU2YWe3e0VU8Qd6
B2RlKKScJf9LIqpYQjNekQKqBiY0YZLl8O+kzdIcyKWX+6XjoNcR5RbVLsI3XmI=
=V7NF
-----END PGP SIGNATURE-----

--h31gzZEtNLTqOjlF--