From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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® 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