path: root/0f/f0afab40348096594d30f28f019451dfb4aeda

Return-Path: <outlook_32F81FD1D1BD8CA0@outlook.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 86AAA978
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 13 Feb 2017 11:58:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from BAY004-OMC3S27.hotmail.com (bay004-omc3s27.hotmail.com
	[65.54.190.165])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4967D106
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 13 Feb 2017 11:58:11 +0000 (UTC)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com ([65.54.190.187])
	by BAY004-OMC3S27.hotmail.com over TLS secured channel with
	Microsoft SMTPSVC(7.5.7601.23008); Mon, 13 Feb 2017 03:58:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
	s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; 
	bh=iXWsOI1eCvfAD6BGHmAw3gqamMLh5mQnRQn0VY2UHMs=;
	b=K8MLgSGc2Va2+P8f+Xl3y48yPdNacAtjbgc92k1CtyjOJfbs4fEXC7lVy3dJsdtD6TEPc/uqBIcM7kSsOQMwQ/7n6AU5iv8EyCvA8uxXlsPLu+8gQVQsQgC2jAdCRoBe4TPz/vPI0QRAszaDkvSOTULZEJkoNAAOkkWmQmYXtklWqh7XMecxGMiglZA99HO5e5OyhJUCcHRKGw6J3hUGIp1DOevMPEAqpcAHMHZuuZkF23OrOyAIRYGQu5adWaxCbCBNcm2ySmLO4Pq3JLtWvYFWkM9TCNFqNDwECD5vdwFy7k7kL74Rk350Af0Jnpvp+i7azO0Dc7Mes6N6kJNpfg==
Received: from SN1NAM01FT043.eop-nam01.prod.protection.outlook.com
	(10.152.64.51) by SN1NAM01HT132.eop-nam01.prod.protection.outlook.com
	(10.152.64.139) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.904.16;
	Mon, 13 Feb 2017 11:58:09 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.64.56) by
	SN1NAM01FT043.mail.protection.outlook.com (10.152.65.216) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
	15.1.904.16 via Frontend Transport; Mon, 13 Feb 2017 11:58:09 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com ([10.141.92.24]) by
	BL2PR03MB435.namprd03.prod.outlook.com ([10.141.92.24]) with mapi id
	15.01.0888.030; Mon, 13 Feb 2017 11:58:09 +0000
From: John Hardy <john@seebitcoin.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
	"bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Proof of Nodework (PoNW) - a method to trustlessly
	reward nodes for storing and verifying the blockchain
Thread-Index: AQHSgTURNQj70TZ4G063Cioon3OvHqFl2RGAgAD29N4=
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Mon, 13 Feb 2017 11:58:09 +0000
Message-ID: <BL2PR03MB4355F39BE003DBF200591EBEE590@BL2PR03MB435.namprd03.prod.outlook.com>
References: <BL2PR03MB435AA04A0AB8AC0E7781CA7EE430@BL2PR03MB435.namprd03.prod.outlook.com>,
	<CAKzdR-qvDcUMcFDyS_w5XvuYi+zBzH_z9rp=EqBkN3o+MyuubA@mail.gmail.com>
In-Reply-To: <CAKzdR-qvDcUMcFDyS_w5XvuYi+zBzH_z9rp=EqBkN3o+MyuubA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed)
	header.d=none; gmail.com;
	dmarc=none action=none header.from=seebitcoin.com; 
x-incomingtopheadermarker: OriginalChecksum:903F6F2B3EFE7CA2F158F80ADC47079D07B9ED7C7B8AD94E558F045249B9880E;
	UpperCasedChecksum:331DC7CBE29F0658A91421ED5DAA2B6C09CD320F8A0C2E1EE91B34F2CE866B9B;
	SizeAsReceived:8161; Count:40
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [ek8mYwUxYznHmWiM+3toW14tEXWiVeKG]
x-incomingheadercount: 40
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; SN1NAM01HT132;
	5:4KqFYHvHjZRxtFCHN1419WpeB9NjKggWsxKun7fSxHYc+/EcQK0qjN31P+Z+KOxCxspAsDcf4fFMhJ7Vv3yVQwMVTHgn16Wn4RU0WqS9dzxz7agxNweuzkoLi9j6mNHG1gdDiEw6XGyVd9AB5cSNzA==;
	24:3QF9SrhQMqvhARf8YDI3ZFvGCLN0tPhaspX1YPelKW4z7XfBZ+tO7ECTTFT0y7tQNRqC8lD5Pjkw43CI9yoAyleI55EiZa+/6Qy75uSc3F4=;
	7:Uy6MRs+/uPXklJgJ0O+NDYO4Ar9onCJ5KS30+GcXCD5zNUVVCI8b4f9pittdJUD8dy1xHhsHCHR8HViuVeAXJWOwfQh3khpQeo1ZfmhH3CstGGjjQpnOmBLXHlnp7nIyme4wXF1qnoipkZzO2fcuYXQhu7pfA2MbvGHepmxv32/e6dh5cITHxUu+v15gfLmnljIypBNdg3p32Zz1bdXmd7U+anzlzvZ7JNbakaexiPNDGpGy7XpzJBeH7zmU+Cq5AYb4sBq/wFNIpGF3udA4+dYtOfibHAPPf0gOeC5yWoSysMys+12ll18osjJVRWpL84PRDFtxchZrCsEZho8IXrXOqbdJQw6WT+zQij9ecQhbuuThY5FWR3bT5SAiyoI5Dw7aI2CoQ5BQeFxgXjEQw99415lkEC5Ufb3CPa3WQ74Vuy3xqWt5g6sPX6x03lxT/tFSeK/TKyagpalv9OAEKeWLhEuhRNtw35CKjKEJJzbfvBaXvlvThXXcb05EyyMgxPhEMV2UVrCgaAlC/PDukg==
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900007);
	DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM01HT132;
	H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: 5b50f778-e42e-4285-116e-08d454079465
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(5061506426)(5061507331)(1603103135)(1603101373)(1601125107)(1701031045);
	SRVR:SN1NAM01HT132; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015086)(82015046);
	SRVR:SN1NAM01HT132; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT132; 
x-forefront-prvs: 02176E2458
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BL2PR03MB4355F39BE003DBF200591EBEE590BL2PR03MB435namprd_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 11:58:09.1373 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT132
X-OriginalArrivalTime: 13 Feb 2017 11:58:10.0797 (UTC)
	FILETIME=[7291D1D0:01D285F0]
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 13 Feb 2017 12:07:38 +0000
Subject: Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method to
 trustlessly reward nodes for storing and verifying 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: Mon, 13 Feb 2017 11:58:12 -0000

--_000_BL2PR03MB4355F39BE003DBF200591EBEE590BL2PR03MB435namprd_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Sergio,


Thanks for your response, interesting work, very excited for RSK.


I like the ephemeral payload, I suppose that aspect of my proposal could be=
 described as ephemeral blockspace.


I'm curious about the challenge phase, what incentive do nodes to have to c=
heck other nodes' responses? Is any validation of responses mandatory, or d=
oes policing the system rely on altruism?


I also wondered how time-based responses are enforced? What prevents a mine=
r censoring challenge responses so they do not get included in a block 'in =
time' - if  inclusion within a block is the mechanism used?


I saw your tweet on Lumino - sounds very promising. Would be keen to take a=
 look at the paper if you're looking for any additional review at this stag=
e.


Regards,


John Hardy


________________________________
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Sent: Sunday, February 12, 2017 8:22 PM
To: John Hardy; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method to trustless=
ly reward nodes for storing and verifying the blockchain

Hi John,
 RSK platform (a Bitcoin sidechain) is already prepared to do something sim=
ilar to this, although very efficiently. We set apart 1% of the block rewar=
d to automatically reward full nodes.

We have two systems being evaluated: the first is based on PoUBS (Proof of =
Unique Blockchain Storage) which uses asymmetric-time operations to encode =
the blockchain based on each user public key such that decoding is fast, bu=
t encoding is slow. The second is more traditional proof of retrievability,=
 but it requires some ASIC-resistance assumptions.

In both cases, a special smart contract is being called at every block that=
 creates periodic challenges. Every full node that wants to participate can=
 submits a commitment to the Merkle hash root of a pseudo-random sequence o=
f encoded blocks. Then the smart contract chooses random elements from the =
committed dataset, and each full node has a period to submit Merkle-proofs =
that such random elements belong to the commitment.

To prevent blockchain bloat we designed a very cool new type of transaction=
 payload: Ephemeral Payload. Ephemeral payload is a payload in a transactio=
n that gets discarded after N blocks if no smart contract does reference it=
. If is does, it's solidified forever in the blockchain.
Then there is a challenge phase where other full nodes can inform the smart=
 contract if they find an error in the submitted responses. Then the smart =
contract ONLY evaluates the responses which have been questioned by users.

This way the smart contract does very little computation (only when a user =
misbehaves) and the blockchain normally does not store any proof forever (o=
nly the ones created by misbehaving users).

Because RSK/Rootstock has a very short block interval (10 seconds), all thi=
s happens very quickly and does not require much computation.

Best regards,
 Sergio Lerner
 Chief Scientist RSK (aka Roostock)


On Tue, Feb 7, 2017 at 8:27 AM, John Hardy via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote=
:

Proof of Nodework (PoNW) is a way to reward individual nodes for keeping a =
full copy of and verifying the blockchain.


Hopefully they also do useful =91traditional=92 node activities too like re=
lay transactions and blocks, but there isn=92t really any way I can think o=
f to trustlessly verify this also.


PoNW would require a new separate area of block space, a nodeblock, purely =
concerned with administering the system. A nodeblock is committed to a bloc=
k as with SegWit. A recent history of nodeblocks needs to be stored by node=
s, however the data eventually becomes obsolete and so does not need to be =
retained forever.


In order to prevent Sybil, a node must register an Bitcoin address by submi=
tting an addNode transaction - along with a security deposit to prevent che=
ating.


This transaction will be stored in the nodeblock. Once a node can see that =
its addNode transaction has been added it can begin the PoNW process. The n=
ode=92s registered address will be hashed with the block header of the bloc=
k it wants to work on. This will determine exactly where within the blockch=
ain to begin the PoNW.


The PoNW method could be as simple as creating a Merkle tree from the rando=
mly generated point on the blockchain, though a method that is CPU/Memory h=
eavy and less likely to be replaced by dedicated hardware like ASICs would =
be better. This process could not begin until the most recent block has bee=
n fully verified, and while being carried out should still enable normal re=
lay activities to proceed as normal, since it shouldn=92t tie up network at=
 all. The data processed should also be mixed with data from the latest blo=
ck so that it cannot be computed in advance.


A node can do as much PoNW for a block as it likes. Once finished it will t=
hen create a nodeWorkComplete transaction for that block with its final pro=
of value, add how much =91work=92 it did - and create a couple of assertion=
s about what it processed (such as there were x number of pieces of data ma=
tching a particular value during calculating). These assertions can be accu=
rate or inaccurate.


The system will run in epochs. During each epoch of say 2016 blocks, there =
will be an extended window for PoNW transactions to be added to nodeblocks =
to limit minor censorship.


The random hash generated from a node=92s address and blockhash will also b=
e used to determine nodeWorkComplete transactions from a previous block tha=
t the node must also verify, and correctly calculate whether the assertions=
 it made were true or false. The average PoNW that a node performed in its =
previous x nodeblocks will be used to determine the target PoNW for the nod=
e to verify - and this will randomly be a large number of smaller PoNW tran=
sactions, or a smaller number of large PoNW. This process will be determini=
stic based on that block and address hash. All the data will be put togethe=
r in a transaction and then signed by the node addresses private key.


If a nodeWorkComplete transaction contains any incorrect information in an =
attempt to cheat the validation process a challenge transaction can be crea=
ted. This begins a refereeing process where other nodes check the challenge=
 and vote whether it is to be upheld or not. The losing node is punished by=
 losing their accrued PoNW for that epoch and a percentage of their securit=
y deposit.


Nodes will also be punished if they broadcast more than one signed transact=
ion per block.


In order to prevent nodes from having multiple keys registered - which woul=
d enable them choose to perform PoNW on a subset of the data that they hold=
 - the share of reward that the node gets will be multiplied based on the n=
umber of blocks within an epoch that the node performs PoNW on. The share o=
f reward is limited based on how much security deposit has been staked. The=
 higher the PoNW the higher the deposit needed in order to claim their full=
 allocation of any reward.


At the end of an epoch, with a wait period for any delayed or censored tran=
sactions or challenges to be included and settled up, the process of calcul=
ating the reward each node is due can begin. This will then be then paid in=
 a regular block, and means for all the data involved in PoNW, the only per=
manent mark it makes on the main blockchain is for a transaction that pays =
all addresses their share of the reward at the end of epoch. Any miner who =
creates a block without correctly calculating and paying the due reward wil=
l have mined an invalid block and be orphaned.


The question of where and how much the reward comes from is a different one=
. It could come from the existing miner reward, or a special new tx donatio=
n fee for nodes. If there was some way for users to =91donate=92 to the rew=
ard pool for nodes this would increase the incentive for additional nodes t=
o participate on the network in the event of centralisation.


This is a relatively effective way to create a reward for all nodes partici=
pating on a network. I=92d be keen to field any questions or critiques.

Thanks,


John Hardy

john@seebitcoin.com<mailto:john@seebitcoin.com>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



--_000_BL2PR03MB4355F39BE003DBF200591EBEE590BL2PR03MB435namprd_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<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:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<p>Hi Sergio,</p>
<p><br>
</p>
<p>Thanks for your response, interesting work, very excited for RSK.</p>
<p><br>
</p>
<p>I like the ephemeral payload, I suppose that aspect of my proposal could=
 be described as ephemeral&nbsp;blockspace.</p>
<p><br>
</p>
<p>I'm curious about the challenge phase, what incentive do nodes to have t=
o check other nodes' responses? Is any validation of responses mandatory, o=
r does policing the system rely on altruism?</p>
<p><br>
</p>
<p>I also wondered how time-based responses are enforced? What prevents a m=
iner censoring challenge responses so they do not get included in a block '=
in time' - if &nbsp;inclusion within a block is the mechanism used?</p>
<p><br>
</p>
<p>I saw your tweet on Lumino - sounds very promising. Would be keen to tak=
e a look at the paper if you're looking for any additional review at this s=
tage.</p>
<p><br>
</p>
<p>Regards,</p>
<p><br>
</p>
<p>John Hardy</p>
<br>
<br>
<div style=3D"color: rgb(0, 0, 0);">
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Sergio Demian Lerner =
&lt;sergio.d.lerner@gmail.com&gt;<br>
<b>Sent:</b> Sunday, February 12, 2017 8:22 PM<br>
<b>To:</b> John Hardy; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method to tr=
ustlessly reward nodes for storing and verifying the blockchain</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr">Hi John,
<div>&nbsp;RSK platform (a Bitcoin sidechain) is already prepared to do som=
ething similar to this, although very efficiently. We set apart 1% of the b=
lock reward to automatically reward full nodes.</div>
<div><br>
</div>
<div>We have two systems being evaluated: the first is based on PoUBS (Proo=
f of Unique Blockchain Storage) which uses asymmetric-time operations to en=
code the blockchain based on each user public key such that decoding is fas=
t, but encoding is slow. The second
 is more traditional proof of retrievability, but it requires some ASIC-res=
istance assumptions.&nbsp;</div>
<div><br>
</div>
<div>In both cases, a special smart contract is being called at every block=
 that creates periodic challenges. Every full node that wants to participat=
e can submits a commitment to the Merkle hash root of a pseudo-random seque=
nce of encoded blocks. Then the
 smart contract chooses random elements from the committed dataset, and eac=
h full node has a period to submit Merkle-proofs that such random elements =
belong to the commitment.</div>
<div><br>
</div>
<div>To prevent blockchain bloat we designed a very cool new type of transa=
ction payload: Ephemeral Payload. Ephemeral payload is a payload in a trans=
action that gets discarded after N blocks if no smart contract does referen=
ce it. If is does, it's solidified
 forever in the blockchain.</div>
<div>Then there is a challenge phase where other full nodes can inform the =
smart contract if they find an error in the submitted responses. Then the s=
mart contract ONLY evaluates the responses which have been questioned by us=
ers.</div>
<div><br>
</div>
<div>This way the smart contract does very little computation (only when a =
user misbehaves) and the blockchain normally does not store any proof forev=
er (only the ones created by misbehaving users).</div>
<div><br>
</div>
<div>Because RSK/Rootstock has a very short block interval (10 seconds), al=
l this happens very quickly and does not require much computation.&nbsp;</d=
iv>
<div><br>
</div>
<div>Best regards,<br>
</div>
<div>&nbsp;Sergio Lerner</div>
<div>&nbsp;Chief Scientist RSK (aka Roostock)</div>
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Tue, Feb 7, 2017 at 8:27 AM, John Hardy via b=
itcoin-dev
<span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex; border-left:1=
px #ccc solid; padding-left:1ex">
<div dir=3D"ltr">
<div id=3D"m_8783055025000134944divtagdefaultwrapper" dir=3D"ltr" style=3D"=
font-size:12pt; color:#000000; font-family:Calibri,Arial,Helvetica,sans-ser=
if">
<p><span id=3D"m_8783055025000134944docs-internal-guid-4ac5038f-1853-2d21-3=
f80-3a53c5100e51"></span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">Proof of Nodework (Po=
NW) is a way to reward individual nodes
 for keeping a full copy of and verifying the blockchain.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">Hopefully they also d=
o useful =91traditional=92 node activities
 too like relay transactions and blocks, but there isn=92t really any way I=
 can think of to trustlessly verify this also.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">PoNW would require a =
new separate area of block space, a nodeblock,
 purely concerned with administering the system. A nodeblock is committed t=
o a block as with SegWit. A recent history of nodeblocks needs to be stored=
 by nodes, however the data eventually becomes obsolete and so does not nee=
d to be retained forever.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">In order to prevent S=
ybil, a node must register an Bitcoin
 address by submitting an addNode transaction - along with a security depos=
it to prevent cheating.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">This transaction will=
 be stored in the nodeblock. Once a node
 can see that its addNode transaction has been added it can begin the PoNW =
process. The node=92s registered address will be hashed with the block head=
er of the block it wants to work on. This will determine exactly where with=
in the blockchain to begin the PoNW.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">The PoNW method could=
 be as simple as creating a Merkle tree
 from the randomly generated point on the blockchain, though a method that =
is CPU/Memory heavy and less likely to be replaced by dedicated hardware li=
ke ASICs would be better. This process could not begin until the most recen=
t block has been fully verified,
 and while being carried out should still enable normal relay activities to=
 proceed as normal, since it shouldn=92t tie up network at all. The data pr=
ocessed should also be mixed with data from the latest block so that it can=
not be computed in advance.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">A node can do as much=
 PoNW for a block as it likes. Once finished
 it will then create a nodeWorkComplete transaction for that block with its=
 final proof value, add how much =91work=92 it did - and create a couple of=
 assertions about what it processed (such as there were x number of pieces =
of data matching a particular value
 during calculating). These assertions can be accurate or inaccurate.</span=
></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">The system will run i=
n epochs. During each epoch of say 2016
 blocks, there will be an extended window for PoNW transactions to be added=
 to nodeblocks to limit minor censorship.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">The random hash gener=
ated from a node=92s address and blockhash
 will also be used to determine nodeWorkComplete transactions from a previo=
us block that the node must also verify, and correctly calculate whether th=
e assertions it made were true or false. The average PoNW that a node perfo=
rmed in its previous x nodeblocks
 will be used to determine the target PoNW for the node to verify - and thi=
s will randomly be a large number of smaller PoNW transactions, or a smalle=
r number of large PoNW. This process will be deterministic based on that bl=
ock and address hash. All the data
 will be put together in a transaction and then signed by the node addresse=
s private key.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">If a nodeWorkComplete=
 transaction contains any incorrect information
 in an attempt to cheat the validation process a challenge transaction can =
be created. This begins a refereeing process where other nodes check the ch=
allenge and vote whether it is to be upheld or not. The losing node is puni=
shed by losing their accrued PoNW
 for that epoch and a percentage of their security deposit.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">Nodes will also be pu=
nished if they broadcast more than one
 signed transaction per block.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">In order to prevent n=
odes from having multiple keys registered
 - which would enable them choose to perform PoNW on a subset of the data t=
hat they hold - the share of reward that the node gets will be multiplied b=
ased on the number of blocks within an epoch that the node performs PoNW on=
. The share of reward is limited
 based on how much security deposit has been staked. The higher the PoNW th=
e higher the deposit needed in order to claim their full allocation of any =
reward.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">At the end of an epoc=
h, with a wait period for any delayed
 or censored transactions or challenges to be included and settled up, the =
process of calculating the reward each node is due can begin. This will the=
n be then paid in a regular block, and means for all the data involved in P=
oNW, the only permanent mark it
 makes on the main blockchain is for a transaction that pays all addresses =
their share of the reward at the end of epoch. Any miner who creates a bloc=
k without correctly calculating and paying the due reward will have mined a=
n invalid block and be orphaned.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">The question of where=
 and how much the reward comes from is
 a different one. It could come from the existing miner reward, or a specia=
l new tx donation fee for nodes. If there was some way for users to =91dona=
te=92 to the reward pool for nodes this would increase the incentive for ad=
ditional nodes to participate on the
 network in the event of centralisation.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">This is a relatively =
effective way to create a reward for all
 nodes participating on a network. I=92d be keen to field any questions or =
critiques.</span></p>
<div><span style=3D"font-size:11pt; font-family:Arial; background-color:tra=
nsparent; vertical-align:baseline; white-space:pre-wrap"><br>
</span></div>
Thanks,
<p></p>
<p><br>
</p>
<p>John Hardy</p>
<p><a href=3D"mailto:john@seebitcoin.com" target=3D"_blank">john@seebitcoin=
.com</a></p>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_BL2PR03MB4355F39BE003DBF200591EBEE590BL2PR03MB435namprd_--