Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 173.246.101.161 as permitted sender)
	client-ip=173.246.101.161;
	envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; 
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
In-Reply-To: <201108042042.55214.andyparkins@gmail.com>
References: <201108041423.14176.andyparkins@gmail.com>
	<201108041922.16956.andyparkins@gmail.com>
	<1312483196.3109.38.camel@Desktop666>
	<201108042042.55214.andyparkins@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1";
	protocol="application/pgp-signature";
	boundary="=-dtd5I49CEd1OjQn1bijA"
Date: Thu, 04 Aug 2011 22:33:29 +0200
Message-ID: <1312490009.3109.45.camel@Desktop666>
Mime-Version: 1.0
Subject: Re: [Bitcoin-development] Double spend detection to speed up
 transaction trust
Precedence: list


--=-dtd5I49CEd1OjQn1bijA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-08-04 at 20:42 +0100, Andy Parkins wrote:
> On Thursday 04 August 2011 19:39:56 Matt Corallo wrote:
>=20
> > But why? It results in slightly more network traffic which is exactly
> > what we don't want, and it adds yet another message people have to know
> > about.
>=20
> "Slightly" is an understatement.  It add more network traffic for every=
=20
> double spend attempt.  Which don't happen very often.
Exactly, why add more network traffic for something that you can get
better without doing that?
>=20
> Also, I'm not proposing a new message, heaven forbid that we add a new=
=20
> message type, I'm proposing that we do this:
>=20
>  enum
>  {
>      MSG_TX =3D 1,
>      MSG_BLOCK,
> +    MSG_DOUBLESPEND,
>  };
>=20
> Also, people don't "have" to know about it.  And it's not "people" it's a=
n=20
> addition to the _one_ official client.  _and_ it's backward compatible=
=20
> because if they don't know about it, nothing changes... the TX gets dropp=
ed=20
> just as it is now.
Again though, adding more crap to the protocols is something we want to
avoid, especially if it offers no gain.
>=20
> > > I think you've missed the point.  Double spend transactions that ente=
rs
> > > the network at two reasonably evenly connected points are each only
> > > seen by half the network, since the first one locks out the second
> > > from propagation.
> >=20
> > No one cares about what the network thinks is the right transaction, it=
s
> > only what miners believe that matters.
>=20
> They do care because the network as a whole is what makes the eventual=
=20
> decision about which is the block-chain-to-rule-them-all.  Chain forks, a=
nd=20
> eventual reorgs are also far less disruptive when each leg of a double sp=
end=20
> isn't on each potential chain.  "Half the network" includes half of the=
=20
> miners.  It's perfectly possible for half the miners to be working on one=
=20
> leg, half on the other.  That means it's 50/50 which leg eventually gets=
=20
> confirmed.
Nope, the network decides nothing, only the miners decide.
>=20
> > Even if the vending machine doesn't keep the full chain and doesn't
> > accept incoming connections, its still the target node.  What other
> > nodes on the network think doesn't matter as long as you get the target
> > to think a transaction that won't be confirmed will be.  If it doesn't
> > accept incoming connections you want to find nodes that do that are
> > connected to your target.
>=20
> Well that's true enough; but how on earth you're going to identify an IP=
=20
> address of a particular vending machine that isn't accepting incoming=20
> connections is beyond me.  If it is a target it's pretty close to invisib=
le.
Then your whole attack scenario is broken and it becomes a 50/50 (or
more likely less) guess.
>=20
> > Its much easier to create than to change the network code to relay info
> > on double-spend transactions.
>=20
> What?  It's easier to trigger massive adoption and organisation of an=20
> inherently disorgainsed network of miners than it is to write a few lines=
 of=20
> code?  If that's true, then the bitcoin source is even more impenetrable=
=20
> than I imagine.
No, its easier for people who care to make sure they are peered with
well-connected nodes than for us to change the network protocol.
>=20
> > > Well that's what happens now.  But that doesn't help the poor sap who=
's
> > > just handed over some goods.  I want it so that small businesses can
> > > use the client to give them practical answers instead of this
> > > "0/unconfirmed" stuff which requires understanding of the system.
> >=20
> > No, thats not what happens now.  Currently if your node gets a
> > transaction which conflicts with one it already knows about, it silentl=
y
> > drops it without a second thought.  My point is if you actually dealt
> > with such cases and made good connections, you would be able to prevent
> > double spends nearly perfectly.
>=20
> It's not about prevention, they are already prevented.  It's about=20
> detection.  Quickly.
Yep, which is what my suggestion does.
>=20
> > > I'm not really trying to prevent double spends -- bitcoin _already_
> > > prevents double spends.  Also: the only difference between your
> > > suggestion (don't drop) and my suggestion (don't drop but mark with
> > > MSG_DOUBLESPEND) is a single number in the inv.  I really don't get
> > > the objection.
> >=20
> > No, my suggestion is not to relay the second transaction.  The second
> > transaction should continue to not be relayed as it currently is,
> > however receiving such a transaction should trigger the node to notify
> > the user that the transaction should not be accepted until it makes it
> > into a block (in fact, you could already do this if you implemented a
> > debug.log parser and made well-placed connections).
>=20
> How is this second transaction going to end up anywhere but on a few=20
> isolated nodes if it isn't propagated?  The only way _both_ can be in a p=
ool=20
> is if they are both received.  If they aren't both forwarded then it won'=
t=20
> be in most pools.  If it isn't in most pools then which how is the releva=
nt=20
> user going to get notified?
If it only ends up on a few isolated nodes, then you dont care as the
ones that you dont know about will never be confirmed.  If it ends up on
a node you peer with, you will be able to fetch both transactions and
then you know about the double spend.  Hence why you have to have
well-connected peers.
>=20
> > Bitcoin is absolutely still an experiment and no one thinks that any
> > kind of future is guaranteed.  This was not meant as an argument, but
>=20
> If it's still an experiment why is there such huge objection to pretty mu=
ch=20
> every change anyone proposes?  Bitcoin is one of the most conservative=
=20
> projects I've ever seen, even for the most passive of changes.  I can=20
> understand wanting to prevent potential financial loss, but it's not like=
=20
> I'm suggesting we start broadcasting private keys on the network.
No one is against making changes if they offer clear incentive.  This
one doesnt.  Additionally, whether its an experiment or not, people have
money stored in it and a mistake could mean the loss of tens of
thousands or hundreds of thousands of dollars.  Lastly, no one is (yet)
paid to work on Bitcoin, sorry the developers dont spend enough time
merging for your liking.
>=20
> > simply as "if bitcoin does end up going somewhere, it will likely be
> > done like this".
>=20
> When you're using it as an argument for why a suggestion is unnecessary=
=20
> that's not how it sounds.
>=20
> Anyway; it's fine.  You don't think it's a good idea; and I suspect none =
of=20
> the other official client developers will either, they don't like protoco=
l=20
> changes.  So be it; it was only a suggestion and I'm a nobody around here=
.
I think having the ability to detect double-spends rapidly is something
that is needed, my point is that you already can with relatively little
effort, no point adding more stuff to make it no easier.

Matt

--=-dtd5I49CEd1OjQn1bijA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

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

iQIcBAABAgAGBQJOOwINAAoJEBrh01BD4I5UYSEQAK17GS7ZD6+n73DqrCCybOPS
aZ1G2OLjc23Wb4k2JLhPkuK3lQkVuG0aiQ9jXnrFz2n6fMLGqn5ukZt55IJ5UtZ5
Us3KyQkoBvq0YkKi4j3ER9BIs7PFyRWMsCBtnZnNBwZqD5RzM7YOUT4DxqorHx5s
TLtO7TBAFGJySoy3atYnvi87zABIW/1A0CtniBe+YHxiteJNjJZZA2o7mAi1Od01
H2DKQDkWqaJcKuecNfV2r54Q5a+KPfr1kAQL4OAOUIPkST1vhSBT2UymaqF2nebn
7EwK0dlvN0MGokQC77gevrfVWiblpFv8g3ZeoPXD34YHiyO+qV8CdMkUC/q7y6+e
pfxsBQD/moSAF2R+5X+Gug2k8KZ95nYKEjaEVGDP+NqF/l11IjloEs9CtMrB8Kye
lAKMtN5VOjkLEhpYy9wE5ne68Rls7snhrt89Sl8ZL35yY1MXQ47QeEOGzKrPQe35
OHmbtnd0O0tzQFGdxR0Y+f9JldnDbO3VXTdtoRl+O9pKlMH8/ouMxVJmfHzjPEFK
YQ7ar4f1touhMK2Cmtdcwt9bUZWok4NAvaHfsxoEy9aZkdqFqCW/XnhETIJ0pgMr
mPruHbmIJoOQMKA0qONU3YCIkQVAqHvfkLi6mYqrJCmKn4khhunbV7tEWzV4hMCk
TUTheCnJUbs0MzZVQCnq
=yHcC
-----END PGP SIGNATURE-----

--=-dtd5I49CEd1OjQn1bijA--