* [bitcoin-dev] v3 onion services
@ 2019-11-17 4:33 Mr. Lee Chiffre
2019-11-17 15:35 ` s7r
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Mr. Lee Chiffre @ 2019-11-17 4:33 UTC (permalink / raw)
To: bitcoin-dev
Right now bitcoin client core supports use of tor hidden service. It
supports v2 hidden service. I am in progress of creating a new bitcoin
node which will use v3 hidden service instead of v2. I am looking at
bitcoin core and btcd to use. Do any of these or current node software
support the v3 onion addresses for the node address? What about I2P
addresses? If not what will it take to get it to support the longer
addresses that is used by i2p and tor v3?
--
lee.chiffre@secmail•pro
PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] v3 onion services
2019-11-17 4:33 [bitcoin-dev] v3 onion services Mr. Lee Chiffre
@ 2019-11-17 15:35 ` s7r
2019-11-17 20:04 ` LORD HIS EXCELLENCY JAMES HRMH
2019-11-17 23:42 ` Matt Corallo
[not found] ` <46FCD14B-02CC-4986-9C60-D8EC547F33FA@carldong.me>
2 siblings, 1 reply; 9+ messages in thread
From: s7r @ 2019-11-17 15:35 UTC (permalink / raw)
To: Mr. Lee Chiffre, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 1948 bytes --]
Mr. Lee Chiffre via bitcoin-dev wrote:
> Right now bitcoin client core supports use of tor hidden service. It
> supports v2 hidden service. I am in progress of creating a new bitcoin
> node which will use v3 hidden service instead of v2. I am looking at
> bitcoin core and btcd to use. Do any of these or current node software
> support the v3 onion addresses for the node address? What about I2P
> addresses? If not what will it take to get it to support the longer
> addresses that is used by i2p and tor v3?
>
>
Hello,
Yes, that is correct. Currently at present moment only v2 onion services
are supported. Bitcoin Core is limited at 128 bit 'addresses' in the p2p
protocol, so it requires a rework of the p2p protocol. v3 onion services
are whole ed25519 public keys, base32 encoded with .onion at the end.
Same reason applies to I2P 'address types' as well. However, I am not an
expert in I2P and don't actually know how many bitcoin full nodes might
exist in I2P.
See:
https://github.com/bitcoin/bitcoin/issues/9214
https://github.com/bitcoin/bitcoin/issues/2091
For the default `ADD_ONION` feature, the onion service key was
downgraded to explicitly RSA1024 (legacy, v2 onion services) to ensure
the feature still works out of the box:
https://github.com/bitcoin/bitcoin/pull/9234
If you want a Tor only full node, you are best to use v2 onion services
for now. Why do you need the bitcoin node to explicitly have a v3 onion
address? You can have a service that is accessible to the general public
as a v3 onion service, and in the back uses a bitcoin full node that
uses v2 onion service to talk to other nodes. The v2 onion service
bitcoin network is extended fairly.
You can use in the same torrc (Tor configuration file), implicitly same
Tor process/daemon simultaneously v2 and v3 onion services by setting
HiddenServiceVersion parameter after every HiddenServiceDir parameter.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] v3 onion services
2019-11-17 15:35 ` s7r
@ 2019-11-17 20:04 ` LORD HIS EXCELLENCY JAMES HRMH
2019-11-17 23:01 ` Christopher Allen
0 siblings, 1 reply; 9+ messages in thread
From: LORD HIS EXCELLENCY JAMES HRMH @ 2019-11-17 20:04 UTC (permalink / raw)
To: Mr. Lee Chiffre, Bitcoin Protocol Discussion, s7r
[-- Attachment #1: Type: text/plain, Size: 4118 bytes --]
For those perhaps not so well versed in the operation of Bitcoin (and Bitcoin Core) with Tor, connectivity through the outgoing connection to other nodes is all accomplished via the socks5 proxy which enables all current gossip and the distribution of the nodes own transactions to other nodes. This is a full connectivity feature.
For listening, Bitcoin Core instructs Tor to create an ephemeral hidden service which, depending on the various factors, may be currently v2 only or v3 (future implementation). This is not necessary for the functionality of node connectivity in any way and is only used to allow for hidden listening so that other nodes connecting out on the onion can connect privately without hopping on the public internet at all and without exposing the nodes public IP or ports as listening (no port forwarding required and no listing on nodes list with public IP). It is currently possible for many nodes to exist as onion only nodes.
For the time being, although I did wonder myself, the use of v3 ephemeral service is not a requirement of operation on Bitcoin and hardly adds anything to security especially if we enable transient onion listening (a feature proposal is currently waiting for consideration/approval on bitcoin-core-dev and GitHub), however, eventually it will be essential to make use of the v3 ephemeral service as the v2 service support will, as I understand, eventually be dropped from the Tor network. I do not know if there are any current distinct plans.
My opinion is, v3 support is a nice idea but hardly urgent yet. Good luck if it ends up with an ack as I suspect some of the changes required will be complex and this may be perhaps the best reason to begin on it while there is interest.
Regards,
LORD HIS EXCELLENCY JAMES HRMH
________________________________
From: bitcoin-dev <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of s7r via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Sent: Monday, 18 November 2019 2:35 AM
To: Mr. Lee Chiffre <lee.chiffre@secmail•pro>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] v3 onion services
Mr. Lee Chiffre via bitcoin-dev wrote:
> Right now bitcoin client core supports use of tor hidden service. It
> supports v2 hidden service. I am in progress of creating a new bitcoin
> node which will use v3 hidden service instead of v2. I am looking at
> bitcoin core and btcd to use. Do any of these or current node software
> support the v3 onion addresses for the node address? What about I2P
> addresses? If not what will it take to get it to support the longer
> addresses that is used by i2p and tor v3?
>
>
Hello,
Yes, that is correct. Currently at present moment only v2 onion services
are supported. Bitcoin Core is limited at 128 bit 'addresses' in the p2p
protocol, so it requires a rework of the p2p protocol. v3 onion services
are whole ed25519 public keys, base32 encoded with .onion at the end.
Same reason applies to I2P 'address types' as well. However, I am not an
expert in I2P and don't actually know how many bitcoin full nodes might
exist in I2P.
See:
https://github.com/bitcoin/bitcoin/issues/9214
https://github.com/bitcoin/bitcoin/issues/2091
For the default `ADD_ONION` feature, the onion service key was
downgraded to explicitly RSA1024 (legacy, v2 onion services) to ensure
the feature still works out of the box:
https://github.com/bitcoin/bitcoin/pull/9234
If you want a Tor only full node, you are best to use v2 onion services
for now. Why do you need the bitcoin node to explicitly have a v3 onion
address? You can have a service that is accessible to the general public
as a v3 onion service, and in the back uses a bitcoin full node that
uses v2 onion service to talk to other nodes. The v2 onion service
bitcoin network is extended fairly.
You can use in the same torrc (Tor configuration file), implicitly same
Tor process/daemon simultaneously v2 and v3 onion services by setting
HiddenServiceVersion parameter after every HiddenServiceDir parameter.
[-- Attachment #2: Type: text/html, Size: 6443 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] v3 onion services
2019-11-17 20:04 ` LORD HIS EXCELLENCY JAMES HRMH
@ 2019-11-17 23:01 ` Christopher Allen
0 siblings, 0 replies; 9+ messages in thread
From: Christopher Allen @ 2019-11-17 23:01 UTC (permalink / raw)
To: LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev; +Cc: Peter Denton
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
Blockchain Commons is using v3 tor authentication for remote clients
controlling a full node created using our Bitcoin Standup project
(currently only macOS but more platforms coming):
https://github.com/BlockchainCommons/Bitcoin-Standup
Docs at:
https://github.com/BlockchainCommons/Bitcoin-Standup#tor-v3-authentication-using-standup-and-fullynoded
Video demonstrating securing remote connection of a full node to the iOS
wallet Fully Noded: https://youtu.be/pSm2VftTCBI
More details on v3 authentication at:
https://github.com/AnarchoTechNYC/meta/wiki/Connecting-to-an-authenticated-Onion-service#connecting-to-authenticated-version-3-onion-services
— Christopher Allen
[-- Attachment #2: Type: text/html, Size: 1309 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] v3 onion services
2019-11-17 4:33 [bitcoin-dev] v3 onion services Mr. Lee Chiffre
2019-11-17 15:35 ` s7r
@ 2019-11-17 23:42 ` Matt Corallo
2019-11-18 11:59 ` Aymeric Vitte
[not found] ` <46FCD14B-02CC-4986-9C60-D8EC547F33FA@carldong.me>
2 siblings, 1 reply; 9+ messages in thread
From: Matt Corallo @ 2019-11-17 23:42 UTC (permalink / raw)
To: Mr. Lee Chiffre, Bitcoin Protocol Discussion
There is effort ongoing to upgrade the Bitcoin P2P protocol to support other address types, including onion v3. There are various posts on this ML under the title “addrv2”. Further review and contributions to that effort is, as always, welcome.
> On Nov 17, 2019, at 00:05, Mr. Lee Chiffre via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Right now bitcoin client core supports use of tor hidden service. It
> supports v2 hidden service. I am in progress of creating a new bitcoin
> node which will use v3 hidden service instead of v2. I am looking at
> bitcoin core and btcd to use. Do any of these or current node software
> support the v3 onion addresses for the node address? What about I2P
> addresses? If not what will it take to get it to support the longer
> addresses that is used by i2p and tor v3?
>
>
> --
> lee.chiffre@secmail•pro
> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] v3 onion services
2019-11-17 23:42 ` Matt Corallo
@ 2019-11-18 11:59 ` Aymeric Vitte
2019-11-18 12:34 ` LORD HIS EXCELLENCY JAMES HRMH
0 siblings, 1 reply; 9+ messages in thread
From: Aymeric Vitte @ 2019-11-18 11:59 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion, Mr. Lee Chiffre; +Cc: fontainedenton
[-- Attachment #1: Type: text/plain, Size: 3024 bytes --]
As I briefly sketched here before I think that a better long term
solution would be to link the bitcoin traffic with something like
node-Tor (https://github.com/Ayms/node-Tor)
Much more light (the whole code not minified is only ~1MB), not using
tons of libraries prone to security/maintenance issues, easy to
use/configure/maintain and you don't need the (heavy/complicate) onions
RDV concepts and addresses, which in addition is useless for bitcoin
As simple as a duplex stream *bitcoin.pipe(node-Tor)* inside servers or
browsers (difficult to imagine full nodes and the blocks inside browsers
but why not one day, so for light clients probably implementing part of
the bitcoin protocol like https://peersm.com/wallet, for now it's a
standalone offline webapp but of course it would be interesting to
connect it in a secure way to bitcoin nodes to retrieve info from the
utxo set and send txs for example since it's not obvious for users to
create their txs in its current form)
This would be a separate network using the Tor protocol over TCP,
WebSockets and WebRTC, making it possible also for browsers to relay the
traffic, probably the nodes discovery (to get the keys) could be linked
to the bitcoin peer discovery system (we just have to add the onion key
to the peer profile, and maybe long term id key), anyway that's simple
to setup, and probably for a p2p network 2 hops will be enough
I really don't think that the Tor network is designed and adapted to
support bitcoin nodes, using it for something else than browsing is just
a workaround and I would be surprised that the Tor project team
contradicts this and/or encourage this use
Le 18/11/2019 à 00:42, Matt Corallo via bitcoin-dev a écrit :
> There is effort ongoing to upgrade the Bitcoin P2P protocol to support other address types, including onion v3. There are various posts on this ML under the title “addrv2”. Further review and contributions to that effort is, as always, welcome.
>
>> On Nov 17, 2019, at 00:05, Mr. Lee Chiffre via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Right now bitcoin client core supports use of tor hidden service. It
>> supports v2 hidden service. I am in progress of creating a new bitcoin
>> node which will use v3 hidden service instead of v2. I am looking at
>> bitcoin core and btcd to use. Do any of these or current node software
>> support the v3 onion addresses for the node address? What about I2P
>> addresses? If not what will it take to get it to support the longer
>> addresses that is used by i2p and tor v3?
>>
>>
>> --
>> lee.chiffre@secmail•pro
>> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 4473 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] v3 onion services
2019-11-18 11:59 ` Aymeric Vitte
@ 2019-11-18 12:34 ` LORD HIS EXCELLENCY JAMES HRMH
0 siblings, 0 replies; 9+ messages in thread
From: LORD HIS EXCELLENCY JAMES HRMH @ 2019-11-18 12:34 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion, Mr. Lee Chiffre,
Aymeric Vitte
Cc: fontainedenton
[-- Attachment #1: Type: text/plain, Size: 4908 bytes --]
The Tor team encourages active participating Tor nodes, preferably exit/ middle/guard nodes and not only client nodes, which is actually a significant part of the reason that the documentation I put together in Bitcoin.SE does not deal much with configuration tweaking Tor; as out of the box Tor participates actively in the Tor network.
As for applications other than web browsing, i is simply not true to suggest that Tor is implemented solely for web browsing and I suppose that this view has come about because of the Tor browser, an attempt to engage more active Tor nodes while providing an OOB privacy solution to simplify setup for the not-so-technical. As just one example of other uses, you will note the Tor configuration item `LongLivedPorts` and its implications. No, it is completely not necessary to tweak this option for Bitcoin although you may.
I encourage you to forward these comments to the Tor mailing list.
>I really don't think that the Tor network is designed and adapted to support bitcoin nodes, using it for something else than browsing is just a workaround and I would be surprised that the Tor project team contradicts this and/or encourage this use
Regards,
LORD HIS EXCELLENCY JAMES HRMH
________________________________
From: bitcoin-dev <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Aymeric Vitte via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Sent: Monday, 18 November 2019 10:59 PM
To: Matt Corallo <lf-lists@mattcorallo•com>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>; Mr. Lee Chiffre <lee.chiffre@secmail•pro>
Cc: fontainedenton@googlemail•com <fontainedenton@googlemail•com>
Subject: Re: [bitcoin-dev] v3 onion services
As I briefly sketched here before I think that a better long term solution would be to link the bitcoin traffic with something like node-Tor (https://github.com/Ayms/node-Tor)
Much more light (the whole code not minified is only ~1MB), not using tons of libraries prone to security/maintenance issues, easy to use/configure/maintain and you don't need the (heavy/complicate) onions RDV concepts and addresses, which in addition is useless for bitcoin
As simple as a duplex stream bitcoin.pipe(node-Tor) inside servers or browsers (difficult to imagine full nodes and the blocks inside browsers but why not one day, so for light clients probably implementing part of the bitcoin protocol like https://peersm.com/wallet, for now it's a standalone offline webapp but of course it would be interesting to connect it in a secure way to bitcoin nodes to retrieve info from the utxo set and send txs for example since it's not obvious for users to create their txs in its current form)
This would be a separate network using the Tor protocol over TCP, WebSockets and WebRTC, making it possible also for browsers to relay the traffic, probably the nodes discovery (to get the keys) could be linked to the bitcoin peer discovery system (we just have to add the onion key to the peer profile, and maybe long term id key), anyway that's simple to setup, and probably for a p2p network 2 hops will be enough
I really don't think that the Tor network is designed and adapted to support bitcoin nodes, using it for something else than browsing is just a workaround and I would be surprised that the Tor project team contradicts this and/or encourage this use
Le 18/11/2019 à 00:42, Matt Corallo via bitcoin-dev a écrit :
There is effort ongoing to upgrade the Bitcoin P2P protocol to support other address types, including onion v3. There are various posts on this ML under the title “addrv2”. Further review and contributions to that effort is, as always, welcome.
On Nov 17, 2019, at 00:05, Mr. Lee Chiffre via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org><mailto:bitcoin-dev@lists•linuxfoundation.org> wrote:
Right now bitcoin client core supports use of tor hidden service. It
supports v2 hidden service. I am in progress of creating a new bitcoin
node which will use v3 hidden service instead of v2. I am looking at
bitcoin core and btcd to use. Do any of these or current node software
support the v3 onion addresses for the node address? What about I2P
addresses? If not what will it take to get it to support the longer
addresses that is used by i2p and tor v3?
--
lee.chiffre@secmail.pro<mailto:lee.chiffre@secmail•pro>
PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 7571 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] v3 onion services
[not found] ` <46FCD14B-02CC-4986-9C60-D8EC547F33FA@carldong.me>
@ 2019-11-18 16:44 ` Carl Dong
2019-11-18 22:19 ` Aymeric Vitte
0 siblings, 1 reply; 9+ messages in thread
From: Carl Dong @ 2019-11-18 16:44 UTC (permalink / raw)
To: Mr. Lee Chiffre, Bitcoin Protocol Discussion
Hi Mr. Lee Chiffre,
I have been working on an implementation of addrv2 (BIP-155). Is this what you meant by I2P and Torv3 address support?
My WIP pull request: https://github.com/bitcoin/bitcoin/pull/16748
Merged BIP: https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
Ongoing discussion: https://github.com/bitcoin/bips/pull/766
Note: Even though the pull request to the BIP repo is merged, we’re still discussing some details in the pull request thread and will amend the BIP once it seems like we’ve worked out all the kinks
Review and further discussion is very much welcome! :-)
Cheers,
Carl Dong
contact@carldong•me
"I fight for the users"
> On Nov 16, 2019, at 11:33 PM, Mr. Lee Chiffre via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> Right now bitcoin client core supports use of tor hidden service. It
> supports v2 hidden service. I am in progress of creating a new bitcoin
> node which will use v3 hidden service instead of v2. I am looking at
> bitcoin core and btcd to use. Do any of these or current node software
> support the v3 onion addresses for the node address? What about I2P
> addresses? If not what will it take to get it to support the longer
> addresses that is used by i2p and tor v3?
>
>
> --
> lee.chiffre@secmail•pro
> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] v3 onion services
2019-11-18 16:44 ` Carl Dong
@ 2019-11-18 22:19 ` Aymeric Vitte
0 siblings, 0 replies; 9+ messages in thread
From: Aymeric Vitte @ 2019-11-18 22:19 UTC (permalink / raw)
To: Carl Dong, Bitcoin Protocol Discussion, Mr. Lee Chiffre
So I must ask the question: what is the rational for a bitcoin node to
be hidden? ie to use RDV points like hidden services?
For me the rational for bitcoin is to anonymize communications between
nodes and/or clients, typically who sent this tx, not to hide that you
are operating a bitcoin node, then back to what I sent earlier
I tried to find the explaination in the bitcoin docs before sending this
post but did not find any, except referring to the fact that bitcoin
communications should be anonymized, which does not need RDV points
Another question is why to mimic the Tor network for RDV points with
.onion addresses?
The answers might be "this is what exists and we have no other way to do
it", I am proposing another way
I will not repeat what I wrote before, but I am operating node-Tor nodes
inside the Tor network since ~10 years, the js implementation of the Tor
protocol had not been easy (as well as putting everything inside
browsers) but I consider that the most difficult had been to handle all
unexpected events that happen inside the Tor network, even after
selecting carefully the nodes and testing them, this is a mess, nodes
are coming in, going out, responding, not responding, responding
correcltly or all of a sudden responding shxtty stuff, I was even
considering to get the entropy for the js prng from all of those
unexpected events
I don't think that any other people except the Tor project team know
this, a good example is http://peersm.com/peersm2, see the logs (destroy
and destroy and destroy) and how long it takes to establish 6 circuits
knowing that our server is the first one in the path (eliminating one
dubious node among 3)
I am not "promoting" this, everything is open source now and it is made
to be used, and I think that my proposal has some interest, using the
Tor network for bitcoin is a very bad idea, for security and
performances reasons
Le 18/11/2019 à 17:44, Carl Dong via bitcoin-dev a écrit :
> Hi Mr. Lee Chiffre,
>
> I have been working on an implementation of addrv2 (BIP-155). Is this what you meant by I2P and Torv3 address support?
>
> My WIP pull request: https://github.com/bitcoin/bitcoin/pull/16748
> Merged BIP: https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
> Ongoing discussion: https://github.com/bitcoin/bips/pull/766
> Note: Even though the pull request to the BIP repo is merged, we’re still discussing some details in the pull request thread and will amend the BIP once it seems like we’ve worked out all the kinks
>
> Review and further discussion is very much welcome! :-)
>
> Cheers,
> Carl Dong
> contact@carldong•me
> "I fight for the users"
>
>> On Nov 16, 2019, at 11:33 PM, Mr. Lee Chiffre via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>
>> Right now bitcoin client core supports use of tor hidden service. It
>> supports v2 hidden service. I am in progress of creating a new bitcoin
>> node which will use v3 hidden service instead of v2. I am looking at
>> bitcoin core and btcd to use. Do any of these or current node software
>> support the v3 onion addresses for the node address? What about I2P
>> addresses? If not what will it take to get it to support the longer
>> addresses that is used by i2p and tor v3?
>>
>>
>> --
>> lee.chiffre@secmail•pro
>> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-11-18 22:19 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-17 4:33 [bitcoin-dev] v3 onion services Mr. Lee Chiffre
2019-11-17 15:35 ` s7r
2019-11-17 20:04 ` LORD HIS EXCELLENCY JAMES HRMH
2019-11-17 23:01 ` Christopher Allen
2019-11-17 23:42 ` Matt Corallo
2019-11-18 11:59 ` Aymeric Vitte
2019-11-18 12:34 ` LORD HIS EXCELLENCY JAMES HRMH
[not found] ` <46FCD14B-02CC-4986-9C60-D8EC547F33FA@carldong.me>
2019-11-18 16:44 ` Carl Dong
2019-11-18 22:19 ` Aymeric Vitte
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox