path: root/f9/f745778e43b24b950c84c209a6001b453c10fc

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <andrew@andrewschaaf.com>) id 1Qp4cn-0005F5-QR
	for bitcoin-development@lists.sourceforge.net;
	Thu, 04 Aug 2011 20:34:37 +0000
Received-SPF: softfail (sog-mx-4.v43.ch3.sourceforge.com: transitioning domain
	of andrewschaaf.com does not designate 209.85.216.182 as
	permitted sender) client-ip=209.85.216.182;
	envelope-from=andrew@andrewschaaf.com;
	helo=mail-qy0-f182.google.com; 
Received: from mail-qy0-f182.google.com ([209.85.216.182])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Qp4cm-0007PD-OK
	for bitcoin-development@lists.sourceforge.net;
	Thu, 04 Aug 2011 20:34:37 +0000
Received: by qyk9 with SMTP id 9so1310965qyk.13
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 04 Aug 2011 13:34:31 -0700 (PDT)
Received: by 10.224.17.144 with SMTP id s16mr1015854qaa.233.1312488465040;
	Thu, 04 Aug 2011 13:07:45 -0700 (PDT)
Received: from [192.168.0.182] (rrcs-72-43-172-2.nyc.biz.rr.com [72.43.172.2])
	by mx.google.com with ESMTPS id q9sm1584129qct.20.2011.08.04.13.07.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 04 Aug 2011 13:07:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=windows-1252
From: Andrew Schaaf <andrew@andrewschaaf.com>
In-Reply-To: <201108042042.55214.andyparkins@gmail.com>
Date: Thu, 4 Aug 2011 16:07:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <82CEB610-9821-4928-8A13-30088A59223C@andrewschaaf.com>
References: <201108041423.14176.andyparkins@gmail.com>
	<201108041922.16956.andyparkins@gmail.com>
	<1312483196.3109.38.camel@Desktop666>
	<201108042042.55214.andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
X-Mailer: Apple Mail (2.1244.3)
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
X-Headers-End: 1Qp4cm-0007PD-OK
Subject: Re: [Bitcoin-development] Double spend detection to speed up
	transaction trust
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: Thu, 04 Aug 2011 20:34:37 -0000


One double-spend fighting option is for each mining pool to offer a =
realtime feed of accepted TXs.

I am hoping to complete the following later this month:
=09
	(1) A minimal bitcoind patch that writes raw accepted TXs and =
BLOCKs to stdout with a prefix of ("2naXaRQj--TX\n%d\n" % (data_length))
		(Proof-of-concept done =97 I'll submit a pull request =
with "--print-accepted-txs-and-blocks" when I get a chance to clean it =
up)
=09
	(2) A minimal NodeJS app which invokes bitcoind as a subprocess, =
parses the TXs and BLOCKs, and offers a realtime feed



On Aug 4, 2011, at 3:42 PM, 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.
>=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 an=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 =
dropped=20
> just as it is now.
>=20
>>> I think you've missed the point.  Double spend transactions that =
enters
>>> 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, =
its
>> 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, and=20
> eventual reorgs are also far less disruptive when each leg of a double =
spend=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.
>=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 =
invisible.
>=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.
>=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 =
silently
>> 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.
>=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 pool=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 =
relevant=20
> user going to get notified?
>=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 =
much=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.
>=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 =
protocol=20
> changes.  So be it; it was only a suggestion and I'm a nobody around =
here.
>=20
>=20
>=20
> Andy
>=20
> --=20
> Dr Andy Parkins
> andyparkins@gmail.com
>=20
> =
--------------------------------------------------------------------------=
----
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.=20
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development