<unnamed>

Public Key

npub1ws7kd2knmz65wpdh2xsymr85e2lkuqhktkvfq0a8h9snt9td96ksafv6kh

Profile Code

nprofile1qqs8g0tx4tfa3d28qkm4rgzd3n6v40mwqtm9mxys87nmjcf4j4kjatgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsgsdh3s

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 04:50:13 CEST

- reply

📅 Original date posted:2011-12-20
🗒️ Summary of this message: Bitcoin client "satoshi" supports TOR use with proxy option, and developers may integrate TOR functionality into the client in the future.
📝 Original message:> Developers could even choose to integrate Tor functionality into the
> client itself at some point.
>
The "satoshi" bitcoin client already supports use over TOR with the proxy
option - I think this was something Satoshi made regular use of.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111221/1d579878/attachment.html>

2023-06-07 04:47:00 CEST

- reply

📅 Original date posted:2011-12-15
🗒️ Summary of this message: A proposal to combine DNSSEC TXT record and HTTPS to get the dynamism of HTTPS without a rigid URL scheme for querying the server.
📝 Original message:Just so we're clear, what is the need for HTTP at all?
A query for a string and an answer can all be handled via DNS.
On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze <zellfaze at yahoo.com> wrote:
> Could we combine this proposal and the HTTPS proposal?
>
> The DNSSEC TXT record could give instructions on how to query an HTTPS
> server to get the address. Then we get the dynamism of HTTPS without
> having a rigid URL scheme for querying the server along with the advantages
> of DNSSEC.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111215/2289ae2c/attachment.html>

2023-06-07 04:43:22 CEST

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: A proposal to enable complete [email protected] handling in Bitcoin by extending the protocol for transactions to IP addresses and enabling DNS lookups.
📝 Original message:This is the first proposal I've seen regarding mapping something like
user at host that actually makes sense to me.
Bitcoin itself is decentralised by design, in my opinion it seems obvious
that it needs to continue to maintain this feature.
On Fri, Dec 16, 2011 at 8:59 AM, theymos <theymos at mm.st> 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:
> - 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.
> - 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.
>
> DoS attacks are already handled by the IP transactions code: the same IP
> address is always given the same bitcoin address until it pays to that
> bitcoin address.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/f86f05de/attachment.html>