Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.180 as permitted sender)
	client-ip=74.125.82.180; envelope-from=jameson.lopp@gmail.com;
	helo=mail-we0-f180.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAEG8yzmS61H7uqWQuqx09T1NjiHrpK=3MYT+63AXb=_xkz831g@mail.gmail.com>
References: <CAEG8yzmS61H7uqWQuqx09T1NjiHrpK=3MYT+63AXb=_xkz831g@mail.gmail.com>
Date: Tue, 24 Feb 2015 09:54:17 -0500
Message-ID: <CADL_X_cYanZGob_EdYwVmRonK3kHBv5KFxg3epJNasrmnxjutg@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Chris Page <pagecr@gmail.com>
Content-Type: multipart/alternative; boundary=f46d041824dc707cb3050fd6b1ca
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
Precedence: list

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

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.

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'd also be interested to know more how endorsements would be limited
(fairly) to only a subset of nodes.

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?

- 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
>
>

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

<div dir=3D"ltr">This is an interesting idea from the standpoint of trying =
to incentivize people to run nodes, though from a high level it seems to ju=
st be adding complexity to the current process by which nodes &#39;endorse&=
#39; 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 &#39;endo=
rses&#39; as valid.<div><br></div><div><span style=3D"font-size:12.80000019=
07349px">&quot;Because there is an incentive 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><br></div><div><spa=
n 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 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&#39;t your =
proposal necessitate a change to this logic so that blocks with &#39;better=
&#39; endorsements get propagated even if they are received after non-endor=
sed or lesser-endorsed blocks?</span></div><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><span style=3D"font=
-size:12.8000001907349px">I&#39;m a bit fuzzy on the endorsement timing. Yo=
u&#39;re saying that a miner will add endorsement payouts in their block ba=
sed upon nodes that endorsed the previous block? Which means they&#39;re pa=
ying nodes to endorse a block that they probably didn&#39;t even mine? Or w=
ould a miner only include payouts to endorsers for the last block that they=
 mined that was accepted by the network?</span></div><div><span style=3D"fo=
nt-size:12.8000001907349px"><br></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">On Mon, Feb 23, 2015 at 2:27 PM, Chris Page =
<span dir=3D"ltr">&lt;<a href=3D"mailto:pagecr@gmail.com" target=3D"_blank"=
>pagecr@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><br><div>I&#39;m soliciting feedback on an idea to will imp=
rove security, increase the number of full nodes, and provide more avenues =
for bitcoin distribution. =C2=A0 The idea is still in its infancy, but I ne=
ed constructive feedback before I take this further, or decide to abandon t=
he idea.</div><div><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 edu=
cated, so fair trade!</div><div><br></div><div>Here is the high-level overv=
iew:</div><div><br></div><div>1) A new block B0 is mined and broadcast as u=
sual</div><div><br></div><div>2) Full nodes verify block B0. A subset of th=
ese nodes broadcast a new &quot;endorsement&quot; message endorsing the blo=
ck as valid, and preferred.</div><div><br></div><div>3) Miners, now assembl=
ing and beginning mining a new block (B1), add endorsements of B0 to B1&#39=
;s coinbase transaction, sharing the block reward with endorsers of B0.</di=
v><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>He=
re some details about each of the steps above, and what it buys us:</div><d=
iv><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><di=
v><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 foll=
owing the announcement of each new block.=C2=A0 An endorsement message need=
s to identify exactly one block at a specific height that it is endorsing.=
=C2=A0 It needs to include a payout address that meets certain validation c=
riteria 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+ b=
itcoin balance, some 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 mine=
r could easily fabricate a valid endorsement payout address.=C2=A0 The othe=
r 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. =C2=A0 This directly ties endorsements to a =
specific block, and makes it computationally inexpensive to verify/relay, o=
r drop invalid endorsement messages. The combination of PoS and mask will r=
estrict the number of valid addresses.=C2=A0 There are no restrictions on w=
hich endorsements a miner can include, as long as they are valid.=C2=A0 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 coin=
base transaction.</div><div><br></div><div>3) Miners consider whether to in=
clude endorsement payouts as part of their coinbase transaction.=C2=A0 They=
 need not do so, but by including endorsements, they significantly increase=
 the likelihood that their block will be selected.</div><div><br></div><div=
>CHANGE TO BEST CHAIN SELECTION</div><div><br></div><div>Block Endorsement =
requires a change to the best chain selection algorithm to encourage miners=
 to include endorsement payouts.=C2=A0 Because there is an incentive to inc=
lude endorsers, there is an incentive to broadcast mined blocks as soon as =
possible.=C2=A0</div><div><br></div><div>For the purpose of best chain sele=
ction, a block should get a significant bonus to its work (10%) for each va=
lid endorsement payout included in a block&#39;s valid coinbase transaction=
.=C2=A0 How many endorsements should be permitted is a design parameter whi=
ch is in play, but let&#39;s assume that up to 10 endorsements are permitte=
d. =C2=A0 For the purpose of block selection, a block&#39;s work, with 10 e=
ndorsements, is be effectively doubled.</div><div><br></div><div>EFFECT ON =
51% ATTACK</div><div><br></div><div>With Block Endorsement, because of the =
extra weight given to a block that has endorsements, a sustained 51% attack=
 becomes more expensive.=C2=A0 Valid blocks with full endorsements would wi=
n out over the attack blocks unless the attacker was able to not only contr=
ol 51% of the compute power, but to also control sufficient endorsements to=
 overcome the rest of the network.=C2=A0 To prevent an attacker from just u=
sing 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.=C2=A0 Quite possib=
ly we might need to provide a way for a booting node to request lists of en=
dorsers.</div><div><br></div><div>CHANGE TO BLOCK REWARD</div><div><br></di=
v><div>Miners would share block rewards with endorsers using a defined form=
ula which is TBD.=C2=A0 Endorsement rewards would be as much as 20% (design=
 parameter) of the block reward, and shared evenly between all endorsers in=
cluded in the coinbase.</div><div><br></div><div>CHANGE TO MINING STRATEGIE=
S</div><div><br></div><div>When a new block is broadcast, miners will begin=
 assembling yet another block.=C2=A0 Meanwhile, full nodes would validate t=
he new block, and endorsements would propagate quickly thereafter to all mi=
ners.=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 asse=
mbling a block, there would be a number of potential endorsers to include i=
n the coinbase tx, and if 10 were not available, a miner could decide to wa=
it, or begin mining it.=C2=A0 I suspect the time to collect 10 valid endors=
ers would be low, as endorsers should reply quickly in hopes of being inclu=
ded. Therefore, this additional wait time, if any, would not have a appreci=
able impact on the level of difficulty required to mine a block.</div><div>=
<br></div><div>I have thoughts on how to provide additional incentives to m=
iners to include multiple endorsers - for example, reducing the total endor=
sement fee down to 10% if endorsed by a full complement of endorsers.=C2=A0=
 We could also start with a lower reward and ramp up to some target over ti=
me 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 mu=
ch return.=C2=A0 It is easy to add complexity.=C2=A0 The challenge is to ke=
ep it as simple as possible.=C2=A0</div><div><br></div><div>CONCLUSION</div=
><div><br></div><div>By implementing Block Endorsement, we increase securit=
y of the blockchain by giving more weight to blocks that have been broadcas=
t and endorsed by multiple full nodes.=C2=A0 By providing a reward to these=
 endorsers, we provide an incentive for more full nodes.=C2=A0 With proof o=
f state mining on top of existing proof of work, we provide a low barrier t=
o entry, while not sacrificing the benefits provided by PoW.=C2=A0 With a l=
ower barrier to entry, we provide a more accessible avenue for mining, and =
in turn, encourage bitcoin adoption.</div><div><br></div><div>This is just =
the beginnings of an idea.=C2=A0 Assuming there isn&#39;t a fundamental fla=
w(s), there are many 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 ye=
t even as a thought experiment.=C2=A0 For instance, what new attack vectors=
 might be introduced?=C2=A0 Would a person controlling many potential endor=
sement 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 multi=
plier?=C2=A0 Or is that not practical?=C2=A0 The answer is probably a funct=
ion of the endorsement 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 consider.=C2=A0</div><div><br></div><div>And as I read disc=
ussions about double-spends and zero-confirmation transactions I can&#39;t =
help but wonder if maybe there is a way for endorsers to play a role in ide=
ntifying 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 feedback isn&#39;t derailing, would the next step be to proce=
ed with implementation, or would a new BIP be recommended?=C2=A0</div><div>=
<br></div><div>Well, I thought this would be only a few paragraphs.=C2=A0 I=
t is easy to carry on when you are excited about something.=C2=A0 That&#39;=
s also the time when 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 a=
ppreciative of constructive comments and questions.</div><div><br></div><di=
v>Thanks</div><span class=3D"HOEnZb"><font color=3D"#888888"><div>Chris Pag=
e</div></font></span></div>
<br>-----------------------------------------------------------------------=
-------<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">Bitcoin-develo=
pment@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>

--f46d041824dc707cb3050fd6b1ca--