Matt Corallo [ARCHIVE] on Nostr: ๐
Original date posted:2011-12-16 ๐๏ธ Summary of this message: Proposal to use ...
๐
Original date posted:2011-12-16
๐๏ธ Summary of this message: Proposal to use Bitcoin's existing code for transactions to IP addresses for dynamic address lookup. Suggestions include extending the protocol and enabling DNS lookups.
๐ Original message:On Thu, 2011-12-15 at 13:59 -0600, theymos wrote:
> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete user at server.com handling:
I'm not against this, but I think its way overcomplicated when compared
to the DNS or HTTPS methods.
> - Extend the protocol so that "reply" messages can be signed by a fixed
> public key
> - Extend "checkorder" messages so they can specify an account to
> send BTC to. Or standardize on how to put the account into the
> message field.
OK, not too debatable, but considering how terrible bitcoind's account
handling is, the second might not be easy to get right...
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
> also be used here to avoid having to use the IP transaction protocol
> sometimes. The public key for signing "reply" messages can be gotten
> from TXT records. This will be safe with DNSSEC and Namecoin. With
> plain DNS Bitcoin could take a SSH-like approach and ask the user to
> verify the public key the first time it is used, remembering it later.
This is where I think this method becomes way overcomplicated. Not only
do you have to update the IP-Transaction code, but now you have to
implement the full DNS System that is the other option as well. Note
that to make this secure, we have to have a full DNSSEC-capable resolver
built-into bitcoind (there are libs, but it has to happen). Yes you can
ask the user "does this fingerprint look right to you? Y/N" but that
always opens you up to a ton of users getting screwed out of coins and I
don't think it should be enabled, except in bitcoind, and since the main
target of this whole alias system is bitcoin-qt users, well...
Matt
Published at
2023-06-07 02:43:29Event JSON
{
"id": "4b62ab68e13791d79a9431bf9efbd5154482df25c898b26a971c3afc292614ec",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686105809,
"kind": 1,
"tags": [
[
"e",
"247922e9146ee6b54a634fc05ad7a489892c01debcd0510d008be95a47f6db80",
"",
"root"
],
[
"e",
"6d6b9532d9fa431824a8331b224985ca5a9cd194c30c43f9887a7d7ab57e2b33",
"",
"reply"
],
[
"p",
"77979142f3407f28a5a71956e33342e486ee981e614e0d2ea36ddaf27b8a5a67"
]
],
"content": "๐
Original date posted:2011-12-16\n๐๏ธ Summary of this message: Proposal to use Bitcoin's existing code for transactions to IP addresses for dynamic address lookup. Suggestions include extending the protocol and enabling DNS lookups.\n๐ Original message:On Thu, 2011-12-15 at 13:59 -0600, theymos wrote:\n\u003e Bitcoin already has code and a protocol for transactions to IP\n\u003e addresses. Why not reuse that for dynamic address lookup? Just a few\n\u003e changes are necessary to enable complete user at server.com handling:\nI'm not against this, but I think its way overcomplicated when compared\nto the DNS or HTTPS methods.\n\u003e - Extend the protocol so that \"reply\" messages can be signed by a fixed\n\u003e public key\n\u003e - Extend \"checkorder\" messages so they can specify an account to\n\u003e send BTC to. Or standardize on how to put the account into the\n\u003e message field.\nOK, not too debatable, but considering how terrible bitcoind's account\nhandling is, the second might not be easy to get right...\n\u003e - Enable DNS lookups for IP transactions. The DNS-only proposals could\n\u003e also be used here to avoid having to use the IP transaction protocol\n\u003e sometimes. The public key for signing \"reply\" messages can be gotten\n\u003e from TXT records. This will be safe with DNSSEC and Namecoin. With\n\u003e plain DNS Bitcoin could take a SSH-like approach and ask the user to\n\u003e verify the public key the first time it is used, remembering it later.\nThis is where I think this method becomes way overcomplicated. Not only\ndo you have to update the IP-Transaction code, but now you have to\nimplement the full DNS System that is the other option as well. Note\nthat to make this secure, we have to have a full DNSSEC-capable resolver\nbuilt-into bitcoind (there are libs, but it has to happen). Yes you can\nask the user \"does this fingerprint look right to you? Y/N\" but that\nalways opens you up to a ton of users getting screwed out of coins and I\ndon't think it should be enabled, except in bitcoind, and since the main\ntarget of this whole alias system is bitcoin-qt users, well...\n\nMatt",
"sig": "ac41b69dcfae102a5e0f5af24e6b45ba782494a47034680a8dbc872e0886917b85eebc871c1cdae11b0617f18ccd88b2b1785048c0cf1d898858ea689344f97f"
}