📅 Original date posted:2012-04-14
📝 Original message:On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote:
> >> Furthermore, many of these ideas -- like sending TX's directly to the
> >> merchant -- involve far more direct payee<->payer communication on the
> >> part of the wallet client than is currently envisioned
> >
> > Yes, though it's worth remembering that the original Bitcoin design
> > did have participants communicate directly. When I talked with Satoshi
> > in 2009 he saw the pay-to-IP-address mode imagined as the normal way
> > to make payments, with pay-to-address being used as a kind of backup
> > for when the recipient was offline.
> >
> > In the end that's not how things evolved, but it the pendulum could
> > easily swing back the other way.
>
> But I also have a "gut feeling" that these sorts of payments and
> direct communication should be done via a wholly separate protocol
> than the bitcoin P2P protocol. Doing p2ip as it was done originally,
> inside the bitcoin P2P protocol, was a mistake. Extensible as it is,
> I think a better job -- and faster evolution -- can be done with a
> separate protocol on a separate port.
>
> Some HTTP derivative would probably make life easier for mobile
> payments and firewalled scenarios, and for client->merchant
> communications, for instance.
Have you ever read https://gist.github.com/1237788 ?
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 10:04:23
in reply to nevent1q…l76p
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 10:04:23Event JSON
{
"id": "6996259625a8e7883dcbce4c885480af5a301797664f9202bb227f646215bb9f",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686132263,
"kind": 1,
"tags": [
[
"e",
"5f0cc6578a9ca4b7b0857c070ede1826db3227f161e70524c04566da5c5a56a8",
"",
"root"
],
[
"e",
"74d5a7fa67ef69d7063db157093abffe9b74b6818a348ee9c4208ea410c6eef9",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2012-04-14\n📝 Original message:On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote:\n\u003e \u003e\u003e Furthermore, many of these ideas -- like sending TX's directly to the\n\u003e \u003e\u003e merchant -- involve far more direct payee\u003c-\u003epayer communication on the\n\u003e \u003e\u003e part of the wallet client than is currently envisioned\n\u003e \u003e\n\u003e \u003e Yes, though it's worth remembering that the original Bitcoin design\n\u003e \u003e did have participants communicate directly. When I talked with Satoshi\n\u003e \u003e in 2009 he saw the pay-to-IP-address mode imagined as the normal way\n\u003e \u003e to make payments, with pay-to-address being used as a kind of backup\n\u003e \u003e for when the recipient was offline.\n\u003e \u003e\n\u003e \u003e In the end that's not how things evolved, but it the pendulum could\n\u003e \u003e easily swing back the other way.\n\u003e \n\u003e But I also have a \"gut feeling\" that these sorts of payments and\n\u003e direct communication should be done via a wholly separate protocol\n\u003e than the bitcoin P2P protocol. Doing p2ip as it was done originally,\n\u003e inside the bitcoin P2P protocol, was a mistake. Extensible as it is,\n\u003e I think a better job -- and faster evolution -- can be done with a\n\u003e separate protocol on a separate port.\n\u003e \n\u003e Some HTTP derivative would probably make life easier for mobile\n\u003e payments and firewalled scenarios, and for client-\u003emerchant\n\u003e communications, for instance.\n\nHave you ever read https://gist.github.com/1237788 ?\n\n-- \nPieter",
"sig": "2b27de2e85ec45c7a0d6aff2ab8777d2ba42733ae422ef8c3cee833642d07cb8ad77ac9ced0bc889933256d404670505288e65c9308cff945f7930e945cc97f2"
}