From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>
To: "Stephen Reed" <stephenreed@yahoo.com>
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper
Date: Tue, 20 May 2014 23:47:36 -0700 [thread overview]
Message-ID: <6d3b8553c923f009cdb378c4a4967518.squirrel@fulvetta.riseup.net> (raw)
In-Reply-To: <1400602373.46778.YahooMailNeo@web160501.mail.bf1.yahoo.com>
> I completed a whitepaper for Bitcoin a proof-of-stake version which uses a
> single nomadic verifiable mint agent and distributed replication of a
> single blockchain by compensated full nodes to achieve 6-hop, sub-second
> transaction acknowledgement times. Plus it pays dividends to holders
> instead of wasting it on miners. Subsidized transaction fees are thus
> lower.
I look at this and agree of course that the nodes are decreasing, see,
https://getaddr.bitnodes.io/ But when I see stuff in the white paper
like "misbehaving nodes" in the context of an "audit agent," a "single
non-forking blockchain," the notion of "Misbehaving nodes" that would be
"banned from the network" so as to "motivat(e) honest behavior," ~ really,
all of this does sound as though a sort of morality is being formulated
rather than a mathematical solution.
This is not to say that the white paper hasn't addressed a problem that
needs to be addressed, namely... the problem of the nodes disappearing,
and a few other things. But to take that and then layer onto that the
issues associated with proof of stake... There does seem to be a simpler
way to address this and I think first without suggesting the complex issue
of some kind of thing that would involve dividends for those in a
proof-of-stake system, consensus achieved by stake-weighted voting, and so
forth, one would be better off removing all references to voting and
stake, and determining ways simply to incentivize more substantively those
who actually run a full node. Additionally I am hesitant to characterize
behavior as has been described in the white paper, as it would seem that
(in such a system) there would be an inclination or a tendency to exclude
certain patterns or groups of participants rather than determine ways in
which all participants or potential peers can serve the network.
>
> https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE
>
>
> Because the code is not yet written, this idea is half-baked so to speak.
> Comments appreciated on my project thread, which will be a development
> diary. I plan a hard fork of the Bitcoin blockchain in early 2016, after a
> year of public system testing, and conditioned on wide approval.
>
> https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403
>
> -Steve
>
> Stephen L. Reed
> Austin, Texas, USA
> 512.791.7860------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
prev parent reply other threads:[~2014-05-21 6:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-20 16:12 [Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper Stephen Reed
2014-05-20 16:42 ` Nick Simpson
2014-05-21 15:52 ` Benjamin Cordes
2014-05-21 6:47 ` Odinn Cyberguerrilla [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d3b8553c923f009cdb378c4a4967518.squirrel@fulvetta.riseup.net \
--to=odinn.cyberguerrilla@riseup.net \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=stephenreed@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox