summaryrefslogtreecommitdiff
path: root/40/79ab5c64fdcfbaec3bf8f41fd061355b3945b8
blob: 0783b91868e2196392a7e559d30f9864d447f883 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1UtEcp-0007rq-Vf
	for bitcoin-development@lists.sourceforge.net;
	Sun, 30 Jun 2013 10:12:56 +0000
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; 
Received: from outmail149080.authsmtp.com ([62.13.149.80])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UtEcm-0000MS-PJ for bitcoin-development@lists.sourceforge.net;
	Sun, 30 Jun 2013 10:12:55 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
	r5UACil0018623; Sun, 30 Jun 2013 11:12:44 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r5UACeYY065591
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Sun, 30 Jun 2013 11:12:42 +0100 (BST)
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)
X-Server-Quench: 9a66bfa7-e16d-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdQIUEkAaAgsB AmUbWlVeUV97XWA7 bAxPbAVDY01GQQRq
	WVdMSlVNFUsqBHlw dUt3Oxl0cgBPeTBy ZUBlXD5SDUJ8JxAs
	RVMBFGtSeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA4zBDkk QAsLGWdnOFABWyQZ
	LgBuI0VUEEsfO1g2 LRMtVEkbLxgKaEVV G0BABjMRIF9JTSs3 BgRbWwgZCjI1
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1UtEcm-0000MS-PJ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop
 client on bitcoin.org
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 30 Jun 2013 10:12:56 -0000


--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--