[Bitcoin-development] Proof-of-Stake branch?

[Bitcoin-development] Proof-of-Stake branch?

[Stephen Reed]

Hello all.

I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list.
-----

A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread.

"Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice?"

"I do not care or do not know enough." - 5 (16.1%) 
"I would download and run the existing Proof-of-Work program to fight the change." - 14 (45.2%) 
"I would download and run the new Proof-of-Stake program to favor the change. " - 12 (38.7%) 
Total Voters: 31 
-----

Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion.

Thanks for taking a bit of your time to read this message.

-Steve

Stephen L. Reed

Austin, Texas, USA
512.791.7860 

Re: [Bitcoin-development] Proof-of-Stake branch?

[Troy Benjegerdes]

Do it. Someone will scream harm. The loudest voices screaming how it would
be harmful are doing the most harm.

The only way to know is build it, and test it. If the network breaks, then
it is better we find out sooner rather than later.

My only suggestion is call it 'bitstake' or something to clearly differentiate
it from Bitcoin. This also might be an interesting application of the side
chains concept Peter Todd has discussed.

On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
> Hello all.
> 
> I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list.
> -----
> 
> A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread.
> 
> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice?"
> 
> "I do not care or do not know enough." - 5 (16.1%) 
> "I would download and run the existing Proof-of-Work program to fight the change." - 14 (45.2%) 
> "I would download and run the new Proof-of-Stake program to favor the change. " - 12 (38.7%) 
> Total Voters: 31 
> -----
> 
> Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion.
> 
> Thanks for taking a bit of your time to read this message.




-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: [Bitcoin-development] Proof-of-Stake branch?

[Stephen Reed]

My understanding is that sidechains require merged mining support and that sidechains create no coinbase transactions themselves. When Bitcoin Core supports the two-way peg then I would update my source code branch to incorporate that or any other change that is released. Ideally, when sidechains can work with PoW Bitcoin, then those same sidechains should work without any changes with PoS Bitcoin running in my testnet.

I will be examining PPC, NXT and whitepapers for ideas that I can implement in such a way as the result can be called Bitcoin. The only difference would be the absence of wasteful Proof-of-Work, and the presence of mining rewards distributed to full nodes in proportion to the amount of bitcoin each is willing to expose to the network. Coin age is a good starting point. A reference peer-to-peer pool developed by me would be responsible for fairly distributing the mining rewards as daily dividend payments to PoS full node pool members.

In a few days, I plan to establish a Proof-of-Stake Bitcoin project thread in the Project Development sub-forum of Bitcointalk. We can continue the technical discussion there, starting with a list of principles.


Stephen L. Reed 
Austin, Texas, USA 
512.791.7860

On Friday, April 25, 2014 4:42 AM, Jeffrey Paul <sneak@acidhou.se> wrote:

Are proof of stake blockchains compatible with the sidechain/two-way peg system invented by Greg (and maybe others - reports unclear)?
>
>http://letstalkbitcoin.com/blockchain-2-0-let-a-thousand-chains-blossom/
>
>It's my limited understanding that any sidechains in such a model are somewhat cryptographically tied to the PoW system that bitcoin's chain uses. I am seriously curious if alternate decentralized consensus algorithms (proof of execution, proof of stake, et c) are compatible with the sidechain universe as envisioned. 
>
>Perhaps someone with a deeper technical understanding could explain how, if so, or if my incomplete hunch (that alternate consensus algorithms cannot retain compatibility with Bitcoin in a two way peg model) is correct.
>
>These sorts of "alternate universe" altcoin experiments with different proof models take on a different cost/benefit ratio if they can't ever interoperate as sidechains, which is why I'm curious. 
>
>Best,
>-jp
>
>-- 
>Jeffrey Paul   +1 (312) 361-0355
>5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
>
>
>> On 25.04.2014, at 00:33, Troy Benjegerdes <hozer@hozed.org> wrote:
>> 
>> This also might be an interesting application of the side
>> chains concept Peter Todd has discussed.
>
> 

Re: [Bitcoin-development] Proof-of-Stake branch?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3965 bytes --]

Please be aware that your emails are being spamfoldered by Gmail. This is
because Yahoo has enabled DMARC enforcement for mail sent from Yahoo and
that renders it incompatible with Sourceforge mailing lists.

There are two fixes:

1) Don't use Yahoo.

2) The real fix which is, we should stop using Sourceforge mailing list
software

Fundamentally all Yahoo is saying with their policy is that rewriting of
mails sent from their service is not allowed. This is a highly reasonable
policy, akin to forbidding SSL MITM attacks, but for email.

There are several ways to be compatible with this policy: unfortunately
sf.net doesn't do any of them.




On Fri, Apr 25, 2014 at 12:35 PM, Stephen Reed <stephenreed@yahoo.com>wrote:

> My understanding is that sidechains require merged mining support and that
> sidechains create no coinbase transactions themselves. When Bitcoin Core
> supports the two-way peg then I would update my source code branch to
> incorporate that or any other change that is released. Ideally, when
> sidechains can work with PoW Bitcoin, then those same sidechains should
> work without any changes with PoS Bitcoin running in my testnet.
>
> I will be examining PPC, NXT and whitepapers for ideas that I can
> implement in such a way as the result can be called Bitcoin. The only
> difference would be the absence of wasteful Proof-of-Work, and the presence
> of mining rewards distributed to full nodes in proportion to the amount of
> bitcoin each is willing to expose to the network. Coin age is a good
> starting point. A reference peer-to-peer pool developed by me would be
> responsible for fairly distributing the mining rewards as daily dividend
> payments to PoS full node pool members.
>
> In a few days, I plan to establish a Proof-of-Stake Bitcoin project thread
> in the Project Development sub-forum of Bitcointalk. We can continue the
> technical discussion there, starting with a list of principles.
>
>
> Stephen L. Reed
> Austin, Texas, USA
> 512.791.7860
>
> On Friday, April 25, 2014 4:42 AM, Jeffrey Paul <sneak@acidhou.se> wrote:
>
> Are proof of stake blockchains compatible with the sidechain/two-way peg
> system invented by Greg (and maybe others - reports unclear)?
> >
> >http://letstalkbitcoin.com/blockchain-2-0-let-a-thousand-chains-blossom/
> >
> >It's my limited understanding that any sidechains in such a model are
> somewhat cryptographically tied to the PoW system that bitcoin's chain
> uses. I am seriously curious if alternate decentralized consensus
> algorithms (proof of execution, proof of stake, et c) are compatible with
> the sidechain universe as envisioned.
> >
> >Perhaps someone with a deeper technical understanding could explain how,
> if so, or if my incomplete hunch (that alternate consensus algorithms
> cannot retain compatibility with Bitcoin in a two way peg model) is correct.
> >
> >These sorts of "alternate universe" altcoin experiments with different
> proof models take on a different cost/benefit ratio if they can't ever
> interoperate as sidechains, which is why I'm curious.
> >
> >Best,
> >-jp
> >
> >--
> >Jeffrey Paul   +1 (312) 361-0355
> >5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
> >
> >
> >> On 25.04.2014, at 00:33, Troy Benjegerdes <hozer@hozed.org> wrote:
> >>
> >> This also might be an interesting application of the side
> >> chains concept Peter Todd has discussed.
> >
> >
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 5177 bytes --]

Re: [Bitcoin-development] Proof-of-Stake branch?

[Mark Friedenbach]

There's no need to be confrontational. I don't think anyone here objects
to the basic concept of proof-of-stake. Some people, myself included,
have proposed protocols which involve some sort of proof of stake
mechanism, and the idea itself originated as a mechanism for eliminating
checkpoints, something which is very much on topic and of concern to
many here.

The problems come when one tries to *replace* proof-of-work mining with
proof-of-stake "mining." You encounter problems related to the fact that
with proof-of-stake nothing is actually at stake. You are free to sign
as many different forks as you wish, and worse have incentive to do so,
because whatever fork does win, you want it to be yours. In the worst
case this results in double-spends at will, and in the best case with
any of the various proposed protections deployed, it merely reduces to
proof-of-work as miners grind blocks until they find one that names them
or one of their sock puppets as the signer of the next block.

I sincerely doubt you will find a solution to this, as it appears to be
a fundamental issue with proof-of-stake, in that it must leverage an
existing mechanism for enforced scarcity (e.g. proof-of-work) in order
to work in a consensus algorithm. Is there some solution that you have
in mind for this?

Mark

On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
> Do it. Someone will scream harm. The loudest voices screaming how it would
> be harmful are doing the most harm.
> 
> The only way to know is build it, and test it. If the network breaks, then
> it is better we find out sooner rather than later.
> 
> My only suggestion is call it 'bitstake' or something to clearly differentiate
> it from Bitcoin. This also might be an interesting application of the side
> chains concept Peter Todd has discussed.
> 
> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>> Hello all.
>>
>> I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list.
>> -----
>>
>> A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread.
>>
>> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice?"
>>
>> "I do not care or do not know enough." - 5 (16.1%) 
>> "I would download and run the existing Proof-of-Work program to fight the change." - 14 (45.2%) 
>> "I would download and run the new Proof-of-Stake program to favor the change. " - 12 (38.7%) 
>> Total Voters: 31 
>> -----
>>
>> Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion.
>>
>> Thanks for taking a bit of your time to read this message.
> 
> 
> 
> 

Re: [Bitcoin-development] Proof-of-Stake branch?

[Gareth Williams]

What about using fraud proofs? Your coinbase only matures if nobody publishes proof that you signed a competing block. 

Then something is at least at stake. When it's your chance to sign a block, attempting to sign and publish more than one at the same height reliably punishes you (you effectively waste your chance and receive no reward.)

I can't remember who I saw discussing this idea. Might have been Vitalik Buterin?

On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach <mark@monetize.io> wrote:
>There's no need to be confrontational. I don't think anyone here
>objects
>to the basic concept of proof-of-stake. Some people, myself included,
>have proposed protocols which involve some sort of proof of stake
>mechanism, and the idea itself originated as a mechanism for
>eliminating
>checkpoints, something which is very much on topic and of concern to
>many here.
>
>The problems come when one tries to *replace* proof-of-work mining with
>proof-of-stake "mining." You encounter problems related to the fact
>that
>with proof-of-stake nothing is actually at stake. You are free to sign
>as many different forks as you wish, and worse have incentive to do so,
>because whatever fork does win, you want it to be yours. In the worst
>case this results in double-spends at will, and in the best case with
>any of the various proposed protections deployed, it merely reduces to
>proof-of-work as miners grind blocks until they find one that names
>them
>or one of their sock puppets as the signer of the next block.
>
>I sincerely doubt you will find a solution to this, as it appears to be
>a fundamental issue with proof-of-stake, in that it must leverage an
>existing mechanism for enforced scarcity (e.g. proof-of-work) in order
>to work in a consensus algorithm. Is there some solution that you have
>in mind for this?
>
>Mark
>
>On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
>> Do it. Someone will scream harm. The loudest voices screaming how it
>would
>> be harmful are doing the most harm.
>> 
>> The only way to know is build it, and test it. If the network breaks,
>then
>> it is better we find out sooner rather than later.
>> 
>> My only suggestion is call it 'bitstake' or something to clearly
>differentiate
>> it from Bitcoin. This also might be an interesting application of the
>side
>> chains concept Peter Todd has discussed.
>> 
>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>>> Hello all.
>>>
>>> I understand that Proof-of-Stake as a replacement for Proof-of-Work
>is a prohibited yet disputed change to Bitcoin Core. I would like to
>create a Bitcoin branch that provides a sandboxed testbed for
>researching the best PoS implementations. In the years to come, perhaps
>circumstances might arise, such as shifting of user opinion as to
>whether PoS should be moved from the prohibited list to the hard-fork
>list.
>>> -----
>>>
>>> A poll I conducted today on bitcointalk,
>https://bitcointalk.org/index.php?topic=581635.0 with an
>attention-grabbing title suggests some minority support for Bitcoin
>Proof-of-Stake. I invite any of you to critically comment on that
>thread.
>>>
>>> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full
>nodes outnumber existing Proof-of-Work full nodes by three-to-one. What
>is your choice?"
>>>
>>> "I do not care or do not know enough." - 5 (16.1%) 
>>> "I would download and run the existing Proof-of-Work program to
>fight the change." - 14 (45.2%) 
>>> "I would download and run the new Proof-of-Stake program to favor
>the change. " - 12 (38.7%) 
>>> Total Voters: 31 
>>> -----
>>>
>>> Before I branch the source code and learn the proper way of doing
>things in this community, I ask you simply if creating the branch is
>harmful? My goal is to develop, test and document PoS, while exploring
>its vulnerabilities and fixing them in a transparent fashion.
>>>
>>> Thanks for taking a bit of your time to read this message.
>> 
>> 
>> 
>> 
>
>------------------------------------------------------------------------------
>Start Your Social Network Today - Download eXo Platform
>Build your Enterprise Intranet with eXo Platform Software
>Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>Get Started Now And Turn Your Intranet Into A Collaboration Platform
>http://p.sf.net/sfu/ExoPlatform
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Bitcoin-development] Proof-of-Stake branch?

[Mark Friedenbach]

That makes double-spends trivially easy: sign two blocks, withholding
one. Then at a later point in time reveal the second signed block
(demonstrating your own fraud) and force a reorg.

On 04/26/2014 04:44 PM, Gareth Williams wrote:
> What about using fraud proofs? Your coinbase only matures if nobody publishes proof that you signed a competing block. 
> 
> Then something is at least at stake. When it's your chance to sign a block, attempting to sign and publish more than one at the same height reliably punishes you (you effectively waste your chance and receive no reward.)
> 
> I can't remember who I saw discussing this idea. Might have been Vitalik Buterin?
> 
> On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach <mark@monetize.io> wrote:
>> There's no need to be confrontational. I don't think anyone here
>> objects
>> to the basic concept of proof-of-stake. Some people, myself included,
>> have proposed protocols which involve some sort of proof of stake
>> mechanism, and the idea itself originated as a mechanism for
>> eliminating
>> checkpoints, something which is very much on topic and of concern to
>> many here.
>>
>> The problems come when one tries to *replace* proof-of-work mining with
>> proof-of-stake "mining." You encounter problems related to the fact
>> that
>> with proof-of-stake nothing is actually at stake. You are free to sign
>> as many different forks as you wish, and worse have incentive to do so,
>> because whatever fork does win, you want it to be yours. In the worst
>> case this results in double-spends at will, and in the best case with
>> any of the various proposed protections deployed, it merely reduces to
>> proof-of-work as miners grind blocks until they find one that names
>> them
>> or one of their sock puppets as the signer of the next block.
>>
>> I sincerely doubt you will find a solution to this, as it appears to be
>> a fundamental issue with proof-of-stake, in that it must leverage an
>> existing mechanism for enforced scarcity (e.g. proof-of-work) in order
>> to work in a consensus algorithm. Is there some solution that you have
>> in mind for this?
>>
>> Mark
>>
>> On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
>>> Do it. Someone will scream harm. The loudest voices screaming how it
>> would
>>> be harmful are doing the most harm.
>>>
>>> The only way to know is build it, and test it. If the network breaks,
>> then
>>> it is better we find out sooner rather than later.
>>>
>>> My only suggestion is call it 'bitstake' or something to clearly
>> differentiate
>>> it from Bitcoin. This also might be an interesting application of the
>> side
>>> chains concept Peter Todd has discussed.
>>>
>>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>>>> Hello all.
>>>>
>>>> I understand that Proof-of-Stake as a replacement for Proof-of-Work
>> is a prohibited yet disputed change to Bitcoin Core. I would like to
>> create a Bitcoin branch that provides a sandboxed testbed for
>> researching the best PoS implementations. In the years to come, perhaps
>> circumstances might arise, such as shifting of user opinion as to
>> whether PoS should be moved from the prohibited list to the hard-fork
>> list.
>>>> -----
>>>>
>>>> A poll I conducted today on bitcointalk,
>> https://bitcointalk.org/index.php?topic=581635.0 with an
>> attention-grabbing title suggests some minority support for Bitcoin
>> Proof-of-Stake. I invite any of you to critically comment on that
>> thread.
>>>>
>>>> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full
>> nodes outnumber existing Proof-of-Work full nodes by three-to-one. What
>> is your choice?"
>>>>
>>>> "I do not care or do not know enough." - 5 (16.1%) 
>>>> "I would download and run the existing Proof-of-Work program to
>> fight the change." - 14 (45.2%) 
>>>> "I would download and run the new Proof-of-Stake program to favor
>> the change. " - 12 (38.7%) 
>>>> Total Voters: 31 
>>>> -----
>>>>
>>>> Before I branch the source code and learn the proper way of doing
>> things in this community, I ask you simply if creating the branch is
>> harmful? My goal is to develop, test and document PoS, while exploring
>> its vulnerabilities and fixing them in a transparent fashion.
>>>>
>>>> Thanks for taking a bit of your time to read this message.
>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Proof-of-Stake branch?

[Gareth Williams]

Who said anything about a re-org? The original block remains valid, your block reward is just zero, upon maturity, in light of a valid fraud proof.

ie. the "coinbase confiscation" that I was just arguing against in another thread :P but of course here based on cryptographic proof, not human judgement.

On 27 April 2014 11:22:07 AM AEST, Mark Friedenbach <mark@monetize.io> wrote:
>That makes double-spends trivially easy: sign two blocks, withholding
>one. Then at a later point in time reveal the second signed block
>(demonstrating your own fraud) and force a reorg.
>
>On 04/26/2014 04:44 PM, Gareth Williams wrote:
>> What about using fraud proofs? Your coinbase only matures if nobody
>publishes proof that you signed a competing block. 
>> 
>> Then something is at least at stake. When it's your chance to sign a
>block, attempting to sign and publish more than one at the same height
>reliably punishes you (you effectively waste your chance and receive no
>reward.)
>> 
>> I can't remember who I saw discussing this idea. Might have been
>Vitalik Buterin?
>> 
>> On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach <mark@monetize.io>
>wrote:
>>> There's no need to be confrontational. I don't think anyone here
>>> objects
>>> to the basic concept of proof-of-stake. Some people, myself
>included,
>>> have proposed protocols which involve some sort of proof of stake
>>> mechanism, and the idea itself originated as a mechanism for
>>> eliminating
>>> checkpoints, something which is very much on topic and of concern to
>>> many here.
>>>
>>> The problems come when one tries to *replace* proof-of-work mining
>with
>>> proof-of-stake "mining." You encounter problems related to the fact
>>> that
>>> with proof-of-stake nothing is actually at stake. You are free to
>sign
>>> as many different forks as you wish, and worse have incentive to do
>so,
>>> because whatever fork does win, you want it to be yours. In the
>worst
>>> case this results in double-spends at will, and in the best case
>with
>>> any of the various proposed protections deployed, it merely reduces
>to
>>> proof-of-work as miners grind blocks until they find one that names
>>> them
>>> or one of their sock puppets as the signer of the next block.
>>>
>>> I sincerely doubt you will find a solution to this, as it appears to
>be
>>> a fundamental issue with proof-of-stake, in that it must leverage an
>>> existing mechanism for enforced scarcity (e.g. proof-of-work) in
>order
>>> to work in a consensus algorithm. Is there some solution that you
>have
>>> in mind for this?
>>>
>>> Mark
>>>
>>> On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
>>>> Do it. Someone will scream harm. The loudest voices screaming how
>it
>>> would
>>>> be harmful are doing the most harm.
>>>>
>>>> The only way to know is build it, and test it. If the network
>breaks,
>>> then
>>>> it is better we find out sooner rather than later.
>>>>
>>>> My only suggestion is call it 'bitstake' or something to clearly
>>> differentiate
>>>> it from Bitcoin. This also might be an interesting application of
>the
>>> side
>>>> chains concept Peter Todd has discussed.
>>>>
>>>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>>>>> Hello all.
>>>>>
>>>>> I understand that Proof-of-Stake as a replacement for
>Proof-of-Work
>>> is a prohibited yet disputed change to Bitcoin Core. I would like to
>>> create a Bitcoin branch that provides a sandboxed testbed for
>>> researching the best PoS implementations. In the years to come,
>perhaps
>>> circumstances might arise, such as shifting of user opinion as to
>>> whether PoS should be moved from the prohibited list to the
>hard-fork
>>> list.
>>>>> -----
>>>>>
>>>>> A poll I conducted today on bitcointalk,
>>> https://bitcointalk.org/index.php?topic=581635.0 with an
>>> attention-grabbing title suggests some minority support for Bitcoin
>>> Proof-of-Stake. I invite any of you to critically comment on that
>>> thread.
>>>>>
>>>>> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full
>>> nodes outnumber existing Proof-of-Work full nodes by three-to-one.
>What
>>> is your choice?"
>>>>>
>>>>> "I do not care or do not know enough." - 5 (16.1%) 
>>>>> "I would download and run the existing Proof-of-Work program to
>>> fight the change." - 14 (45.2%) 
>>>>> "I would download and run the new Proof-of-Stake program to favor
>>> the change. " - 12 (38.7%) 
>>>>> Total Voters: 31 
>>>>> -----
>>>>>
>>>>> Before I branch the source code and learn the proper way of doing
>>> things in this community, I ask you simply if creating the branch is
>>> harmful? My goal is to develop, test and document PoS, while
>exploring
>>> its vulnerabilities and fixing them in a transparent fashion.
>>>>>
>>>>> Thanks for taking a bit of your time to read this message.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>------------------------------------------------------------------------------
>>> Start Your Social Network Today - Download eXo Platform
>>> Build your Enterprise Intranet with eXo Platform Software
>>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>>> http://p.sf.net/sfu/ExoPlatform
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
>
>------------------------------------------------------------------------------
>Start Your Social Network Today - Download eXo Platform
>Build your Enterprise Intranet with eXo Platform Software
>Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>Get Started Now And Turn Your Intranet Into A Collaboration Platform
>http://p.sf.net/sfu/ExoPlatform
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Bitcoin-development] Proof-of-Stake branch?

[Alex Mizrahi]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

>
> I can't remember who I saw discussing this idea. Might have been Vitalik
> Buterin?
>

Yes, he described it in an article a couple of months ago:

http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/

but it is an old idea.
For example, I've mentioned punishment of this kind in discussion about
PPCoin when it was released in 2012, and, I think, it was described in
Etlase2's Decrit design.

Also, I and Iddo did some research on pure proof-of-stake, and it seems to
be feasible, in the sense that there are no obvious problems like "nothing
is actually at stake". (Unfortunately I can't refer to it now as it isn't
published yet.)

[-- Attachment #2: Type: text/html, Size: 1245 bytes --]