Relevant chat log from the #bitcoin-wizards IRC channel . . .
<gmaxwell> 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. ...
<gmaxwell> ... 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.
. . .
<gmaxwell> 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 ...
<gmaxwell> ... 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.
<gmaxwell> (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)
<stephenreed> 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.
<gmaxwell> adam3us: Amiller, jbonneau and others have been working on a systemizing bitcoin knoweldge paper:
https://github.com/citp/bitcoin-sok. . .
<stephenreed> 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.
<stephenreed> gmaxwell: Nick Szabo explained the benefit of unforgeable logs as you probably alreadky know.
<gmaxwell> 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)
<stephenreed> 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?
<stephenreed> 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.
<stephenreed> gmaxwell: Sybils are prevented by the need to sufficient stake them.
<gmaxwell> 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.
<stephenreed> 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.
<gmaxwell> 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 ...
<gmaxwell> ... is the 'real one'?
<stephenreed> 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.
<andytoshi> stephenreed: the problem is that you have humans determining which transactions go where, so there is no canonical "behaves correctly" in this case
<stephenreed> 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.
<gmaxwell> 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)
<stephenreed> gmaxwell: created by a very carefully watched single nomadic mint agent ...
<gmaxwell> 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.
<adam3us> 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)
<stephenreed> 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.
<jgarzik> noooo
<andytoshi> 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)
<gmaxwell> 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 )
<jgarzik> somebody else proposed a super node network at the AMS conference
<jgarzik> how many variants of "but, if we just TRUST these guys over here a little bit more" do we need?
<stephenreed> jgarzik: my ideas are not new. The super peer idea evolved out of the p2p stuff back when Satoshi was looking at napster.
<stephenreed> gmaxwell: My software agents are trustless as Szabo suggests. The unforgeable log enables peers to validate.
<stephenreed> jgarzik: Super peers have superior network/server capability but run the same code base.
<jgarzik> same code base or not is immaterial
<stephenreed> 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.
<andytoshi> detecting cheating is easy, determining who is/isn't cheating is not
<andytoshi> 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
<stephenreed> jgarzik: material because tamper-evident logs record every action, inputs and outputs of a peer.
<stephenreed> andytoshi: that point addressed in the paper linked above - less than 50% faulty agents can be tolerated.
<adam3us> stephenreed: how can i audit a network entities tamper-evident logs? TPM remote attestation?
<jgarzik> andytoshi, indeed. And RE detecting cheating, Sybil'd views can make you particularly vulnerable
<stephenreed> 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.
<stephenreed> adam3us: here is the paper on TPM attestation that I studied -
http://www.mysmu.edu/faculty/xhding/publications/stc08.pdf<gmaxwell> 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.
<stephenreed> adam3us: For TPM I was looking at a bare metal implementation not a hypervisor.
<gmaxwell> (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)
<stephenreed> 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.
<stephenreed> 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.
<gmaxwell> 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.
<gmaxwell> Well I look forward to seeing some neat stuff!
<stephenreed> I wish the Barcelona test harness was done. I need to orchestrate lots of peers to meet your challenges.
<gmaxwell> (don't take my cycnism for dislike)
<stephenreed> gmaxwell: according to Gavin's videos you are the core developer that I need to convince first - Thanks and wait for code.
<stephenreed> Thanks for observing while I write the code of a lifetime.
<adam3us> 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
<gmaxwell> 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'.
<jgarzik> Yes, gmaxwell is the gateway to a new universe ;p
<gmaxwell> Hopefully not in the sense of some volcano-involving rital sacrifice.
<gmaxwell> 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)
<stephenreed> 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
<stephenreed> air somehow.
<sipa> "the keypair", which?
<stephenreed> 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.
<sipa> you say "capture the keypair somehow" -> which keypair?
<gmaxwell> 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.
<stephenreed> sipa: Well the QT wallet securely stores private keys so I suppose I would reuse that method.
<sipa> nodes have nothing to do with wallets
<sipa> it's a historical accident that satoshi's software does both
<gmaxwell> 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.
<stephenreed> 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".
<sipa> sounds like you just need something like a host key
<sipa> independent of the wallet
<stephenreed> sipa: how would you store it?
<sipa> oh, you also use it to receive coins?
<stephenreed> sipa: I need to receive bitcoins yes but that may be orthogonal
<sipa> you get rewards for running a full node?
<stephenreed> sipa: I hope that you will read my whitepaper ...
https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE<andytoshi> 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)
<stephenreed> sipa: I also have a good set of extended references on the bitcointalk thread OP -
https://bitcointalk.org/index.php?topic=584719.0<andytoshi> 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
<stephenreed> 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.
<sipa> sounds like a very different trust model than bitcoin
<sipa> (which is not a bad thing, but suggesting it as a replacement seems strange)
<stephenreed> sipa: a different trustless model yes. Cooperate to save effort, and verify peers to ban cheaters.
<sipa> bitcoin isn't fully trustless, and neither is this
<stephenreed> andytoshi: I will note your comment.
<stephenreed> 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.
<andytoshi> 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
<stephenreed> 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.
<andytoshi> stephenreed: the hard problem is getting people to stay up when it's costing them resources and maintenance
<stephenreed> 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!
<andytoshi> 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
<stephenreed> 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.
<andytoshi> 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)
<stephenreed> 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.
<stephenreed> andytoshi: If there was a way for a software probe to determine, and to ensure, dispersed geographical locations - then I would use that.
<andytoshi> 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
<andytoshi> 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
<andytoshi> if anything using stake as a gatekeeping mechanism will cause your system to tend to oligarchy
<stephenreed> andytoshi: have to go, but I think online wallet hosting will be the largest stake holders.
<andytoshi> alright, ttyl, but as sipa says this is a large philosophical shift away from bitcoin
