| 00:01:15 | adam3us: | seems likely to me the coincidence that hal lived in the same city for some time as dorian precipitated the article, at least he got his denial in so hopefully they leave him alone |
| 00:02:08 | sipa: | oh god, are they going after hal now too? |
| 00:03:14 | warren: | the article has a screenshot of his personal wallet |
| 00:04:07 | BlueMatt: | adam3us: yea, the article spent half its time commenting about why hal could be satoshi, and then repeatedly said "but I'm convinced its not him" |
| 00:04:20 | BlueMatt: | all of the non-satoshi stuff was nice, but the satoshi crap was annoying |
| 00:04:47 | adam3us: | i'm not sure what the forrest gump ref was about. followed by hal is really smart. |
| 00:04:51 | tacotime: | There already was a formal denial on bitcointalk. https://bitcointalk.org/index.php?topic=155054.0 |
| 00:07:26 | sipa: | if hal is satoshi, he's very good at pretending to not know crypto when coding :) |
| 00:18:42 | adam3us: | btw the hal bitcoin extortion attempt in the article, apparently according to the nyt journalist nathaniel popper at coinsumm.it was relating to hal's admitting he had mined really early, and not satoshi suspect status |
| 00:21:05 | BlueMatt: | sounds right |
| 00:24:59 | Luke-Jr: | sipa: heh |
| 00:27:50 | midnightmagic: | adam3us: It's ablist nonsense-talk. |
| 01:01:16 | Sangheili: | Sangheili is now known as Fistful_of_FiatB |
| 01:01:37 | Fistful_of_FiatB: | Fistful_of_FiatB is now known as Sangheili |
| 01:07:31 | justanotheruser: | maaku: my question is how we manage these 10000s of altchains. How do SPV clients find the full nodes on these networks? Will there just be really high bandwidth seed nodes for every network? |
| 01:07:56 | justanotheruser: | Also, will coinswaps ever be safe with malleability? |
| 01:11:57 | koval: | koval is now known as Fistful_of_Loins |
| 01:12:47 | maaku: | justanotheruser: I don't expect there be 10000s of altchains in the style of the bitcoin p2p network |
| 01:13:05 | maaku: | there will probably only be a small handful of active decentralized p2p side chains |
| 01:13:08 | Sangheili: | Sangheili is now known as Fistful_of_Taxes |
| 01:13:10 | maaku: | and a large number of private chains |
| 01:13:22 | maaku: | the private case is easy: you connect directly to the accountant |
| 01:13:37 | justanotheruser: | maaku: That actually makes sense, there could be chains that only last a month long and can take 1000's of tx per minute |
| 01:14:26 | justanotheruser: | Well I'm talking about the public chains |
| 01:14:45 | justanotheruser: | Hmm, what advantage does a private chain give? Aren't most tx involving people you don't know? |
| 01:17:46 | maaku: | well there are multiple use cases - you can use it for peer-to-peer accounting a la the original ripple design |
| 01:18:04 | maaku: | or you can talk about datacenter-sized validators that process >1 million transactions per second |
| 01:18:11 | Fistful_of_Taxes: | Fistful_of_Taxes is now known as Sangheili |
| 01:18:21 | justanotheruser: | So like a Visa altchain? |
| 01:18:25 | maaku: | surprisingly, the private accounting server is actually *more* secure than a merged mined side chain |
| 01:18:45 | maaku: | yeah, or NASDAQ altchain if you have the freimarkets extensions |
| 01:19:22 | justanotheruser: | maaku: is freimarkets in the freicoin paper? |
| 01:19:50 | justanotheruser: | I need to get around to reading that, the first page was interesting :p |
| 01:20:18 | maaku: | http://freico.in/docs/freimarkets.pdf |
| 01:20:26 | justanotheruser: | Ya, it's in a tab :p |
| 01:20:27 | maaku: | we have a lot of updates we need to make to it however |
| 01:21:00 | maaku: | it's sortof a frozen snapshot of our thinking around 9 months ago, and a lot has happened since |
| 01:21:24 | Fistful_of_Loins: | Fistful_of_Loins is now known as dima1236 |
| 01:21:28 | maaku: | still valid, just simpler and more powerful constructions have been found in the mean time |
| 01:21:30 | justanotheruser: | maaku: when do you think it will be "finished" |
| 01:21:39 | maaku: | "soon-ish" |
| 01:21:39 | justanotheruser: | or good enough, like all the features you have done now |
| 01:21:52 | justanotheruser: | I'm going to quote you on that |
| 01:21:54 | dima1236: | dima1236 is now known as koval |
| 01:22:03 | justanotheruser: | Makku Karples |
| 01:22:13 | maaku: | justanotheruser: it's mostly a matter of finding the time/funding to work on it |
| 01:25:00 | LarsLarsen: | If you have bearer bonds and backing brokerages, you can transact in those without confirmations, the broker themselves becomes the oracle that prevents a double spend. |
| 01:29:03 | maaku: | LarsLarsen: but you need double-spend protection for the medium in which you are transaction, no? |
| 01:31:51 | LarsLarsen: | The bonds are issued by a broker, he's not going to pay you twice for the same IOU |
| 01:32:38 | LarsLarsen: | the problem comes in automatically taking his reserve funds if he doesn't buy it back as he promised. |
| 01:36:00 | LarsLarsen: | "Hey broker, did this guy sell this to anyone else yet? No? Ok" |
| 01:37:24 | LarsLarsen: | If the broker lies and says "no double spends here, trust me!" and in fact he does not buy back the bonds, you need to forfeit his reserves. |
| 01:38:19 | LarsLarsen: | These are high level concepts that require things we dont have today, future money |
| 01:47:09 | LarsLarsen: | "If you have bearer bonds and backing brokerages" is a big assumption to start from :) |
| 01:47:19 | maaku: | LarsLarsen: I'm not sure that answers my question. I have a bearer bond. I give it to someone else. I then try to give it to you. What stops me? |
| 01:47:43 | maaku: | obviously we're talking digital bearer bonds |
| 01:48:09 | LarsLarsen: | maaku: well yes nothing.... but this is a seinorage bond, a loan issued by a broker who's backing it with held reserves |
| 01:48:41 | LarsLarsen: | maaku: if you have that mechanism, you the default of the reserves upon failure to buy back the bond as promised would prevent double spends |
| 01:49:12 | LarsLarsen: | maaku: I never said I had a system to do that yet. |
| 01:49:19 | maaku: | LarsLarsen: yes i understand that, but it seems orthogonal. you still need some ledger system for tracking who owns what |
| 01:50:02 | LarsLarsen: | The broker keeps a ledger, he has to. |
| 01:50:54 | LarsLarsen: | Gox issued gox USD and gox BTC this way. They just weren't held to any system that would forfeit their real actual not-double-spendable currency backing it all. |
| 02:04:24 | LarsLarsen: | You can trade on gox instantly because gox has a ledger. You can trade in bonds instantly because the person issuing them has a ledger. |
| 02:05:01 | topynate: | LarsLarsen: so you mean an on-line protocol where to transfer bonds you have to instruct the issuer to record the transfer. you just want a system that liquidates their reserve if you can prove that you made a valid request and they didn't satisfy it |
| 02:10:17 | LarsLarsen: | yes, that is the key part, everything else hinges upon the mechanisms available to trustlessly enforce a contract like that |
| 02:10:51 | LarsLarsen: | I'm not claiming such a system is possible, just that if such a system existed you could trade those bonds instantly (or as fast as you could check with their issuer that they have not seen them sold to anyone else already) |
| 02:11:28 | LarsLarsen: | If I had devised such a system I'd be telling you all, trust me... lol |
| 02:13:02 | LarsLarsen: | There is so much utility to the bonds that people will pay a seigniorage fee to keep floating it. So they'd have to contact the broker when they buy it anyway, to pay for it. |
| 02:14:05 | LarsLarsen: | IT may be impossible, but if it is possible, it will most likely be useful, Thats all I'm saying. |
| 02:15:39 | maaku: | LarsLarsen: you know that bitcoin *is* the solution, right? |
| 02:15:59 | LarsLarsen: | maaku: I know, but a bond is useful in that you can transact at sub-confirmation-paranoia timescales |
| 02:16:43 | LarsLarsen: | the bond would be redeemed for BTC |
| 02:16:53 | maaku: | read about two-way pegs and (federated) private accounting servers |
| 02:17:03 | maaku: | this provides a centralized solution |
| 02:17:20 | LarsLarsen: | "I will sell you this bond for 1 BTC. I promise to buy it back from you at this date for 0.98 BTC" |
| 02:18:20 | maaku: | yes |
| 02:18:20 | maaku: | that falls under scripting language extensions |
| 02:18:25 | LarsLarsen: | the utility of transacting fast is so great, people will trust millions of dollars to strangers in another country |
| 02:22:15 | LarsLarsen: | The price of bitcoin can jump up and then back down again between block generations. Thats insane. But true. |
| 02:22:19 | maaku: | they shouldn't have to - you can make this 100% trustless |
| 02:23:05 | gmaxwell: | BlueMatt: I am reasonably confident that hal doesn't want attention; or at least before he went super low bandwidth that was strongly my impression. |
| 02:23:35 | LarsLarsen: | I agree with you, I have thought from the bottom up and the top down, but I have not gotten to the middle yet, I think it can be done though. |
| 02:24:51 | maaku: | LarsLarsen: I'm already there. Hopefully soon you'll join us :) Really I wish I had more time/money to sit down and write these concepts and constructions down |
| 02:25:35 | shesek: | hey maaku |
| 02:25:51 | shesek: | nice seeing you again :) |
| 02:26:04 | LarsLarsen: | maaku: yeah, the more I learn the more I realize how much I dont know. I've got several years of stuff to catch up on. |
| 02:26:07 | maaku: | hey shesek - you still in town? |
| 02:26:14 | shesek: | yeah, I'm here for another week or so |
| 02:26:32 | shesek: | I'm actually looking for some interesting ways to spend my time here |
| 02:26:46 | maaku: | LarsLarsen: well to be fair I wasn't convinced it could be done 100% trustless until about 3 weeks ago. this tech moves fast |
| 02:26:47 | shesek: | are you from here? any suggestions? |
| 02:26:56 | LarsLarsen: | maaku: it appears to be in the air |
| 02:27:11 | LarsLarsen: | maaku: I'd doubt myself if I thought I Was the first to crack it |
| 02:29:10 | LarsLarsen: | Ok I'm going to get back to trying to catch up to a moving target again, thanks maaku |
| 02:36:51 | fagmuffinz: | fagmuffinz is now known as toddwildey |
| 06:44:02 | blumenkraft: | blumenkraft is now known as eristisk |
| 06:54:02 | adam3us: | maaku gives question from audience to the alt-coiners skip to 43:25 in http://new.livestream.com/coinsummit/events/2832000 something like whats the place for param-tweak coins in a world with side-chains that can add features - they did not know how to answer that (the 1st 43 mins were not worth listening to :) |
| 06:58:13 | maaku: | heh yeah i kinda predicted that response |
| 07:08:01 | adam3us: | maaku: was that you also at 52:00 ? man these alt-coiners barely understand coin tech |
| 07:08:25 | adam3us: | maaku: they had trouble understanding your question even |
| 07:11:46 | Luke-Jr: | adam3us: which video? there are many on the page |
| 07:12:22 | adam3us: | Luke-Jr: yeah sorry the one that has day2-part2 written under the video |
| 07:14:51 | Luke-Jr: | lol |
| 07:16:21 | Luke-Jr: | coblee thinks people still do developmetn on the forums? XD |
| 07:24:36 | phantomcircuit: | anybody know what 1HC3dc4DubRat1P39YBBkwVRbph3ijbtPQ is |
| 07:25:27 | Luke-Jr: | phantomcircuit: a bitcoin address |
| 07:25:30 | Luke-Jr: | <.< |
| 07:26:12 | phantomcircuit: | Luke-Jr, helpful |
| 07:26:31 | phantomcircuit: | it has a really bizarre use pattern |
| 07:26:46 | phantomcircuit: | exactly even numbers of btc go in |
| 07:26:52 | phantomcircuit: | exactly even numbers go out |
| 07:28:37 | topynate: | https://blockchain.info/address/1HC3dc4DubRat1P39YBBkwVRbph3ijbtPQ shows a negative final balance. is that unusual for blockchain.info? |
| 07:29:17 | Luke-Jr: | unusual that they screw up? not really |
| 07:29:55 | Emcy_: | i think they are pretty prone to chain pasring errors |
| 07:30:58 | topynate: | well, it's a good job no-one is relying on them for business-critical functions |
| 07:31:16 | Luke-Jr: | yeah |
| 07:32:20 | Emcy_: | lol |
| 07:32:54 | topynate: | for example, if a company monitored its balances on blockchain.info but stored them as an unsigned integer, that could be bad |
| 07:33:37 | Emcy_: | relying on a website to tell you how much youve got on your addresses is asking for it |
| 07:34:04 | phantomcircuit: | hmm |
| 07:37:20 | Luke-Jr: | curious 1HC3dc4DubRat1P39YBBkwVRbph3ijbtPQ is invisible to Bitcore/Insight, and overloads blockexplorer |
| 07:58:15 | midnightmagic: | ehh.. block explorer gets overloaded if you sneeze at it the wrong way. :-) |
| 14:10:22 | arubi: | If you're having a hard time reading bitcoin-cli's output in terminal, you can use this pipe : |
| 14:10:24 | arubi: | ./bitcoin-cli createrawtransaction 2>&1 | sed -e 's/\\n/\n/g' -e 's/\\//g' 1>&2 |
| 14:10:40 | arubi: | just discovered it and wanted to share ;P |
| 14:12:28 | sipa: | arubi: #bitcoin or #bitcoin-dev pleaser |
| 14:12:51 | arubi: | not the right place here? sorry |
| 14:18:20 | sipa: | arubi: this channel is not about bitcoin today |
| 14:19:32 | arubi: | sipa, from the topic it looks like it's not been about bitcoin for the past 10 days :) but that's okay |
| 14:20:42 | sipa: | i really want to avoid that "the more interesting" (subjectively) part of bitcoin dev discussions end up here, turning #bitcoin-dev into a support channel only |
| 14:20:48 | BCB: | anyone go to the cryptocurrency research conference at Princeton yesterday? |
| 14:20:59 | sipa: | so whenever i see not-future-research discussions here, i will comment on it |
| 14:22:03 | gmaxwell: | BCB: I did! |
| 14:22:08 | arubi: | sipa, understood. |
| 14:22:17 | BCB: | gmaxwell: it was nice to meet you |
| 14:22:36 | BCB: | You are much nicer in person (but I won't tell anyone here that!) |
| 14:22:47 | BCB: | thanks for taking the time to be there |
| 14:25:28 | Emcy: | will there be confvids |
| 14:26:04 | jgarzik: | BCB, hah |
| 14:26:22 | gmaxwell: | Well I say a lot of harsh stuff in general, but in person you can see that I do honestly feel bad about it. :) |
| 14:26:38 | gmaxwell: | Emcy: I believe there will be videos, they made all the speakers sign releases. |
| 14:27:06 | Emcy: | nice |
| 14:27:17 | gmaxwell: | I don't think the conference itself had a ton of super informative stuff for the folks here, but videos would at least be enjoyable. |
| 14:28:41 | Emcy: | i just put them on in the background and see if i can learn anything |
| 14:29:09 | BCB: | gmaxwell: yea, I was a little disappointed. I forgot how much I hate academics! |
| 14:29:31 | BCB: | But gmaxwell gavinandresen and allanR where terrific |
| 14:29:48 | BCB: | And i really like Sarah M. Smart Lady |
| 14:29:59 | Emcy: | why does everyone joke about academics |
| 14:30:08 | BCB: | Emcy: I'm not joking |
| 14:30:17 | BCB: | Emcy: they live in the clouds |
| 14:30:28 | Emcy: | ? |
| 14:30:38 | BCB: | Emcy: the rubber hits the road when all that theory gets put into practice |
| 14:30:50 | stonecoldpat: | working at a university, i can agree they are not just in the clouds |
| 14:31:01 | Emcy: | oh theory vs practice |
| 14:31:10 | BCB: | Emcy: correct |
| 14:31:36 | Emcy: | still more brains doesnt thurt |
| 14:31:44 | BCB: | Emcy: not always true |
| 14:32:11 | BCB: | best academics are those that have a foot in both worlds or have had a professional career. |
| 14:32:44 | Emcy: | is that rare |
| 14:32:58 | BCB: | Emcy: are you an acedemic or a student |
| 14:33:08 | gmaxwell: | Yea, Sarah is pretty awesome. I hope I didn't offend her too gravely. I think she might have thought I was singling her out on the privacy stuff. |
| 14:33:29 | Emcy: | um neither |
| 14:33:37 | Emcy: | im a guy |
| 14:33:54 | maaku: | Emcy: I wouldn't generalize, but sometimes brainy approaches does get in the way and hinder progress |
| 14:34:02 | BCB: | gmaxwell: I was surprised she reacted so strongly but it was nice she made her point her. Which was entirely valid |
| 14:34:09 | BCB: | maaku: thank you |
| 14:34:42 | Emcy: | maaku seems paradoxical, but no doubt true |
| 14:35:12 | BCB: | its not always a given but pure academics lack a certain understanding and insight that you can only get from "real world" work |
| 14:35:46 | Emcy: | thats probably true of any endeavour |
| 14:35:55 | Emcy: | you call call it "nice system but now add the humans" |
| 14:35:58 | BCB: | Emcy: absolutely |
| 14:35:59 | phantomcircuit: | Well I say a lot of harsh stuff in general, but in person you can see that I do honestly feel bad about it. :) |
| 14:36:02 | phantomcircuit: | ahahah |
| 14:36:22 | maaku: | BCB: I wouldn't be so extreme. Sometimes things work in practice before they are understood in theory, or the currently accepted theory is wrong/obsolete/misguided |
| 14:36:24 | BCB: | phantomcircuit: I finally met gmaxwell in person yesterday. He really is a nice guy. I was shocked! |
| 14:36:47 | BCB: | maaku: absolutely. research is important. |
| 14:37:07 | BCB: | maaku: I 'm just expressing a personal opinion that I could NEVER exist in that world |
| 14:37:16 | stonecoldpat: | BCB: that's true, but you also get people who work in the real world, who lack the knowledge about why their actually doing something. (A bit like watching your mum chop the edges of carrots off for stew, and then repeating it yourself, but not knowing the only reason your mum did that was because the pot was too small to fit the carrot) |
| 14:37:34 | Emcy: | so taht conf was a sort of academic outreach thing |
| 14:37:41 | BCB: | Emcy: yes |
| 14:37:59 | Emcy: | well thats good |
| 14:38:05 | BCB: | to connect acedemics and professionals working on crypto stuff |
| 14:38:13 | maaku: | Frankly academic ecash researchers have been obsessing over the wrong problems for two decades. that's why bitcoin didn't come out of academia. |
| 14:38:13 | maaku: | But eventually they'll get their act together, mostly because newer bitcoin-inspired grad students will do good work. |
| 14:38:37 | maaku: | * maaku observed the same phenomenon NASA with regards to new-space economy |
| 14:38:44 | Emcy: | perhaps with better relations to academia we get better papers on more interesting things than "can we trace this guy off silk road" |
| 14:39:13 | BCB: | Emcy: the conference was very well done and organized and hosted etc. I just didn't need to sit through a boring 45 minute into on bitcoin from an acedemic |
| 14:39:24 | BCB: | Emcy: that was discussed |
| 14:39:55 | BCB: | I think the dev on the pannels suggested that maybe researchers would reach out to the community before they publish to do some fact checking |
| 14:40:21 | BCB: | but that pissed off sarah cause she said academics don't have time to hang out on irc all day like you guys do |
| 14:40:31 | Emcy: | i bet no one is really doing peer review of bitcoin papers any way |
| 14:40:34 | Emcy: | only people like greg |
| 14:40:47 | BCB: | Emcy: that is obvious from the quality of some of those papers |
| 14:41:17 | BCB: | Sarah did bring up that fact that devs could reach out to acedemics for help with looking into persistent issues. |
| 14:41:31 | phantomcircuit: | interesting |
| 14:41:35 | BCB: | it should be a two way street |
| 14:41:35 | Emcy: | i tend to read them till i get to the greek glyphs |
| 14:41:44 | phantomcircuit: | multibit doesn't do headers first |
| 14:41:46 | phantomcircuit: | that's weird |
| 14:41:59 | BCB: | it just need to be coordinated |
| 14:42:01 | Emcy: | then i skip to the graphs and see if i can make heads or tails then its on to the conclusion |
| 14:42:55 | BCB: | Emcy: there was also discussion that every paper starts with a description of bitcoin which always differs from paper to paper and is not always accurate |
| 14:43:22 | Emcy: | think i noticed that |
| 14:43:23 | BCB: | This is partially due to no official documentation of bitcoin to refer to |
| 14:43:34 | maaku: | maaku is now known as Guest34894 |
| 14:43:50 | phantomcircuit: | BCB, they could probably just copy the white paper abstract |
| 14:44:01 | BCB: | Emcy: which leads to dev or othe peers to loose credibility for the work |
| 14:44:25 | BCB: | phantomcircuit: not really. The white paper DOES NOT describe the details of the protocol as it stands now |
| 14:44:46 | tacotime: | Yeah, the white paper from Satoshi is pretty sparse. |
| 14:47:28 | phantomcircuit: | BCB, sure, but they often get the general idea wrong too |
| 14:48:29 | BCB: | phantomcircuit: correct. and that was part of the discussion. You have to read and understand the code to understand the protocol. There was mention that cprogrammers are a dying bread (with younger developers) and make it very inaccessable |
| 14:49:16 | tacotime: | I'm all for more academia involvement, but my experience with academia is that they all too often develop answers to problems that don't exist for the sake of a paper (if they're answers at all). But there are always a few groups doing something interesting. |
| 14:50:10 | phantomcircuit: | BCB, eh |
| 14:55:18 | Guest34894: | Guest34894 is now known as maaku |
| 14:56:28 | BCB: | tacotime: then we need to get the right groups involved that can ad value to the project. I think this conference was a great first step |
| 14:56:51 | tacotime: | Yeah, Princeton is probably a good location to find talent. |
| 14:57:26 | mr_burde_: | mr_burde_ is now known as mr_burdell |
| 14:57:27 | tacotime: | Given my talks with my accountant over the past couple of days, I'm most hopeful that tax lawyers are the next major group of people to get involved in Bitcoin. :P |
| 15:00:22 | Emcy: | i wonder if any of these academics could be found submitting pull requests |
| 15:00:41 | Emcy: | they knock up little apps to support their research sometimes |
| 15:45:51 | gmaxwell: | BCB: oh it absolutely was a good point and I'm glad she made it. |
| 15:48:33 | BCB: | tacotime: the next group of people to "make money" from bitcoin #PicksAndShovels |
| 15:53:25 | gmaxwell: | bcb: yea, well, sorry when I hear this stuff like ruby / python programmers don't understand things that require them to worry about binary encodings and such ... I want to say something like we're failing to tech people computing. But there is a fine line between "I don't understand _this_ code" vs "I'm uncomfortable with dealing with exacting low level details". |
| 15:54:37 | BCB: | gmaxwell: I agree. I think the major disconnect is that this is a financial services protocol and not a fancy new nodejs chat app |
| 15:55:22 | BCB: | gmaxwell: serious question: Why does the endianess in bitcoin switch back and forth depending on the function? |
| 15:55:23 | epscy: | c++ isn't sexy sadly |
| 15:55:37 | BCB: | epscy: I like C myself |
| 15:55:44 | epscy: | i like C |
| 15:55:48 | gmaxwell: | Not just a financial services protocol, but bitcoin itself — at least a pretty large chunk of it— is a cryptosystem. |
| 15:55:53 | epscy: | but it isn't sexy ;) |
| 15:56:04 | gmaxwell: | BCB: because of things satoshi implemented via calls to libraries mostly. |
| 15:56:16 | gmaxwell: | (and libraries used different conventions than satoshi did) |
| 15:56:54 | BCB: | gmaxwell: so could a future implementation of the protocol use a consistent endianess or are we stuck with that? |
| 15:57:10 | gmaxwell: | But I generally consider that stuff to be the smallest possible real complexity. Anyone who has worked on embedded systems has constantly dealt with details far more annoying "Oh all the bits are reversed on _this_ bus". |
| 15:57:11 | BCB: | epscy: Ruby and Python isn't sexy either. Its just "easy" |
| 15:57:50 | gmaxwell: | BCB: in bitcoin we're probably stuck with it, even if we make incompatible changes it's probably not worth increasing the size of the patch to change it. |
| 15:58:20 | BCB: | gmaxwell: who is heading up the crowd sourced documentation effort |
| 15:58:20 | austinhill: | gmaxwell: back from Princeton? welcome back… |
| 15:58:40 | gmaxwell: | Sitting in EWR right now in fact, so not back yet. |
| 15:59:23 | epscy: | BCB: it's not easy if you do it right (in ruby or C), but I agree with your point that people attracted to node, ruby, etc because it's easier to quickly get a satisfying result |
| 16:00:22 | BCB: | espsy they are abstraction. The remove a lot of the complexity and don't require understanding the underlying protocols. |
| 16:00:50 | epscy: | yup, that is kinda the point of them |
| 16:01:32 | epscy: | i make a living as a code monkey mostly doing business logic, I can't justify to the company re-inventing the wheel for each project |
| 16:01:46 | epscy: | it's hard enough to keep on top of technical debt as it is |
| 16:02:08 | epscy: | this is probably OT now, hit me up in #bitcoin if you want to follow up |
| 16:07:15 | gmaxwell: | Well I don't know that it's OT. I am a huge fan of abstraction, but when you're talking about tightly interlocking cryptographic protocols, the details hidden by the abstractions can often be fatal. |
| 16:07:26 | gmaxwell: | esp when you need to interwork multiple implementations. |
| 16:08:07 | gmaxwell: | E.g. if you use a magic python serialization of an integer, it might be subtly different from the magic ruby serialization which is almost the same and doom results. |
| 16:08:32 | gmaxwell: | Or "oh look this seralization supports encoding negative values... and the protocol fails in the case and gives away everyone's money" |
| 16:08:50 | gmaxwell: | So in practice, at least for consensus parts you are often forced to be operating at a very low level. |
| 16:09:21 | gmaxwell: | (and a really large chunk of inconsistencies between bitcoin core and other implementations have been due to abstraction weirdness in one implementation or the other) |
| 16:09:52 | epscy: | oh sure, I'm not suggesting C++ is the wrong tool for bitcoin, I'm just saying use the right tool for the job, often these days that isn't C++ |
| 16:10:26 | gmaxwell: | Full agreement. |
| 16:11:02 | gmaxwell: | (IMO for the rules part of bitcoin there currently exists no right tool, C is probably closest.. not because it's good but because its easier to make it clear exactly _what_ its doing) |
| 16:11:27 | gmaxwell: | (e.g. no hidden behavior from abstractions which can have surprising consequences) |
| 16:12:20 | hearn: | i would not want to use C for bitcoin |
| 16:12:32 | hearn: | the memory management in C++ is dangerous enough, even with STL and all the C++ help |
| 16:13:21 | gmaxwell: | There should be no memory management in the inner rules part at all. |
| 16:13:30 | gmaxwell: | All memory should be statically allocated up front. |
| 16:15:58 | hearn: | that would be just as complicated. better to use GC |
| 16:16:06 | hearn: | i was wondering for a while what the performance would be of switching Core to use boehm gc |
| 16:16:13 | jgarzik: | +1 |
| 16:16:32 | gmaxwell: | ... |
| 16:16:37 | jgarzik: | gmaxwell, picocoin/libccoin API aims to make that _possible_. You have to do the grunt work of statically allocating stuff. |
| 16:16:51 | gmaxwell: | We're probably talking about different stuff. |
| 16:18:40 | hearn: | not sure we are :) GC should not have any impact on rules correctness though. all it can do is eliminate any chance of double frees or use-after-frees |
| 16:18:41 | gmaxwell: | E.g. things like transaction validation, script execution. We should know the memory usage of that entirely in advance, otherwise you can potentially get network partitioning due to ooming nodes. (Well, fortunately, in practice the way script is designed you can't use more than about about 3/4 of meg in any case, as a consequence of other restrictions) |
| 16:19:34 | sipa: | hearn: for the DoS protection through resource tracking you keep talking about (and I agree with), we need to do what gmaxwell says: have a formal understanding of all usage of validation |
| 16:19:40 | gmaxwell: | (as an aside, I believe we've never had a double-free/use after bug anywhere near the consensus code either) |
| 16:19:45 | sipa: | and GC only obfuscates that |
| 16:20:18 | gmaxwell: | right and if we know the usage then we can just have it static, which is good for performance (pfft who cares) and also reasoning about the worst case... including enabling static analysis. |
| 16:20:21 | hearn: | gmaxwell: yes we got lucky that satoshi was so into modern C++ and there are hardly any new/delete calls anywhere. i hope we remain that lucky |
| 16:20:23 | hearn: | as the code evolves |
| 16:20:41 | hearn: | however even a use-after-free or double free in the networking code would be fatal |
| 16:21:55 | hearn: | sipa: i think we already do, right? as gmaxwell said you can’t really cause huge memory bloat via validation due to all the other rules |
| 16:22:22 | sipa: | hearn: we just have arbitrary limits on some data structures |
| 16:22:41 | sipa: | hearn: we don't actually track any cpu/memory/netork/io resource usage per request/peer/validation |
| 16:23:13 | hearn: | sure, i know. i meant the max possible memory usage of script validation or something. |
| 16:23:19 | sipa: | also, #bitcoin-dev |
| 16:23:27 | hearn: | * hearn takes off his robes and wizard hat |
| 16:23:45 | sipa: | is that a deliberate bash.org reference? |
| 16:24:18 | hearn: | of course it is. everyone knows wizards don’t wear hats. |
| 16:24:22 | hearn: | jeez. did you never watch lord of the rings? |
| 16:24:38 | sipa: | too many times |
| 16:37:39 | jcb1: | jcb1 has left #bitcoin-wizards |
| 16:37:40 | gmaxwell: | (mostly I had it in here because I was initially discussing engineering considerations for this sort of system in the abstract.) |
| 17:01:11 | adam3us: | maaku: (movin this from dev to wizards) i know what hearn means. its a common objection that you'd just as well trust the issuer as you have to trust him for redemption however thats not the full picture. most transactions do not involve redemption (share buy backs or new issues) they involve market sales. and pegged private-chain allows |
| 17:01:54 | adam3us: | maaku: allows you to recover (its like self-custody where they have independent custodians in normal share systems for this reason, in case the exchange goes bankrupt) |
| 17:02:48 | maaku: | adam3us hearn: there are so many roles here - accountant, issuer, authorizer, redeemer, asset-holder/user |
| 17:02:59 | adam3us: | maaku: and it prevents the exchange editing a database record o change your share ownership, or being hacked to do so etc. or from freezing your share ownership, seizing it. bitcoin adds many useful features. counter-party risk (being self-issued) of btc is the only one lost. there are plenty ineresting ones left for issued assets |
| 17:03:20 | maaku: | generally speaking we can't assume these are the same people, and it would be nice to have a trustless medium where the roles are cleanly separated |
| 17:03:49 | maaku: | but maybe this argument only makes sense because I've spent years thinking about the problem ... it doesn't seem to get me much headway with skeptics |
| 17:05:43 | adam3us: | maaku: agreed. did you read gendal's blog? http://gendal.wordpress.com/2014/01/05/a-simple-explanation-of-how-shares-move-around-the-securities-settlement-system/ when he's finished it looks like a spiders-web of counter-parties (each taking a skim:) |
| 17:06:21 | maaku: | not yet i'll look at it |
| 17:06:27 | maaku: | i think it is partly a problem of having a hammer and everything looking like nails |
| 17:06:57 | maaku: | bitcoin is 100% trustless, which leads people to "let's make everything trustless! remove trust from all the things!" |
| 17:07:12 | maaku: | ... except trust is inherent in much/most of all real world transactions |
| 17:07:29 | adam3us: | maaku: the argument of trust the issuer to fulfill all the roles is like the current system. counter in database record, firewall, locked cage in datacenter, armed guard. all fun and games until they get remote compromised, commit internal fraud, or go out of business, or have a conflict of interest with you, or a court order to your detriment |
| 17:08:03 | maaku: | when I buy stock I'm trusting the corporate directors to not run away with the funds, create a ponzi scheme, or do stupid things that the market doesn't like |
| 17:08:18 | adam3us: | maaku: yes. but it is nice to replace unwanted counter-party risk with a trustless mechanism |
| 17:08:26 | maaku: | yes, exactly |
| 17:08:47 | maaku: | i should be trusting the directors. i shouldn't have to trust NASDAQ or my brokers or my lawyer or accountant |
| 17:10:25 | adam3us: | maaku: yes we are in violent agreement. i guess we just articulated the counter-arguments to hearn 's what-if you just trust the issuer, for when he comes back: answer all the usual current bad things happen. and you cant write smart-contrcts in such systems either as smart-contracts should be irrevocable (and i think unfreezable/unseizable also possibly) |
| 17:11:38 | gmaxwell: | 'trust' comes in multiple forms though.. you can trust the issuer but always demand receipts so you can prove that he's cheating. |
| 17:12:32 | gmaxwell: | (I'm a big fan of the "you already trust the issuer, so forget this blockchain crap and just do something efficient" argument... where it applies. But that doesn't mean there aren't things that can be done better than 100% trust) |
| 17:13:13 | adam3us: | gmaxwell: i'm not a fan of that. counters inside firewalls are last century, and must die |
| 17:14:26 | gmaxwell: | adam3us: it depends on what you're talking about precisely. For example. a common colored coin example is that some satoshi controls ownership of a car ... and some tamper resistant computer in the car only lets a key start it if presented with a spv proof that the key holder owns the colored coin. |
| 17:14:30 | adam3us: | gmaxwell: yes to receipts/audit with a usdcoin issuer one should be able to audit the coins in circulation, and demand eg real-time read only usd balance in client funds account from he bank (which might be a different entity). mid-term the whole thing can end up in this mode and can be end-2-end audited even on the usd side |
| 17:15:30 | gmaxwell: | I say this is unnecessary. You can eliminate the satoshi by just having telling the car about the ownership change and then show it that it completed. |
| 17:15:51 | adam3us: | gmaxwell: so then there was the example that the french electric car switched off its batteries mid-driving because the battery lease payment was late. not so good. if you own the car you own the car and ddont want a centrl db overriding that ownership without proof that can be publicly audited |
| 17:16:08 | gmaxwell: | I'm not assuming some centeral db at all. |
| 17:16:56 | gmaxwell: | I'm pointing out that the colored coin is pure overhead. You're trusting the _car_ to follow the protocol. So you can ask the car to obey the right state changes without asking bitcoin to track the ownership. |
| 17:17:01 | gmaxwell: | (in that case) |
| 17:17:08 | adam3us: | gmaxwell: ok. yes to general use blockchain where it makes sense. dont go nuts and waste bandwidth. many interesting and bearer things are possible or server but trustless |
| 17:17:21 | maaku: | gmaxwell: you're assuming some sort of network for tracking ownership changes and doing double-spend protection |
| 17:18:05 | adam3us: | gmaxwell: (without blockchain... i guess blockchain was their first exposure to 3-party protocols to some of the new hammer weilders :) so you no doubt have a point and there would be examples matching what you said |
| 17:20:35 | maaku: | even in the car case, I'm not sure I'd want my ability to transfer ownership be dependent up on someone continueing to operate a private accounting server (and my car having access to that server) |
| 17:21:38 | phantomcircuit: | sipa, neat |
| 17:21:40 | phantomcircuit: | 36442ms |
| 17:21:50 | phantomcircuit: | "keypoolsize" : 1000001, |
| 17:24:06 | adam3us: | maaku gmaxwell: i am not sure about smart property. seems a not that interesting example to me, because its like DRM applied to physical objects. and then definiing ownerhip of the physical object as ownership of the private key for the side-chain token; (or the key fob containing the private key) in that sense you could think of the blockchain as a way to |
| 17:24:46 | maaku: | adam3us: "you could think of the blockchain as a way to"... freenode cut you off |
| 17:24:48 | adam3us: | gmaxwell: transfer ownership to a new key fob using pubic key crypto such that the owner cant go steal the car back by keeping keys or cloning |
| 17:25:11 | adam3us: | maaku: (no that was the end... contd in next above) |
| 17:25:53 | maaku: | adam3us: you described it well. why is it not interesting? |
| 17:26:09 | adam3us: | maaku: but i dunno the whole thing of smart property seems a bit DRM. because well if you have to rely on DRM anyway you dont need online stuff much |
| 17:27:02 | maaku: | yes, well bitcoin *is* DRM. digital rights management over control of currency, specifically |
| 17:27:06 | adam3us: | maaku: ie why do you even need the key at all. because the car's ECU does a challenge response with it.. so the car ECU could have offline DRM and mediate ownership transfer almost as effectively as you're already depending on it not to be bypassable |
| 17:27:48 | adam3us: | maaku: right. and that makes sense for a virtual object tht is embodied by the currency unit. but a physical object has a local DRM enforcement anyway |
| 17:27:48 | maaku: | the smart property case gives you the same assurances bitcoin does : you can't have your access to the car frozen, or forceably transferred away from you (short of taking the car and installing a new lock) |
| 17:28:06 | adam3us: | maaku: but thats already true for the offline DRM |
| 17:28:42 | maaku: | adam3us: enlighten me as I know of no physical DRM system which provides those protections |
| 17:28:45 | adam3us: | maaku: i think you can make the argument that given the option to write the code that goes in the ECU to do the key fob challenge repsonse and key fob ownership transfer you get the same effect without bandwidth and being online |
| 17:29:38 | maaku: | one other advantage is integration with government: your department of motor vehicles could assay taxes & other restrictions through enumerated mechanisms on chain |
| 17:29:42 | adam3us: | maaku: well i dont know much except my old merc v class van decided one day to not start anymore . turns out the ECU had decided the key had failed 30 times within some time period (or ever) and so hat was that. new ECU for e1000 from germany or brick car |
| 17:29:48 | maaku: | as well as collecting tolls, etc. |
| 17:31:00 | adam3us: | maaku: so there is actually a crypto challenge response between the key and the ECU to decide if it will start. so if thats what you want and the assumption is you cant rip out or reflash the ECU (because its put in an inconvenient location and moderately tamper-resistant) then just get people to buy keys. |
| 17:31:44 | gmaxwell: | maaku: nope. E.g. owner1 tells the car, I intend to sell you to owner2, you are sold when 1 btc is paid to xyz. Confirm. And the car signmessages that it agrees. .. etc.. (gah so frustrating to lose net connectivity mid sentence) |
| 17:31:53 | adam3us: | maaku: if i sell you the car, i press some special key combo and transfer ownership from the ECU perspective from my key to your key. as its your key you trust me not to have tampered withit. if i tampered with the ecu to steal the car back anyway the bockchain cant help you |
| 17:32:17 | gmaxwell: | (there are a couple other transaction styles that work and require no network ... just a provable payment being made, so long as the car is trustworthy) |
| 17:32:37 | jtimon: | adam3us the chain becomes the place to trade the keys, that's the whole point |
| 17:32:42 | gmaxwell: | and yea, if the car is not trustworthy you're busted.. the protocols that have the car sign also leave evidence |
| 17:32:46 | maaku: | gmaxwell: the car is listening to the network though, right? |
| 17:32:50 | adam3us: | maaku gmaxwell: so it seems to me that a pure ownership would be equivalent without the blockchain |
| 17:33:39 | adam3us: | jtimon: right. actually to provably sell the car so then you buy my old mercv for 1BTC and its a smart-contract which also transfers ownership to your key fob key |
| 17:34:05 | jtimon: | the brick car problem can be easily solved by allowing the in-chain key to create off-chain keys the car accepts until revocated |
| 17:34:10 | maaku: | adam3us: i don't think they're equivalent. you can't do things like remote revokation of delegated key rights without some sort of external database it is connecting to |
| 17:34:36 | adam3us: | (funnily enough i sold it on ebay to a guy who actually did go try to reflash the ECU, his day job involved ECU work. the new ECU was more than the car was worth so from my perspective it was bricked) |
| 17:34:50 | maaku: | (e.g. daughter runs off with the car, and dad disables her key) |
| 17:36:03 | jtimon: | the api of the car could be {open, new_subkey, add_revoke, revoke_all} |
| 17:37:49 | adam3us: | maaku jtimon: i guess my argument is that the blockchain version is convenient wth the smart contract, atomic swap of car ownership key for 1btc, but only guarantees you have a signature from say a mercedes TPM asserted cert in the ECU. but ultimately that assumes i did not bypass or hack the ECU (like the guy I sold the real car to) |
| 17:39:04 | maaku: | adam3us: yes that was an assumption I enumerated above |
| 17:39:09 | adam3us: | maaku: so there is a last step assurance gap because the binding from the ownership key to the physical object is imperfect |
| 17:39:17 | maaku: | if you have physical access to the car, all of these schemes are moot anyway |
| 17:40:09 | maaku: | but in real life not academia, this assumption is fine for all but some outlier cases |
| 17:40:19 | gmaxwell: | maaku: the car doesn't have to. |
| 17:40:38 | jtimon: | yes, you could also sell the p2p keys of a glass made house ;) |
| 17:42:13 | adam3us: | maaku: hmm but cars are not so interesting unless you have physical access. but yes i saw what my van looked like after the mechanic pulled the ECU. dismantled a lot of the dash took him a while. and it could be made tamper resistant the box / chip also |
| 17:42:13 | jtimon: | you may want a legal contract associated to the keys |
| 17:43:08 | jtimon: | ideally you would digitalize property registries, but who knows how long it will take for any administration to adopt that |
| 17:43:22 | maaku: | adam3us: but ultimately you can just break the window and hotwire the car |
| 17:43:32 | maaku: | same goes for home security |
| 17:44:23 | adam3us: | maaku: i dont think you want remote revocation necessarily. maybe just positive ownership transfer (new key fob plays ownership transfer tx to ECU when first used) |
| 17:44:44 | jtimon: | so as said you probably want the key AND a legal certificate |
| 17:45:01 | maaku: | adam3us: same thing. remote revocation == key transfer to new multisig output |
| 17:45:39 | maaku: | jtimon: the interesting use case is putting the legal certificate on the chain |
| 17:46:03 | adam3us: | maaku: yes. i just mean i'd sooner hve the car off and stationary and with new owner present . not a fan of remote bricking protocols. sort of things law enforcement like: car kill switches |
| 17:46:04 | maaku: | then you no longer need government buracracy and title companies etc. |
| 17:46:45 | maaku: | adam3us: nor am I. that would seem a dangerous thing to do if it were my daughter. but I would want the flexability to do that. |
| 17:47:04 | maaku: | i think smart physical property contracts are fine, but they all do suffer from the real-world interface limitation |
| 17:47:29 | gmaxwell: | I've replaced an ECU, it's a PITA. it's trivial shop work but not something you want to do in a parking lot. |
| 17:47:30 | maaku: | smart digital property contracts are more interesting as you can't get around them by hacking the device |
| 17:47:58 | gmaxwell: | (in some cars you have to remove the seats to get to it if you don't want to cut through things) |
| 17:48:12 | maaku: | but i'm not counting out large transformations to society coming from smart physical property contracts |
| 17:48:18 | gmaxwell: | (as well as the dash as mentioned) |
| 17:48:50 | maaku: | gmaxwell: certainly all on purpose. no one wants it to be something you can do unnoticed in a parkinglot |
| 17:49:01 | gmaxwell: | in any case, I'm just pointing out that I think at least in those property cases you can get equivilence without any tracking token in bitcoin. If you're unconvinced we should probably talk through it in person with a whiteboard. :) |
| 17:49:13 | gmaxwell: | I dunno how much that applies to other things. |
| 17:49:17 | gmaxwell: | (also, about to fly. :) ) |
| 17:51:20 | adam3us: | maaku: the other thing is these electronic keys come with reprogramming minikeys, but if you lose them, the garage has some override/master reprogramming key so if this is over-the-air you can bet law enforcement will demand access to it and remote kill stuff all the time |
| 17:52:36 | jtimon: | gmaxwell in freimarkets you have a legal contract hash field |
| 17:52:45 | jtimon: | on the asset defintion |
| 17:53:32 | maaku: | jtimon: meh is that even still in the draft? |
| 17:53:53 | maaku: | i'm less convinced of the utility of that. it was basically jost a "notes" field |
| 17:54:08 | gmaxwell: | hm the cdecker malleability paper doesn't even point out that safe behavior prevents loss regardless of malleability. :( |
| 17:54:11 | gmaxwell: | that sucks. |
| 17:54:31 | gmaxwell: | (link: http://www.bit.ly/1rCqKED) |
| 17:54:59 | gmaxwell: | it's interestin in that they can count mutants that are otherwise undetectable because they were apparently logging the network. |
| 17:55:19 | gmaxwell: | There is a flaw in their approach however, in that if the mtgox original was non-IsStandard they wouldn't have heard it. |
| 17:55:19 | adam3us: | gmaxwell: i think its time for some fightback. collect samples. |
| 17:56:00 | adam3us: | gmaxwell: write paper enumerating academic paper bitcoin misunderstandings. htye might even read it if it was pubished, and then be embarrassed to do the same! |
| 17:56:27 | adam3us: | gmaxwell: yes lucky they logged with wide connectivity, very handy |
| 17:56:48 | jtimon: | never removed it, external contract, msybe is a ricardian contract instead of a legal contract, but it's more than a memo out of the chain, you can have digital legal contracts in some countries and it may be possible to refer to the protocol rules in the legal contract itself |
| 17:56:53 | gmaxwell: | The author there has been involved in the bitcoin community some (but sadly it hasn't prevented him from publishing stuff in the past that covered things we'd already done a year befor his papers :) ), dunno why he missed where I've explained this point a number of times. |
| 17:57:17 | gmaxwell: | not the biggest thing, but they should probably improve that explination if they still can (since its a preprint) |
| 17:58:09 | sipa: | phantomcircuit: try using my secp256k1 branch :p |
| 17:59:42 | gmaxwell: | adam3us: yea, but the logging doesn't help when the txn don't relay at all due to invalid der encoding. |
| 18:00:10 | adam3us: | gmaxwell: incorrect blame allocation is relativel important to fix , in that it incorrectly paints the reliabiliyt of bitcoin protocol |
| 18:00:45 | adam3us: | gmaxwell: i guess even gox local node would drop, so being 1-hop wouldnt help you |
| 18:00:50 | gmaxwell: | yep. |
| 18:00:55 | gmaxwell: | exactly. |
| 18:01:18 | maaku: | * maaku adds OP_RECOVERPUBKEYFROMSIGNATURE to his hard-fork wishlist |
| 18:01:30 | gmaxwell: | they also don't note the actual effect of the later attacks that were 'triggered' by the press release (e.g. that they were a DOS attack but there is no reported losses) |
| 18:01:34 | adam3us: | gmaxwell: is someone or someones going to contact cdecker and tell him that should be corrected? it should be done |
| 18:01:56 | gmaxwell: | I am going to be on an airplane in moments, one of you should go point out these things. |
| 18:02:08 | gmaxwell: | (but be kind, if you cause them to be defensive they might not fix it) |
| 18:02:17 | gmaxwell: | really some small additions would help a lot. |
| 18:02:48 | gmaxwell: | though the problem that they might not have seen all the txn really weakens their position which is currently mtgox is a bunch of lying liars that lie (which may well be true, but I don't think their work conclusively shows this) |
| 18:06:02 | maaku: | gmaxwell: that's a pretty significant flaw, isn't it? mtgox's supposid losses was due to IsStandard breakage |
| 18:15:34 | bdhuser: | bdhuser is now known as bedeho |
| 18:28:29 | jps_: | jps_ is now known as jps |
| 18:53:56 | maaku: | kazcw: you do verify the amount by calculating it yourself, and fail a script which doesn't provide the correct amount |
| 18:54:35 | kazcw: | but what do you gain by including the amount with the script? |
| 18:54:48 | maaku: | but any output which fails is black listed (you throw away transactions using it in the future) to get DoS prevention |
| 18:55:05 | maaku: | and you can charge fees appropriately as a further DoS prevention against abusively long scripts |
| 18:55:32 | maaku: | (moving a discussion about turing-completeness in script to here from #bitcoin-dev) |
| 19:14:44 | sipa: | maaku: the problem is that computations for script evaluation are a shared resource, like blockchain size |
| 19:15:07 | sipa: | maaku: so you want some comsensus rule for full nodes to demand limited computational requirememts |
| 19:15:31 | sipa: | which also aligns miners' incentives, by making them prefer higher fee/computatiom |
| 19:18:28 | maaku: | sipa: there would have to be a per-block cap |
| 19:18:47 | sipa: | yeah, exact |
| 19:18:48 | sipa: | y |
| 19:19:59 | pigeons: | here he tries to have distributed consensus on the price of an asset without actually offering to buy or sell the asset, just voting on what price you want it to be, and thats supposed to be the price used by executing contracts. seems weird: http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ |
| 19:27:44 | kazcw: | Even assuming no entity has a lot of votes, everyone wants to aim for 25th %ile or 75th each round (depending on what they want the price to do), giving two clusters in the votes. Over repeated rounds, these points would diverge indefinitely. |
| 19:30:12 | kazcw: | Hm, maybe not. Since 50% of voters will be outside the winning range each round, everyone wants to be on the moderate side of the cluster they're aiming for -- pitting competition within each cluster against competition between clusters |
| 19:35:50 | maaku: | kazcw: or maybe I want to fuck with the price, just because? |
| 19:38:12 | maaku: | but it seems he knows this "The economics of it are not perfect, and if large collusions are possible then it may break down" |
| 19:38:16 | kazcw: | maaku: Oh right, as long as some people are voting minimally or maximally, the center of people below the median could be toward the extreme side of the cluster, leading to explosive divergence |
| 19:40:30 | kazcw: | so it seems like that scheme is probably as dumb as it at first sounds |
| 19:41:52 | maaku: | kazcw: the assumption is that I am more motivated to participate honestly than to be a dick |
| 19:42:24 | maaku: | but that's an assumption that becomes weak as soon as you use the construction for anything important |
| 19:42:45 | kazcw: | I don't think it even takes trolls for it to break down though, it seems like economically rational behavior would break it |
| 19:42:53 | maaku: | if I can make more money by manipulating the price -- yes |
| 19:43:13 | kazcw: | the desired equilibrium is not a unique stable equilibrium, if it's stable at all |
| 19:43:21 | jtimon: | yeah, voting for price discovery seems stupid |
| 19:43:50 | maaku: | if I'm a small fry then my interest is to vote honestly, if i'm a whale than my interest is to manipulate the vote and extract tons of profit from all the puny little investors |
| 19:44:05 | maaku: | it's a mechanism which increases weath disparity |
| 19:45:34 | jtimon: | more importantly, what do voters know about production costs and the utility for the consumers, what should they decide on prices? |
| 19:46:23 | kazcw: | maaku: no one's interest is to vote honestly though, everyone's incentive is to aim for 25th %ile or 75th |
| 19:46:32 | kazcw: | if not minimally or maximally |
| 19:46:33 | maaku: | the prisoner game from the article is a total red herring - the prisoner has nothing to gain from manipulating the vote, and everything to gain from colluding |
| 19:47:20 | maaku: | kazcw: no, he's proposing using it for price discovery for the purpose of constucting contracts - i've seen it called 'synthetic assets' in other contexts |
| 19:47:58 | kazcw: | right, but everyone either wants the price to go up or wants it to go down |
| 19:48:04 | maaku: | so I put up an option to buy bitcoins at some crazy low price, then manipulate the vote to drive the price down (synthetic price, not the bitstamp price), and exercise |
| 19:51:26 | jtimon: | synthetic assets are economic perpetuum mobiles, generally |
| 19:56:11 | c0rw1n: | c0rw1n is now known as c0rw|away |
| 20:55:10 | jaekwon: | are there any promising consensus algorithms besides pow? |
| 20:55:57 | Luke-Jr: | not yet |
| 21:00:07 | Elriel: | I think a usable decentralized timestamp service could be created out of a decentralized network of individual servers that will cross reference each other's timestamps in their own. |
| 21:00:45 | Elriel: | however, the algorithms that would allow the thing to work effectively are not easy to come up with |
| 21:01:42 | Elriel: | without PoW in the mix, you'd need to trust any single server to be honest to be able to use the network. |
| 21:41:41 | maaku: | in the 60 years of computer science that has lookat at this problem, hashcash proof-of-work is the only solution ever to have been found |
| 21:41:58 | maaku: | and even then it only works under certain limitations and circumstances |
| 21:42:10 | maaku: | i would not expect a miracle waiting for some alternative consensus system |
| 21:59:11 | mr_burde_: | mr_burde_ is now known as mr_burdell |
| 22:01:11 | jcb1: | jaekwon, Elriel: I've been trying to design a (semi) decentralized consensus system based on multiple verifiably append-only logs (notaries). I have a few pages of google-doc with my thoughts if you're interested: https://docs.google.com/document/d/1lTzjb85TyubsOInk_pe-bjCuCmFyCaFfSG8RYbI4NAQ/edit |
| 22:02:59 | jcb1: | not claiming this is a solution... trying to write details down has mostly made me that this is a hard problem and some type of centralization seemingly wants to emerge |
| 22:11:24 | Elriel: | jcb1: I think it'd make sense to limit the system to just timestamping. Other layers can then make use of the timestamps to actually make some sense of the hashes that are timestamped. |
| 22:11:53 | Elriel: | so the only thing the system would need to be able to answer is "which hash existed first?" |
| 22:15:44 | jcb1: | Elriel: interesting definition of the problem. What are the trust requirements? Does everybody need to trust a set of timestamping services which overlaps significantly with the set that everybody else trusts? |
| 22:17:12 | Elriel: | jcb1: the way I've envisioned it, it's enough to fully trust a single timestamping server. This, incidentally, gives everyone an incentive to run one. |
| 22:18:03 | Elriel: | that the servers timestamp each others "blocks" means that there will be loops within the data |
| 22:18:48 | Elriel: | and those loops can be used to prove definite bounds between which certain hashes appeared. |
| 22:20:12 | Elriel: | in other words, in this layer, there would be no consensus required. |
| 22:21:03 | Elriel: | but this layer would help other layers to form their consensus |
| 22:21:15 | jcb1: | would definitely be interested to see a write-up and try to reason about attacks on this |
| 22:22:07 | Elriel: | unfortunately, beyond the basic structure, I've been unable to flesh it out accurately enough for that. |
| 22:23:01 | Elriel: | the basic proof structure is obvious, but the algorithms for efficiently finding that data are not so simple |
| 22:23:18 | Elriel: | this thing would generate a lot of data that's scattered all over the network |
| 22:23:55 | jcb1: | I envisioned participants encoding the set of servers they trust each time they timestamp data/transactions, which adds complexity but the goal was that you don't need to have a globally trusted set. Communities would probably converge on a common set for efficiency but there's an elegant way to roll-over to new notaries |
| 22:24:17 | sipa: | that starts to sound like ripple |
| 22:24:43 | sipa: | (sorry, just chiming in, ignore me if i'm way off) |
| 22:25:47 | Elriel: | sipa: ripple keeps consensus, what I'm describing throws consensus out the window and only tries to answer "what was first?" |
| 22:26:07 | sipa: | ok |
| 22:28:07 | jcb1: | my proposal also throws consensus out in the sense that servers don't have to agree on things, participants determine consensus by looking at what a majority of servers have said |
| 22:28:59 | jcb1: | with "majority of servers" for each transaction being specified by the previous transactions it is redeeming |
| 22:31:34 | jaekwon: | hi jcb1, just woke up from a nap. i'll read it now. |
| 23:24:38 | jaekwon: | jcb1: can you elaborate on this? Ownership of a token in the system is represented by an unredeemed transaction output combined with the token history, which is a directed acyclic graph (dag) of all past transactions on which this transaction depends. Leaves of the dag are originally issued tokens. This corresponds to an SPV proof in Bitcoin. |
| 23:31:54 | jcb1: | jaekwon: to prove you were at one point the owner, you provide the transaction history up to a transaction sending the token to you, with a set of proof-of-inclusions for each past transaction. This part is sort of like SPV in Bitcoin in that you don't provide everything the notaries have ever notarized. You can then prove you're the current owner by showing that a majority of notaries who'd need to notarize the nex |
| 23:32:26 | jcb1: | jaekwon: perhaps I need to include an example if I haven't it explained my thinking well |