📅 Original date posted:2012-11-29
📝 Original message:> I'd still like to understand the rationale for having the merchant
> broadcast the transaction
There are several reasons for this:
1) P2P network sockets are a limited resource and bringing up
connections to the network, whilst somewhat fast today, is not
guaranteed to be fast in future. Passing transactions to the merchant
for broadcast reduces the load on the P2P nodes because lots of thin
clients aren't any longer connecting and disconnecting when sending.
They only need to talk to the network when the user has received
money.
2) Some users may not have network connectivity at all. For example,
this happens quite often whilst traveling at Bitcoin conferences ;)
The solution, which Andreas and I prototyped in Berlin together, is
for the buyer to communicate only with the seller which can be done
over Bluetooth or WiFi Direct or some other mobile radio protocol.
Again, send only, but for the common case where you load up your
wallet before setting out and then buy things, it works OK.
4) A longer term reason - in time, people may choose to not broadcast
transactions at all in some cases. I think how network speed will be
funded post-inflation is still an open question. Assuming the simplest
arrangement where users pay fees, getting transactions into the chain
has a cost. In cases where you trust the sender to not double spend on
you, you may keep a fee-less transaction around "in your pocket". Then
when it's your turn to pay, you use some unconfirmed transactions to
do so. People pass around longer and longer chains of un-broadcast
transactions until a payment crosses a trust boundary, at which point
the receiver adds on their own transaction that spends back to himself
but with a fee, and broadcasts them all together as a unit. In this
way only people who genuinely need to fear double spends pay for
security.
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 10:42:07
in reply to nevent1q…t8sf
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 10:42:07Event JSON
{
"id": "758ad39150fe298d1844985d5e239e1d75fb9b9ae1b917042624de759d30aa15",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686134527,
"kind": 1,
"tags": [
[
"e",
"f5f2400f8aa8a7067be3d080f096fd7cbfeecdd6e589c178b85b63a9338150a5",
"",
"root"
],
[
"e",
"32b8f95c273e8e90c859b919a2d1550d277bb7e2fb4717a64923eadbc0f42a7c",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2012-11-29\n📝 Original message:\u003e I'd still like to understand the rationale for having the merchant\n\u003e broadcast the transaction\n\nThere are several reasons for this:\n\n1) P2P network sockets are a limited resource and bringing up\nconnections to the network, whilst somewhat fast today, is not\nguaranteed to be fast in future. Passing transactions to the merchant\nfor broadcast reduces the load on the P2P nodes because lots of thin\nclients aren't any longer connecting and disconnecting when sending.\nThey only need to talk to the network when the user has received\nmoney.\n\n2) Some users may not have network connectivity at all. For example,\nthis happens quite often whilst traveling at Bitcoin conferences ;)\nThe solution, which Andreas and I prototyped in Berlin together, is\nfor the buyer to communicate only with the seller which can be done\nover Bluetooth or WiFi Direct or some other mobile radio protocol.\nAgain, send only, but for the common case where you load up your\nwallet before setting out and then buy things, it works OK.\n\n4) A longer term reason - in time, people may choose to not broadcast\ntransactions at all in some cases. I think how network speed will be\nfunded post-inflation is still an open question. Assuming the simplest\narrangement where users pay fees, getting transactions into the chain\nhas a cost. In cases where you trust the sender to not double spend on\nyou, you may keep a fee-less transaction around \"in your pocket\". Then\nwhen it's your turn to pay, you use some unconfirmed transactions to\ndo so. People pass around longer and longer chains of un-broadcast\ntransactions until a payment crosses a trust boundary, at which point\nthe receiver adds on their own transaction that spends back to himself\nbut with a fee, and broadcasts them all together as a unit. In this\nway only people who genuinely need to fear double spends pay for\nsecurity.",
"sig": "63b6b93809943cd9094f529e0675b855ef7b7ae758cb7cbff24f50b17a3dfac07f5dde0a1b45f52ef49e6d8161b11646f92df456685b9220b293bd78c9330b38"
}