Topic: AI Coin Development Diary - page 12. (Read 49310 times)

I don't think you quite appreciate the irony of that statement.

If we are going to drive Visa and bank wire transfers out of business, then our network needs to be better than theirs. It cannot depend on part-time laptops and ADSL connections. It can be supplemented by those sort of home computers, but the network needs to be non-stop, redundant, and robust in case of power failure and Internet connection outages.

Enterprise class servers and networks are a solved problem. All it takes is money. Each day block creation rewards total about $1.6 million. There is plenty of money to give Bitcoin the hardware it deserves and to pay people around the world to run full nodes - if and when CPoS replaces PoW.

Enterprise-class would be a major downgrade from bitcoin's current class.  Bitcoin is AT LEAST solar-system-class.

The response was . . .

Bitcoin is not a democracy. It's a micro-government, but where those with the hashing-power are for ever the rulers of Bitcointopia. There is no necessity to preserve the existing wealth. If the system is superior it will earn it of the market. And so we have a market of competing currencies. The incentives are high enough for people to make a better invention. Starting from scratch in software is often a good thing.

Initial Install of Bitcoin Core and wallet . . .

Following Jameson Lopp's directions http://coinchomp.com/2014/04/03/set-ide-developing-bitcoin-core-ubuntu-linux/

I have the branch from GitHub at https://github.com/StephenLReed/bitcoin

I followed the directions in build-unix.md. I have Ubuntu 13.10.
 
I added the bitcoin repository - ppa:bitcoin/bitcoin

Of the options, I chose to install libdb4.8, libboost1.53 and libminiupnpc-dev.

I executed ./autogen.sh
I executed ./configure until no errors
I executed make
OK

I installed NetBeans for C++ and compiled the bitcoin project OK. NetBeans gives hints as to problems it finds in the editor pane and I messaged sipa on #bitcoin-dev about this unresolved forward reference in main.h . . .


sipa said it should be . . .


The change built OK in NetBeans, so the next step is to run the provided regression tests. The regression tests ran OK.

The bitcoin core code only has perhaps 30% of Satoshi's code remaining. It can change.

The proposed system takes pains to preserve as much as the Satoshi Social Contract as possible. That is what users see. For them nothing much should change, and what does change should be much better. Full nodes are the foundation of Satoshi's Bitcoin. My proposal pays for upgrades so that they may process all the world's transactions.

A comment from the bitcoin-development email list . . .

I'm doing a hard fork, too. In my version 78% of the wealth will go to me, which I will redistribute on based on personal preferences. Come and join me into a new and obviously superior system.

More seriously though: the paper is not bad, but I can guarantee you that Bitcoin will never change that drastically. That's the whole point. It has an indestructible kernel (think DNA). Rather it will do a slow death, probably in 5-10 years. If you care for PoS than just launch your own.

Dividends should come in the form of burned stake, not in the form of redistributed stake. If you burn transaction fees, for example, that is an implicit dividend to everyone on the network since the money supply increased and purchasing power is transferred from those transacting to those saving.

Thanks for commenting on my whitepaper. I linked proof-of-stake and infrastructure incentives because reallocating the block creation rewards yields $1.6 million daily, which pays for a lot of infrastructure, transaction fee subsidies - and just say 200 paid developers.

The banning of misbehaving nodes is an unclear statement on my part which is an attempt to characterize how a bitcoind instance currently disconnects from peers who repeatedly send invalid messages to it. That aspect of bitcoind I would not change. I extend that behavior so that peers actively replay each other's operations to check for consistency. When an inconsistent peer is identified by a quorum of its peers, it is disconnected - for some temporary period. And the reason would be made clear to the disconnected peer owner by an alert.

Morality is math. As long as it's equally applied throughout a system it's useful.
So as long as everyone follows the same rules no matter how ridiculous it seems it still creates order.

Call it morality or call it algorithm and there is no real difference between the two for a machine. It seems they are more critical of the framing and language you're using than the math behind it.

Overall what you intend to do looks a lot like DPoS. We may know whether or not your CPoS scheme can work from a review of the functioning of DPoS on the Bitshares network. It works on very similar principles except with a different metaphor to explain it. The delegates or the trustee would be fired for misbehavior (which is the same as being banned). I also see some similarities between CPoS and NXT.

Slight difference is that DPoS is deflationary from the beginning. Transaction fees are burned in DPoS, but there are some very good ideas in your whitepaper which it seems DPoS hasn't thought about so CPoS will be a very interesting experiment.

CPoS in my opinion is the right direction to take Bitcoin so you have my vote. Proof of Work is dead and the core devs might be able to save if it they switch from SHA-256 but we all know they cannot for political reasons. The fact that they haven't switched for political reasons is all the proof I need that Bitcoin is centralized. You're attempting to redecentralize Bitcoin and I applaud your effort.

Relevant chat log from the #bitcoin-wizards IRC channel . . .

stephenreed: Yes, bitcoin is ugly in many ways. I spent a decade working for a company building huge routers for internet backbones and working with big providers... I'm well familar with big communications infrastructure.  Bitcoin uses non-scalable mechnimes in a way which "can't work" to achieve an end— an anonymous decenteralized consensus— which "isn't possible" by conventional thinking.  In practice, so far, it does work.  ...
... And I'd love to see something that achieved the same ends, but wishing it doesn't make it so... The uglyness in Bitcoin is not an accident, not a result of ignorance... the problem space truly is hard.
. . .
At one point I wrote long winded essays that what bitcoin achieves— a decenteralized consensus— was precluded by physical law. I was wrong, because I didn't consider the right relaxations of the requirements (the the consensus could be eventual and only so under certian economic assumptions, that a vote could be sufficiently sybil resources through the provable expendature of physically finite resources and at the same time ...
... create the incentives the first required). There might be similar alterations of the assumptions or requirements that yield alternative solutions. I certantly hope so.  But I'd expect the presentation any successful attempt to start with a very clear statement of what the assumptions and limitations are, and how it addresses the hard problems that arise in this space.
(well to be clear, I'm already aware of some different designs with different assumptions— e.g. there are some proposals which achieve awesome properties— fast, secure, and scalable— that depend on a simple majority of non-anonymous signing registrars being honest. E.g. the compromise decenteralization to get basically every other property you could ask for)
adam3us: I saw the link to Chris' paper on the dev mail list, read it, and asked him for permission to use it as a reference in my paper. He gave it.
adam3us: Amiller, jbonneau and others have been working on a systemizing bitcoin knoweldge paper: https://github.com/citp/bitcoin-sok
. . .
gmaxwell: this is a key paper that I referenced - http://iris.csail.mit.edu/irisbib/papers/aaom:sosp21/paper.pdf    Attested Append-Only Memory: Making Adversaries Stick to their Word, Chun et al. Their math says it is byzantine fault tolerant with respect to relicas less than 50% faulty. Then I use timeline entanglement to make the logs tamper-evident. Also a reference from my paper.
gmaxwell: Nick Szabo explained the benefit of unforgeable logs as you probably alreadky know.
stephenreed: I believe I've read this before? Will check... but generally the problem the clasical approaches have is they do not work in the model of anonymous membership. You have have agreed in advance the identity of the members of the participants in the system. (and have some method to be confident that they are not mostly sybils of a single party)
gmaxwell: given your network architecture experience, superior to my own, would you say that such a network could indeed handle all the world's transactions?
gmaxwell: in my system the peers provide a controlled bitcoin address both for identity and for signing their non-transaction messages. That is the audit trail peers can easily verify.
gmaxwell: Sybils are prevented by the need to sufficient stake them.
stephenreed: Bitcoin the payment network? of course not, but it doesn't need to for bitcoin the currency to handle all the worlds transactions (if the world wished it so).  With a sold, throughly secure and decenteralized base we can run additional payment systems on top of bitcoin to achieve additional features and scale.
gmaxwell: I mean is the super peer network truly capable of handling all the worlds transactions? I think so based on what I read about VisaNet and SwiftNet.
stephenreed: If the identity is a propery inside the system how do you prevent simulation?  An example of simulation attacks: past participants leave the system, someone obtains their keys, recovers a snapshot from when they were still a quorum, then plays forward creating a new alternative history.  A new entrant joins the system, he can tell that someone cheated (by the conflicting signatures) but how can he distinguish which state ...
... is the 'real one'?
gmaxwell: the point is weakened if the peer behaves correctly. A thief to the original owner - but that is same in the current system with regard to hacking a hot wallet.
stephenreed: the problem is that you have humans determining which transactions go where, so there is no canonical "behaves correctly" in this case
The orginal history was created by a very carefully single nomadic mint. Did you get that point? All full nodes replicate the single version blockchain.
Those thefts happen all the time, even when there is something significant at stake— in my example though they keys could be stolen after the peer has no involvement with bitcoin at all and will lose nothing in an attack (and in fact, may gain handsomly by facilitating an attack)
gmaxwell: created by a very carefully watched single nomadic mint agent ...
stephenreed: I'm not sure I follow your question wrt super peer network. My own prior comment was that I believe the bitcoin ecosystem in total would be able to handle all the worlds transactions, if we wished it to.
gmaxwell: i think the scale question should be with the caveat that to interestingly scale, the main bitcoin properties should still be available to all users (unseizable, unfreezable, user control) for that to be an interesting scaling architecture.  its less interesting if we have a $100k min transaction clearing network with unseizability for them, but trust me for users.  (less but still interesting, viz international banking freezes and spats)
gmaxwell: Indeed a mesh network could have preferred connections and that is how I intend to modify the core to become a super peer network.
noooo
stephenreed: to a newcomer, the original history and a forked history may be indistinguishable as far as legitimacy goes. it's hard to verify things like "carefully watched" even if you are forcing your superpeers to basically be visible economic entities (since they need so much space and bandwidth)
stephenreed: There are a great many things you can do if you have a centeral point of trust. And lots of ways to achieve audiability where misconduct of that agent is visible... Thats a viable approach but _very_ philosophically different from Bitcoin, because that agent is still trusted. (I wonder if you've seen the original p2pfoundation announcement of bitcoin? http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source )
somebody else proposed a super node network at the AMS conference
how many variants of "but, if we just TRUST these guys over here a little bit more" do we need?
jgarzik: my ideas are not new. The super peer idea evolved out of the p2p stuff back when Satoshi was looking at napster.
gmaxwell: My software agents are trustless as Szabo suggests. The unforgeable log enables peers to validate.
jgarzik: Super peers have superior network/server capability but run the same code base.
same code base or not is immaterial
andytoshi: yes visible so that cooperation is assumed but cheating quickly detected. The network reengineering can easily handle the increased traffic - point to point, not mesh.
detecting cheating is easy, determining who is/isn't cheating is not
stephenreed: even if you get trustless software agents (e.g. by auditing their behavior or somehow TPM-verifying that they are clean VMs running only your software) you still have (a) random coins, e.g. for peer selection, and (b) user decisions, e.g. transactions, which are inputs from the real world and therefore can be used to introduce distortions and/or forks
jgarzik: material because tamper-evident logs record every action, inputs and outputs of a peer.
andytoshi: that point addressed in the paper linked above - less than 50% faulty agents can be tolerated.
stephenreed: how can i audit a network entities tamper-evident logs? TPM remote attestation?
andytoshi, indeed.  And RE detecting cheating, Sybil'd views can make you particularly vulnerable
adam3us: yes, but I omitted TPM attestation from the paper because current implementations are too proprietary. I want a TPM enabled stack that says your current release of bitcoind is running and nothing else - no keyloggers etc.
adam3us: here is the paper on TPM attestation that I studied - http://www.mysmu.edu/faculty/xhding/publications/stc08.pdf
stephenreed: These are all neat technologies that we've talked about in here and ought to exist as part of the greater bitcoin ecosystem... but they are really not a replacement for what Bitcoin provides.  E.g. the TPM hardware maker can trivially compromise those systems.
adam3us: For TPM I was looking at a bare metal implementation not a hypervisor.
(I happen to have an IBM cryptocard myself— which is basically the pinnical of remote attest technology right now— ... and I've been playing around with the nexus operating system, which is a hypervisory OS that facilitates remote attest)
gmaxwell: right about TPM. I understand you need a license to use it in China for example. So remote attestation of unforgeable logs per Szablo works too.
gmaxwell: They are not a replacement for proof-of-work. They are a replacement that preserves the Satoshi Social Contract between developers and users. My ideas are half-baked now. The code to be written will speak for itself.
Traditional reserve currencies are backed by power and authority of natition states— entities with the power to extinguish all life on earth (well, at least all human life)— and yet they do not behave in a way that many people consider trustworthy— they are rules by politics and personalities not by Law.  Some of them have apparently strong social contracts, and yet they do not prevent mission drift.
Well I look forward to seeing some neat stuff!
I wish the Barcelona test harness was done. I need to orchestrate lots of peers to meet your challenges.
(don't take my cycnism for dislike)
gmaxwell: according to Gavin's videos you are the core developer that I need to convince first - Thanks and wait for code.
Thanks for observing while I write the code of a lifetime.
stephenreed: i would encourage generally to explain algo before coding it because its many orders of magnitude faster to explain an algo than to code it; that way you get feedback early if there are problems that'd need a rewrite
Right well in particular make sure the high level objectives of the algorithim are clear before the details.  It's a lot of work to sort out the limitations in the architecture of an idea starting at the 'molecular level'.
Yes, gmaxwell is the gateway to a new universe ;p
Hopefully not in the sense of some volcano-involving rital sacrifice.
In other news, the bytecoin-derrived cryptocurrencies ecosystem is now using merged mining, there is now a fork that is merged mined against and of the 3 (or more?) prior bytecoin-derrived cryptocurrencies. (this isn't super news its a few weeks old, but its news to me)
adam3us: After making or reusing a test harness,  the first bit of work is the tamper evident log, which should be easy to document since I will look closely at the current debug log of bitcoind. The step beyond that would be timeline entanglement which makes the logs tamper-evident. I need to be able to digitally sign a peers log. The functions I need should already be in the core, provided I can capture the key p
air somehow.
"the keypair", which?
sipa: If you have been following the conversation, then Szabo style unforgeable logs can be created if peers sign  each others logs. I propose for a peer operating a full node to provide a key pair for that purpose, e.g. a bitcoin address public/private key pair.
you say "capture the keypair somehow" -> which keypair?
stephenreed: in bitcoin the blockchain itself is the unforgable log, but because the system is anonymous (there are no enumerated identities) they are signed via cumulative proof of work instead of a traditional digital signature.  Debug.log is orthorgonal, it's just for software QA, and very little of it is about information which is interesting to other parties.
sipa: Well the QT wallet securely stores private keys so I suppose I would reuse that method.
nodes have nothing to do with wallets
it's a historical accident that satoshi's software does both
stephenreed: normally bitcoin keys in wallets are intended to be single use, one transaction. As sipa notes we've been slowy working towards seperating the functionality.
separation is great. My purposes require that a peer sign another peers log to make it tamper-evident. I need for the node operator to provide the private key to bitcoind. The wallet has a method to input and securely store private keys. I may need the wallet in order to received daily dividends from the "reward agent".
sounds like you just need something like a host key
independent of the wallet
sipa: how would you store it?
oh, you also use it to receive coins?
sipa: I need to receive bitcoins yes but that may be orthogonal
you get rewards for running a full node?
sipa: I hope that you will read my whitepaper ... https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE
sipa: as i understand it, that is part of stephenreed's proposal because he has mechanisms by which peers enter and leave the system (which include proving some amount of dedicated resources as a sybil prevention)
sipa: I also have a good set of extended references on the bitcointalk thread OP - https://bitcointalksearch.org/topic/ai-coin-development-diary-584719
stephenreed: you want to separate bitcoin addresses from authentication, you can attach addresses (for receiving funds) to your ID by signing them with your auth key, but because addresses are supposed to be ephemeral they are not well-suited to auth on their own
sipa:  The whitepaper describes -  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 paying miners. Subsidized transaction fees are thus lower.
sounds like a very different trust model than bitcoin
(which is not a bad thing, but suggesting it as a replacement seems strange)
sipa: a different trustless model yes. Cooperate to save effort, and verify peers to ban cheaters.
bitcoin isn't fully trustless, and neither is this
andytoshi: I will  note your comment.
andytoshi: compared to todays bitcoin, I strongly desire permanent full nodes and would allocate sufficient reward to them to make that happen. SPV nodes can come and go.
i guess you mean quasi-permanent, like tor, and that's another hard problem (though i don't believe it's impossible) to incentivize in a sybil-resistant way
andytoshi: You must think that there is a hard problem that I am missing. I appears simple to me to keep track of peer uptime. I would create another agent to perform that duty.
stephenreed: the hard problem is getting people to stay up when it's costing them resources and maintenance
andytoshi: the peer would be identified by IP address and offered public bitcoin address. I would pay them to stay up. The current reward is $1.6 million per day divided by say 10000 full nodes!
right, but it's easy to farm IP addresses and route them to a single box, it's hard to prove that every IP corresponds to disparate physical resources
andytoshi: That is true of the current system where full nodes are hosted for $19 per month in a data center sharing a portion of some server. Replication of the blockchain is very important.
it's true but why would anyone bother? it doesn't improve the decentralization or value of the network (which is the only incentive to run a full node today, besides goodwill and geek cred, which are also not helped by standing up sybils)
andytoshi: Identity is supported by the controlled bitcoin address offered by each full node. The more stake, then more likely they are to be Sybil resistant.
andytoshi: If there was a way for a software probe to determine, and to ensure, dispersed geographical locations - then I would use that.
we had a recent discussion on ##crypto (or was it here?) about cryptographic proof of location, and i think we landed on "it's probably impossible" at least on earth since attackers can use fast airborne radio waves while honest parties have to use slow quantum signals in fiber optics
regarding sybil resistance, if i have a lot of stake i'll get more reward but that still doesn't incentivize me to start more physical nodes. i'll open as many fake ones as my stake allows
if anything using stake as a gatekeeping mechanism will cause your system to tend to oligarchy
andytoshi: have to go, but I think online wallet hosting will be the largest stake holders.
alright, ttyl, but as sipa says this is a large philosophical shift away from bitcoin

Comment from the Bitcoin-development email list . . .

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.

So its mostly based on DPoS?

Can't wait for a DPoS coin to come up (I think its close judging by Bytemaster's updates), and then see how it operates in real environment.

As a result of writing the whitepaper and listening to constructive comments, e.g. yours, about the proposed Bitcoin system, I am persuaded that paying dividends to stakeholders is a lower priority than investing bitcoin block creation rewards into a network capable of processing all the world's transactions.

This system needs a way to prevent an attacker from establishing numerous puppet nodes, who by acting in concert, could outvote the correct nodes and allow misbehavior. Proof-of-stake provides a means to limit the ability of an attacker to outvote correct nodes. The assumption is that correct nodes will offer sufficient stake in a hot wallet in return for a certain amount of dividends.

The reward allocation policy is most certainly going to be contentious, and increasingly so as the technical barriers are overcome by working code through the end of this year. Core developers are skeptical of my ideas. But if they are won over by working code, then what to do with the $1.6 million daily block creation reward is moved from fantasy conjecture to pressing importance.

The block creation rewards increase with the price of bitcoin, halving in the summer of 2016 to 12.5 bitcoins per block, but staying at that schedule through 2020. Supposing bitcoin indeed reaches $1 million per bitcoin in 2017-2018, then the daily block reward in 2017 might be $1.8 billion per day.

Provided that network infrastructure is generously funded, including just say two hundred paid developers, and that sufficient dividends are paid to support proof-of-stake voting, why not subsidize transaction fees with the block creation reward? I can imagine circumstances in which bitcoin transaction fees could be negative. Visa could not compete with that. The challenge is to prevent abuse, e.g. we could figure out a way for merchants to identify themselves and subsidize transactions paid to them.

QFT.

It is surprisingly often good, when a proposal is being discussed, to consider doing the exact opposite. If it is not found pernicious, it is doubtful that the proposal is found beneficial.

I always see people quote the Gavin phrase of "nothing at stake" as fact, but it seems like a complete logical fallacy to me.  Don't you need a majority of people holding the proof of stake currency to run non-reference clients to stake multiple chains at once for this to be true?  So you're basically saying the people with the most financial incentive to protect the network are all going to attempt to destroy the network security on purpose, and do it en masse?  How does this not violate game theory?

Bitcoin relies on game theory to exist.  It seems like these same principles should prevent such a thing occurring in proof of stake.

Let's not forget that most people on the planet aren't programmers.  If any crypto coins make it into the mainstream, the majority of people holding proof of stake coins, or using the network at all, will not have any idea how to leverage their stake to attack it.  I feel like many proof of stake attack vectors are done under the assumption that the majority of coin holders are Russian cyber criminals.

Assuming the proof of stake complaints are either dispelled or fixed, the main issue I have with proof of stake is it's attacks are very hard to see coming.  If a vendor like Amazon was taking huge volume of Bitcoin, they would actively monitor network hashrate and have a Defcon 1, red alarm siren go off when the hash rate became too lopsided to accept BTC.  They would then just not accept payments until the hash is distributed better.  Practices like this make the 51% attack almost irrelevant for big business.

Doing something similar to the above with proof of stake seems almost impossible.

what about a solution to mint with an offline wallet, connected to an online one? it's possible?

If you think burning dollar bills represents useless spending, then do you also think printing new dollar bills represents useful savings?  I think you must because your dividend idea essentially prints new bitcoin bills and distributes them, not to those who did work, but to those who held stake.  You seem to think this represents increased wealth (savings).  

The truth is that burning dollars bills is not spending because nothing was consumed.  Similarly, printing more dollar bills is not savings because no consumption was deferred.  

In both cases (burning or printing dollars bills), all you are doing is changing the value of M in the Quantity Theory of Money equation:

   M V = P Q

If you burn dollar bills, then M decreases.  To maintain the economy's real output Q and velocity of money V, the price levels across the economy need to decrease.  So I would argue that you burning your dollar bills is actually a good thing for me because it will very slightly decrease the prices I pay.  It is like a small donation to all the holders of the currency.

In your proposal, you do the opposite: you print new bitcoin bills and distribute them to the stake holders. But this just devalues the money, and assuming all else remains constant, price levels across the economy would tend to rise.  In other words, stake holders may have 10% more money but everything costs 10% more.      

Why don't you invite Sunny King to chip in? He is the one that turns PoS into reality through PPC.

Just wondering from your user name if you are a fellow miner?

If so, would you be better off buying dividend paying bitcoins with the money you otherwise set aside to upgrade your rigs? The bitcoin bubble and bust cycles tend to ruin miners. I keep my GPU scrypt rigs leased out for bitcoin on LeaseRigs. I will not sell the cards, I just migrate the mining algorithm away from ASICs.