[bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys

[bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys

[Christopher Gilliard]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

I have written up a proposed BIP. It has to do with Signature formats when
using Bitcoin Private keys. It is here:
https://github.com/cgilliard/BIP/blob/master/README.md

This BIP was written up as suggested in this github issue:
https://github.com/bitcoin/bitcoin/issues/10542

Note that the proposal is inline with the implementation that Trezor
implemented in the above issue.

Any feedback would be appreciated. Please let me know what the steps are
with regards to getting a BIP number assigned or any other process steps
required.

Regards,
Chris

[-- Attachment #2: Type: text/html, Size: 877 bytes --]

Re: [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys

[Adam Ficsor]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

In Wasabi wallet we are in the finishing line of an encryption manager.
I'll ask the OP to review your BIP and probably I'll do it myself, too
before I'd merge. Feel free to review/test our PR, too:
https://github.com/zkSNACKs/WalletWasabi/pull/1127

On Sun, Feb 17, 2019 at 6:01 PM Christopher Gilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have written up a proposed BIP. It has to do with Signature formats when
> using Bitcoin Private keys. It is here:
> https://github.com/cgilliard/BIP/blob/master/README.md
>
> This BIP was written up as suggested in this github issue:
> https://github.com/bitcoin/bitcoin/issues/10542
>
> Note that the proposal is inline with the implementation that Trezor
> implemented in the above issue.
>
> Any feedback would be appreciated. Please let me know what the steps are
> with regards to getting a BIP number assigned or any other process steps
> required.
>
> Regards,
> Chris
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best,
Ádám

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

Re: [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

Then, since you wrote this proposal, maybe you should add the very
precise description of the signing/verification process since it is
documented nowhere

I don't get the use of the speech regarding keys while it should focus
on signatures which are summarized in a vague sentence inspired by your
ref [2] with a not very logical link to the next paragraph stating that
r,s should be 32B and the whole thing 65B with a header of 1B, you did
not invent it, that's probably the rule, not sure where it is specified
again and for what purpose, the header seems completely of no use
especially when you extend to segwit/bech32 since you just have to check
that related compressed key matches

Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
> I have written up a proposed BIP. It has to do with Signature formats
> when using Bitcoin Private keys. It is
> here: https://github.com/cgilliard/BIP/blob/master/README.md
>
> This BIP was written up as suggested in this github
> issue: https://github.com/bitcoin/bitcoin/issues/10542
>
> Note that the proposal is inline with the implementation that Trezor
> implemented in the above issue.
>
> Any feedback would be appreciated. Please let me know what the steps
> are with regards to getting a BIP number assigned or any other process
> steps required.
>
> Regards,
> Chris
>
> _______________________________________________
> 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


[-- Attachment #2: Type: text/html, Size: 4531 bytes --]

Re: [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys

[Christopher Gilliard]

[-- Attachment #1: Type: text/plain, Size: 3837 bytes --]

The proposal includes actual code that does verification, but I didn't
include code for signing. I thought it could be inferred, but I could at
least include a description of how to sign. I am not sure exactly what part
you are referring to by "keys speech", but the signatures are done by ECDSA
keys so it's hard to not include anything about keys even though that's not
the main topic. The "Background on ECDSA keys" section was mainly meant to
give background about what kind of keys Bitcoin uses, for people who
already know that they can easily skip this section so I would probably
think it's best just to leave in.  Maybe it should be at the end as an
addendum though. Yes, I did not invent any of this, I'm just documenting
what people actually seem to do because I had to verify signatures as part
of a project I'm working on. I would have liked to have had this document
when I started the project so I thought it might be useful to others since
as far as I can tell this was not specified anywhere. The reason for
including this data in the header is the same that compressed/uncompressed
is included in the header so that you know which type of key the signature
is from and you don't have to try all options to see if any matches. This
is why Trezor did that way and why I documented it. I'm sure there are
other ways to do this, but since this is out there in the field being used
and is a reasonable solution, I thought I'd write it up.

On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte <vitteaymeric@gmail.com>
wrote:

> Then, since you wrote this proposal, maybe you should add the very precise
> description of the signing/verification process since it is documented
> nowhere
>
> I don't get the use of the speech regarding keys while it should focus on
> signatures which are summarized in a vague sentence inspired by your ref
> [2] with a not very logical link to the next paragraph stating that r,s
> should be 32B and the whole thing 65B with a header of 1B, you did not
> invent it, that's probably the rule, not sure where it is specified again
> and for what purpose, the header seems completely of no use especially when
> you extend to segwit/bech32 since you just have to check that related
> compressed key matches
> Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
>
> I have written up a proposed BIP. It has to do with Signature formats when
> using Bitcoin Private keys. It is here:
> https://github.com/cgilliard/BIP/blob/master/README.md
>
> This BIP was written up as suggested in this github issue:
> https://github.com/bitcoin/bitcoin/issues/10542
>
> Note that the proposal is inline with the implementation that Trezor
> implemented in the above issue.
>
> Any feedback would be appreciated. Please let me know what the steps are
> with regards to getting a BIP number assigned or any other process steps
> required.
>
> Regards,
> Chris
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://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
>
>

[-- Attachment #2: Type: text/html, Size: 6796 bytes --]

Re: [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 5388 bytes --]

Ah, OK, that's of course a good thing to document this undocumented (and
strange) stuff, as a matter of fact I implemented it after reading your
post (because this was on my todo list since some time) and got annoyed
quickly, mainly by what is doing formatMessageForSigning (which is quite
trivial when you know it but would be good to document precisely)

So, yes, it's a good idea to write this, regarding the header I still
don't see the use, testing the different possibilities is not a big
deal, why the signature format is not the same as transactions one is
mysterious too

Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :
> The proposal includes actual code that does verification, but I didn't
> include code for signing. I thought it could be inferred, but I could
> at least include a description of how to sign. I am not sure exactly
> what part you are referring to by "keys speech", but the signatures
> are done by ECDSA keys so it's hard to not include anything about keys
> even though that's not the main topic. The "Background on ECDSA keys"
> section was mainly meant to give background about what kind of keys
> Bitcoin uses, for people who already know that they can easily skip
> this section so I would probably think it's best just to leave in. 
> Maybe it should be at the end as an addendum though. Yes, I did not
> invent any of this, I'm just documenting what people actually seem to
> do because I had to verify signatures as part of a project I'm working
> on. I would have liked to have had this document when I started the
> project so I thought it might be useful to others since as far as I
> can tell this was not specified anywhere. The reason for including
> this data in the header is the same that compressed/uncompressed is
> included in the header so that you know which type of key the
> signature is from and you don't have to try all options to see if any
> matches. This is why Trezor did that way and why I documented it. I'm
> sure there are other ways to do this, but since this is out there in
> the field being used and is a reasonable solution, I thought I'd write
> it up.
>
> On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte <vitteaymeric@gmail.com
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>     Then, since you wrote this proposal, maybe you should add the very
>     precise description of the signing/verification process since it
>     is documented nowhere
>
>     I don't get the use of the speech regarding keys while it should
>     focus on signatures which are summarized in a vague sentence
>     inspired by your ref [2] with a not very logical link to the next
>     paragraph stating that r,s should be 32B and the whole thing 65B
>     with a header of 1B, you did not invent it, that's probably the
>     rule, not sure where it is specified again and for what purpose,
>     the header seems completely of no use especially when you extend
>     to segwit/bech32 since you just have to check that related
>     compressed key matches
>
>     Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
>>     I have written up a proposed BIP. It has to do with Signature
>>     formats when using Bitcoin Private keys. It is
>>     here: https://github.com/cgilliard/BIP/blob/master/README.md
>>
>>     This BIP was written up as suggested in this github
>>     issue: https://github.com/bitcoin/bitcoin/issues/10542
>>
>>     Note that the proposal is inline with the implementation that
>>     Trezor implemented in the above issue.
>>
>>     Any feedback would be appreciated. Please let me know what the
>>     steps are with regards to getting a BIP number assigned or any
>>     other process steps required.
>>
>>     Regards,
>>     Chris
>>
>>     _______________________________________________
>>     bitcoin-dev mailing list
>>     bitcoin-dev@lists.linuxfoundation.org <mailto: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
>
-- 
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


[-- Attachment #2: Type: text/html, Size: 10516 bytes --]

Re: [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys

[Christopher Gilliard]

[-- Attachment #1: Type: text/plain, Size: 5977 bytes --]

Trying the four possible options (p2pkh compressed, p2pkh uncompressed,
seg3, and bech32) is certainly a possibility and in fact, that's what I
ended up doing because not every wallet implements something like this, but
if there is a header field currently in use, it seemed reasonable to me to
use it specify which type of key is being used. If the header includes
whether the key is compressed or not compressed it seems logical to include
all data about what type of key it is and not just this one type of
information. That's why I thought the solution made sense and I wrote it up.

On Mon, Feb 18, 2019 at 3:50 PM Aymeric Vitte <vitteaymeric@gmail.com>
wrote:

> Ah, OK, that's of course a good thing to document this undocumented (and
> strange) stuff, as a matter of fact I implemented it after reading your
> post (because this was on my todo list since some time) and got annoyed
> quickly, mainly by what is doing formatMessageForSigning (which is quite
> trivial when you know it but would be good to document precisely)
>
> So, yes, it's a good idea to write this, regarding the header I still
> don't see the use, testing the different possibilities is not a big deal,
> why the signature format is not the same as transactions one is mysterious
> too
> Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :
>
> The proposal includes actual code that does verification, but I didn't
> include code for signing. I thought it could be inferred, but I could at
> least include a description of how to sign. I am not sure exactly what part
> you are referring to by "keys speech", but the signatures are done by ECDSA
> keys so it's hard to not include anything about keys even though that's not
> the main topic. The "Background on ECDSA keys" section was mainly meant to
> give background about what kind of keys Bitcoin uses, for people who
> already know that they can easily skip this section so I would probably
> think it's best just to leave in.  Maybe it should be at the end as an
> addendum though. Yes, I did not invent any of this, I'm just documenting
> what people actually seem to do because I had to verify signatures as part
> of a project I'm working on. I would have liked to have had this document
> when I started the project so I thought it might be useful to others since
> as far as I can tell this was not specified anywhere. The reason for
> including this data in the header is the same that compressed/uncompressed
> is included in the header so that you know which type of key the signature
> is from and you don't have to try all options to see if any matches. This
> is why Trezor did that way and why I documented it. I'm sure there are
> other ways to do this, but since this is out there in the field being used
> and is a reasonable solution, I thought I'd write it up.
>
> On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte <vitteaymeric@gmail.com>
> wrote:
>
>> Then, since you wrote this proposal, maybe you should add the very
>> precise description of the signing/verification process since it is
>> documented nowhere
>>
>> I don't get the use of the speech regarding keys while it should focus on
>> signatures which are summarized in a vague sentence inspired by your ref
>> [2] with a not very logical link to the next paragraph stating that r,s
>> should be 32B and the whole thing 65B with a header of 1B, you did not
>> invent it, that's probably the rule, not sure where it is specified again
>> and for what purpose, the header seems completely of no use especially when
>> you extend to segwit/bech32 since you just have to check that related
>> compressed key matches
>> Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
>>
>> I have written up a proposed BIP. It has to do with Signature formats
>> when using Bitcoin Private keys. It is here:
>> https://github.com/cgilliard/BIP/blob/master/README.md
>>
>> This BIP was written up as suggested in this github issue:
>> https://github.com/bitcoin/bitcoin/issues/10542
>>
>> Note that the proposal is inline with the implementation that Trezor
>> implemented in the above issue.
>>
>> Any feedback would be appreciated. Please let me know what the steps are
>> with regards to getting a BIP number assigned or any other process steps
>> required.
>>
>> Regards,
>> Chris
>>
>> _______________________________________________
>> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://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
>>
>> --
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 11937 bytes --]

[bitcoin-dev] Fwd: BIP proposal - Signatures of Messages using Bitcoin Private Keys

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 6940 bytes --]

Re-sending to the list since it never made it

BIP or not, at least this process desserves to be documented precisely


-------- Message transféré --------
Sujet : 	Re: [bitcoin-dev] BIP proposal - Signatures of Messages using
Bitcoin Private Keys
Date : 	Mon, 18 Feb 2019 16:29:34 -0800
De : 	Christopher Gilliard <christopher.gilliard@gmail.com>
Pour : 	Aymeric Vitte <vitteaymeric@gmail.com>
Copie à : 	Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>



Trying the four possible options (p2pkh compressed, p2pkh uncompressed,
seg3, and bech32) is certainly a possibility and in fact, that's what I
ended up doing because not every wallet implements something like this,
but if there is a header field currently in use, it seemed reasonable to
me to use it specify which type of key is being used. If the header
includes whether the key is compressed or not compressed it seems
logical to include all data about what type of key it is and not just
this one type of information. That's why I thought the solution made
sense and I wrote it up.

On Mon, Feb 18, 2019 at 3:50 PM Aymeric Vitte <vitteaymeric@gmail.com
<mailto:vitteaymeric@gmail.com>> wrote:

    Ah, OK, that's of course a good thing to document this undocumented
    (and strange) stuff, as a matter of fact I implemented it after
    reading your post (because this was on my todo list since some time)
    and got annoyed quickly, mainly by what is doing
    formatMessageForSigning (which is quite trivial when you know it but
    would be good to document precisely)

    So, yes, it's a good idea to write this, regarding the header I
    still don't see the use, testing the different possibilities is not
    a big deal, why the signature format is not the same as transactions
    one is mysterious too

    Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :
>     The proposal includes actual code that does verification, but I
>     didn't include code for signing. I thought it could be inferred,
>     but I could at least include a description of how to sign. I am
>     not sure exactly what part you are referring to by "keys speech",
>     but the signatures are done by ECDSA keys so it's hard to not
>     include anything about keys even though that's not the main topic.
>     The "Background on ECDSA keys" section was mainly meant to give
>     background about what kind of keys Bitcoin uses, for people who
>     already know that they can easily skip this section so I would
>     probably think it's best just to leave in.  Maybe it should be at
>     the end as an addendum though. Yes, I did not invent any of this,
>     I'm just documenting what people actually seem to do because I had
>     to verify signatures as part of a project I'm working on. I would
>     have liked to have had this document when I started the project so
>     I thought it might be useful to others since as far as I can tell
>     this was not specified anywhere. The reason for including this
>     data in the header is the same that compressed/uncompressed is
>     included in the header so that you know which type of key the
>     signature is from and you don't have to try all options to see if
>     any matches. This is why Trezor did that way and why I documented
>     it. I'm sure there are other ways to do this, but since this is
>     out there in the field being used and is a reasonable solution, I
>     thought I'd write it up.
>
>     On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte
>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>
>         Then, since you wrote this proposal, maybe you should add the
>         very precise description of the signing/verification process
>         since it is documented nowhere
>
>         I don't get the use of the speech regarding keys while it
>         should focus on signatures which are summarized in a vague
>         sentence inspired by your ref [2] with a not very logical link
>         to the next paragraph stating that r,s should be 32B and the
>         whole thing 65B with a header of 1B, you did not invent it,
>         that's probably the rule, not sure where it is specified again
>         and for what purpose, the header seems completely of no use
>         especially when you extend to segwit/bech32 since you just
>         have to check that related compressed key matches
>
>         Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a
>         écrit :
>>         I have written up a proposed BIP. It has to do with Signature
>>         formats when using Bitcoin Private keys. It is
>>         here: https://github.com/cgilliard/BIP/blob/master/README.md
>>
>>         This BIP was written up as suggested in this github
>>         issue: https://github.com/bitcoin/bitcoin/issues/10542
>>
>>         Note that the proposal is inline with the implementation that
>>         Trezor implemented in the above issue.
>>
>>         Any feedback would be appreciated. Please let me know what
>>         the steps are with regards to getting a BIP number assigned
>>         or any other process steps required.
>>
>>         Regards,
>>         Chris
>>
>>         _______________________________________________
>>         bitcoin-dev mailing list
>>         bitcoin-dev@lists.linuxfoundation.org <mailto: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
>
    -- 
    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


[-- Attachment #2: Type: text/html, Size: 15519 bytes --]