[Bitcoin-development] Identity protocol observation

[Bitcoin-development] Identity protocol observation

[Daniel Lidstrom]

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

The location of a tx in the blockchain can be encoded in n=log2(h)+log2(t)
bits, where h is the block height, and t is the number of transactions in
the block.  Currently h~250,000 and t~500, so n~27.  A CVC phoneme encodes
~10.7 bits *, so a transaction today can be located in the blockchain with
3 of these, e.g. reb-mizvig.  This is reasonably short, readable and
memorable.

The identity protocol Jeff Garzik is working on will link a public key
fingerprint to a miner sacrifice transaction.  This tx could in turn be
uniquely described with a short name as above.  Associating this name with
the public key becomes secure once the tx is sufficiently buried in the
blockchain.  In the identity protocol, lightweight clients check the
validity of a sacrifice tx by checking that its merkle path is valid.  But
this path encodes, via the ordering of the hashes at each level, the
location of the transaction in the block, so the lightweight client can
verify the sacrifice tx's short name using only the information he already
has.

Some more random names:
vec-halhic
wom-vizpyd
guv-zussof
jog-copwug
seg-rizges
jyg-somgod
pax-synjem
zyg-zuxdyj
gid-mutdyj
rel-hyrdaj

Sources of inspiration:
urbit.org
https://en.bitcoin.it/wiki/Identity_protocol_v1

* This is somewhat restricted: I disallowed q for obvious reasons and k
because it conflicts with c, and c looks much softer and less like
Klingon.  H is allowed for the first consonant, but not the second, and x
is allowed for the last one, but not the first one.  Y is a vowel, but not
a consonant.  Maybe these weren't quite the right choices.  Paint away!

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

Re: [Bitcoin-development] Identity protocol observation

[Daniel Lidstrom]

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

A couple more thoughts on this:

1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits per
phoneme.
2) An extra phoneme (4 encode 43 bits total) gives room to put extra
information into the name, e.g. the first 5 bits could be input as the key
to a PRP that permutes the last 38 back to a standard encoding of a tx
location.  This would give the user 32 random names per sacrifice to choose
from, and 38 bits to encode its location in the blockchain, which is enough
for pretty large blocks.

Sample 4 phoneme names:
~milmoz-vyrnyx
~mypnoz-fojzas
~sawfex-bovlec
~fidhut-guvgis
~bobfej-jessuk
~furcos-diwhuw
~wokryx-wilrox
~bygbyl-caggos
~vewcyv-jyjsal
~daxsaf-cywkul

They're not that bad IMHO, especially if you get to pick a decent one from
a bunch.


On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:

> The location of a tx in the blockchain can be encoded in n=log2(h)+log2(t)
> bits, where h is the block height, and t is the number of transactions in
> the block.  Currently h~250,000 and t~500, so n~27.  A CVC phoneme encodes
> ~10.7 bits *, so a transaction today can be located in the blockchain with
> 3 of these, e.g. reb-mizvig.  This is reasonably short, readable and
> memorable.
>
> The identity protocol Jeff Garzik is working on will link a public key
> fingerprint to a miner sacrifice transaction.  This tx could in turn be
> uniquely described with a short name as above.  Associating this name with
> the public key becomes secure once the tx is sufficiently buried in the
> blockchain.  In the identity protocol, lightweight clients check the
> validity of a sacrifice tx by checking that its merkle path is valid.  But
> this path encodes, via the ordering of the hashes at each level, the
> location of the transaction in the block, so the lightweight client can
> verify the sacrifice tx's short name using only the information he already
> has.
>
> Some more random names:
> vec-halhic
> wom-vizpyd
> guv-zussof
> jog-copwug
> seg-rizges
> jyg-somgod
> pax-synjem
> zyg-zuxdyj
> gid-mutdyj
> rel-hyrdaj
>
> Sources of inspiration:
> urbit.org
> https://en.bitcoin.it/wiki/Identity_protocol_v1
>
> * This is somewhat restricted: I disallowed q for obvious reasons and k
> because it conflicts with c, and c looks much softer and less like
> Klingon.  H is allowed for the first consonant, but not the second, and x
> is allowed for the last one, but not the first one.  Y is a vowel, but not
> a consonant.  Maybe these weren't quite the right choices.  Paint away!
>

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

Re: [Bitcoin-development] Identity protocol observation

[Mike Hearn]

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

Interesting observation, thanks.

I'd think any competent implementation of such an identity scheme would not
involve end users directly handling randomized nonsense words, however. I
always imagined a sacrifice as being a file that you make with a GUI tool
and load into a browser extension.


On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:

> A couple more thoughts on this:
>
> 1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits per
> phoneme.
> 2) An extra phoneme (4 encode 43 bits total) gives room to put extra
> information into the name, e.g. the first 5 bits could be input as the key
> to a PRP that permutes the last 38 back to a standard encoding of a tx
> location.  This would give the user 32 random names per sacrifice to choose
> from, and 38 bits to encode its location in the blockchain, which is enough
> for pretty large blocks.
>
> Sample 4 phoneme names:
> ~milmoz-vyrnyx
> ~mypnoz-fojzas
> ~sawfex-bovlec
> ~fidhut-guvgis
> ~bobfej-jessuk
> ~furcos-diwhuw
> ~wokryx-wilrox
> ~bygbyl-caggos
> ~vewcyv-jyjsal
> ~daxsaf-cywkul
>
> They're not that bad IMHO, especially if you get to pick a decent one from
> a bunch.
>
>
> On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>
>> The location of a tx in the blockchain can be encoded in
>> n=log2(h)+log2(t) bits, where h is the block height, and t is the number of
>> transactions in the block.  Currently h~250,000 and t~500, so n~27.  A CVC
>> phoneme encodes ~10.7 bits *, so a transaction today can be located in the
>> blockchain with 3 of these, e.g. reb-mizvig.  This is reasonably short,
>> readable and memorable.
>>
>> The identity protocol Jeff Garzik is working on will link a public key
>> fingerprint to a miner sacrifice transaction.  This tx could in turn be
>> uniquely described with a short name as above.  Associating this name with
>> the public key becomes secure once the tx is sufficiently buried in the
>> blockchain.  In the identity protocol, lightweight clients check the
>> validity of a sacrifice tx by checking that its merkle path is valid.  But
>> this path encodes, via the ordering of the hashes at each level, the
>> location of the transaction in the block, so the lightweight client can
>> verify the sacrifice tx's short name using only the information he already
>> has.
>>
>> Some more random names:
>> vec-halhic
>> wom-vizpyd
>> guv-zussof
>> jog-copwug
>> seg-rizges
>> jyg-somgod
>> pax-synjem
>> zyg-zuxdyj
>> gid-mutdyj
>> rel-hyrdaj
>>
>> Sources of inspiration:
>> urbit.org
>> https://en.bitcoin.it/wiki/Identity_protocol_v1
>>
>> * This is somewhat restricted: I disallowed q for obvious reasons and k
>> because it conflicts with c, and c looks much softer and less like
>> Klingon.  H is allowed for the first consonant, but not the second, and x
>> is allowed for the last one, but not the first one.  Y is a vowel, but not
>> a consonant.  Maybe these weren't quite the right choices.  Paint away!
>>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

Re: [Bitcoin-development] Identity protocol observation

[Daniel Lidstrom]

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

Fair enough, though people still manage okay with phone numbers.  And a
decentralized naming system seems to come at great cost - with namecoin you
need the whole blockchain to resolve names without trust.  Strip out a bell
and whistle - meaningfulness and transferability of names - and you get a
simple, rudimentary (spam killing!) system that scales on any device.  I'll
only argue that it seems to be Good Enough *for the types of people who
might care about decentralized names*.  Probably a very small set :)


On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn <mike@plan99.net> wrote:

> Interesting observation, thanks.
>
> I'd think any competent implementation of such an identity scheme would
> not involve end users directly handling randomized nonsense words, however.
> I always imagined a sacrifice as being a file that you make with a GUI tool
> and load into a browser extension.
>
>
> On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>
>> A couple more thoughts on this:
>>
>> 1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits
>> per phoneme.
>> 2) An extra phoneme (4 encode 43 bits total) gives room to put extra
>> information into the name, e.g. the first 5 bits could be input as the key
>> to a PRP that permutes the last 38 back to a standard encoding of a tx
>> location.  This would give the user 32 random names per sacrifice to choose
>> from, and 38 bits to encode its location in the blockchain, which is enough
>> for pretty large blocks.
>>
>> Sample 4 phoneme names:
>> ~milmoz-vyrnyx
>> ~mypnoz-fojzas
>> ~sawfex-bovlec
>> ~fidhut-guvgis
>> ~bobfej-jessuk
>> ~furcos-diwhuw
>> ~wokryx-wilrox
>> ~bygbyl-caggos
>> ~vewcyv-jyjsal
>> ~daxsaf-cywkul
>>
>> They're not that bad IMHO, especially if you get to pick a decent one
>> from a bunch.
>>
>>
>> On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>>
>>> The location of a tx in the blockchain can be encoded in
>>> n=log2(h)+log2(t) bits, where h is the block height, and t is the number of
>>> transactions in the block.  Currently h~250,000 and t~500, so n~27.  A CVC
>>> phoneme encodes ~10.7 bits *, so a transaction today can be located in the
>>> blockchain with 3 of these, e.g. reb-mizvig.  This is reasonably short,
>>> readable and memorable.
>>>
>>> The identity protocol Jeff Garzik is working on will link a public key
>>> fingerprint to a miner sacrifice transaction.  This tx could in turn be
>>> uniquely described with a short name as above.  Associating this name with
>>> the public key becomes secure once the tx is sufficiently buried in the
>>> blockchain.  In the identity protocol, lightweight clients check the
>>> validity of a sacrifice tx by checking that its merkle path is valid.  But
>>> this path encodes, via the ordering of the hashes at each level, the
>>> location of the transaction in the block, so the lightweight client can
>>> verify the sacrifice tx's short name using only the information he already
>>> has.
>>>
>>> Some more random names:
>>> vec-halhic
>>> wom-vizpyd
>>> guv-zussof
>>> jog-copwug
>>> seg-rizges
>>> jyg-somgod
>>> pax-synjem
>>> zyg-zuxdyj
>>> gid-mutdyj
>>> rel-hyrdaj
>>>
>>> Sources of inspiration:
>>> urbit.org
>>> https://en.bitcoin.it/wiki/Identity_protocol_v1
>>>
>>> * This is somewhat restricted: I disallowed q for obvious reasons and k
>>> because it conflicts with c, and c looks much softer and less like
>>> Klingon.  H is allowed for the first consonant, but not the second, and x
>>> is allowed for the last one, but not the first one.  Y is a vowel, but not
>>> a consonant.  Maybe these weren't quite the right choices.  Paint away!
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

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

Re: [Bitcoin-development] Identity protocol observation

[Mike Hearn]

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

1) Generate sacrifice proof file using an app
2) Load file into browser
3) Surf

Where are the names in that design? I'm not sure where NameCoin comes into
this. The point of a sacrifice is it's an anonymous identity, there's no
point attaching a name to it.

BTW I keep phone numbers in an address book ;)




On Thu, Oct 3, 2013 at 5:16 PM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:

> Fair enough, though people still manage okay with phone numbers.  And a
> decentralized naming system seems to come at great cost - with namecoin you
> need the whole blockchain to resolve names without trust.  Strip out a bell
> and whistle - meaningfulness and transferability of names - and you get a
> simple, rudimentary (spam killing!) system that scales on any device.  I'll
> only argue that it seems to be Good Enough *for the types of people who
> might care about decentralized names*.  Probably a very small set :)
>
>
> On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> Interesting observation, thanks.
>>
>> I'd think any competent implementation of such an identity scheme would
>> not involve end users directly handling randomized nonsense words, however.
>> I always imagined a sacrifice as being a file that you make with a GUI tool
>> and load into a browser extension.
>>
>>
>> On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>>
>>> A couple more thoughts on this:
>>>
>>> 1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits
>>> per phoneme.
>>> 2) An extra phoneme (4 encode 43 bits total) gives room to put extra
>>> information into the name, e.g. the first 5 bits could be input as the key
>>> to a PRP that permutes the last 38 back to a standard encoding of a tx
>>> location.  This would give the user 32 random names per sacrifice to choose
>>> from, and 38 bits to encode its location in the blockchain, which is enough
>>> for pretty large blocks.
>>>
>>> Sample 4 phoneme names:
>>> ~milmoz-vyrnyx
>>> ~mypnoz-fojzas
>>> ~sawfex-bovlec
>>> ~fidhut-guvgis
>>> ~bobfej-jessuk
>>> ~furcos-diwhuw
>>> ~wokryx-wilrox
>>> ~bygbyl-caggos
>>> ~vewcyv-jyjsal
>>> ~daxsaf-cywkul
>>>
>>> They're not that bad IMHO, especially if you get to pick a decent one
>>> from a bunch.
>>>
>>>
>>> On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>>>
>>>> The location of a tx in the blockchain can be encoded in
>>>> n=log2(h)+log2(t) bits, where h is the block height, and t is the number of
>>>> transactions in the block.  Currently h~250,000 and t~500, so n~27.  A CVC
>>>> phoneme encodes ~10.7 bits *, so a transaction today can be located in the
>>>> blockchain with 3 of these, e.g. reb-mizvig.  This is reasonably short,
>>>> readable and memorable.
>>>>
>>>> The identity protocol Jeff Garzik is working on will link a public key
>>>> fingerprint to a miner sacrifice transaction.  This tx could in turn be
>>>> uniquely described with a short name as above.  Associating this name with
>>>> the public key becomes secure once the tx is sufficiently buried in the
>>>> blockchain.  In the identity protocol, lightweight clients check the
>>>> validity of a sacrifice tx by checking that its merkle path is valid.  But
>>>> this path encodes, via the ordering of the hashes at each level, the
>>>> location of the transaction in the block, so the lightweight client can
>>>> verify the sacrifice tx's short name using only the information he already
>>>> has.
>>>>
>>>> Some more random names:
>>>> vec-halhic
>>>> wom-vizpyd
>>>> guv-zussof
>>>> jog-copwug
>>>> seg-rizges
>>>> jyg-somgod
>>>> pax-synjem
>>>> zyg-zuxdyj
>>>> gid-mutdyj
>>>> rel-hyrdaj
>>>>
>>>> Sources of inspiration:
>>>> urbit.org
>>>> https://en.bitcoin.it/wiki/Identity_protocol_v1
>>>>
>>>> * This is somewhat restricted: I disallowed q for obvious reasons and k
>>>> because it conflicts with c, and c looks much softer and less like
>>>> Klingon.  H is allowed for the first consonant, but not the second, and x
>>>> is allowed for the last one, but not the first one.  Y is a vowel, but not
>>>> a consonant.  Maybe these weren't quite the right choices.  Paint away!
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>>> from
>>> the latest Intel processors and coprocessors. See abstracts and register
>>> >
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>

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

Re: [Bitcoin-development] Identity protocol observation

[Daniel Lidstrom]

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

Names clearly solve a different problem than that, but we still use them,
so they must be solving _some_ problem :p  In this case they're a unique
identifier humans can remember after a bit of use and easily communicate to
each other with little room for error.  Securely mapping them to public
keys would make key verification simpler.  Simpler than checking a much
larger key fingerprint, at least.  Like I said, it's probably a niche
product ;)

I used to remember dozens of phone numbers before my phone did it for me,
but maybe I was just weird.


On Thu, Oct 3, 2013 at 9:22 AM, Mike Hearn <mike@plan99.net> wrote:

> 1) Generate sacrifice proof file using an app
> 2) Load file into browser
> 3) Surf
>
> Where are the names in that design? I'm not sure where NameCoin comes into
> this. The point of a sacrifice is it's an anonymous identity, there's no
> point attaching a name to it.
>
> BTW I keep phone numbers in an address book ;)
>
>
>
>
> On Thu, Oct 3, 2013 at 5:16 PM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>
>> Fair enough, though people still manage okay with phone numbers.  And a
>> decentralized naming system seems to come at great cost - with namecoin you
>> need the whole blockchain to resolve names without trust.  Strip out a bell
>> and whistle - meaningfulness and transferability of names - and you get a
>> simple, rudimentary (spam killing!) system that scales on any device.  I'll
>> only argue that it seems to be Good Enough *for the types of people who
>> might care about decentralized names*.  Probably a very small set :)
>>
>>
>> On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn <mike@plan99.net> wrote:
>>
>>> Interesting observation, thanks.
>>>
>>> I'd think any competent implementation of such an identity scheme would
>>> not involve end users directly handling randomized nonsense words, however.
>>> I always imagined a sacrifice as being a file that you make with a GUI tool
>>> and load into a browser extension.
>>>
>>>
>>> On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>>>
>>>> A couple more thoughts on this:
>>>>
>>>> 1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits
>>>> per phoneme.
>>>> 2) An extra phoneme (4 encode 43 bits total) gives room to put extra
>>>> information into the name, e.g. the first 5 bits could be input as the key
>>>> to a PRP that permutes the last 38 back to a standard encoding of a tx
>>>> location.  This would give the user 32 random names per sacrifice to choose
>>>> from, and 38 bits to encode its location in the blockchain, which is enough
>>>> for pretty large blocks.
>>>>
>>>> Sample 4 phoneme names:
>>>> ~milmoz-vyrnyx
>>>> ~mypnoz-fojzas
>>>> ~sawfex-bovlec
>>>> ~fidhut-guvgis
>>>> ~bobfej-jessuk
>>>> ~furcos-diwhuw
>>>> ~wokryx-wilrox
>>>> ~bygbyl-caggos
>>>> ~vewcyv-jyjsal
>>>> ~daxsaf-cywkul
>>>>
>>>> They're not that bad IMHO, especially if you get to pick a decent one
>>>> from a bunch.
>>>>
>>>>
>>>> On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>>>>
>>>>> The location of a tx in the blockchain can be encoded in
>>>>> n=log2(h)+log2(t) bits, where h is the block height, and t is the number of
>>>>> transactions in the block.  Currently h~250,000 and t~500, so n~27.  A CVC
>>>>> phoneme encodes ~10.7 bits *, so a transaction today can be located in the
>>>>> blockchain with 3 of these, e.g. reb-mizvig.  This is reasonably short,
>>>>> readable and memorable.
>>>>>
>>>>> The identity protocol Jeff Garzik is working on will link a public key
>>>>> fingerprint to a miner sacrifice transaction.  This tx could in turn be
>>>>> uniquely described with a short name as above.  Associating this name with
>>>>> the public key becomes secure once the tx is sufficiently buried in the
>>>>> blockchain.  In the identity protocol, lightweight clients check the
>>>>> validity of a sacrifice tx by checking that its merkle path is valid.  But
>>>>> this path encodes, via the ordering of the hashes at each level, the
>>>>> location of the transaction in the block, so the lightweight client can
>>>>> verify the sacrifice tx's short name using only the information he already
>>>>> has.
>>>>>
>>>>> Some more random names:
>>>>> vec-halhic
>>>>> wom-vizpyd
>>>>> guv-zussof
>>>>> jog-copwug
>>>>> seg-rizges
>>>>> jyg-somgod
>>>>> pax-synjem
>>>>> zyg-zuxdyj
>>>>> gid-mutdyj
>>>>> rel-hyrdaj
>>>>>
>>>>> Sources of inspiration:
>>>>> urbit.org
>>>>> https://en.bitcoin.it/wiki/Identity_protocol_v1
>>>>>
>>>>> * This is somewhat restricted: I disallowed q for obvious reasons and
>>>>> k because it conflicts with c, and c looks much softer and less like
>>>>> Klingon.  H is allowed for the first consonant, but not the second, and x
>>>>> is allowed for the last one, but not the first one.  Y is a vowel, but not
>>>>> a consonant.  Maybe these weren't quite the right choices.  Paint away!
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> October Webinars: Code for Performance
>>>> Free Intel webinars can help you accelerate application performance.
>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> most from
>>>> the latest Intel processors and coprocessors. See abstracts and
>>>> register >
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>
>

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