📅 Original date posted:2011-08-04
🗒️ Summary of this message: The discussion is about adding an extra type to the inventory list to prevent double-spending in Bitcoin transactions, making it easier for small businesses to use the client.
📝 Original message:On Thursday 04 August 2011 18:45:17 Matt Corallo wrote:
> There really is no reason to add the extra network complexity for this.
It's hardly complex. It's exactly as it is now, with exactly the messages
there are now, but with an extra type added to the inventory list. A
transaction _already_ propagates using inv messages with MSG_TX, is it
really so "complex" to add MSG_DOUBLESPEND to the enum? What's more it's
backward compatible because clients that don't understand MSG_DOUBLESPEND
will ignore the inv ending up exactly where we are now.
> First of all (as you point out) no one buying a Ferrari will refuse to
> wait an hour for the payment to confirm. If someone is attempting to
> pull a similar trick on, say, a vending machine however it might make
> sense. But that changes the equation. In order for these two scammers
Vending machine, newspaper salesman, ice creams, a beer. The list of small
vendors is endless. I picked Ferrari's out of the air.
> to pull it off, some effort is required in terms of communicating the
> time to send the coins and the nodes of the targets (vending machines or
> whatever) must be figured out. So now its less of "make it impossible"
> and more of "make it really hard to the point that it is no where near
> worth the effort".
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.
> Lets simplify the scenario a bit so that one scammer can pull it off.
> Send one copy of your transaction to the target node and another to
> large mining operations so that the payment transaction is considered
> invalid to miners and a transaction which pays you is confirmed.
There is no "target" node. There is only a vending machine listening for
transactions. It's unlikely that vending machines will even have incoming
connections enabled. They certainly won't be keeping a full copy of the
block chain or be mining.
> If you are the vending machine, your goal is not to figure out any
> transactions which are yours, but to figure out which transactions which
It is a little bit. Your job is _first_ to figure out which are yours;
then, as you say, to see which are going to be confirmed. Well: once you've
seen a transaction on the net you know it's going to be confirmed... unless
a matching double spend transaction was accepted by the next miner to
generate a block.
> are yours are going to be confirmed. So, you peer with the largest
> miners (a "Bitcoin backbone" or large miners and merchants has been
> suggested over and over again and really hasn't happened) and modify
It hasn't happened, and yet it seems to be that this non-existant thing is
your solution to the problem.
> your client to, instead of dropping transactions which are
> double-spends, keep both in memory pool and consider them both invalid
> until one of them confirms.
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.
> This will work with 1, 2, or n scammers, doesn't require any additional
> network messages, and offers just as good, if not better security over a
> double spend message.
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.
> Additionally, in the future, when(/if) Bitcoin payment processors exist,
"In the future" is all well and good. What if there is no future because
bitcoin is still too difficult for average joe to use?
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
Andy Parkins [ARCHIVE] /
npub1nx…7wjrv
2023-06-07 02:12:05
in reply to nevent1q…pc8k
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 02:12:05Event JSON
{
"id": "5604cec7767af960df35726d05d2b45ab29b5a9a5636dda28b62d66e2ee22866",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686103925,
"kind": 1,
"tags": [
[
"e",
"f7bac66510d148bc7cd5c36f79897fafe3410a2bc9df45238a65f8429b9407f0",
"",
"root"
],
[
"e",
"25fea2cf4113879ea7a2ce43b8c597d16610ce8c095bbb68e5f4097f112fa04d",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2011-08-04\n🗒️ Summary of this message: The discussion is about adding an extra type to the inventory list to prevent double-spending in Bitcoin transactions, making it easier for small businesses to use the client.\n📝 Original message:On Thursday 04 August 2011 18:45:17 Matt Corallo wrote:\n\u003e There really is no reason to add the extra network complexity for this.\n\nIt's hardly complex. It's exactly as it is now, with exactly the messages \nthere are now, but with an extra type added to the inventory list. A \ntransaction _already_ propagates using inv messages with MSG_TX, is it \nreally so \"complex\" to add MSG_DOUBLESPEND to the enum? What's more it's \nbackward compatible because clients that don't understand MSG_DOUBLESPEND \nwill ignore the inv ending up exactly where we are now.\n\n\u003e First of all (as you point out) no one buying a Ferrari will refuse to\n\u003e wait an hour for the payment to confirm. If someone is attempting to\n\u003e pull a similar trick on, say, a vending machine however it might make\n\u003e sense. But that changes the equation. In order for these two scammers\n\nVending machine, newspaper salesman, ice creams, a beer. The list of small \nvendors is endless. I picked Ferrari's out of the air.\n\n\u003e to pull it off, some effort is required in terms of communicating the\n\u003e time to send the coins and the nodes of the targets (vending machines or\n\u003e whatever) must be figured out. So now its less of \"make it impossible\"\n\u003e and more of \"make it really hard to the point that it is no where near\n\u003e worth the effort\".\n\nI think you've missed the point. Double spend transactions that enters the \nnetwork at two reasonably evenly connected points are each only seen by half \nthe network, since the first one locks out the second from propagation.\n\n\u003e Lets simplify the scenario a bit so that one scammer can pull it off.\n\u003e Send one copy of your transaction to the target node and another to\n\u003e large mining operations so that the payment transaction is considered\n\u003e invalid to miners and a transaction which pays you is confirmed.\n\nThere is no \"target\" node. There is only a vending machine listening for \ntransactions. It's unlikely that vending machines will even have incoming \nconnections enabled. They certainly won't be keeping a full copy of the \nblock chain or be mining.\n\n\u003e If you are the vending machine, your goal is not to figure out any\n\u003e transactions which are yours, but to figure out which transactions which\n\nIt is a little bit. Your job is _first_ to figure out which are yours; \nthen, as you say, to see which are going to be confirmed. Well: once you've \nseen a transaction on the net you know it's going to be confirmed... unless \na matching double spend transaction was accepted by the next miner to \ngenerate a block.\n\n\u003e are yours are going to be confirmed. So, you peer with the largest\n\u003e miners (a \"Bitcoin backbone\" or large miners and merchants has been\n\u003e suggested over and over again and really hasn't happened) and modify\n\nIt hasn't happened, and yet it seems to be that this non-existant thing is \nyour solution to the problem.\n\n\u003e your client to, instead of dropping transactions which are\n\u003e double-spends, keep both in memory pool and consider them both invalid\n\u003e until one of them confirms.\n\nWell that's what happens now. But that doesn't help the poor sap who's just \nhanded over some goods. I want it so that small businesses can use the \nclient to give them practical answers instead of this \"0/unconfirmed\" stuff \nwhich requires understanding of the system.\n\n\u003e This will work with 1, 2, or n scammers, doesn't require any additional\n\u003e network messages, and offers just as good, if not better security over a\n\u003e double spend message.\n\nI'm not really trying to prevent double spends -- bitcoin _already_ prevents \ndouble spends. Also: the only difference between your suggestion (don't \ndrop) and my suggestion (don't drop but mark with MSG_DOUBLESPEND) is a \nsingle number in the inv. I really don't get the objection.\n\n\u003e Additionally, in the future, when(/if) Bitcoin payment processors exist,\n\n\"In the future\" is all well and good. What if there is no future because \nbitcoin is still too difficult for average joe to use?\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "16bc5c85b61af7d85b4e97e41769d8a83dab387f71fef1a2784639d6060ff76cb993c1488d64f166855c70b6b21dbd4755cb8051c7a460575f3d097b94144474"
}