Joel Joonatan Kaartinen [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-05 🗒️ Summary of this message: Bitcoin resends ...
📅 Original date posted:2011-08-05
🗒️ Summary of this message: Bitcoin resends wallet transactions with zero confirmations, and both sent and received transactions fall within the "wallet tx" superset. UDP packets with spoofed sender addresses are interesting, but unreliable. TCP over UDP is possible with UTP.
📝 Original message:On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote:
> Yes, that is correct. Bitcoin resends wallet transactions with zero
> confirmations, and both sent and received transactions fall within the
> "wallet tx" superset.
>
> TBH I had forgotten about the resend on the receiver side, though.
> It, of course, makes plenty of sense in the context of importing
> transactions from foreign sources, e.g. receiving transactions via a
> USB flash drive.
Could every node do the resends? Alternatively, could we implement a TOR
like tunneling system just for the first leg of the transactions
(overkill?). Then again, maybe just a TOR gateway if that's desired.
> > Drawok's suggestion about using UDP packets with spoofed sender addresses is
> > interesting, as UDP has another advantage; you can open up an "inbound" UDP
> > port on almost any NAT router without any UPNP magic: just send out an UDP
> > packet, the router will wait a certain time for answers (on a mapped port
> > number) and relay these back.
This is a nice idea but sounds rather unreliable.
> Well, it -is- possible to implement TCP over UDP <grin> The TCP
> connection sequence over UDP helps to work against spoofing, while UDP
> helps to open an inbound UDP port as you describe.
There's already an implementation of this, called UTP. If we do decide
that using UDP is worthwhile, this library is probably better than
implementing something ourselves.
- Joel
Published at
2023-06-07 02:11:37Event JSON
{
"id": "0b50175c3135cd3b1d64d145762ab599a37a41e14f3a7405248214281b42e3c8",
"pubkey": "d52a1b72551bba47beb14639a1b6f5e6cd98603ecbaaa6ab02031708d9cc4473",
"created_at": 1686103897,
"kind": 1,
"tags": [
[
"e",
"3fd0921829ed37c0f8350ddeea75079340fd443c86a6a3228d2e1e0ae90eb86b",
"",
"root"
],
[
"e",
"802d05bcb0262bf38164099f640bd067b6bfdcac936a2da1a025ee820b760d2e",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2011-08-05\n🗒️ Summary of this message: Bitcoin resends wallet transactions with zero confirmations, and both sent and received transactions fall within the \"wallet tx\" superset. UDP packets with spoofed sender addresses are interesting, but unreliable. TCP over UDP is possible with UTP.\n📝 Original message:On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote:\n\u003e Yes, that is correct. Bitcoin resends wallet transactions with zero\n\u003e confirmations, and both sent and received transactions fall within the\n\u003e \"wallet tx\" superset.\n\u003e \n\u003e TBH I had forgotten about the resend on the receiver side, though.\n\u003e It, of course, makes plenty of sense in the context of importing\n\u003e transactions from foreign sources, e.g. receiving transactions via a\n\u003e USB flash drive.\n\nCould every node do the resends? Alternatively, could we implement a TOR\nlike tunneling system just for the first leg of the transactions\n(overkill?). Then again, maybe just a TOR gateway if that's desired.\n\n\u003e \u003e Drawok's suggestion about using UDP packets with spoofed sender addresses is\n\u003e \u003e interesting, as UDP has another advantage; you can open up an \"inbound\" UDP\n\u003e \u003e port on almost any NAT router without any UPNP magic: just send out an UDP\n\u003e \u003e packet, the router will wait a certain time for answers (on a mapped port\n\u003e \u003e number) and relay these back.\n\nThis is a nice idea but sounds rather unreliable.\n\n\u003e Well, it -is- possible to implement TCP over UDP \u003cgrin\u003e The TCP\n\u003e connection sequence over UDP helps to work against spoofing, while UDP\n\u003e helps to open an inbound UDP port as you describe.\n\nThere's already an implementation of this, called UTP. If we do decide\nthat using UDP is worthwhile, this library is probably better than\nimplementing something ourselves.\n\n- Joel",
"sig": "688ce0cd068d3951f1667c87bc0979140c4b8d993d61aa2fc33ce327406509c368bda2bac36338cd2881b81a8dc27e3e2adc73a5f0216e7cb0b5bec02284691d"
}