Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EFCEE15FD for ; Mon, 21 May 2018 20:03:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56E48180 for ; Mon, 21 May 2018 20:03:40 +0000 (UTC) Received: by mail-lf0-f54.google.com with SMTP id j193-v6so25672060lfg.6 for ; Mon, 21 May 2018 13:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=j2PKtyCiDEvU7OYeNYmWvQTdlx0BXhHQZ93gU3nH8+o=; b=dhRA6NSr3m0faLW4zDSn8jHm8OVLMy+ZVb9YBkXNEyCg1P352S2IuK+vDjAJ4COfTb arw28dt/8SiReM7HheTuIWgM/tnfr46CsIiLpDfea6b0z3DQ6F8uaMjw+P1UM7uzaX1u dMBpplDJZ07bkwaDxIWy3nMp7yGJbTA6IndbpC8wRmmrtScaRlaiT7KiEwzrQS8rOtgk Skb++X8yB4r00NyzcVx471/mvT5HoLtMoOJGCvSHNcrpxEx5uvh1ndV8lMjI4Ik0ti8A hOHb7yNANUV2aWtvo6sBMdGSqm6BYqnuiV7gXvffT5R2uAko3RaMf99Isam9M4EyH+o2 ZoNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=j2PKtyCiDEvU7OYeNYmWvQTdlx0BXhHQZ93gU3nH8+o=; b=CUxKRhtx1R91xyqOqfUL5Z/btyplNh/nLDvv4MQLEMzreMSzr4DeOqjt17wBsK3kS1 TgnZuVnJTAkq62MRzy4DDpt8A6FQKn6abVKOqAmZrBxOgJ4fVgW+KDKM7kQRbBaYS9Dd ETN9SbKEA4PljwblhPVbHLGPSC+3ktyBYz+H2zpfIahlAc5z1+jJpYAjNBERkocFoDci owoNzqO6NCWaqsHnUFcLX3RAvIP6emGciGjPWEUpvvZl6SarmtkwM1xmg7Fu3K939DTC 9F4tbd/pLA8bEQryE3plI4iK88ATK10ps3S6Cb8HB1FPTAWNr5RZsvyVMk1U5EmdYFZs c34A== X-Gm-Message-State: ALKqPweQp0dwuO1WmJph9xI3nBFbM4gyJNRbv/F0L7pUTtggG8QI/87U Ce2vqBBXZfvSvOPEcZDY3vLnULmle2tC8p8nC8o= X-Google-Smtp-Source: AB8JxZpidwGfbuXqpx8onjxn1nmobEhH8vUkPkQW+NfNUOIii3OzQBksfnmf1U8lJaDkFXSyQNey0qDowU1c7KIhv+A= X-Received: by 2002:a19:1b90:: with SMTP id b138-v6mr4113819lfb.17.1526933018578; Mon, 21 May 2018 13:03:38 -0700 (PDT) MIME-Version: 1.0 Sender: dscotese@gmail.com Received: by 2002:a19:d40c:0:0:0:0:0 with HTTP; Mon, 21 May 2018 13:03:37 -0700 (PDT) In-Reply-To: References: From: Dave Scotese Date: Mon, 21 May 2018 13:03:37 -0700 X-Google-Sender-Auth: ofn3jk41i71dppeb6PZ9KlmG3_4 Message-ID: To: Damian Williamson Content-Type: multipart/alternative; boundary="0000000000002b13c4056cbccca5" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [bitcoin-discuss] Checkpoints in the Blockchain. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 20:03:43 -0000 --0000000000002b13c4056cbccca5 Content-Type: text/plain; charset="UTF-8" Our wetware memory is faulty at details, but a rendering that provides features at which it isn't faulty makes it a decent backup in situations where technology has been used to hide important differences from us. Some of us may recall being in a situation where something seems off, and we start to investigate, and then we discover that something was off. April Fools jokes are good examples, as well as satire and news reports from The Onion. The point of storing the entire blockchain history is to prevent any of that history being changed in a way that illicitly alters the UTXO Set. Whenever a memorable enough rendering of the UTXO Set is produced (which has happened exactly once - when Bitcoin started, it was empty, and after that, it just looks like a bunch of random computer data), the risk of altering the history before it goes up, even if you have the computing power to make subsequent block headers follow all the rules (and even to successfully execute a 51% attack!). In this announcement , the first item under "new features" has this, which follows the same principle as my idea: Introduce experimental SSH Fingerprint ASCII Visualisation to ssh(1) and > ssh-keygen(1). Visual fingerprinnt display is controlled by a new > ssh_config(5) option "VisualHostKey". The intent is to render SSH host keys > in a visual form that is amenable to easy recall and rejection of changed > host keys. This technique inspired by the graphical hash visualisation > schemes known as "random art[*]", and by Dan Kaminsky's musings at 23C3 in > Berlin. > On Sat, May 19, 2018 at 10:12 PM, Damian Williamson wrote: > I do understand your point, however, 'something like stuxnet' cannot be > used to create valid data without re-doing all the PoW. Provided some valid > copies of the blockchain continue to exist, the network can re-synchronise. > > > Unrelated, it would seem useful to have some kind of deep blockchain > corruption recovery mechanism if it does not exist; where blocks are > altered at a depth exceeding the re-scan on init, efficient recovery is > possible *on detection*. Presumably, it would be possible for some > stuxnet like thing to modify blocks by modifying the table data making > blocks invalid but without causing a table corruption. I would also suppose > that if the node is delving deep into the blockchain for transaction data, > that is would also validate the block at least that it has a valid hash > (apart from Merkle tree validation for the individual transaction?) and > that the hash of its immediate ancestor is also valid. > > > Regards, > > Damian Williamson > > > ------------------------------ > *From:* bitcoin-discuss-bounces@lists.linuxfoundation.org < > bitcoin-discuss-bounces@lists.linuxfoundation.org> on behalf of Dave > Scotese via bitcoin-discuss > *Sent:* Sunday, 20 May 2018 11:58 AM > *To:* Scott Roberts > *Cc:* Bitcoin Discuss > *Subject:* Re: [bitcoin-discuss] Checkpoints in the Blockchain. > > I wouldn't limit my rendering to words, but that is a decent starting > point. The richer the rendering, the harder it will be to forget, but it > needn't all be developed at once. My goal here is to inspire the creation > of art that is, at the same time, highly useful and based on randomness. > > Anyway, I asked what "premise that this is needed" you meant and I still > don't know the answer. > > "The archive is a shared memory" - yes, a shared *computer* memory, and > growing larger (ie more cumbersome) every day. If something like stuxnet is > used to change a lot of the copies of it at some point, it seems likely > that people will notice a change, but which history is correct won't be so > obvious because for the *humans* whose memories are not so easily > overwritten, computer data is remarkably non-memorable in it's normal form > (0-9,a-f, whatever). If we ever want to abandon the historical transaction > data, having a shared memory of the state of a recent UTXO Set will help to > obviate the need for it. Yes, of course the blockchain is the perfect > solution, as long as there is *exactly one* and everyone can see that > it's the same one that everyone else sees. Any other number of archives > presents a great difficulty. > > In that scenario, there's no other way to prove that the starting point is > valid. Bitcoin has included a hardcoded-checkpoint in the code which > served the same purpose, but this ignores the possibility that two versions > of the code could be created, one with a fake checkpoint that is useful to > a powerful attacker. If the checkpoint were rendered into something > memorable at the first opportunity, there would be little question about > which one is correct when the difference is discovered. > > On Sat, May 19, 2018 at 5:22 PM, Scott Roberts > wrote: > > I just don't see the point of needing to know it any different from the > hex value. Or maybe I should say I can't imagine it being useful because I > can't imagine what you're after is possible. There might be a theoretical > proof that what you're after is impossible. Hard to forget is almost the > opposite of many options and what we're trying to do is decide between many > options. I'll assume English because it's the only starting point I have > that's even in the ballpark of being possible. You might need to constrain > the word selection and the structure in which you put it. I can only > imagine that you are talking about putting the words into some sort of > story. The only kind of story that would be hard to forget is one that > fits into an overall structure that we are familiar with but those types of > structures are few compared to the possibilities that we're trying to > encode. "Hard to deny" is a type of "hard to forget". Besides trying to > connect it to external reality or history that we can all agree on there is > also an internal consistency that could be used like a checksum such as the > structure I mentioned. The only thing that seems to fit the bill is the > blockchain itself. It's on everyone's computer so it's impossible to forget > and it has internal consistency. Is the only shared memory we have that > can't be subject to a Sybil attack or other hijacking of our memory of the > true history. Our translation of the hash into words and a story could > potentially be subject to hijacking if it's not done perfectly correct. It > just seems best to me to use the hash itself. They archived existence of > the prior parts of the blockchain are what make that particular hash hard > to forget. Supposedly it can't be forged to reference a fake history. The > archive is a shared memory that fits the encoding rules. > > On Sat, May 19, 2018, 4:30 PM Dave Scotese > wrote: > > Did you mean the premise that we have "the need to retain the full > blockchain in order to validate the UTXO Set"? > > I hadn't thought of just making it *easier* to remember, as your > suggestion does (12-13 words), and that's a great idea. I have passphrases > of that kind, but I noticed a kind of mandela effect > just with > myself. For example, I one of the words I chose was like "olfactory" but > after a few months, what I remembered was like "ontology". The solution I > came up with is to couple the data with far more items than we normally > do. Every ten minutes, we get a new set of 256 bits that can be used to > create something potential *very difficult* to forget, and that's what > I'm after. > > An algorithm could be used to do this with the Bip39 word list. If we > categorized the words according to parts of speech, the bits could be used > to determine which word goes next in a kind of ad-lib, but this creates a > phrase that is only memorable in the language for which the algorithm is > developed. As a thought experiment, I'll try adjective noun verb(as past > tense) noun preposition adjective adjective noun: Stuff would come out like > "Able abstract abused accident across actual adult affair." not memorable > at all, but sense can be made of it and sometimes the sense will be > remarkable. As it is, I will have forgotten it in an hour or two. > > On Thu, May 17, 2018 at 4:29 PM, Scott Roberts > wrote: > > I disagree with your premise that this is needed, I like the question. > Humans are experts at language and I don't think we have another repository > at hand that we can categorize for memory that is better than words. Using > words is a common way of doing what you're thinking about. If the > checkpoint could be a hash that meets a difficulty target the possibilities > are 2^182 at the current hashrate instead of 2^256. So we need only 12 or > 13 common words with their various possible endings (30,000). I would find > it easier to insert a letter and 3 numbers after every 2 words so there > would be only 8 words used. There are probably other tricks people have > figured out but there can't be any kind of advanced encoding because it > wouldn't benefit more than one word. There might be a way to convert the > words into something that almost sounds like English sentences but it would > probably come out a cost of at least doubling the number of words. > > On Thu, May 17, 2018, 12:13 PM Dave Scotese via bitcoin-discuss < > bitcoin-discuss@lists.linuxfoundation.org> wrote: > > I got the idea that a SHA256 hash could be rendered into something > difficult to forget. The rendering would involve using each of the 256 > bits to specify something important about the rendering - important in an > instinctive human-memory way. > > Let's assume such a rendering is possible, and that at any time, any > person can execute the rendering against the SHA256 hash of a consistent > representation of the UTXO Set. Sometimes, someone will execute the > rendering and discover that it is remarkable in some way (making it even > more memorable), and therefore will publish it. > > The published, memorable rendering now becomes a kind of protection > against any possible re-writing of the blockchain from any point prior to > that UTXO Set. When everyone involved in Bitcoin recognizes this > protection, it relieves us of the need to retain the full blockchain in > order to validate the UTXO Set at that point, because enough people will > recognize it, and it can be validated without reference to any kind of > prior computer record. > > This does leave open the possibility that an attacker could create a more > favorable UTXO Set that happens to have a rendering similar enough to fool > people, or one that has exactly the same SHA256-hash, but that possibility > is remote enough to ignore (just as we all ignore the possibility that > whatever creates the master seed for our HD wallet will create a unique > master seed). > > I've been working on how such a rendering could happen. It could describe > music, characters, colors, plot points, memorable elements of characters, > etc. > > Dave Scotese > > _______________________________________________ > bitcoin-discuss mailing list > bitcoin-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss > > > > > -- > I like to provide some work at no charge to prove my value. Do you need a > techie? > I own Litmocracy and Meme Racing > (in alpha). > I'm the webmaster for The Voluntaryist > which now accepts Bitcoin. > I also code for The Dollar Vigilante . > "He ought to find it more profitable to play by the rules" - Satoshi > Nakamoto > > > > > -- > I like to provide some work at no charge to prove my value. Do you need a > techie? > I own Litmocracy and Meme Racing > (in alpha). > I'm the webmaster for The Voluntaryist > which now accepts Bitcoin. > I also code for The Dollar Vigilante . > "He ought to find it more profitable to play by the rules" - Satoshi > Nakamoto > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --0000000000002b13c4056cbccca5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Our wetware memory is faulty at details, but a rendering that provides= features at which it isn't faulty makes it a decent backup in situatio= ns where technology has been used to hide important differences from us. So= me of us may recall being in a situation where something seems off, and we = start to investigate, and then we discover that something was off.=C2=A0 Ap= ril Fools jokes are good examples, as well as satire and news reports from = The Onion.

The point of storing the entire blockch= ain history is to prevent any of that history being changed in a way that i= llicitly alters the UTXO Set.=C2=A0 Whenever a memorable enough rendering o= f the UTXO Set is produced (which has happened exactly once - when Bitcoin = started, it was empty, and after that, it just looks like a bunch of random= computer data), the risk of altering the history before it goes up, even i= f you have the computing power to make subsequent block headers follow all = the rules (and even to successfully execute a 51% attack!).=C2=A0=20 In this announcement, the first item under "new feature= s" has this, which follows the same principle as my idea:
Introduce experimental SSH Fingerprint ASCII Visualisation to ssh(1) and ssh-keygen(1). Visual fingerprinnt display is controlled by a new ssh_config(5) option "VisualHostKey". The intent is to render SSH host keys in a visual form that is amenable to easy recall and rejection of changed host keys. This technique inspired by the graphical hash visualisation schemes known as "random art[*]", and by Dan Kaminsky's musings at 23C3 in Berlin.

=C2=A0

On Sat, May 19, 2018 at 10:12 PM,= Damian Williamson <willtech@live.com.au> wrote:

I do understand your point, howev= er, 'something like stuxnet' cannot be used to create valid data wi= thout re-doing all the PoW. Provided some valid copies of the blockchain co= ntinue to exist, the network can re-synchronise.


Unrelated, it would seem useful t= o have some kind of deep blockchain corruption recovery mechanism if it doe= s not exist; where blocks are altered at a depth exceeding the re-scan on i= nit, efficient recovery is possible on detection. Presumably, it would be possible for some stuxnet like= thing to modify blocks by modifying the table data making blocks invalid b= ut without causing a table corruption. I would also suppose that if the nod= e is delving deep into the blockchain for transaction data, that is would also validate the block at least that = it has a valid hash (apart from Merkle tree validation for the individual t= ransaction?) and that the hash of its immediate ancestor is also valid.


Regards,

Damian Williamson



From:= bitcoin-discuss-bounces@lists.linuxfoundation.org <= ;bitcoin-discuss-bounces@lists.linuxfoundation.org>= on behalf of Dave Scotese via bitcoin-discuss <bitcoin-discuss@lists.linuxfoundation.org>
Sent: Sunday, 20 May 2018 11:58 AM
To: Scott Roberts
Cc: Bitcoin Discuss
Subject: Re: [bitcoin-discuss] Checkpoints in the Blockchain.
=C2=A0
I wouldn't limit my rendering to words, but that is a decent start= ing point.=C2=A0 The richer the rendering, the harder it will be to forget,= but it needn't all be developed at once. My goal here is to inspire th= e creation of art that is, at the same time, highly useful and based on randomness.

Anyway, I asked what "premise that this is needed" you meant= and I still don't know the answer.

"The archive is a shared memory" - yes, a shared computer= memory, and growing larger (ie more cumbersome) every day. If somethin= g like stuxnet is used to change a lot of the copies of it at some point, i= t seems likely that people will notice a change, but which history is correct won't be so obvious because for the hu= mans whose memories are not so easily overwritten, computer data is rem= arkably non-memorable in it's normal form (0-9,a-f, whatever).=C2=A0 If= we ever want to abandon the historical transaction data, having a shared memory of the state of a recent UTXO Set will help t= o obviate the need for it.=C2=A0 Yes, of course the blockchain is the perfe= ct solution, as long as there is exactly one and everyone can see that it's the same one that eve= ryone else sees.=C2=A0 Any other number of archives presents a great diffic= ulty.

In that scenario, there's no other way to prove that the starting = point is valid.=C2=A0 Bitcoin has included a hardcoded-checkpoint in the co= de which served the same purpose, but this ignores the possibility that two= versions of the code could be created, one with a fake checkpoint that is useful to a powerful attacker.=C2=A0 If the= checkpoint were rendered into something memorable at the first opportunity= , there would be little question about which one is correct when the differ= ence is discovered.

On Sat, May 19, 2018 at = 5:22 PM, Scott Roberts <wo= rdsgalore@gmail.com> wrote:
I just don't see the point of needing to know it any = different from the hex value. Or maybe I should say I can't imagine it = being useful because I can't imagine what you're after is possible.= There might be a theoretical proof that what you're after is impossible. Hard to forget is almost the opposite of many options= and what we're trying to do is decide between many options. I'll a= ssume English because=C2=A0 it's the only starting point I have that= 9;s even in the ballpark of being possible. You might need to constrain the word selection and the structure in which you put it= . I can only imagine that you are talking about putting the words into some= sort of story. The only kind of story that would be hard to forget=C2=A0 i= s one that=C2=A0 fits into an overall structure that we are familiar with but those types of structures are few=C2=A0 comp= ared to the possibilities that we're trying to encode. "Hard to de= ny" is a type of "hard to forget". Besides trying to connect= it to external reality or history that we can all agree on there is also an internal consistency that could be used like a checksum such as= the structure I mentioned. The only thing that seems to fit the bill is th= e blockchain itself. It's on everyone's computer so it's imposs= ible to forget and it has internal consistency. Is the only shared memory we have that can't be subject to a Sybil att= ack or other hijacking of our memory of the true history. Our translation o= f the hash into words and a story could potentially be subject to hijacking= if it's not done perfectly correct. It just seems best to me to use the hash itself. They archived existence o= f the prior parts of the blockchain are what make that particular hash hard= to forget. Supposedly it can't be forged to reference=C2=A0 a fake his= tory. The archive is a shared memory that fits the encoding rules.

On Sat, May 19, 2018, 4:30 PM Dave Scotese <dscotese@litmoc= racy.com> wrote:
Did you mean the premise that we have "the need to retain the ful= l blockchain in order to validate the UTXO Set"?

I hadn't thought of just making it easier to remember, as y= our suggestion does (12-13 words), and that's a great idea.=C2=A0 I hav= e passphrases of that kind, but I noticed a kind of mandela effect just with myself.=C2=A0 For example, I one of the words = I chose was like "olfactory" but after a few months, what I remem= bered was like "ontology". The solution I came up with is to coup= le the data with far more items than we normally do.=C2=A0 Every ten minutes, we get a new set of 256 bits that can be used to create somet= hing potential very difficult to forget, and that's what I'm after.

An algorithm could be used to do this with the Bip39 word list.=C2=A0 = If we categorized the words according to parts of speech, the bits could be= used to determine which word goes next in a kind of ad-lib, but this creat= es a phrase that is only memorable in the language for which the algorithm is developed.=C2=A0 As a thought expe= riment, I'll try adjective noun verb(as past tense) noun preposition ad= jective adjective noun: Stuff would come out like "Able abstract abuse= d accident across actual adult affair."=C2=A0 not memorable at all, but sense can be made of it and sometimes the sense will be remark= able.=C2=A0 As it is, I will have forgotten it in an hour or two.

On Thu, May 17, 2018 at = 4:29 PM, Scott Roberts <wordsgalore@gmail.com> wrote:
I disagree with your premise that this is needed, I like = the question. Humans are experts at language and I don't think we have = another repository at hand that we can categorize for memory that is better= than words. Using words is a common way of doing what you're thinking about. If the checkpoint could be a hash= that meets a difficulty target the possibilities are 2^182 at the current = hashrate instead of 2^256. So we need only 12 or 13 common words with their= various possible endings (30,000).=C2=A0 I would find it easier to insert=C2=A0 a letter and 3 numbers after every = 2 words so there would be only 8 words used. There are probably other trick= s people have figured out but there can't be any kind of advanced encod= ing because it wouldn't benefit more than one word. There might be a way to convert the words into something that al= most sounds like English sentences but it would probably come out a cost of= at least doubling the number of words.

On Thu, May 17, 2018, 12:13 PM Dave Scotese via bitcoin-di= scuss <bitcoin-discuss@lists.linuxfoundation.org> wrote:
I got the idea that a SHA256 hash could be rendered into something dif= ficult to forget.=C2=A0 The rendering would involve using each of the 256 b= its to specify something important about the rendering - important in an in= stinctive human-memory way.

Let's assume such a rendering is possible, and that at any time, a= ny person can execute the rendering against the SHA256 hash of a consistent= representation of the UTXO Set.=C2=A0 Sometimes, someone will execute the = rendering and discover that it is remarkable in some way (making it even more memorable), and therefore will publish it= .

The published, memorable rendering now becomes a kind of protection ag= ainst any possible re-writing of the blockchain from any point prior to tha= t UTXO Set.=C2=A0 When everyone involved in Bitcoin recognizes this protect= ion, it relieves us of the need to retain the full blockchain in order to validate the UTXO Set at that point, becau= se enough people will recognize it, and it can be validated without referen= ce to any kind of prior computer record.

This does leave open the possibility that an attacker could create a m= ore favorable UTXO Set that happens to have a rendering similar enough to f= ool people, or one that has exactly the same SHA256-hash, but that possibil= ity is remote enough to ignore (just as we all ignore the possibility that whatever creates the master seed for= our HD wallet will create a unique master seed).

I've been working on how such a rendering could happen.=C2=A0 It c= ould describe music, characters, colors, plot points, memorable elements of= characters, etc.

Dave Scotese

_______________________________________________
bitcoin-discuss mailing list
bitcoin-discuss@lists.linuxfou<= wbr>ndation.org
ht= tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss<= /a>



--
I like to provide some work at no charge to prove my value= . Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more profitable to play by the rules" - Sato= shi Nakamoto



--
I like to provide some work at no charge to prove my value= . Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more profitable to play by the rules" - Sato= shi Nakamoto



--
I like to provi= de some work at no charge to prove my value. Do you need a techie?=C2=A0 I own Litmocracy<= /a> and Meme Racing= (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoi= n.
I also code for The Dollar Vigilante.
"He ought to find it more profitable= to play by the rules" - Satoshi Nakamoto
--0000000000002b13c4056cbccca5--