path: root/7d/e346564f34db4859ff3185a780f332fb8badb6

Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 938D16C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 20 May 2018 05:12:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-SG2-obe.outbound.protection.outlook.com
	(mail-oln040092253028.outbound.protection.outlook.com [40.92.253.28])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12417284
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 20 May 2018 05:12:26 +0000 (UTC)
Received: from PU1APC01FT040.eop-APC01.prod.protection.outlook.com
	(10.152.252.58) by PU1APC01HT130.eop-APC01.prod.protection.outlook.com
	(10.152.253.84) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.696.11;
	Sun, 20 May 2018 05:12:23 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.54) by
	PU1APC01FT040.mail.protection.outlook.com (10.152.253.118) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.696.11 via
	Frontend Transport; Sun, 20 May 2018 05:12:23 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) by
	PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) with mapi id
	15.20.0776.015; Sun, 20 May 2018 05:12:23 +0000
From: Damian Williamson <willtech@live.com.au>
To: Dave Scotese <dscotese@litmocracy.com>,
	"bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-discuss] Checkpoints in the Blockchain.
Thread-Index: AQHT7foFpbanfYqmX0m970nJ+zBo+qQ3hH2VgABb03WAADLFwg==
Date: Sun, 20 May 2018 05:12:23 +0000
Message-ID: <PS2P216MB01792E0070D82D4E155EDC139D960@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <CAGLBAhc6KoRNj-UB+Zo6D6NL-DcL++MM-qMMarTCOKjYLB_bPg@mail.gmail.com>
	<CADtTMvnNTkWWwGw7_u5cvTf28LEKhxcRHb_n5qctf3oLidh=ng@mail.gmail.com>
	<CAGLBAhfzrv5CD+ohEcQGXC=WzGs58+_UwaHup-e-rs-1WaFxug@mail.gmail.com>
	<CADtTMv=tjQiaSDu5zMzHpmt_EX5Ku+RSrQAGOywA3S16sj78yQ@mail.gmail.com>,
	<CAGLBAhcBPJFEidtNA0UDva-=_0e5Zn0400O9i2nwV3W4HkWnfg@mail.gmail.com>
In-Reply-To: <CAGLBAhcBPJFEidtNA0UDva-=_0e5Zn0400O9i2nwV3W4HkWnfg@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:1E492902D904316E8661306EE0273015CBC03D8425F631279BDA4903E6A0D1BE;
	UpperCasedChecksum:BAA2E233AA57B949983CC6BC86F17F294CB6306551731B2A5BF15FF0DAFBE7AD;
	SizeAsReceived:7381; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [gD9PIzGBuUtHzrJ6i+WzCIfqm66rC0UH]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT130;
	7:q35EDjq0HRhO/ZP2NtSwZ3kg9v6JMUbE0CL69l32CHS295YpD8QAyGnawJ0S7HgP+xKtFhuNWVJbbPIyRybpF6u+gfNC5ylieD5lzItU4Aln32E7g16bJjVAzEET8bp2WS31lQriVeZVN8fQfqfddlM2QPYRHep35b5e0SDQhhuUAI8IbV+NkIgBVVLZqgxp4zyaj3t42EZKpIWuGd0SexMNm4jQ8z58w6tX9t4Va4fyoRwMLNfm1JKIypUeqNY4
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045);
	SRVR:PU1APC01HT130; 
x-ms-traffictypediagnostic: PU1APC01HT130:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:PU1APC01HT130; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT130; 
x-forefront-prvs: 06780E24F8
x-forefront-antispam-report: SFV:NSPM;
	SFS:(7070007)(189003)(199004)(52314003)(110136005)(6306002)(6346003)(236005)(86362001)(3660700001)(99286004)(8676002)(11346002)(476003)(76176011)(74482002)(2501003)(7696005)(446003)(53386004)(966005)(54896002)(93886005)(55016002)(6246003)(9686003)(53546011)(81156014)(59450400001)(25786009)(53376002)(2900100001)(6506007)(486006)(3280700002)(102836004)(14454004)(551934003)(8936002)(106356001)(229853002)(104016004)(82202002)(19627405001)(606006)(6436002)(74316002)(105586002)(68736007)(14971765001)(26005)(5660300001)(97736004)(33656002)(6606003)(77096007)(7066003);
	DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT130;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None;
	PTR:InfoNoRecords; MX:1; A:1; LANG:; 
received-spf: None (protection.outlook.com: live.com.au does not designate
	permitted sender hosts)
authentication-results: spf=none (sender IP is )
	smtp.mailfrom=willtech@live.com.au; 
x-microsoft-antispam-message-info: NkhO5kpUcmCXp6ex/Bbwdq96RyEiRl5cjaerkGri+tEQAiQtMOKJ+4N262zg9NZEIxPr9oTiwOuMaYqvAwyXkOz+BOmiY5tnVcpOBPZvDTKgkCCb7lJdYd4sbC/g2Wo7UX1XRo8kjoBzKMROGy25dB6MaFotO+IXXQ1Hmi5v51jr5jo5b24hX8i2jLuZA182
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB01792E0070D82D4E155EDC139D960PS2P216MB0179KORP_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 54121694-ff20-4fb7-714b-08d5be10455a
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-Network-Message-Id: 54121694-ff20-4fb7-714b-08d5be10455a
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2018 05:12:23.4633 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT130
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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
X-Mailman-Approved-At: Sun, 20 May 2018 13:29:29 +0000
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 20 May 2018 05:12:29 -0000

--_000_PS2P216MB01792E0070D82D4E155EDC139D960PS2P216MB0179KORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I do understand your point, however, 'something like stuxnet' cannot be use=
d to create valid data without re-doing all the PoW. Provided some valid co=
pies of the blockchain continue to exist, the network can re-synchronise.


Unrelated, it would seem useful to have some kind of deep blockchain corrup=
tion 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 det=
ection. Presumably, it would be possible for some stuxnet like thing to mod=
ify blocks by modifying the table data making blocks invalid but without ca=
using 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 validat=
ion for the individual transaction?) and that the hash of its immediate anc=
estor is also valid.


Regards,

Damian Williamson


________________________________
From: bitcoin-discuss-bounces@lists.linuxfoundation.org <bitcoin-discuss-bo=
unces@lists.linuxfoundation.org> on behalf of Dave Scotese via bitcoin-disc=
uss <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.

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 do=
n't know the answer.

"The archive is a shared memory" - yes, a shared computer memory, and growi=
ng 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 pe=
ople 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, compu=
ter 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 sh=
ared 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 ever=
yone 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 serve=
d the same purpose, but this ignores the possibility that two versions of t=
he code could be created, one with a fake checkpoint that is useful to a po=
werful 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 <wordsgalore@gmail.com<mailt=
o:wordsgalore@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 proo=
f that what you're after is impossible. Hard to forget is almost the opposi=
te of many options and what we're trying to do is decide between many optio=
ns. 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 wo=
rd 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 overa=
ll structure that we are familiar with but those types of structures are fe=
w  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 r=
eality or history that we can all agree on there is also an internal consis=
tency 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 o=
n everyone's computer so it's impossible to forget and it has internal cons=
istency. 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 translati=
on of the hash into words and a story could potentially be subject to hijac=
king if it's not done perfectly correct. It just seems best to me to use th=
e 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 fi=
ts the encoding rules.

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

I hadn't thought of just making it easier to remember, as your suggestion d=
oes (12-13 words), and that's a great idea.  I have passphrases of that kin=
d, but I noticed a kind of mandela effect<https://www.snopes.com/news/2016/=
07/24/the-mandela-effect/> just with myself.  For example, I one of the wor=
ds I chose was like "olfactory" but after a few months, what I remembered w=
as 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 cate=
gorized the words according to parts of speech, the bits could be used to d=
etermine which word goes next in a kind of ad-lib, but this creates a phras=
e that is only memorable in the language for which the algorithm is develop=
ed.  As a thought experiment, I'll try adjective noun verb(as past tense) n=
oun preposition adjective adjective noun: Stuff would come out like "Able a=
bstract abused accident across actual adult affair."  not memorable at all,=
 but sense can be made of it and sometimes the sense will be remarkable.  A=
s 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<mailt=
o:wordsgalore@gmail.com>> wrote:
I disagree with your premise that this is needed, I like the question. Huma=
ns 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 wor=
ds is a common way of doing what you're thinking about. If the checkpoint c=
ould be a hash that meets a difficulty target the possibilities are 2^182 a=
t the current hashrate instead of 2^256. So we need only 12 or 13 common wo=
rds with their various possible endings (30,000).  I would find it easier t=
o 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 mo=
re 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-di=
scuss@lists.linuxfoundation.org<mailto:bitcoin-discuss@lists.linuxfoundatio=
n.org>> wrote:
I got the idea that a SHA256 hash could be rendered into something difficul=
t to forget.  The rendering would involve using each of the 256 bits to spe=
cify 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 represen=
tation 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 UTX=
O Set.  When everyone involved in Bitcoin recognizes this protection, it re=
lieves us of the need to retain the full blockchain in order to validate th=
e UTXO Set at that point, because enough people will recognize it, and it c=
an be validated without reference to any kind of prior computer record.

This does leave open the possibility that an attacker could create a more f=
avorable UTXO Set that happens to have a rendering similar enough to fool p=
eople, or one that has exactly the same SHA256-hash, but that possibility i=
s remote enough to ignore (just as we all ignore the possibility that whate=
ver creates the master seed for our HD wallet will create a unique master s=
eed).

I've been working on how such a rendering could happen.  It could describe =
music, characters, colors, plot points, memorable elements of characters, e=
tc.

Dave Scotese

_______________________________________________
bitcoin-discuss mailing list
bitcoin-discuss@lists.linuxfoundation.org<mailto:bitcoin-discuss@lists.linu=
xfoundation.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 t=
echie?
I own Litmocracy<http://www.litmocracy.com> and Meme Racing<http://www.meme=
racing.net> (in alpha).
I'm the webmaster for The Voluntaryist<http://www.voluntaryist.com> which n=
ow accepts Bitcoin.
I also code for The Dollar Vigilante<http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamo=
to



--
I like to provide some work at no charge to prove my value. Do you need a t=
echie?
I own Litmocracy<http://www.litmocracy.com> and Meme Racing<http://www.meme=
racing.net> (in alpha).
I'm the webmaster for The Voluntaryist<http://www.voluntaryist.com> which n=
ow accepts Bitcoin.
I also code for The Dollar Vigilante<http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamo=
to

--_000_PS2P216MB01792E0070D82D4E155EDC139D960PS2P216MB0179KORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size: 12pt; color: rgb(0, 0,=
 0); font-family: Calibri, Helvetica, sans-serif, &quot;EmojiFont&quot;, &q=
uot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, NotoColorEmoji, &q=
uot;Segoe UI Symbol&quot;, &quot;Android Emoji&quot;, EmojiSymbols;" dir=3D=
"ltr">
<p style=3D"margin-top:0;margin-bottom:0">I do understand your point, howev=
er, 'something like stuxnet' cannot be used to create valid data without re=
-doing all the PoW. Provided some valid copies of the blockchain continue t=
o exist, the network can re-synchronise.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">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
<u>on detection</u>. 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.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">Regards,</p>
<p style=3D"margin-top:0;margin-bottom:0">Damian Williamson<br>
</p>
<br>
<br>
<div style=3D"color: rgb(0, 0, 0);">
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" color=
=3D"#000000" face=3D"Calibri, sans-serif"><b>From:</b> bitcoin-discuss-boun=
ces@lists.linuxfoundation.org &lt;bitcoin-discuss-bounces@lists.linuxfounda=
tion.org&gt; on behalf of Dave Scotese via bitcoin-discuss
 &lt;bitcoin-discuss@lists.linuxfoundation.org&gt;<br>
<b>Sent:</b> Sunday, 20 May 2018 11:58 AM<br>
<b>To:</b> Scott Roberts<br>
<b>Cc:</b> Bitcoin Discuss<br>
<b>Subject:</b> Re: [bitcoin-discuss] Checkpoints in the Blockchain.</font>
<div>&nbsp;</div>
</div>
<meta content=3D"text/html; charset=3Dutf-8">
<div>
<div dir=3D"ltr">
<div>I wouldn't limit my rendering to words, but that is a decent starting =
point.&nbsp; 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 creati=
on of art that is, at the same time,
 highly useful and based on randomness.</div>
<div><br>
</div>
<div>Anyway, I asked what &quot;premise that this is needed&quot; you meant=
 and I still don't know the answer.</div>
<div><br>
</div>
<div>&quot;The archive is a shared memory&quot; - yes, a shared <b>computer=
</b> 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 <i>humans=
</i> whose memories are not so easily overwritten, computer data is remarka=
bly non-memorable in it's normal form (0-9,a-f, whatever).&nbsp; 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.&nbsp; Yes, of course the blockchain is the perfe=
ct solution, as long as there is
<b>exactly one</b> and everyone can see that it's the same one that everyon=
e else sees.&nbsp; Any other number of archives presents a great difficulty=
.<br>
</div>
<div><br>
</div>
<div>In that scenario, there's no other way to prove that the starting poin=
t is valid.&nbsp; Bitcoin has included a hardcoded-checkpoint in the code w=
hich served the same purpose, but this ignores the possibility that two ver=
sions of the code could be created, one
 with a fake checkpoint that is useful to a powerful attacker.&nbsp; 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.<br>
</div>
</div>
<div class=3D"x_gmail_extra"><br>
<div class=3D"x_gmail_quote">On Sat, May 19, 2018 at 5:22 PM, Scott Roberts=
 <span dir=3D"ltr">
&lt;<a href=3D"mailto:wordsgalore@gmail.com" target=3D"_blank" id=3D"LPlnk1=
94674" class=3D"OWAAutoLink" previewremoved=3D"true">wordsgalore@gmail.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex; border-left=
:1px #ccc solid; padding-left:1ex">
<div dir=3D"auto">I just don't see the point of needing to know it any diff=
erent from the hex value. Or maybe I should say I can't imagine it being us=
eful 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 En=
glish because&nbsp; 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&nbsp; i=
s one that&nbsp; fits into an overall structure
 that we are familiar with but those types of structures are few&nbsp; comp=
ared to the possibilities that we're trying to encode. &quot;Hard to deny&q=
uot; is a type of &quot;hard to forget&quot;. 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 impossible to forg=
et 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 th=
e 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&nbsp; a fake history=
. The archive is a shared memory that
 fits the encoding rules.</div>
<div class=3D"x_HOEnZb">
<div class=3D"x_h5"><br>
<div class=3D"x_gmail_quote">
<div dir=3D"ltr">On Sat, May 19, 2018, 4:30 PM Dave Scotese &lt;<a href=3D"=
mailto:dscotese@litmocracy.com" target=3D"_blank" id=3D"LPlnk529846" class=
=3D"OWAAutoLink" previewremoved=3D"true">dscotese@litmocracy.com</a>&gt; wr=
ote:<br>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex; border-left=
:1px #ccc solid; padding-left:1ex">
<div dir=3D"ltr">
<div>Did you mean the premise that we have &quot;the need to retain the ful=
l blockchain in order to validate the UTXO Set&quot;?<br>
</div>
<div><br>
</div>
<div>I hadn't thought of just making it <i>easier</i> to remember, as your =
suggestion does (12-13 words), and that's a great idea.&nbsp; I have passph=
rases of that kind, but I noticed a kind of
<a href=3D"https://www.snopes.com/news/2016/07/24/the-mandela-effect/" rel=
=3D"noreferrer" target=3D"_blank" id=3D"LPlnk311474" class=3D"OWAAutoLink" =
previewremoved=3D"true">
mandela effect</a> just with myself.&nbsp; For example, I one of the words =
I chose was like &quot;olfactory&quot; but after a few months, what I remem=
bered was like &quot;ontology&quot;. The solution I came up with is to coup=
le the data with far more items than we normally do.&nbsp; Every
 ten minutes, we get a new set of 256 bits that can be used to create somet=
hing potential
<i>very difficult</i> to forget, and that's what I'm after.</div>
<div><br>
</div>
<div>An algorithm could be used to do this with the Bip39 word list.&nbsp; =
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.&nbsp; As a thought expe=
riment, I'll try adjective noun verb(as past tense) noun preposition adject=
ive adjective noun: Stuff would come out like &quot;Able abstract abused ac=
cident across actual adult affair.&quot;&nbsp; not memorable
 at all, but sense can be made of it and sometimes the sense will be remark=
able.&nbsp; As it is, I will have forgotten it in an hour or two.<br>
</div>
</div>
<div class=3D"x_gmail_extra"><br>
<div class=3D"x_gmail_quote">On Thu, May 17, 2018 at 4:29 PM, Scott Roberts=
 <span dir=3D"ltr">
&lt;<a href=3D"mailto:wordsgalore@gmail.com" rel=3D"noreferrer" target=3D"_=
blank" id=3D"LPlnk734576" class=3D"OWAAutoLink" previewremoved=3D"true">wor=
dsgalore@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex; border-left=
:1px #ccc solid; padding-left:1ex">
<div dir=3D"auto">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 anot=
her repository at hand that we can categorize for memory that is better tha=
n words. Using words is a common way
 of doing what you're thinking about. If the checkpoint could be a hash tha=
t meets a difficulty target the possibilities are 2^182 at the current hash=
rate instead of 2^256. So we need only 12 or 13 common words with their var=
ious possible endings (30,000).&nbsp;
 I would find it easier to insert&nbsp; 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 encoding =
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.</div>
<br>
<div class=3D"x_gmail_quote">
<div>
<div class=3D"x_m_3687701302981427351m_4601416284332251381h5">
<div dir=3D"ltr">On Thu, May 17, 2018, 12:13 PM Dave Scotese via bitcoin-di=
scuss &lt;<a href=3D"mailto:bitcoin-discuss@lists.linuxfoundation.org" rel=
=3D"noreferrer" target=3D"_blank" id=3D"LPlnk791085" class=3D"OWAAutoLink" =
previewremoved=3D"true">bitcoin-discuss@lists.<wbr>linuxfoundation.org</a>&=
gt;
 wrote:<br>
</div>
</div>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex; border-left=
:1px #ccc solid; padding-left:1ex">
<div>
<div class=3D"x_m_3687701302981427351m_4601416284332251381h5">
<div dir=3D"ltr">
<div>I got the idea that a SHA256 hash could be rendered into something dif=
ficult to forget.&nbsp; 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.</div>
<div><br>
</div>
<div>Let's assume such a rendering is possible, and that at any time, any p=
erson can execute the rendering against the SHA256 hash of a consistent rep=
resentation of the UTXO Set.&nbsp; Sometimes, someone will execute the rend=
ering and discover that it is remarkable
 in some way (making it even more memorable), and therefore will publish it=
.<br>
</div>
<div><br>
</div>
<div>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.&nbsp; 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.<br>
</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>I've been working on how such a rendering could happen.&nbsp; It could=
 describe music, characters, colors, plot points, memorable elements of cha=
racters, etc.</div>
<div><br>
</div>
<div>Dave Scotese<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
______________________________<wbr>_________________<br>
bitcoin-discuss mailing list<br>
<a href=3D"mailto:bitcoin-discuss@lists.linuxfoundation.org" rel=3D"norefer=
rer noreferrer" target=3D"_blank" id=3D"LPlnk668661" class=3D"OWAAutoLink" =
previewremoved=3D"true">bitcoin-discuss@lists.<wbr>linuxfoundation.org</a><=
br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discu=
ss" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank" id=3D"LPlnk6=
66715" class=3D"OWAAutoLink" previewremoved=3D"true">https://lists.linuxfou=
ndation.<wbr>org/mailman/listinfo/bitcoin-<wbr>discuss</a><br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<br clear=3D"all">
<br>
-- <br>
<div class=3D"x_m_3687701302981427351m_4601416284332251381gmail_signature">
<div dir=3D"ltr">I like to provide some work at no charge to prove my value=
. Do you need a techie?&nbsp;
<br>
I own <a href=3D"http://www.litmocracy.com" rel=3D"noreferrer" target=3D"_b=
lank" id=3D"LPlnk280464" class=3D"OWAAutoLink" previewremoved=3D"true">
Litmocracy</a> and <a href=3D"http://www.memeracing.net" rel=3D"noreferrer"=
 target=3D"_blank" id=3D"LPlnk811111" class=3D"OWAAutoLink" previewremoved=
=3D"true">
Meme Racing</a> (in alpha). <br>
I'm the webmaster for <a href=3D"http://www.voluntaryist.com" rel=3D"norefe=
rrer" target=3D"_blank" id=3D"LPlnk171451" class=3D"OWAAutoLink" previewrem=
oved=3D"true">
The Voluntaryist</a> which now accepts Bitcoin.<br>
I also code for <a href=3D"http://dollarvigilante.com/" rel=3D"noreferrer" =
target=3D"_blank" id=3D"LPlnk753958" class=3D"OWAAutoLink" previewremoved=
=3D"true">
The Dollar Vigilante</a>.<br>
&quot;He ought to find it more profitable to play by the rules&quot; - Sato=
shi Nakamoto</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear=3D"all">
<br>
-- <br>
<div class=3D"x_gmail_signature">
<div dir=3D"ltr">I like to provide some work at no charge to prove my value=
. Do you need a techie?&nbsp;
<br>
I own <a href=3D"http://www.litmocracy.com" target=3D"_blank" id=3D"LPlnk44=
8217" class=3D"OWAAutoLink" previewremoved=3D"true">
Litmocracy</a> and <a href=3D"http://www.memeracing.net" target=3D"_blank" =
id=3D"LPlnk20419" class=3D"OWAAutoLink" previewremoved=3D"true">
Meme Racing</a> (in alpha). <br>
I'm the webmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_bl=
ank" id=3D"LPlnk762533" class=3D"OWAAutoLink" previewremoved=3D"true">
The Voluntaryist</a> which now accepts Bitcoin.<br>
I also code for <a href=3D"http://dollarvigilante.com/" target=3D"_blank" i=
d=3D"LPlnk136274" class=3D"OWAAutoLink" previewremoved=3D"true">
The Dollar Vigilante</a>.<br>
&quot;He ought to find it more profitable to play by the rules&quot; - Sato=
shi Nakamoto</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_PS2P216MB01792E0070D82D4E155EDC139D960PS2P216MB0179KORP_--