| 00:00:57 | gmaxwell: | I probably need go do some talks on some actually interesting technology. Too much attention is being sopped up by things which are a bit weak. |
| 00:01:22 | antephialtic: | gmaxwell: such as? |
| 00:01:31 | sipa: | gmaxwell: i'm afraid you're too competent |
| 00:01:38 | petertodd: | sipa: I've noticed a lot of these projects have far more non-tech people than tech... |
| 00:02:03 | austinhill: | The problem with ethereum and all altcoins discussion ignore a very basic truth. The concept of digital scarcity needs to be rare for any of us to succeed. As with FIAT currencies the confidence in the system is based on trust - every altcoin game, mistake and celebrity moment (Kayne West coins) affect the confidence in the entire ecosystem which as we saw last two weeks when rumours infect the system (mt gox) it change |
| 00:02:11 | sipa: | "there are 2 types of people: those who actually achieve things, and those who try to take credit for it. Try to belong to the first group; there's less competition" |
| 00:02:25 | austinhill: | sipa: +1 |
| 00:03:05 | petertodd: | austinhill: ethereum isn't an altcoin in that sense |
| 00:03:24 | gmaxwell: | antephialtic: any of the stuff we talk about in here? I dunno. I've been trying to decide what would make a good talk that ties togeather some of the things that have been interesting me in the last year or two. I think there is a coherent thread that runs through a lot of it, but I haven't quite figured out the structure. |
| 00:03:35 | petertodd: | austinhill: it's basically saying "if bitcoin had features xyz it'd be much better" and "bitcoin isn't going to implement that because risky" |
| 00:03:38 | adam3us: | petertodd: ethereum is several things... a TC script lang, a premine, and an alt |
| 00:04:07 | adam3us: | petertodd: the eth is an alt in the sense of starting its own PoW and scarcity race |
| 00:04:44 | petertodd: | adam3us: point is the fact that it's an alt is a side-effect of trying to raise money, which means the criticism of it re: dilution is misguided |
| 00:04:48 | zooko: | petertodd: I do not see posts about merged mining by you to bitcoin-dev mailing list. |
| 00:05:10 | gmaxwell: | antephialtic: mostly on trustless systems, new cryptographic structures, I think I could actually explain my simple ZK proof for general purpose computation in a presntation, and then tie that into how that technology can let us build more powerful cryptosystems. |
| 00:05:49 | petertodd: | zooko: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03574.html |
| 00:05:55 | antephialtic: | gmaxwell: "Zero Knowledge without moon math" |
| 00:05:57 | adam3us: | petertodd: concept level dilution i think - like litecoin is dilution or primecoin - its the same as that no? |
| 00:05:59 | austinhill: | petertodd: at a meta-communication level (which is all the media & blogosphere know how to report on) it's also don't trust in just bitcoin, because Dogecoin is different, or Litecoin is better, or ZeroCoin is more private and that infects the trust pool that can only carry so many memes before it throws all the cryptocurrencies into the "nice idea but tulip bubble" pile |
| 00:06:20 | gmaxwell: | or another thread is how simple things like hashlocked transactions in bitcoin can be combined with interactive protocols to achieve some very powerful results. |
| 00:06:35 | petertodd: | adam3us: that's the thing, ethereum is fundementally different underlying tech, whether or not that tech works is another question, but it's not concept dilution |
| 00:07:46 | petertodd: | austinhill: yeah well, that's a comms problem - again, ethereum is meant to enable different things that bitcoin can't currently do, not true with dogecoin in a meaningful way |
| 00:08:17 | gmaxwell: | petertodd: eeehh. not clear there, I mean, nothing functionality wise I've seen them propose couldn't be softfork added to bitcoin (if it were clear that it were wise to do so!) |
| 00:08:33 | petertodd: | gmaxwell: sure, but is such a soft-fork going to happen? not likely |
| 00:08:35 | gmaxwell: | certantly it's not as overlapping as dogecoin. :) |
| 00:08:40 | adam3us: | petertodd: yeah so each alt has a hook; some of them are even interesting or plausible. ethereum is still an alt. it didnt have to be an alt, someone chose to make it an alt. |
| 00:09:12 | petertodd: | adam3us: meh, it'd end up being an alt due to the economics of this stuff - you gotta find a way to get money to pay devs |
| 00:09:16 | gmaxwell: | petertodd: if ethereum proved a more powerful script was both viable and useful, perhaps! adding functionality— at least functionality without nasty tradeoffs— is not _that_ controversial. |
| 00:09:31 | sipa: | OP_X86 ftw |
| 00:10:00 | petertodd: | gmaxwell: sure, which is why I'd advise people to remember that bitcoin can do that if you're thinking about long-term ether investments, but bitcoin wouldn't do that without proof that it's a viable and useful thing to do - chicken and egg problem there |
| 00:10:57 | sipa: | at least ethereum is actually building something innovative |
| 00:11:04 | sipa: | whether it's a good idea is a wholly different question |
| 00:11:23 | petertodd: | adam3us: also, another case in point is my tree chains thing, which even though it looks like it can be a merge-mined addon to bitcoin, changes the economics - at the very least it can make pools irrelevant, so good luck getting support there |
| 00:11:58 | adam3us: | sipa: its a high quality hook :) "turing complete script!" the implications are endless. |
| 00:12:07 | petertodd: | sipa: like I said on -dev, it's unclear if this decentralized finance stuff in general has a use-case |
| 00:12:36 | sipa: | didn't see that |
| 00:13:06 | petertodd: | sipa: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03895.html |
| 00:13:33 | sipa: | ah, yes, i read that |
| 00:13:46 | austinhill: | petertodd: re: money to pay dev's - there is a way to do that. It's called VENTURE CAPITAL. They are good at funding risk, experimental technology. I know, I've been a VC and a cypherpunk who raised $200+ million : doing an alt-coin is not a good funding model for innovation |
| 00:14:05 | petertodd: | austinhill: there's no clear way to make a profit from creating these systems you realize... |
| 00:14:19 | petertodd: | austinhill: I was talking to a VC a few weeks ago actually; my advice was that the RedHat model *might* work |
| 00:16:12 | austinhill: | petertodd: I think you are wrong ;) the entire system needs to be distributed, not owned by anyone, trustless, open source and free with permissionless innovation as a core principles without an alt-coin & support bitcoin & blockchain — but there's trillions of dollars available for the person who figures out how to support the investment required to build that kind of ecosystem |
| 00:17:52 | austinhill: | The RedHat model isn't the right model, support doesn't work for this type of world |
| 00:18:07 | adam3us: | petertodd: i think the thing that worries me about alts is its not neutral, bitcoin bootstrapped; with new alts people suspect its a pump & dump; if it succeeds you dont know if you should trust the motives of the people pumping it.. (actually someone i know has the same reservation about bitcoin! that people talking up bitcoin are investors in bitcoin). but at least bitcoin succeeded with a big element of luck. |
| 00:18:34 | petertodd: | austinhill: OK, case in point: So I have this idea called tree-chains. Basically you make blocks into a binary tree, and you get a nice security/scalability trade-off - point is you can make systems with really high numbers of transactins/sec over the whole system. Now I could probably put this into practice if I had a team, especially if I could hire some SCIP experts, but that's expensive. So I get this VC capital, implement it and... um, ... |
| 00:18:40 | petertodd: | ... now what? It's open-source software, the only way I'll make money off of it is by selling support. Hence, the red hat model. |
| 00:19:25 | gmaxwell: | sipa: it's sad that there is not a trendy phrase for what scripts rough computational power is (well ignoring the disabled opcodes kinda breaking it)... ("FSM complete!" (which includes verification of NP witnesses)) |
| 00:19:29 | petertodd: | adam3us: honestly, meh. We can't fight this stuff with ta-taing people making alts; fight it by showing the public that the economics are silly and that the economics of bitcoin or whatever somehow does make sense. So go off an 51% attack some alts today and ruin them. |
| 00:20:22 | tacotime_: | petertodd: about the sharded system, how do you maintain temporal consistency? bitcoin is very easy for this because each block comes in and it's very clear where a tx is located temporally. |
| 00:20:28 | adam3us: | petertodd: i guess if that works, and scip has a few problems as a building block, then it becomes valuable once bitcoin scaling starts to be an issue. |
| 00:20:34 | tacotime_: | petertodd: and are you allowing new roots to be mined from the root of the top node itself? |
| 00:20:47 | petertodd: | tacotime_: ah! I think I have something really clever for that actually, which is a two-phase commit for transactions. |
| 00:21:00 | austinhill: | petertodd: On Jabber I'm mailto:austin@jabber.cc.de we can chat / OTR about this out of channel |
| 00:21:37 | petertodd: | tacotime_: So lets say we have a blockchain, where each block is notated as b^depth_age right? so the top block's genesis is b^0_0, next b^0_1, etc. |
| 00:22:04 | petertodd: | tacotime_: each block b^d has two children, marked b^{d+1} (left and right) |
| 00:22:21 | tacotime_: | okay. |
| 00:22:25 | petertodd: | tacotime_: note how my notation is 2d when the actual structure is 3d... but anyway. |
| 00:24:10 | petertodd: | So if I want to spend an output at b^d_i, I can mark it spent at that subchain, then wait as subsequnt blocks "propagate" that spend information to b^{d-1}, b^{d-2} etc. until I'm at b^0. Now I can prove to a block on another part of the tree that the top-level block in common to both sides depends on that spend, and then record the other half of the transaction in the other block. |
| 00:25:00 | petertodd: | If the rule is that a block is made invalid if a higher block in the tree is also made invalid, I now know that re-orging one side is guaranteed to make the other side go away too, thus we have temporal consistency. |
| 00:25:13 | tacotime_: | So your new roots verify new branching nodes of old blocks. |
| 00:25:16 | Luke-Jr: | petertodd: sell the software at first |
| 00:25:30 | zooko: | petertodd: thanks. |
| 00:25:33 | petertodd: | tacotime_: hang on, I didn't say anything about verification yet :) |
| 00:25:34 | Luke-Jr: | petertodd: start at $10k for getting access on day 1 |
| 00:25:39 | Luke-Jr: | $9k for day 2 |
| 00:25:39 | tacotime_: | Ah, okay, sorry. |
| 00:25:40 | Luke-Jr: | etc |
| 00:25:53 | Luke-Jr: | (or something like that) |
| 00:26:09 | petertodd: | tacotime_: Assume for now that all miners are "honest" and all blocks contain valid transactions - see how I've guaranteed that at least the consensus will be consistent? |
| 00:27:58 | tacotime_: | When you say propagate that spend information, are you saying they explicitly reference a tx in one of the shards of a former block? |
| 00:28:32 | petertodd: | tacotime_: well you can always make a compact proof via a merkle path right |
| 00:28:55 | tacotime_: | Yes. |
| 00:29:07 | Guest53102: | Guest53102 is now known as ageis |
| 00:29:10 | tacotime_: | I see. |
| 00:29:54 | petertodd: | so a miner on one side of the tree can use that proof as proof that the transaction output was legitimately marked as spent on the other side, and that the block they're producing will be invalidated correctly if the top block is reorganized, thus keeping the temporal consistency |
| 00:30:32 | petertodd: | the issue however is ensuring that the miners on the other side are honest - with magical SCIP that'd be dead easy, just have them produce a SCIP proof that the rules were followed. in the non-moon-magic world it'll be harder |
| 00:31:17 | zooko: | tacotime_: "Andrew's draft is rather damning" ← what draft? (I'm trying to catch up on this IRC channel, see.) |
| 00:31:30 | petertodd: | the other issue is the "data loss" one I explained earlier on -wizards, but at least there you can make the procedure for handling data loss economically neutral - ie track how many worth of value "entered" and "exited" that part of the tree and make sure no coins get illegitimately created out of thin air |
| 00:31:41 | tacotime_: | zooko: http://download.wpsoftware.net/bitcoin/alts.pdf |
| 00:32:03 | tacotime_: | * tacotime_ nods. |
| 00:32:13 | tacotime_: | Does the tree have minimum difficulty at some point? |
| 00:32:40 | petertodd: | but... solve those problems and you've got a system with no arbitrary limit on transactions/sec, rather it has a limit based on economics/security where at some point the difficulty of some deep down tree is just so low that your coins may get destroyed by an attacker |
| 00:32:57 | tacotime_: | petertodd, exactly what i was just thinking. |
| 00:33:09 | petertodd: | tacotime_: well, difficulty is an interesting questiion: looks to me that if you simply take the top difficulty, and divide it by two every step down, you actually make 51% attacks harder |
| 00:33:18 | tacotime_: | Not a huge issue though, the system then scales with quantity of PoW being performed I guess. |
| 00:33:28 | tacotime_: | petertodd, yes |
| 00:33:54 | petertodd: | tacotime_: the way that works is you make the rule be that blocks *must* alternate "sides", so left gets mined, then right, and so on. I'm still working through the details, but the way the math works is that applying, say, 10% of the hashing power to some part of the tree to attack that part becomes non-trivial in that case |
| 00:33:56 | tacotime_: | To a point I guess, eventually at some level you can publish whatever |
| 00:34:01 | petertodd: | not impossible, but harder |
| 00:34:07 | tacotime_: | Hmmm. |
| 00:34:30 | tacotime_: | implementing blocks basically as binary search trees? |
| 00:34:33 | petertodd: | tacotime_: exactly! with SCIP moon-magic you wouldn't be able to publish garbage, but you might be the only miner who actually has the data, and thus are one HD failure from losing it and the coins |
| 00:34:41 | petertodd: | tacotime_: yes, hence "tree-chains" |
| 00:34:51 | tacotime_: | that could be efficient. |
| 00:35:02 | tacotime_: | I had proposed a marginally similar method for increasing bandwidth over the past couple of months, though the details I never really made public. |
| 00:35:10 | petertodd: | tacotime_: although remember that it's not like one block is a *whole* tree, rather each block and subblock adds to part of a tree in the shape of a binary search thing |
| 00:35:10 | tacotime_: | I thought it was neat, vitalik didn't. |
| 00:35:20 | tacotime_: | * tacotime_ nods |
| 00:35:32 | gmaxwell: | I found nsh and ens lost in #bitcoin discussing cut and choose protocols. |
| 00:35:36 | petertodd: | yeah, I proposed a ring of blockchains ages ago as a thought experiment |
| 00:35:40 | petertodd: | gmaxwell: lol |
| 00:35:55 | ens: | petertodd: ring of block chains? for local proofs of work? |
| 00:36:03 | nsh: | (i was just pretending to do computer science while i picked people's pockets) |
| 00:36:04 | petertodd: | ens: local proofs of *validity* |
| 00:36:08 | tacotime_: | My idea was to fragment the tx tree and keep it sorted by fees, and to make the verification of levels be responsibilities of subsequent blocks. |
| 00:36:08 | ens: | aha! |
| 00:36:22 | petertodd: | tacotime_: right, that's kinda similar |
| 00:36:26 | ens: | that actually fits into an idea i was coming up with for modelling a proof of work for Co-NP complete problems. |
| 00:36:52 | tacotime_: | petertodd, the only issue is that for verification you need to wait a while, one level would be one block, two levels two blocks, etc |
| 00:36:57 | ens: | i think people actually underestimate how radical the idea of proof of work chains actually are in compsci. |
| 00:36:59 | tacotime_: | Or you could you m-level trees. |
| 00:37:04 | petertodd: | tacotime_: my first ideas along those lines were fee related too, until I realized that the temporal consistency of the scheme made it possible to have coin amounts be arbitrary, no matter where in the tree the txout was |
| 00:37:24 | tacotime_: | How so? |
| 00:38:02 | petertodd: | tacotime_: like I said, if you can get miners to make honest blocks, via SCIP moon-magic or something less strong, then it's ok to record a txout of any value based on a txout of the same value being marked spent in another part of the tree |
| 00:39:07 | petertodd: | tacotime_: fraud-proofing is an obvious way, I also proposed a much weaker "institutionalize fraud" scheme a while back here where you'd just use NI proofs to show the previous history of a coin was valid with some probability - mining to make new coins would be brute forcing those witnesses to make false proofs |
| 00:39:19 | petertodd: | s/proofs/witnesses/ |
| 00:40:01 | tacotime_: | I guess I'd been thinking more simply than even that; I just thought that you could list the tx by number in subsequent blocks and just have each single one validated or invalidated based on the contents of the current or past blocks. |
| 00:40:34 | petertodd: | Right, but... how do you know the contents? |
| 00:40:52 | petertodd: | The trick after all is to *not* have to know the contents! |
| 00:41:17 | tacotime_: | I guess you need to prove having verified or seen all the tx in some way. |
| 00:41:43 | tacotime_: | Is that what you mean by SCIP moon-magic, I guess? |
| 00:41:49 | petertodd: | Now, an interesting thing here is with TXO commitments you can make relatively compact proofs that a given TXO remained unspent for some number of blocks. |
| 00:42:19 | petertodd: | yeah, SCIP basically means "I can prove to you I ran a verification program on the blockchain data proving that the txout was in fact real and unspent, and all prior txouts for it were similarly valid" |
| 00:42:27 | tacotime_: | * tacotime_ nods. |
| 00:42:49 | petertodd: | SCIP proofs for programs that themselves check SCIP proofs are deep moon-magic that may not be actually possible. |
| 00:43:13 | gmaxwell: | SCIP is mostly this groups brand name for their ZK-SNARK stuff: http://www.scipr-lab.org/ |
| 00:43:41 | petertodd: | But, at least if every block is allowed to create some amoutn of inflation, you can prove *economic* honesty by just making a NI proof that would cost more to fake than the gains. |
| 00:43:46 | ens: | SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge << holy crap :D |
| 00:43:53 | petertodd: | ens: magic isn't it |
| 00:44:00 | nsh: | the voodoo variety |
| 00:44:04 | ens: | i must read this right now. |
| 00:44:07 | petertodd: | gmaxwell: yeah, what term would you suggest I use for what I'm talking about? |
| 00:44:08 | adam3us: | petertodd: this sounds like the problem of using sharding. each shard has to be merge mined, and then you end up not improving scaling (MM 10 shards, and you have to see all the traffic) |
| 00:44:09 | jcrubino: | jcrubino has left #bitcoin-wizards |
| 00:44:14 | nsh: | ens, there's a talk too that's worth watching |
| 00:44:28 | gmaxwell: | ens: You might want to go find the GGPR'12 paper which is what that moon math is based on. |
| 00:44:42 | petertodd: | adam3us: yeah, and since this is a tree, the sharding does improve scaling because you only pick some subset of the tree to listen to |
| 00:45:02 | petertodd: | adam3us: e.g. the rules in this system would be a given share can *only* mine some linear path down the tree |
| 00:45:13 | ens: | do you know if it addresses the case where a negative answer was found to the NP complete problem? |
| 00:45:30 | austinhill: | tacotime_: read the whitepaper on Altcoins - is this something that you want shared or feedback on? happy to do both, lots of good ideas in there |
| 00:45:52 | petertodd: | ens: these proofs are probabalistic, so they definitely don't say anything about NP completeness |
| 00:46:23 | tacotime_: | austinhill: it's not my paper, gmaxwell passed it to me. As I'm an alt coin dev I'm obviously a little bit in dissent heh |
| 00:46:27 | petertodd: | ens: and really, if I understand correctly the accepted terminology is to refer to a *witness* instead of a proof - witnesses can lie |
| 00:46:49 | ens: | Given a C program, we produce a circuit whose satisfiability encodes the correctness of execution of the program. << this is exactly what i was researching before i came in here. |
| 00:46:55 | gmaxwell: | ens: what it does is proves the checking of a witness of NP execution, the scheme there has cryptographic soundness (any succinct system has at best cryptographic soundness) and perfect zero knoweldge. |
| 00:47:28 | ens: | petertodd: in this case where distributed computation is involved where nodes are not trusted that makes better sense. |
| 00:47:50 | gmaxwell: | petertodd: well it encods the proof for verifing that the witness does not lie. Though the scheme has only cryptographic soundness. meaning that by breaking the crypto you can make a false witness pass. |
| 00:48:19 | petertodd: | ens: no, there's a deep crypto reason for this: a ZK-SNARK witness always has some probability that an attacker could create a false witness, it's just stupidly unlikely |
| 00:48:54 | gmaxwell: | ens: when you burn out on the moon math you may like my (? it's not very original) moon-math free not at all succinct verifyable execution http://people.xiph.org/~greg/simple_verifyable_execution.txt |
| 00:49:03 | nsh: | +1 |
| 00:49:21 | gmaxwell: | No succinct scheme can have perfect soundness. There is a kind of wanky proof of this. |
| 00:49:25 | petertodd: | gmaxwell: right, I'm talking about how all this stuff is probabalistic, so it's not a proof in the traditional math sense directly |
| 00:50:10 | gmaxwell: | petertodd: some of the stuff in this space does have perfect soundness but it cannot have proofs which are sublinear in the transcript length. |
| 00:50:39 | petertodd: | gmaxwell: ah, good point |
| 00:50:53 | petertodd: | gmaxwell: not that linear would be terribly useful for tree-chains :) |
| 00:56:26 | poggy: | gmaxwell is that yours ? |
| 00:56:40 | gmaxwell: | poggy: is what mine? |
| 00:57:04 | poggy: | http://people.xiph.org/~greg/simple_verifyable_execution.txt |
| 00:57:18 | ens: | gmaxwell: i'm actually fairly shocked by that paper. |
| 00:58:07 | ens: | i thought doing something like this would be the keystone to creating something like a 3SAT coin. |
| 00:58:39 | gmaxwell: | Yes, I wrote that. The scheme is heavily inspired by the linked low-moon-math scheme for multiparty computation, but I'm not sure if what I'm describing there has been described by anyone else before (perhaps it has some weakness I haven't found yet; ... its a useful teaching tool regardless) |
| 00:59:47 | gmaxwell: | ens: 3sat coin is not so interesting, for one random 3sat problems are very easily solved by a hurestic solver, so you can just grind out problem examples until you get an easy one. ... but generally POW twiddling seems boring, it mostly seems to shift around constant factors in the incentives. |
| 01:00:01 | gmaxwell: | If you want to pow twiddle I have some sexier ideas. |
| 01:00:23 | gmaxwell: | but in general, I think pow is like debating bicycle color. :P |
| 01:00:25 | ens: | i just want to use it to make a distributed security checking device. |
| 01:00:33 | ens: | for formal verification of software |
| 01:00:47 | ens: | but takes on a form similiar to BTC. |
| 01:01:09 | ens: | but yeah, generation of random instances is another major hurdle |
| 01:01:22 | ens: | but it seems you've actually discussed the harder issues in that paper... |
| 01:01:32 | ens: | nice work man! |
| 01:02:42 | ens: | but you think the difficulty of the problems would flucuate too much for it to be stable as a digital currency? |
| 01:03:29 | gmaxwell: | well I think it enables an easy cheat. You grind your problem generator until you get an easy problem, and you're not even able to solve hard problems. |
| 01:05:17 | ens: | yeah i thought those kind of things would have been an issue aswell, however i did think the problem that you've described in that paper would have been by a huge magnitude harder to solve. |
| 01:09:18 | ens: | i mean your solution to that problem seems like it represents a complexity class with NP and Co-NP as subsets linked by a common concept for probabilistic proof of work. I think you should consider editing the complexity zoo wiki :) |
| 01:52:43 | tacotime_: | tacotime_ is now known as tt_away |
| 03:00:00 | austinhill: | A programmer & cryptocurrency aspiring wizard recently asked me if his alt-coin was worth pursuing, I responded with this. I'd like the communities feedback if I'm directing him wrong : "GIVE UP ON THE ALT COIN DREAM. It's a scam and you should abandon it immediately. Whatever good ideas you have, or skills you develop in programming should be applied into a few areas of the startup ecosystem 1) Blockchain technolog |
| 03:01:48 | jrmithdobbs: | DON'T BOTHER TRYING is not exactly inspiring you know |
| 03:04:41 | jrmithdobbs: | and irc doesn't work like that, that cut off after "1) Blockchain technolog" |
| 03:04:42 | austinhill: | sorry, don't want to repost and pollute others feeds….. |
| 03:04:43 | jrmithdobbs: | pastebin.com is the goto place for random long irc rants |
| 03:07:38 | zooko: | I'd like to see the rest of that rant. |
| 03:08:00 | jgarzik: | +1 |
| 03:08:01 | austinhill: | :jrmithdobbs Thanks for the refer: - for those interested here is what I think is a good link |
| 03:08:03 | austinhill: | http://pastebin.com/2kcsZ3uQ |
| 03:08:40 | jgarzik: | austinhill, or http://0bin.net/ if you want to be all crypto-hip |
| 03:09:23 | zooko: | Well, that makes your position clear! |
| 03:09:28 | zooko: | ^-- austinhill |
| 03:09:35 | zooko: | Hiya jgarzik. |
| 03:09:49 | austinhill: | jgarzik: omfg - so cool http://goo.gl/BHo8tB |
| 03:12:10 | zooko: | Heh heh heh. |
| 03:12:43 | austinhill: | was I too harsch? or not opinionated enough? |
| 03:13:25 | zooko: | * zooko laughs. |
| 03:13:37 | zooko: | Tell us how you really feel! |
| 03:13:49 | zooko: | So, I'm still reading this IRC log. |
| 03:14:00 | jgarzik: | Coming from the Linus Torvalds school of engineering, you can rarely go wrong by roasting someone with a good, fact-backed flame. |
| 03:14:03 | zooko: | I asked a few questions, made a few comments, and then my three children attracted my attention for pretty much the rest of the day. |
| 03:14:05 | petertodd: | austinhill: probably worth pointing out that if you have an idea that absolutely needs to be implemented by changing the way bitcoin works, you can always write it up for litecoin (or even dogecoin!) and get it implemented in a soft-fork |
| 03:14:09 | zooko: | And they are now all asleep... |
| 03:14:18 | zooko: | Oh wait, no they aren't. Their lights are still on. bbiab ☺ |
| 03:14:27 | jgarzik: | hah |
| 03:14:37 | petertodd: | austinhill: also worth mentioning that with just a bit more cleverness, most ideas can be done without forking anything at all |
| 03:15:41 | austinhill: | but I'm sorry petertodd correct me if I'm wrong, but you subscribed with the Mastercoin school of though that has it's own on-blockchain/off-blockchain innovation theories |
| 03:16:22 | austinhill: | (ps - everyone tells me your very clever petertodd) |
| 03:16:34 | petertodd: | austinhill: just because I'm their chief scientist doesn't mean I think they're way is the right way to do things! |
| 03:16:56 | petertodd: | austinhill: there's lots of options - the important thing is starting a brand new coin is very, very rarely the right way to go |
| 03:17:10 | austinhill: | :petertodd +1 |
| 03:18:09 | austinhill: | well like Luke told Vader on Endor - "I see the good in you father, give in to the good side of the force"….. |
| 03:18:27 | petertodd: | fwiw I'd be inclined to point aspiring wizards to colored coins actually - it's a technology just simple enough to be accessible, yet doing it right isn't as easy as it looks |
| 03:19:57 | Luke-Jr: | (it's also useless) |
| 03:20:08 | petertodd: | Luke-Jr: why? |
| 03:20:26 | austinhill: | Let's be honest, colored coins was promoted in mid 90's by Adam Back & Steve Schear. Great idea, but impractical with todays' world. How can you do SPV verification or wallet recognition of colouring in today's blockchain world …. waste of time |
| 03:20:26 | Luke-Jr: | petertodd: lack of a use case |
| 03:20:48 | petertodd: | Luke-Jr: that's debatable (seriously, I mean exactly that) |
| 03:21:04 | Luke-Jr: | petertodd: it's only debatable if you can give an example |
| 03:21:09 | petertodd: | austinhill: the wise wizard will think of ways to solve those problems :) |
| 03:21:28 | Luke-Jr: | until someone comes up with a use case, debating whether it's useful is silly |
| 03:22:19 | Luke-Jr: | anything other than pure blockchain assets (ie, bitcoins) is inherently centralised and therefore can benefit from the higher efficiency of centralisation |
| 03:22:29 | petertodd: | Luke-Jr: it's a peice of accounting software - if someone manages to solve the social problem of making "shared issued by whatever" a useful thing, then colored coins can act as a convenient, low-overhead, way to make sure that digital asset is being moved around honestly |
| 03:22:45 | Luke-Jr: | high-overhead* |
| 03:22:51 | petertodd: | essentially the big use-case of colored coins is in fault-tolerence |
| 03:22:56 | austinhill: | luke-jr: we dont' need a use care actually, just a practical discussion of throwing technology over the wall. Can you colour coins with a history & marker for other asset allocation / issuance : = YES |
| 03:23:08 | petertodd: | Luke-Jr: for the *users* of colored coins it's low-overhead, not high, the alternatives are high-overhead |
| 03:23:13 | Luke-Jr: | austinhill: sure, you can. but there's no value to it. |
| 03:23:31 | Luke-Jr: | petertodd: nonsense, a simple trading webapp is much lower overhead. |
| 03:23:52 | petertodd: | Also, colored coins (and similar things) give you the building block to take it to the next step and make genuine decentralized marketplaces, something only possible with digital assets. |
| 03:23:52 | austinhill: | Is this practical or implementable in todays world where there is no wallet recognition of colouring or registry of semantic colouring that is trust : NO |
| 03:24:37 | Luke-Jr: | austinhill: does such a world exist where it makes sense? NO |
| 03:24:40 | petertodd: | austinhill: killerstorm is doing good work with ChromaWallet - it's close to a pure programming problem at this point |
| 03:24:58 | petertodd: | Luke-Jr: don't let you distaste of data in the blockchain cloud your judgement |
| 03:25:06 | Luke-Jr: | tangible property inherently requires someone to defend it. ie, the State. therefore, it will always be centralised. |
| 03:25:21 | austinhill: | Luke-Jr: Adam3us and I believe there is way - but it's not alt coins and it's not attacking the blockchain |
| 03:25:29 | Luke-Jr: | austinhill: how? |
| 03:25:48 | Luke-Jr: | what good will a blockchain do, if you don't have someone to defend your right to possession? |
| 03:26:22 | petertodd: | austinhill: my tree-chains stuff above I'm working on specifically to make scalability less of a concern for things like colored coins and mastercoin |
| 03:27:06 | petertodd: | Luke-Jr: in the case of stocks the most likely social construct that would defend your right is consensus in some community |
| 03:27:14 | zooko: | petertodd: do you have a write-up of tree-chains stuff? |
| 03:27:30 | austinhill: | Luke-jr: my jabber address is available & we are hosting a gathering of a large number of bitcoin core dev's in Silicon Valley for the next month. You are on our list, please reach out to Adam Back or I to come join us. We have VC funding and can compensate your travel budget |
| 03:27:57 | petertodd: | zooko: working on one: https://github.com/petertodd/tree-chains-paper <- not too much in digital form, but I want to get it presentable prior to the financial crypto conf |
| 03:28:06 | petertodd: | zooko: mostly see -wizards archives |
| 03:28:18 | petertodd: | austinhill: what time next month? |
| 03:28:28 | zooko: | petertodd: thanks. |
| 03:28:31 | Luke-Jr: | petertodd: in the case of stocks, your only recourse is a lawsuit; ie, State enforcement |
| 03:28:54 | zooko: | I don't think I have time/attention-management to read the -wizards archives though! |
| 03:28:59 | petertodd: | Luke-Jr: no, publication of fraud can be a recourse as well in a world where reputations are valuable |
| 03:29:08 | petertodd: | zooko: grep -i tree-chains :P |
| 03:29:24 | Luke-Jr: | petertodd: that only requires transparency, not decentralisation |
| 03:30:05 | petertodd: | Luke-Jr: strong transparency appears to work best with proof-of-publication, which requires decentralization |
| 03:32:27 | petertodd: | it's notable how I ran into the same problem with fidelity-bonded banking, where you need a proof-of-publication scheme for fraud-proofs if you want the whole thing to work |
| 03:57:11 | zooko: | Well, you wizards, plus my children, are too much for me. I still haven't caught up on the IRC log from today, and now it is the time when I sleep! Fare well, wizards. |
| 03:57:29 | petertodd: | zooko: ha, later, say hi to the kids for me :) |
| 03:57:34 | zooko: | ☺ |
| 03:57:43 | petertodd: | zooko: tell them a wizard said it :P |
| 03:57:54 | zooko: | Heh heh heh. Definitely will. |
| 04:24:27 | justanotheruser: | justanotheruser is now known as just[dead] |
| 04:31:52 | tacotime: | tacotime is now known as tacotime_ |
| 04:45:18 | tacotime_: | tacotime_ has left #bitcoin-wizards |
| 05:40:01 | tacotime_: | tacotime_ is now known as tt_away |
| 05:47:48 | Fistful_of_Coins: | Fistful_of_Coins is now known as Fistful_of_Cigar |
| 06:27:20 | wangbus_: | wangbus_ is now known as wangbus |
| 07:03:30 | petertodd: | jgarzik: got SignatureHash() working as well as all the tx_(in)valid unittests in python-bitcoinlib pythonize branch |
| 07:05:07 | petertodd: | Also found another screwy edge case: FindAndDelete() can return an invalid CScript instance if you arrange for the signature being found - possible with the SIGHASH_SINGLE bug - to match part of a different PUSHDATA encoding. |
| 07:05:41 | petertodd: | Gotta get around to making up a test-case for that monster... |
| 07:31:25 | qwertyoruiop_: | qwertyoruiop_ is now known as qwertyoruiop |
| 10:09:07 | Sarchar_: | Sarchar_ has left #bitcoin-wizards |
| 13:49:43 | jgarzik: | petertodd, cool |
| 14:20:16 | HobGoblin: | HobGoblin is now known as Guest73215 |
| 14:38:08 | kaptah: | kaptah is now known as Guest27907 |
| 14:41:09 | kinlo_: | kinlo_ is now known as kinlo |
| 15:31:39 | holmes.freenode.net: | topic is: "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 15:31:39 | holmes.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot petertodd wumpus heakins a5m0 @ChanServ michagogo|cloud keus jrmithdobbs pajarillo Taek42 epscy c--O-O Alanius optimator ryan-c Manfred__ wangbus aksyn Luke-Jr Muis ageis coryfields pigeons Sorcier_FXK sipa jarpiain Krellan CodeShark grzs realazthat sha256 rdymac ens Ursium MoALTz_ c0rw1n qwertyoruiop Guest73215 bobke BitCoroner austinhill kinlo jtimon_ andytoshi Hunger- nsh_ iddo helo forrestv EasyAt_ Sangheil- tacotime_ |
| 15:31:39 | holmes.freenode.net: | Users on #bitcoin-wizards: hno midnightmagic jron samson_ comboy_ Guest77513 area poggy gmaxwell perrier_ Mikalv amiller typex harrow andytosh1 Ryan52 Fistful_of_Coins roconnor__ |
| 15:31:54 | otoburb_: | otoburb_ is now known as Guest29613 |
| 15:43:03 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 260 seconds)) |
| 16:00:48 | irc.freenode.net: | Disconnected from irc.freenode.net (Connection reset by peer) |
| 16:11:28 | adams.freenode.net: | topic is: "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 16:11:28 | adams.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot Hunger- area nOgAnOo orperelman poggy _ingsoc K1773R iddo harrow kaptah HM typex amiller Mikalv perrier_ gmaxwell samson_ petertodd wumpus heakins a5m0 @ChanServ michagogo|cloud keus jrmithdobbs pajarillo Taek42 epscy c--O-O Alanius optimator ryan-c Manfred__ wangbus aksyn Luke-Jr Muis ageis coryfields pigeons Sorcier_FXK sipa jarpiain Krellan CodeShark grzs realazthat sha256 rdymac ens Ursium MoALTz_ c0rw1n qwertyoruiop |
| 16:11:28 | adams.freenode.net: | Users on #bitcoin-wizards: Guest73215 bobke BitCoroner austinhill kinlo jtimon_ nsh forrestv EasyAt_ Sangheil- tacotime_ hno midnightmagic |
| 16:13:14 | helo: | helo is now known as Guest41573 |
| 16:17:44 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 246 seconds)) |
| 16:19:41 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Connection timed out)) |
| 16:21:35 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Connection timed out)) |
| 16:23:29 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Connection timed out)) |
| 16:32:02 | irc.freenode.net: | Disconnected from irc.freenode.net (Connection reset by peer) |
| 16:46:17 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: 70.70.46.218 (Connection timed out)) |
| 17:07:20 | irc.freenode.net: | Disconnected from irc.freenode.net (Connection reset by peer) |
| 17:27:39 | dickson.freenode.net: | topic is: "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 17:27:39 | dickson.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot zzyzx poggy _ingsoc K1773R rs0 Guest58635 nanotube roidster BlueMatt |
| 17:35:03 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: 70.70.46.218 (Ping timeout: 272 seconds)) |
| 17:39:35 | sendak.freenode.net: | topic is: "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 17:39:35 | sendak.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot nomailing petertodd wumpus heakins a5m0 @ChanServ michagogo|cloud keus jrmithdobbs pajarillo Taek42 epscy c--O-O Alanius optimator ryan-c Manfred__ wangbus aksyn Luke-Jr Muis ageis coryfields pigeons Sorcier_FXK sipa jarpiain Krellan CodeShark grzs realazthat sha256 rdymac ens Ursium MoALTz_ c0rw1n qwertyoruiop Guest73215 bobke BitCoroner austinhill kinlo jtimon_ nsh samson_ crucif0rm Mikalv_ Guest68182 espes__ harrow iddo |
| 17:43:51 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 252 seconds)) |
| 17:54:23 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Sorry, server is full - try later)) |
| 17:56:09 | dickson.freenode.net: | topic is: "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 17:56:09 | dickson.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot maaku_ zzyzx phantomcircuit_ nomailing antephialtic Ryan52 _ingsoc rs0 matrixfox roconnor |
| 18:07:11 | jtimon_: | if accountant A blocks mike, mike goes to accountant B |
| 18:07:11 | tacotime_: | Yes |
| 18:07:11 | tacotime_: | But you still end up with two viable forks. |
| 18:07:11 | jtimon_: | no, no fork |
| 18:07:11 | tacotime_: | And a massive currency duplication event |
| 18:07:11 | jtimon_: | accountant B can be inter-operable with A, but they're two independent chains |
| 18:07:11 | jtimon_: | no, issuers don't issue the same coin in two networks |
| 18:07:11 | jtimon_: | legitimate issuers at least, at BlueMatt says, if you don't trust the issuer you're screwed |
| 18:07:11 | tacotime_: | Well, yes, but then every consumer has to choose which network they will operate on. |
| 18:07:11 | jtimon_: | no, you can have a client that operates with all of them |
| 18:07:11 | tacotime_: | Yes, but the forks are administered by different authorities. |
| 18:07:11 | jtimon_: | there's no forks in private chains!! |
| 18:07:11 | jtimon_: | there's no pow |
| 18:07:11 | tacotime_: | Are there transactions? |
| 18:07:11 | jtimon_: | yes |
| 18:07:12 | tacotime_: | They're public? |
| 18:07:12 | tacotime_: | Because there's nothing to stop someone from just changing the signing rules if some of the network decides that they don't stand for it, and preserving all blocks mined and verified by the other issuer. |
| 18:07:12 | jtimon_: | https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers |
| 18:07:12 | jtimon_: | no one can change the rules |
| 18:07:12 | jtimon_: | the accountant only accepts valid txs until he decides to go out of business for some reason |
| 18:07:15 | tacotime_: | This sounds a lot like traditional banking constructed on top of top of Bitcoin's protocol. |
| 18:07:29 | tacotime_: | * -duplicate "top of" |
| 18:07:43 | jtimon_: | there can be multiple issuers per accountant just like there can be multiple issuers per OT server |
| 18:08:39 | tacotime_: | * tacotime_ nods. |
| 18:08:39 | tacotime_: | Is there an advantage over OT? |
| 18:08:39 | jtimon_: | I think it is really different |
| 18:09:12 | jtimon_: | you can trade assets in different N accountant chains atomically |
| 18:09:20 | jtimon_: | also trade atomically for public assets |
| 18:09:35 | jtimon_: | you cannot trade 2 assets in 2 different OT servers |
| 18:09:59 | tacotime_: | Well, you can't program OT servers to talk to each other? |
| 18:10:18 | jtimon_: | apart from more compatibility with the existing crypto infrastructure |
| 18:10:50 | jtimon_: | you can move 1 of the assets to the other server and trade them there, but atomic trades only occur in 1 server |
| 18:11:54 | tacotime_: | Forgive my ignorance; can you define atomicity in trading? Is it the same as for database systems? |
| 18:12:56 | tacotime_: | I'm confused how you could achieve atomicity b/t two private chains; isn't it just based on the central block producing authority confirming that it has occurred between both of them? |
| 18:12:59 | jtimon_: | Alice offers 10 aaa for 10 bbb, Bob offers 10 bbb for 10 ccc, Carol wants to execute both orders providing the 10 ccc Bob wants and getting Alice's 10 aaa |
| 18:13:14 | jtimon_: | either all transfers happen or none of them |
| 18:13:19 | tacotime_: | Right |
| 18:14:02 | jtimon_: | two phase commit, similar to ripple distributed protocol v0.6 (pre-ripple labs) |
| 18:14:30 | jtimon_: | http://archive.ripple-project.org/Protocol/Protocol |
| 18:15:28 | jtimon_: | here's an example for freimarkets https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#hybrid-transitive-transaction |
| 18:15:37 | imsaguy: | imsaguy is now known as Guest17723 |
| 19:05:00 | andy__: | andy__ is now known as apoelstra |
| 19:54:59 | amiller: | amiller is now known as Guest27600 |
| 20:01:53 | tacotime_: | tacotime_ is now known as tt_away |
| 20:59:38 | area: | area is now known as Guest57710 |
| 21:33:59 | jtimon: | catching up the malleability thread, I always have trouble to see the practical difference between oracles and simple escrows |
| 21:38:07 | sipa: | i guess the main difference is that an oracle does not know whose transactions it signs |
| 21:38:45 | jtimon: | doesn't have to know, but is there anything preventing him from knowing it? |
| 21:39:55 | jtimon: | my question is, why would you trust an oracle not to collude with your counterparty more than an escrow? |
| 21:42:25 | jtimon: | I'm probably missing something fundamental to oracles |
| 21:42:40 | jtimon: | s/to/about |
| 21:43:34 | sipa: | well oracles need to be anonymously testable |
| 21:45:25 | jtimon: | yeah, I guess that's it, I guess I just need to think deeper about the consequences of that, thank you |
| 21:59:19 | petertodd: | sipa: keep in mind an oracle with the seckey revealing technique doesn't need to be signing transactions at all |
| 22:00:13 | petertodd: | sipa: which is interesting, because you can convert any 2-of-3 escrow CHECKMULTISIG into A 2-of-4 CHECKMULTISIG oracle, with the advantage being the oracle need not know anything about the funds being moved |
| 22:03:25 | petertodd: | makes sense to me too: why should your escrow agent know details about the transaction? if both parties are happy, then they don't need to know what funds were actually moved. if there is a dispute, then again the escrow doesn't need to know about the actual transactions |
| 23:08:45 | jgarzik: | jgarzik is now known as Guest29624 |
| 23:21:49 | jtimon: | ok, then oracles sound a lot like 2PC's registries/timestampers, but with more data than just a timestamp |
| 23:40:06 | gmaxwell: | gmaxwell is now known as Guest26438 |
| 23:46:10 | Guest26438: | Guest26438 is now known as gmaxwell |