path: root/40/56308de300983f5a6e142c7fa1c144549a4ce8

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pagecr@gmail.com>) id 1YQJ3p-0006ca-GN
	for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 17:14:17 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.49 as permitted sender)
	client-ip=209.85.215.49; envelope-from=pagecr@gmail.com;
	helo=mail-la0-f49.google.com; 
Received: from mail-la0-f49.google.com ([209.85.215.49])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YQJ3m-0006Ar-NR
	for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 17:14:17 +0000
Received: by labhv19 with SMTP id hv19so4530815lab.10
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 24 Feb 2015 09:14:08 -0800 (PST)
X-Received: by 10.152.178.197 with SMTP id da5mr15020795lac.87.1424798048232; 
	Tue, 24 Feb 2015 09:14:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.42.79 with HTTP; Tue, 24 Feb 2015 09:13:47 -0800 (PST)
In-Reply-To: <CADL_X_cYanZGob_EdYwVmRonK3kHBv5KFxg3epJNasrmnxjutg@mail.gmail.com>
References: <CAEG8yzmS61H7uqWQuqx09T1NjiHrpK=3MYT+63AXb=_xkz831g@mail.gmail.com>
	<CADL_X_cYanZGob_EdYwVmRonK3kHBv5KFxg3epJNasrmnxjutg@mail.gmail.com>
From: Chris Page <pagecr@gmail.com>
Date: Tue, 24 Feb 2015 12:13:47 -0500
Message-ID: <CAEG8yzmzMtVgMZfuK28ct62kKewzGXjbrcOmYWzivkN11eCq2g@mail.gmail.com>
To: Jameson Lopp <jameson.lopp@gmail.com>
Content-Type: multipart/alternative; boundary=001a11340c688aac58050fd8a505
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(pagecr[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YQJ3m-0006Ar-NR
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Request for comments on hybrid PoW/PoS
 enhancement for Bitcoin
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2015 17:14:17 -0000

--001a11340c688aac58050fd8a505
Content-Type: text/plain; charset=UTF-8

Thanks for the feedback and questions.  Answers inline.

On Tue, Feb 24, 2015 at 9:54 AM, Jameson Lopp <jameson.lopp@gmail.com>
wrote:

> This is an interesting idea from the standpoint of trying to incentivize
> people to run nodes, though from a high level it seems to just be adding
> complexity to the current process by which nodes 'endorse' blocks. When a
> node receives and validates a block it then informs its peers of the new
> inventory, thus offering to send the block that 'endorses' as valid.
>
> "Because there is an incentive to include endorsers, there is an incentive
> to broadcast mined blocks as soon as possible." - I'd say that this is
> already the case due to the incentive for a miner's block to get propagated
> around the network first.
>

I agree with this, for well meaning miners.  In the case of a 51% attack,
there is an incentive to mine a block and not share it right away, so that
another block could be mined on top of it.  Because that first block wasn't
shared, it wouldn't have endorsers.  The total work represented in this
"attack" chain, even with 2 blocks, would ideally represent less work that
one fully endorsed block.  This is because, as currently proposed,
endorsers provide a work multiplier, which when a block has a full
complement of endorsers, its proof of work is doubled for the purpose of
best chain selection.  That's if we allow up to 10 endorsers each providing
a 10% work bonus.

My concern is that giving endorsers too much power potentially opens up
another attack vector where endorsers could collude to endorse an invalid
block.  But that's why it is so important that the selection criteria for
endorsers needs to be both random and narrow.  I discuss that more below.


>
>
> My first question would be whether or not your proposal would include a
> change to how nodes propagate new blocks. At the moment, a node that hears
> about a second valid block at the tip of the chain will ignore it and not
> propagate it to its peers. Wouldn't your proposal necessitate a change to
> this logic so that blocks with 'better' endorsements get propagated even if
> they are received after non-endorsed or lesser-endorsed blocks?
>


I think that the proposal does impact consensus, which creates a high
barrier to acceptance, and I'm not yet convinced that the benefits are
worth the risk.  My hope is that in sharing the idea, we can identify ways
to reduce the risk.

Whenever there is a fork, Bitcoin chooses the chain with the most work.  I
could easily be mistaken, so correct me if I cam wrong, but based on a
current level of difficulty, any arriving valid block is going to present
an equivalent proof of work.  So currently, it makes sense to simply ignore
a second valid block.  With the proposal, if a second valid block came in
with more endorsers, it would displace the current tip.

In practice, with proper incentive, I would expect all found blocks to have
the same number of endorsers.  Therefore all incoming blocks would be
interchangeable, and it would be the case that in practice, a second valid
block would be ignored just as today.



>
> I'd also be interested to know more how endorsements would be limited
> (fairly) to only a subset of nodes.
>
>
A node endorses by providing an address for payout.  The limiting criteria
is a function of that address.

The first requirement is that the address must have a relationship to the
block that it is endorsing.  As an
example, 0000000000000000082ab88cefb003f1dc1fa25881dbd56ed58c0548fbec5382 is
the hash of a recent block.  The requirement is that the address matches
some number (TBD) of trailing bits.  If the threshold were 32 bits, then
the address (more likely, the hash of the public address) would need to end
in fbec5382..

An valid address must have some proof of stake.  Maybe that isn't fair,
because it limits participation by balance, and it is yet another case of
the rich get richer.  But without proof of stake, everyone would generate
enough addresses so that they could always find an address that meets the
first requirement.

Assuming the idea has merit, in order to get it right, we'd need much
discussion to understand what combination of PoS and size of mask makes
sense.


> I'm a bit fuzzy on the endorsement timing. You're saying that a miner will
> add endorsement payouts in their block based upon nodes that endorsed the
> previous block? Which means they're paying nodes to endorse a block that
> they probably didn't even mine? Or would a miner only include payouts to
> endorsers for the last block that they mined that was accepted by the
> network?
>
>
With my proposal, miners would not be required to payout to endorsers at
all.  I think that this would help us avoid a hard fork.  But when they
choose to payout to endorsers, yes, they would be paying out to those that
endorsed the tip of the chain that they are building on.   Why would a
miner ever do that?  Because they would benefit from the multiplier
provided by the endorsers.

Any block that includes endorsers would be providing a higher level of work
which would displace tips without endorsement.  This sort of turmoil
wouldn't sit well with anybody, so I suspect that miners would soon begin
including a full complement of endorsers.

If we were to move ahead with something like this, we might want to ramp up
the amount of the reward shared with endorsers from 0 to the final target
some years later.  I do not want to mess with short term business plans of
miners.

Thanks again for the feedback, thoughts, and questions.  I hope my answers
provide more clarity.

-Chris





> - Jameson
>
> On Mon, Feb 23, 2015 at 2:27 PM, Chris Page <pagecr@gmail.com> wrote:
>
>>
>> I'm soliciting feedback on an idea to will improve security, increase the
>> number of full nodes, and provide more avenues for bitcoin distribution.
>> The idea is still in its infancy, but I need constructive feedback before I
>> take this further, or decide to abandon the idea.
>>
>> In particular, my ego is in check and I'm ready to be made a fool, but in
>> turn, I'll be that much better educated, so fair trade!
>>
>> Here is the high-level overview:
>>
>> 1) A new block B0 is mined and broadcast as usual
>>
>> 2) Full nodes verify block B0. A subset of these nodes broadcast a new
>> "endorsement" message endorsing the block as valid, and preferred.
>>
>> 3) Miners, now assembling and beginning mining a new block (B1), add
>> endorsements of B0 to B1's coinbase transaction, sharing the block reward
>> with endorsers of B0.
>>
>> As proposed, the idea of Block Endorsement requires a new message, but
>> fits into current structures.
>>
>> Here some details about each of the steps above, and what it buys us:
>>
>> 1) The mining of block B0: No changes to current process or format.
>> Blocks are mined and broadcast as they are today.
>>
>> 2)  Only a subset of nodes are eligible to endorse a block, and hence,
>> only a subset are eligible for an endorsement reward.  We restrict to avoid
>> a flood of endorsement messages by every node following the announcement of
>> each new block.  An endorsement message needs to identify exactly one block
>> at a specific height that it is endorsing.  It needs to include a payout
>> address that meets certain validation criteria relative to the block it is
>> endorsing.  A valid payout address will include some proof of stake (PoS),
>> whether that be that it has a 1+ bitcoin balance, some age weighted
>> balance, or something else is TBD.  The reason for PoS is that it should
>> not be the case that a subversive miner could easily fabricate a valid
>> endorsement payout address.  The other requirement is that the tail bits of
>> a valid endorsement payout address, when masked (size of mask TBD) need to
>> match the trailing bits of the hash of the block it is validating.   This
>> directly ties endorsements to a specific block, and makes it
>> computationally inexpensive to verify/relay, or drop invalid endorsement
>> messages. The combination of PoS and mask will restrict the number of valid
>> addresses.  There are no restrictions on which endorsements a miner can
>> include, as long as they are valid.  As part of new block validation, full
>> nodes would need to do all that they do now, but they would also need to
>> validate endorsements included in the coinbase transaction.
>>
>> 3) Miners consider whether to include endorsement payouts as part of
>> their coinbase transaction.  They need not do so, but by including
>> endorsements, they significantly increase the likelihood that their block
>> will be selected.
>>
>> CHANGE TO BEST CHAIN SELECTION
>>
>> Block Endorsement requires a change to the best chain selection algorithm
>> to encourage miners to include endorsement payouts.  Because there is an
>> incentive to include endorsers, there is an incentive to broadcast mined
>> blocks as soon as possible.
>>
>> For the purpose of best chain selection, a block should get a significant
>> bonus to its work (10%) for each valid endorsement payout included in a
>> block's valid coinbase transaction.  How many endorsements should be
>> permitted is a design parameter which is in play, but let's assume that up
>> to 10 endorsements are permitted.   For the purpose of block selection, a
>> block's work, with 10 endorsements, is be effectively doubled.
>>
>> EFFECT ON 51% ATTACK
>>
>> With Block Endorsement, because of the extra weight given to a block that
>> has endorsements, a sustained 51% attack becomes more expensive.  Valid
>> blocks with full endorsements would win out over the attack blocks unless
>> the attacker was able to not only control 51% of the compute power, but to
>> also control sufficient endorsements to overcome the rest of the network.
>> To prevent an attacker from just using suitable addresses as endorsers from
>> the blockchain, a full node would have to maintain a list of recently
>> broadcast endorsement messages for TBD (100) blocks to prove the validity
>> of the endorsements.  Quite possibly we might need to provide a way for a
>> booting node to request lists of endorsers.
>>
>> CHANGE TO BLOCK REWARD
>>
>> Miners would share block rewards with endorsers using a defined formula
>> which is TBD.  Endorsement rewards would be as much as 20% (design
>> parameter) of the block reward, and shared evenly between all endorsers
>> included in the coinbase.
>>
>> CHANGE TO MINING STRATEGIES
>>
>> When a new block is broadcast, miners will begin assembling yet another
>> block.  Meanwhile, full nodes would validate the new block, and
>> endorsements would propagate quickly thereafter to all miners.  This should
>> not take long as it is easy to identify whether or not an address is a
>> valid endorser.  I would expect shortly after assembling a block, there
>> would be a number of potential endorsers to include in the coinbase tx, and
>> if 10 were not available, a miner could decide to wait, or begin mining
>> it.  I suspect the time to collect 10 valid endorsers would be low, as
>> endorsers should reply quickly in hopes of being included. Therefore, this
>> additional wait time, if any, would not have a appreciable impact on the
>> level of difficulty required to mine a block.
>>
>> I have thoughts on how to provide additional incentives to miners to
>> include multiple endorsers - for example, reducing the total endorsement
>> fee down to 10% if endorsed by a full complement of endorsers.  We could
>> also start with a lower reward and ramp up to some target over time to not
>> burden the business plans of current mining operations.  But these and
>> other ideas are added complexity that I don't know offers much return.  It
>> is easy to add complexity.  The challenge is to keep it as simple as
>> possible.
>>
>> CONCLUSION
>>
>> By implementing Block Endorsement, we increase security of the blockchain
>> by giving more weight to blocks that have been broadcast and endorsed by
>> multiple full nodes.  By providing a reward to these endorsers, we provide
>> an incentive for more full nodes.  With proof of state mining on top of
>> existing proof of work, we provide a low barrier to entry, while not
>> sacrificing the benefits provided by PoW.  With a lower barrier to entry,
>> we provide a more accessible avenue for mining, and in turn, encourage
>> bitcoin adoption.
>>
>> This is just the beginnings of an idea.  Assuming there isn't a
>> fundamental flaw(s), there are many knobs to tweak, and no doubt, it would
>> benefit greatly by the technical expertise and creativity of others.  I do
>> feel as if there are still some gaps and that it hasn't yet been full
>> explored yet even as a thought experiment.  For instance, what new attack
>> vectors might be introduced?  Would a person controlling many potential
>> endorsement addresses be able to launch an attack by endorsing a set of
>> blocks, essentially launching a 51% attack but by using endorsements as a
>> PoW multiplier?  Or is that not practical?  The answer is probably a
>> function of the endorsement criteria.  There are many different angles that
>> require thought and scrutiny.  I'm sure there are many that I've yet to
>> even consider.
>>
>> And as I read discussions about double-spends and zero-confirmation
>> transactions I can't help but wonder if maybe there is a way for endorsers
>> to play a role in identifying possible double-spends.  Negative
>> endorsements?
>>
>> I'm new to the development process and the code base.  Assuming the
>> feedback isn't derailing, would the next step be to proceed with
>> implementation, or would a new BIP be recommended?
>>
>> Well, I thought this would be only a few paragraphs.  It is easy to carry
>> on when you are excited about something.  That's also the time when a
>> person is most likely to miss some short-comings, so I am anxious for
>> feedback.  Thanks for reading, and I'd be most appreciative of constructive
>> comments and questions.
>>
>> Thanks
>> Chris Page
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

--001a11340c688aac58050fd8a505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the feedback and questions.=C2=A0 Answers inlin=
e.<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Feb=
 24, 2015 at 9:54 AM, Jameson Lopp <span dir=3D"ltr">&lt;<a href=3D"mailto:=
jameson.lopp@gmail.com" target=3D"_blank">jameson.lopp@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr">This is an interesting ide=
a from the standpoint of trying to incentivize people to run nodes, though =
from a high level it seems to just be adding complexity to the current proc=
ess by which nodes &#39;endorse&#39; blocks. When a node receives and valid=
ates a block it then informs its peers of the new inventory, thus offering =
to send the block that &#39;endorses&#39; as valid.<div><br></div><div><spa=
n style=3D"font-size:12.8000001907349px">&quot;Because there is an incentiv=
e to include endorsers, there is an incentive to broadcast mined blocks as =
soon as possible.&quot; - I&#39;d say that this is already the case due to =
the incentive for a miner&#39;s block to get propagated around the network =
first.</span></div></div></blockquote><div><br></div><div>I agree with this=
, for well meaning miners.=C2=A0 In the case of a 51% attack, there is an i=
ncentive to mine a block and not share it right away, so that another block=
 could be mined on top of it.=C2=A0 Because that first block wasn&#39;t sha=
red, it wouldn&#39;t have endorsers.=C2=A0 The total work represented in th=
is &quot;attack&quot; chain, even with 2 blocks, would ideally represent le=
ss work that one fully endorsed block.=C2=A0 This is because, as currently =
proposed, endorsers provide a work multiplier, which when a block has a ful=
l complement of endorsers, its proof of work is doubled for the purpose of =
best chain selection.=C2=A0 That&#39;s if we allow up to 10 endorsers each =
providing a 10% work bonus.</div><div><br></div><div>My concern is that giv=
ing endorsers too much power potentially opens up another attack vector whe=
re endorsers could collude to endorse an invalid block.=C2=A0 But that&#39;=
s why it is so important that the selection criteria for endorsers needs to=
 be both random and narrow.=C2=A0 I discuss that more below.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div><span style=
=3D"font-size:12.8000001907349px"><br></span></div><div><span style=3D"font=
-size:12.8000001907349px">My first question would be whether or not your pr=
oposal would include a change to how nodes propagate new blocks. At the mom=
ent, a node that hears about a second valid block at the tip of the chain w=
ill ignore it and not propagate it to its peers. Wouldn&#39;t your proposal=
 necessitate a change to this logic so that blocks with &#39;better&#39; en=
dorsements get propagated even if they are received after non-endorsed or l=
esser-endorsed blocks?</span></div></div></blockquote><div><br></div><div><=
br></div><div>I think that the proposal does impact consensus, which create=
s a high barrier to acceptance, and I&#39;m not yet convinced that the bene=
fits are worth the risk.=C2=A0 My hope is that in sharing the idea, we can =
identify ways to reduce the risk.</div><div><br></div><div>Whenever there i=
s a fork, Bitcoin chooses the chain with the most work.=C2=A0 I could easil=
y be mistaken, so correct me if I cam wrong, but based on a current level o=
f difficulty, any arriving valid block is going to present an equivalent pr=
oof of work.=C2=A0 So currently, it makes sense to simply ignore a second v=
alid block.=C2=A0 With the proposal, if a second valid block came in with m=
ore endorsers, it would displace the current tip.</div><div><br></div><div>=
In practice, with proper incentive, I would expect all found blocks to have=
 the same number of endorsers.=C2=A0 Therefore all incoming blocks would be=
 interchangeable, and it would be the case that in practice, a second valid=
 block would be ignored just as today. =C2=A0</div><div><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12=
.8000001907349px"><br></span></div><div><span style=3D"font-size:12.8000001=
907349px">I&#39;d also be interested to know more how endorsements would be=
 limited (fairly) to only a subset of nodes.</span></div><div><span style=
=3D"font-size:12.8000001907349px"><br></span></div></div></blockquote><div>=
<br></div><div>A node endorses by providing an address for payout.=C2=A0 Th=
e limiting criteria is a function of that address. =C2=A0</div><div><br></d=
iv><div>The first requirement is that the address must have a relationship =
to the block that it is endorsing.=C2=A0 As an example,=C2=A000000000000000=
00082ab88cefb003f1dc1fa25881dbd56ed58c0548fbec5382=C2=A0is the hash of a re=
cent block.=C2=A0 The requirement is that the address matches some number (=
TBD) of trailing bits.=C2=A0 If the threshold were 32 bits, then the addres=
s (more likely, the hash of the public address) would need to end in=C2=A0f=
bec5382..</div><div><br></div><div>An valid address must have some proof of=
 stake.=C2=A0 Maybe that isn&#39;t fair, because it limits participation by=
 balance, and it is yet another case of the rich get richer.=C2=A0 But with=
out proof of stake, everyone would generate enough addresses so that they c=
ould always find an address that meets the first requirement.</div><div><br=
></div><div>Assuming the idea has merit, in order to get it right, we&#39;d=
 need much discussion to understand what combination of PoS and size of mas=
k makes sense.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div=
><span style=3D"font-size:12.8000001907349px"></span></div><div><span style=
=3D"font-size:12.8000001907349px">I&#39;m a bit fuzzy on the endorsement ti=
ming. You&#39;re saying that a miner will add endorsement payouts in their =
block based upon nodes that endorsed the previous block? Which means they&#=
39;re paying nodes to endorse a block that they probably didn&#39;t even mi=
ne? Or would a miner only include payouts to endorsers for the last block t=
hat they mined that was accepted by the network?</span></div><div><span sty=
le=3D"font-size:12.8000001907349px"><br></span></div></div></blockquote><di=
v><br></div><div>With my proposal, miners would not be required to payout t=
o endorsers at all.=C2=A0 I think that this would help us avoid a hard fork=
.=C2=A0 But when they choose to payout to endorsers, yes, they would be pay=
ing out to those that endorsed the tip of the chain that they are building =
on. =C2=A0 Why would a miner ever do that?=C2=A0 Because they would benefit=
 from the multiplier provided by the endorsers.</div><div><br></div><div>An=
y block that includes endorsers would be providing a higher level of work w=
hich would displace tips without endorsement.=C2=A0 This sort of turmoil wo=
uldn&#39;t sit well with anybody, so I suspect that miners would soon begin=
 including a full complement of endorsers.</div><div><br></div><div>If we w=
ere to move ahead with something like this, we might want to ramp up the am=
ount of the reward shared with endorsers from 0 to the final target some ye=
ars later.=C2=A0 I do not want to mess with short term business plans of mi=
ners. =C2=A0</div><div><br></div><div>Thanks again for the feedback, though=
ts, and questions.=C2=A0 I hope my answers provide more clarity.</div><div>=
<br></div><div>-Chris</div><div><br></div><div>=C2=A0=C2=A0 =C2=A0 =C2=A0</=
div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<span style=3D"font-size:12.8000001907349px"></span></div><div><span style=
=3D"font-size:12.8000001907349px">- Jameson</span></div></div><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Mon,=
 Feb 23, 2015 at 2:27 PM, Chris Page <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:pagecr@gmail.com" target=3D"_blank">pagecr@gmail.com</a>&gt;</span> wrote=
:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><=
br><div>I&#39;m soliciting feedback on an idea to will improve security, in=
crease the number of full nodes, and provide more avenues for bitcoin distr=
ibution. =C2=A0 The idea is still in its infancy, but I need constructive f=
eedback before I take this further, or decide to abandon the idea.</div><di=
v><br></div><div>In particular, my ego is in check and I&#39;m ready to be =
made a fool, but in turn, I&#39;ll be that much better educated, so fair tr=
ade!</div><div><br></div><div>Here is the high-level overview:</div><div><b=
r></div><div>1) A new block B0 is mined and broadcast as usual</div><div><b=
r></div><div>2) Full nodes verify block B0. A subset of these nodes broadca=
st a new &quot;endorsement&quot; message endorsing the block as valid, and =
preferred.</div><div><br></div><div>3) Miners, now assembling and beginning=
 mining a new block (B1), add endorsements of B0 to B1&#39;s coinbase trans=
action, sharing the block reward with endorsers of B0.</div><div><br></div>=
<div>As proposed, the idea of Block Endorsement requires a new message, but=
 fits into current structures.</div><div><br></div><div>Here some details a=
bout each of the steps above, and what it buys us:</div><div><br></div><div=
>1) The mining of block B0: No changes to current process or format.=C2=A0 =
Blocks are mined and broadcast as they are today.</div><div><br></div><div>=
2) =C2=A0Only a subset of nodes are eligible to endorse a block, and hence,=
 only a subset are eligible for an endorsement reward.=C2=A0 We restrict to=
 avoid a flood of endorsement messages by every node following the announce=
ment of each new block.=C2=A0 An endorsement message needs to identify exac=
tly one block at a specific height that it is endorsing.=C2=A0 It needs to =
include a payout address that meets certain validation criteria relative to=
 the block it is endorsing.=C2=A0 A valid payout address will include some =
proof of stake (PoS), whether that be that it has a 1+ bitcoin balance, som=
e age weighted balance, or something else is TBD.=C2=A0 The reason for PoS =
is that it should not be the case that a subversive miner could easily fabr=
icate a valid endorsement payout address.=C2=A0 The other requirement is th=
at the tail bits of a valid endorsement payout address, when masked (size o=
f mask TBD) need to match the trailing bits of the hash of the block it is =
validating. =C2=A0 This directly ties endorsements to a specific block, and=
 makes it computationally inexpensive to verify/relay, or drop invalid endo=
rsement messages. The combination of PoS and mask will restrict the number =
of valid addresses.=C2=A0 There are no restrictions on which endorsements a=
 miner can include, as long as they are valid.=C2=A0 As part of new block v=
alidation, full nodes would need to do all that they do now, but they would=
 also need to validate endorsements included in the coinbase transaction.</=
div><div><br></div><div>3) Miners consider whether to include endorsement p=
ayouts as part of their coinbase transaction.=C2=A0 They need not do so, bu=
t by including endorsements, they significantly increase the likelihood tha=
t their block will be selected.</div><div><br></div><div>CHANGE TO BEST CHA=
IN SELECTION</div><div><br></div><div>Block Endorsement requires a change t=
o the best chain selection algorithm to encourage miners to include endorse=
ment payouts.=C2=A0 Because there is an incentive to include endorsers, the=
re is an incentive to broadcast mined blocks as soon as possible.=C2=A0</di=
v><div><br></div><div>For the purpose of best chain selection, a block shou=
ld get a significant bonus to its work (10%) for each valid endorsement pay=
out included in a block&#39;s valid coinbase transaction.=C2=A0 How many en=
dorsements should be permitted is a design parameter which is in play, but =
let&#39;s assume that up to 10 endorsements are permitted. =C2=A0 For the p=
urpose of block selection, a block&#39;s work, with 10 endorsements, is be =
effectively doubled.</div><div><br></div><div>EFFECT ON 51% ATTACK</div><di=
v><br></div><div>With Block Endorsement, because of the extra weight given =
to a block that has endorsements, a sustained 51% attack becomes more expen=
sive.=C2=A0 Valid blocks with full endorsements would win out over the atta=
ck blocks unless the attacker was able to not only control 51% of the compu=
te power, but to also control sufficient endorsements to overcome the rest =
of the network.=C2=A0 To prevent an attacker from just using suitable addre=
sses as endorsers from the blockchain, a full node would have to maintain a=
 list of recently broadcast endorsement messages for TBD (100) blocks to pr=
ove the validity of the endorsements.=C2=A0 Quite possibly we might need to=
 provide a way for a booting node to request lists of endorsers.</div><div>=
<br></div><div>CHANGE TO BLOCK REWARD</div><div><br></div><div>Miners would=
 share block rewards with endorsers using a defined formula which is TBD.=
=C2=A0 Endorsement rewards would be as much as 20% (design parameter) of th=
e block reward, and shared evenly between all endorsers included in the coi=
nbase.</div><div><br></div><div>CHANGE TO MINING STRATEGIES</div><div><br><=
/div><div>When a new block is broadcast, miners will begin assembling yet a=
nother block.=C2=A0 Meanwhile, full nodes would validate the new block, and=
 endorsements would propagate quickly thereafter to all miners.=C2=A0 This =
should not take long as it is easy to identify whether or not an address is=
 a valid endorser.=C2=A0 I would expect shortly after assembling a block, t=
here would be a number of potential endorsers to include in the coinbase tx=
, and if 10 were not available, a miner could decide to wait, or begin mini=
ng it.=C2=A0 I suspect the time to collect 10 valid endorsers would be low,=
 as endorsers should reply quickly in hopes of being included. Therefore, t=
his additional wait time, if any, would not have a appreciable impact on th=
e level of difficulty required to mine a block.</div><div><br></div><div>I =
have thoughts on how to provide additional incentives to miners to include =
multiple endorsers - for example, reducing the total endorsement fee down t=
o 10% if endorsed by a full complement of endorsers.=C2=A0 We could also st=
art with a lower reward and ramp up to some target over time to not burden =
the business plans of current mining operations.=C2=A0 But these and other =
ideas are added complexity that I don&#39;t know offers much return.=C2=A0 =
It is easy to add complexity.=C2=A0 The challenge is to keep it as simple a=
s possible.=C2=A0</div><div><br></div><div>CONCLUSION</div><div><br></div><=
div>By implementing Block Endorsement, we increase security of the blockcha=
in by giving more weight to blocks that have been broadcast and endorsed by=
 multiple full nodes.=C2=A0 By providing a reward to these endorsers, we pr=
ovide an incentive for more full nodes.=C2=A0 With proof of state mining on=
 top of existing proof of work, we provide a low barrier to entry, while no=
t sacrificing the benefits provided by PoW.=C2=A0 With a lower barrier to e=
ntry, we provide a more accessible avenue for mining, and in turn, encourag=
e bitcoin adoption.</div><div><br></div><div>This is just the beginnings of=
 an idea.=C2=A0 Assuming there isn&#39;t a fundamental flaw(s), there are m=
any knobs to tweak, and no doubt, it would benefit greatly by the technical=
 expertise and creativity of others.=C2=A0 I do feel as if there are still =
some gaps and that it hasn&#39;t yet been full explored yet even as a thoug=
ht experiment.=C2=A0 For instance, what new attack vectors might be introdu=
ced?=C2=A0 Would a person controlling many potential endorsement addresses =
be able to launch an attack by endorsing a set of blocks, essentially launc=
hing a 51% attack but by using endorsements as a PoW multiplier?=C2=A0 Or i=
s that not practical?=C2=A0 The answer is probably a function of the endors=
ement criteria.=C2=A0 There are many different angles that require thought =
and scrutiny.=C2=A0 I&#39;m sure there are many that I&#39;ve yet to even c=
onsider.=C2=A0</div><div><br></div><div>And as I read discussions about dou=
ble-spends and zero-confirmation transactions I can&#39;t help but wonder i=
f maybe there is a way for endorsers to play a role in identifying possible=
 double-spends.=C2=A0 Negative endorsements?</div><div><br></div><div>I&#39=
;m new to the development process and the code base.=C2=A0 Assuming the fee=
dback isn&#39;t derailing, would the next step be to proceed with implement=
ation, or would a new BIP be recommended?=C2=A0</div><div><br></div><div>We=
ll, I thought this would be only a few paragraphs.=C2=A0 It is easy to carr=
y on when you are excited about something.=C2=A0 That&#39;s also the time w=
hen a person is most likely to miss some short-comings, so I am anxious for=
 feedback.=C2=A0 Thanks for reading, and I&#39;d be most appreciative of co=
nstructive comments and questions.</div><div><br></div><div>Thanks</div><sp=
an><font color=3D"#888888"><div>Chris Page</div></font></span></div>
<br></div></div>-----------------------------------------------------------=
-------------------<br>
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br>
from Actuate! Instantly Supercharge Your Business Reports and Dashboards<br=
>
with Interactivity, Sharing, Native Excel Exports, App Integration &amp; mo=
re<br>
Get technology previously reserved for billion-dollar corporations, FREE<br=
>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D190641631&amp;iu=3D/4140/ostg.clktrk</a><br>__________________=
_____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>

--001a11340c688aac58050fd8a505--