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

[Mike Hearn <mike@plan99.net>]

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