00:01:15adam3us: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:08sipa:oh god, are they going after hal now too?
00:03:14warren:the article has a screenshot of his personal wallet
00:04:07BlueMatt: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:20BlueMatt:all of the non-satoshi stuff was nice, but the satoshi crap was annoying
00:04:47adam3us:i'm not sure what the forrest gump ref was about. followed by hal is really smart.
00:04:51tacotime:There already was a formal denial on bitcointalk. https://bitcointalk.org/index.php?topic=155054.0
00:07:26sipa:if hal is satoshi, he's very good at pretending to not know crypto when coding :)
00:18:42adam3us: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:05BlueMatt:sounds right
00:24:59Luke-Jr:sipa: heh
00:27:50midnightmagic:adam3us: It's ablist nonsense-talk.
01:01:16Sangheili:Sangheili is now known as Fistful_of_FiatB
01:01:37Fistful_of_FiatB:Fistful_of_FiatB is now known as Sangheili
01:07:31justanotheruser: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:56justanotheruser:Also, will coinswaps ever be safe with malleability?
01:11:57koval:koval is now known as Fistful_of_Loins
01:12:47maaku:justanotheruser: I don't expect there be 10000s of altchains in the style of the bitcoin p2p network
01:13:05maaku:there will probably only be a small handful of active decentralized p2p side chains
01:13:08Sangheili:Sangheili is now known as Fistful_of_Taxes
01:13:10maaku:and a large number of private chains
01:13:22maaku:the private case is easy: you connect directly to the accountant
01:13:37justanotheruser: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:26justanotheruser:Well I'm talking about the public chains
01:14:45justanotheruser:Hmm, what advantage does a private chain give? Aren't most tx involving people you don't know?
01:17:46maaku:well there are multiple use cases - you can use it for peer-to-peer accounting a la the original ripple design
01:18:04maaku:or you can talk about datacenter-sized validators that process >1 million transactions per second
01:18:11Fistful_of_Taxes:Fistful_of_Taxes is now known as Sangheili
01:18:21justanotheruser:So like a Visa altchain?
01:18:25maaku:surprisingly, the private accounting server is actually *more* secure than a merged mined side chain
01:18:45maaku:yeah, or NASDAQ altchain if you have the freimarkets extensions
01:19:22justanotheruser:maaku: is freimarkets in the freicoin paper?
01:19:50justanotheruser:I need to get around to reading that, the first page was interesting :p
01:20:26justanotheruser:Ya, it's in a tab :p
01:20:27maaku:we have a lot of updates we need to make to it however
01:21:00maaku:it's sortof a frozen snapshot of our thinking around 9 months ago, and a lot has happened since
01:21:24Fistful_of_Loins:Fistful_of_Loins is now known as dima1236
01:21:28maaku:still valid, just simpler and more powerful constructions have been found in the mean time
01:21:30justanotheruser:maaku: when do you think it will be "finished"
01:21:39justanotheruser:or good enough, like all the features you have done now
01:21:52justanotheruser:I'm going to quote you on that
01:21:54dima1236:dima1236 is now known as koval
01:22:03justanotheruser:Makku Karples
01:22:13maaku:justanotheruser: it's mostly a matter of finding the time/funding to work on it
01:25:00LarsLarsen: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:03maaku:LarsLarsen: but you need double-spend protection for the medium in which you are transaction, no?
01:31:51LarsLarsen:The bonds are issued by a broker, he's not going to pay you twice for the same IOU
01:32:38LarsLarsen:the problem comes in automatically taking his reserve funds if he doesn't buy it back as he promised.
01:36:00LarsLarsen:"Hey broker, did this guy sell this to anyone else yet? No? Ok"
01:37:24LarsLarsen: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:19LarsLarsen:These are high level concepts that require things we dont have today, future money
01:47:09LarsLarsen:"If you have bearer bonds and backing brokerages" is a big assumption to start from :)
01:47:19maaku: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:43maaku:obviously we're talking digital bearer bonds
01:48:09LarsLarsen: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:41LarsLarsen: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:12LarsLarsen:maaku: I never said I had a system to do that yet.
01:49:19maaku:LarsLarsen: yes i understand that, but it seems orthogonal. you still need some ledger system for tracking who owns what
01:50:02LarsLarsen:The broker keeps a ledger, he has to.
01:50:54LarsLarsen: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:24LarsLarsen: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:01topynate: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:17LarsLarsen:yes, that is the key part, everything else hinges upon the mechanisms available to trustlessly enforce a contract like that
02:10:51LarsLarsen: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:28LarsLarsen:If I had devised such a system I'd be telling you all, trust me... lol
02:13:02LarsLarsen: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:05LarsLarsen:IT may be impossible, but if it is possible, it will most likely be useful, Thats all I'm saying.
02:15:39maaku:LarsLarsen: you know that bitcoin *is* the solution, right?
02:15:59LarsLarsen:maaku: I know, but a bond is useful in that you can transact at sub-confirmation-paranoia timescales
02:16:43LarsLarsen:the bond would be redeemed for BTC
02:16:53maaku:read about two-way pegs and (federated) private accounting servers
02:17:03maaku:this provides a centralized solution
02:17:20LarsLarsen:"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:20maaku:that falls under scripting language extensions
02:18:25LarsLarsen:the utility of transacting fast is so great, people will trust millions of dollars to strangers in another country
02:22:15LarsLarsen:The price of bitcoin can jump up and then back down again between block generations. Thats insane. But true.
02:22:19maaku:they shouldn't have to - you can make this 100% trustless
02:23:05gmaxwell: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:35LarsLarsen: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:51maaku: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:35shesek:hey maaku
02:25:51shesek:nice seeing you again :)
02:26:04LarsLarsen: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:07maaku:hey shesek - you still in town?
02:26:14shesek:yeah, I'm here for another week or so
02:26:32shesek:I'm actually looking for some interesting ways to spend my time here
02:26:46maaku: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:47shesek:are you from here? any suggestions?
02:26:56LarsLarsen:maaku: it appears to be in the air
02:27:11LarsLarsen:maaku: I'd doubt myself if I thought I Was the first to crack it
02:29:10LarsLarsen:Ok I'm going to get back to trying to catch up to a moving target again, thanks maaku
02:36:51fagmuffinz:fagmuffinz is now known as toddwildey
06:44:02blumenkraft:blumenkraft is now known as eristisk
06:54:02adam3us: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:13maaku:heh yeah i kinda predicted that response
07:08:01adam3us:maaku: was that you also at 52:00 ? man these alt-coiners barely understand coin tech
07:08:25adam3us:maaku: they had trouble understanding your question even
07:11:46Luke-Jr:adam3us: which video? there are many on the page
07:12:22adam3us:Luke-Jr: yeah sorry the one that has day2-part2 written under the video
07:16:21Luke-Jr:coblee thinks people still do developmetn on the forums? XD
07:24:36phantomcircuit:anybody know what 1HC3dc4DubRat1P39YBBkwVRbph3ijbtPQ is
07:25:27Luke-Jr:phantomcircuit: a bitcoin address
07:26:12phantomcircuit:Luke-Jr, helpful
07:26:31phantomcircuit:it has a really bizarre use pattern
07:26:46phantomcircuit:exactly even numbers of btc go in
07:26:52phantomcircuit:exactly even numbers go out
07:28:37topynate:https://blockchain.info/address/1HC3dc4DubRat1P39YBBkwVRbph3ijbtPQ shows a negative final balance. is that unusual for blockchain.info?
07:29:17Luke-Jr:unusual that they screw up? not really
07:29:55Emcy_:i think they are pretty prone to chain pasring errors
07:30:58topynate:well, it's a good job no-one is relying on them for business-critical functions
07:32:54topynate:for example, if a company monitored its balances on blockchain.info but stored them as an unsigned integer, that could be bad
07:33:37Emcy_:relying on a website to tell you how much youve got on your addresses is asking for it
07:37:20Luke-Jr:curious 1HC3dc4DubRat1P39YBBkwVRbph3ijbtPQ is invisible to Bitcore/Insight, and overloads blockexplorer
07:58:15midnightmagic:ehh.. block explorer gets overloaded if you sneeze at it the wrong way. :-)
14:10:22arubi:If you're having a hard time reading bitcoin-cli's output in terminal, you can use this pipe :
14:10:24arubi:./bitcoin-cli createrawtransaction 2>&1 | sed -e 's/\\n/\n/g' -e 's/\\//g' 1>&2
14:10:40arubi:just discovered it and wanted to share ;P
14:12:28sipa:arubi: #bitcoin or #bitcoin-dev pleaser
14:12:51arubi:not the right place here? sorry
14:18:20sipa:arubi: this channel is not about bitcoin today
14:19:32arubi:sipa, from the topic it looks like it's not been about bitcoin for the past 10 days :) but that's okay
14:20:42sipa: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:48BCB:anyone go to the cryptocurrency research conference at Princeton yesterday?
14:20:59sipa:so whenever i see not-future-research discussions here, i will comment on it
14:22:03gmaxwell:BCB: I did!
14:22:08arubi:sipa, understood.
14:22:17BCB:gmaxwell: it was nice to meet you
14:22:36BCB:You are much nicer in person (but I won't tell anyone here that!)
14:22:47BCB:thanks for taking the time to be there
14:25:28Emcy:will there be confvids
14:26:04jgarzik:BCB, hah
14:26:22gmaxwell: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:38gmaxwell:Emcy: I believe there will be videos, they made all the speakers sign releases.
14:27:17gmaxwell: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:41Emcy:i just put them on in the background and see if i can learn anything
14:29:09BCB:gmaxwell: yea, I was a little disappointed. I forgot how much I hate academics!
14:29:31BCB:But gmaxwell gavinandresen and allanR where terrific
14:29:48BCB:And i really like Sarah M. Smart Lady
14:29:59Emcy:why does everyone joke about academics
14:30:08BCB:Emcy: I'm not joking
14:30:17BCB:Emcy: they live in the clouds
14:30:38BCB:Emcy: the rubber hits the road when all that theory gets put into practice
14:30:50stonecoldpat:working at a university, i can agree they are not just in the clouds
14:31:01Emcy:oh theory vs practice
14:31:10BCB:Emcy: correct
14:31:36Emcy:still more brains doesnt thurt
14:31:44BCB:Emcy: not always true
14:32:11BCB:best academics are those that have a foot in both worlds or have had a professional career.
14:32:44Emcy:is that rare
14:32:58BCB:Emcy: are you an acedemic or a student
14:33:08gmaxwell: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:29Emcy:um neither
14:33:37Emcy:im a guy
14:33:54maaku:Emcy: I wouldn't generalize, but sometimes brainy approaches does get in the way and hinder progress
14:34:02BCB:gmaxwell: I was surprised she reacted so strongly but it was nice she made her point her. Which was entirely valid
14:34:09BCB:maaku: thank you
14:34:42Emcy:maaku seems paradoxical, but no doubt true
14:35:12BCB: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:46Emcy:thats probably true of any endeavour
14:35:55Emcy:you call call it "nice system but now add the humans"
14:35:58BCB:Emcy: absolutely
14:35:59phantomcircuit: 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:22maaku: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:24BCB:phantomcircuit: I finally met gmaxwell in person yesterday. He really is a nice guy. I was shocked!
14:36:47BCB:maaku: absolutely. research is important.
14:37:07BCB:maaku: I 'm just expressing a personal opinion that I could NEVER exist in that world
14:37:16stonecoldpat: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:34Emcy:so taht conf was a sort of academic outreach thing
14:37:41BCB:Emcy: yes
14:37:59Emcy:well thats good
14:38:05BCB:to connect acedemics and professionals working on crypto stuff
14:38:13maaku: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:13maaku:But eventually they'll get their act together, mostly because newer bitcoin-inspired grad students will do good work.
14:38:37maaku:* maaku observed the same phenomenon NASA with regards to new-space economy
14:38:44Emcy: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:13BCB: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:24BCB:Emcy: that was discussed
14:39:55BCB: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:21BCB: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:31Emcy:i bet no one is really doing peer review of bitcoin papers any way
14:40:34Emcy:only people like greg
14:40:47BCB:Emcy: that is obvious from the quality of some of those papers
14:41:17BCB:Sarah did bring up that fact that devs could reach out to acedemics for help with looking into persistent issues.
14:41:35BCB:it should be a two way street
14:41:35Emcy:i tend to read them till i get to the greek glyphs
14:41:44phantomcircuit:multibit doesn't do headers first
14:41:46phantomcircuit:that's weird
14:41:59BCB:it just need to be coordinated
14:42:01Emcy:then i skip to the graphs and see if i can make heads or tails then its on to the conclusion
14:42:55BCB: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:22Emcy:think i noticed that
14:43:23BCB:This is partially due to no official documentation of bitcoin to refer to
14:43:34maaku:maaku is now known as Guest34894
14:43:50phantomcircuit:BCB, they could probably just copy the white paper abstract
14:44:01BCB:Emcy: which leads to dev or othe peers to loose credibility for the work
14:44:25BCB:phantomcircuit: not really. The white paper DOES NOT describe the details of the protocol as it stands now
14:44:46tacotime:Yeah, the white paper from Satoshi is pretty sparse.
14:47:28phantomcircuit:BCB, sure, but they often get the general idea wrong too
14:48:29BCB: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:16tacotime: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:10phantomcircuit:BCB, eh
14:55:18Guest34894:Guest34894 is now known as maaku
14:56:28BCB: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:51tacotime:Yeah, Princeton is probably a good location to find talent.
14:57:26mr_burde_:mr_burde_ is now known as mr_burdell
14:57:27tacotime: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:22Emcy:i wonder if any of these academics could be found submitting pull requests
15:00:41Emcy:they knock up little apps to support their research sometimes
15:45:51gmaxwell:BCB: oh it absolutely was a good point and I'm glad she made it.
15:48:33BCB:tacotime: the next group of people to "make money" from bitcoin #PicksAndShovels
15:53:25gmaxwell: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:37BCB: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:22BCB:gmaxwell: serious question: Why does the endianess in bitcoin switch back and forth depending on the function?
15:55:23epscy:c++ isn't sexy sadly
15:55:37BCB:epscy: I like C myself
15:55:44epscy:i like C
15:55:48gmaxwell:Not just a financial services protocol, but bitcoin itself — at least a pretty large chunk of it— is a cryptosystem.
15:55:53epscy:but it isn't sexy ;)
15:56:04gmaxwell:BCB: because of things satoshi implemented via calls to libraries mostly.
15:56:16gmaxwell:(and libraries used different conventions than satoshi did)
15:56:54BCB:gmaxwell: so could a future implementation of the protocol use a consistent endianess or are we stuck with that?
15:57:10gmaxwell: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:11BCB:epscy: Ruby and Python isn't sexy either. Its just "easy"
15:57:50gmaxwell: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:20BCB:gmaxwell: who is heading up the crowd sourced documentation effort
15:58:20austinhill:gmaxwell: back from Princeton? welcome back…
15:58:40gmaxwell:Sitting in EWR right now in fact, so not back yet.
15:59:23epscy: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:22BCB:espsy they are abstraction. The remove a lot of the complexity and don't require understanding the underlying protocols.
16:00:50epscy:yup, that is kinda the point of them
16:01:32epscy: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:46epscy:it's hard enough to keep on top of technical debt as it is
16:02:08epscy:this is probably OT now, hit me up in #bitcoin if you want to follow up
16:07:15gmaxwell: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:26gmaxwell:esp when you need to interwork multiple implementations.
16:08:07gmaxwell: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:32gmaxwell:Or "oh look this seralization supports encoding negative values... and the protocol fails in the case and gives away everyone's money"
16:08:50gmaxwell:So in practice, at least for consensus parts you are often forced to be operating at a very low level.
16:09:21gmaxwell:(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:52epscy: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:26gmaxwell:Full agreement.
16:11:02gmaxwell:(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:27gmaxwell:(e.g. no hidden behavior from abstractions which can have surprising consequences)
16:12:20hearn:i would not want to use C for bitcoin
16:12:32hearn:the memory management in C++ is dangerous enough, even with STL and all the C++ help
16:13:21gmaxwell:There should be no memory management in the inner rules part at all.
16:13:30gmaxwell:All memory should be statically allocated up front.
16:15:58hearn:that would be just as complicated. better to use GC
16:16:06hearn:i was wondering for a while what the performance would be of switching Core to use boehm gc
16:16:37jgarzik:gmaxwell, picocoin/libccoin API aims to make that _possible_. You have to do the grunt work of statically allocating stuff.
16:16:51gmaxwell:We're probably talking about different stuff.
16:18:40hearn: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:41gmaxwell: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:34sipa: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:40gmaxwell:(as an aside, I believe we've never had a double-free/use after bug anywhere near the consensus code either)
16:19:45sipa:and GC only obfuscates that
16:20:18gmaxwell: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:21hearn: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:23hearn:as the code evolves
16:20:41hearn:however even a use-after-free or double free in the networking code would be fatal
16:21:55hearn: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:22sipa:hearn: we just have arbitrary limits on some data structures
16:22:41sipa:hearn: we don't actually track any cpu/memory/netork/io resource usage per request/peer/validation
16:23:13hearn:sure, i know. i meant the max possible memory usage of script validation or something.
16:23:19sipa:also, #bitcoin-dev
16:23:27hearn:* hearn takes off his robes and wizard hat
16:23:45sipa:is that a deliberate bash.org reference?
16:24:18hearn:of course it is. everyone knows wizards don’t wear hats.
16:24:22hearn:jeez. did you never watch lord of the rings?
16:24:38sipa:too many times
16:37:39jcb1:jcb1 has left #bitcoin-wizards
16:37:40gmaxwell:(mostly I had it in here because I was initially discussing engineering considerations for this sort of system in the abstract.)
17:01:11adam3us: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:54adam3us: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:48maaku:adam3us hearn: there are so many roles here - accountant, issuer, authorizer, redeemer, asset-holder/user
17:02:59adam3us: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:20maaku: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:49maaku: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:43adam3us: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:21maaku:not yet i'll look at it
17:06:27maaku:i think it is partly a problem of having a hammer and everything looking like nails
17:06:57maaku:bitcoin is 100% trustless, which leads people to "let's make everything trustless! remove trust from all the things!"
17:07:12maaku:... except trust is inherent in much/most of all real world transactions
17:07:29adam3us: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:03maaku: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:18adam3us:maaku: yes. but it is nice to replace unwanted counter-party risk with a trustless mechanism
17:08:26maaku:yes, exactly
17:08:47maaku:i should be trusting the directors. i shouldn't have to trust NASDAQ or my brokers or my lawyer or accountant
17:10:25adam3us: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:38gmaxwell:'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:32gmaxwell:(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:13adam3us:gmaxwell: i'm not a fan of that. counters inside firewalls are last century, and must die
17:14:26gmaxwell: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:30adam3us: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:30gmaxwell: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:51adam3us: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:08gmaxwell:I'm not assuming some centeral db at all.
17:16:56gmaxwell: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:01gmaxwell:(in that case)
17:17:08adam3us: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:21maaku:gmaxwell: you're assuming some sort of network for tracking ownership changes and doing double-spend protection
17:18:05adam3us: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:35maaku: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:38phantomcircuit:sipa, neat
17:21:50phantomcircuit:"keypoolsize" : 1000001,
17:24:06adam3us: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:46maaku:adam3us: "you could think of the blockchain as a way to"... freenode cut you off
17:24:48adam3us: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:11adam3us:maaku: (no that was the end... contd in next above)
17:25:53maaku:adam3us: you described it well. why is it not interesting?
17:26:09adam3us: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:02maaku:yes, well bitcoin *is* DRM. digital rights management over control of currency, specifically
17:27:06adam3us: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:48adam3us: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:48maaku: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:06adam3us:maaku: but thats already true for the offline DRM
17:28:42maaku:adam3us: enlighten me as I know of no physical DRM system which provides those protections
17:28:45adam3us: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:38maaku:one other advantage is integration with government: your department of motor vehicles could assay taxes & other restrictions through enumerated mechanisms on chain
17:29:42adam3us: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:48maaku:as well as collecting tolls, etc.
17:31:00adam3us: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:44gmaxwell: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:53adam3us: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:17gmaxwell:(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:37jtimon:adam3us the chain becomes the place to trade the keys, that's the whole point
17:32:42gmaxwell:and yea, if the car is not trustworthy you're busted.. the protocols that have the car sign also leave evidence
17:32:46maaku:gmaxwell: the car is listening to the network though, right?
17:32:50adam3us:maaku gmaxwell: so it seems to me that a pure ownership would be equivalent without the blockchain
17:33:39adam3us: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:05jtimon: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:10maaku: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:36adam3us:(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:50maaku:(e.g. daughter runs off with the car, and dad disables her key)
17:36:03jtimon:the api of the car could be {open, new_subkey, add_revoke, revoke_all}
17:37:49adam3us: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:04maaku:adam3us: yes that was an assumption I enumerated above
17:39:09adam3us:maaku: so there is a last step assurance gap because the binding from the ownership key to the physical object is imperfect
17:39:17maaku:if you have physical access to the car, all of these schemes are moot anyway
17:40:09maaku:but in real life not academia, this assumption is fine for all but some outlier cases
17:40:19gmaxwell:maaku: the car doesn't have to.
17:40:38jtimon:yes, you could also sell the p2p keys of a glass made house ;)
17:42:13adam3us: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:13jtimon:you may want a legal contract associated to the keys
17:43:08jtimon:ideally you would digitalize property registries, but who knows how long it will take for any administration to adopt that
17:43:22maaku:adam3us: but ultimately you can just break the window and hotwire the car
17:43:32maaku:same goes for home security
17:44:23adam3us: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:44jtimon:so as said you probably want the key AND a legal certificate
17:45:01maaku:adam3us: same thing. remote revocation == key transfer to new multisig output
17:45:39maaku:jtimon: the interesting use case is putting the legal certificate on the chain
17:46:03adam3us: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:04maaku:then you no longer need government buracracy and title companies etc.
17:46:45maaku: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:04maaku:i think smart physical property contracts are fine, but they all do suffer from the real-world interface limitation
17:47:29gmaxwell: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:30maaku:smart digital property contracts are more interesting as you can't get around them by hacking the device
17:47:58gmaxwell:(in some cars you have to remove the seats to get to it if you don't want to cut through things)
17:48:12maaku:but i'm not counting out large transformations to society coming from smart physical property contracts
17:48:18gmaxwell:(as well as the dash as mentioned)
17:48:50maaku:gmaxwell: certainly all on purpose. no one wants it to be something you can do unnoticed in a parkinglot
17:49:01gmaxwell: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:13gmaxwell:I dunno how much that applies to other things.
17:49:17gmaxwell:(also, about to fly. :) )
17:51:20adam3us: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:36jtimon:gmaxwell in freimarkets you have a legal contract hash field
17:52:45jtimon:on the asset defintion
17:53:32maaku:jtimon: meh is that even still in the draft?
17:53:53maaku:i'm less convinced of the utility of that. it was basically jost a "notes" field
17:54:08gmaxwell:hm the cdecker malleability paper doesn't even point out that safe behavior prevents loss regardless of malleability. :(
17:54:11gmaxwell:that sucks.
17:54:31gmaxwell:(link: http://www.bit.ly/1rCqKED)
17:54:59gmaxwell:it's interestin in that they can count mutants that are otherwise undetectable because they were apparently logging the network.
17:55:19gmaxwell: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:19adam3us:gmaxwell: i think its time for some fightback. collect samples.
17:56:00adam3us: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:27adam3us:gmaxwell: yes lucky they logged with wide connectivity, very handy
17:56:48jtimon: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:53gmaxwell: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:17gmaxwell:not the biggest thing, but they should probably improve that explination if they still can (since its a preprint)
17:58:09sipa:phantomcircuit: try using my secp256k1 branch :p
17:59:42gmaxwell:adam3us: yea, but the logging doesn't help when the txn don't relay at all due to invalid der encoding.
18:00:10adam3us:gmaxwell: incorrect blame allocation is relativel important to fix , in that it incorrectly paints the reliabiliyt of bitcoin protocol
18:00:45adam3us:gmaxwell: i guess even gox local node would drop, so being 1-hop wouldnt help you
18:01:18maaku:* maaku adds OP_RECOVERPUBKEYFROMSIGNATURE to his hard-fork wishlist
18:01:30gmaxwell: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:34adam3us:gmaxwell: is someone or someones going to contact cdecker and tell him that should be corrected? it should be done
18:01:56gmaxwell:I am going to be on an airplane in moments, one of you should go point out these things.
18:02:08gmaxwell:(but be kind, if you cause them to be defensive they might not fix it)
18:02:17gmaxwell:really some small additions would help a lot.
18:02:48gmaxwell: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:02maaku:gmaxwell: that's a pretty significant flaw, isn't it? mtgox's supposid losses was due to IsStandard breakage
18:15:34bdhuser:bdhuser is now known as bedeho
18:28:29jps_:jps_ is now known as jps
18:53:56maaku:kazcw: you do verify the amount by calculating it yourself, and fail a script which doesn't provide the correct amount
18:54:35kazcw:but what do you gain by including the amount with the script?
18:54:48maaku:but any output which fails is black listed (you throw away transactions using it in the future) to get DoS prevention
18:55:05maaku:and you can charge fees appropriately as a further DoS prevention against abusively long scripts
18:55:32maaku:(moving a discussion about turing-completeness in script to here from #bitcoin-dev)
19:14:44sipa:maaku: the problem is that computations for script evaluation are a shared resource, like blockchain size
19:15:07sipa:maaku: so you want some comsensus rule for full nodes to demand limited computational requirememts
19:15:31sipa:which also aligns miners' incentives, by making them prefer higher fee/computatiom
19:18:28maaku:sipa: there would have to be a per-block cap
19:18:47sipa:yeah, exact
19:19:59pigeons: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:44kazcw: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:12kazcw: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:50maaku:kazcw: or maybe I want to fuck with the price, just because?
19:38:12maaku: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:16kazcw: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:30kazcw:so it seems like that scheme is probably as dumb as it at first sounds
19:41:52maaku:kazcw: the assumption is that I am more motivated to participate honestly than to be a dick
19:42:24maaku:but that's an assumption that becomes weak as soon as you use the construction for anything important
19:42:45kazcw: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:53maaku:if I can make more money by manipulating the price -- yes
19:43:13kazcw:the desired equilibrium is not a unique stable equilibrium, if it's stable at all
19:43:21jtimon:yeah, voting for price discovery seems stupid
19:43:50maaku: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:05maaku:it's a mechanism which increases weath disparity
19:45:34jtimon:more importantly, what do voters know about production costs and the utility for the consumers, what should they decide on prices?
19:46:23kazcw:maaku: no one's interest is to vote honestly though, everyone's incentive is to aim for 25th %ile or 75th
19:46:32kazcw:if not minimally or maximally
19:46:33maaku: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:20maaku: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:58kazcw:right, but everyone either wants the price to go up or wants it to go down
19:48:04maaku: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:26jtimon:synthetic assets are economic perpetuum mobiles, generally
19:56:11c0rw1n:c0rw1n is now known as c0rw|away
20:55:10jaekwon:are there any promising consensus algorithms besides pow?
20:55:57Luke-Jr:not yet
21:00:07Elriel: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:45Elriel:however, the algorithms that would allow the thing to work effectively are not easy to come up with
21:01:42Elriel: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:41maaku: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:58maaku:and even then it only works under certain limitations and circumstances
21:42:10maaku:i would not expect a miracle waiting for some alternative consensus system
21:59:11mr_burde_:mr_burde_ is now known as mr_burdell
22:01:11jcb1: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:59jcb1: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:24Elriel: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:53Elriel:so the only thing the system would need to be able to answer is "which hash existed first?"
22:15:44jcb1: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:12Elriel: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:03Elriel:that the servers timestamp each others "blocks" means that there will be loops within the data
22:18:48Elriel:and those loops can be used to prove definite bounds between which certain hashes appeared.
22:20:12Elriel:in other words, in this layer, there would be no consensus required.
22:21:03Elriel:but this layer would help other layers to form their consensus
22:21:15jcb1:would definitely be interested to see a write-up and try to reason about attacks on this
22:22:07Elriel:unfortunately, beyond the basic structure, I've been unable to flesh it out accurately enough for that.
22:23:01Elriel:the basic proof structure is obvious, but the algorithms for efficiently finding that data are not so simple
22:23:18Elriel:this thing would generate a lot of data that's scattered all over the network
22:23:55jcb1: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:17sipa:that starts to sound like ripple
22:24:43sipa:(sorry, just chiming in, ignore me if i'm way off)
22:25:47Elriel:sipa: ripple keeps consensus, what I'm describing throws consensus out the window and only tries to answer "what was first?"
22:28:07jcb1: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:59jcb1:with "majority of servers" for each transaction being specified by the previous transactions it is redeeming
22:31:34jaekwon:hi jcb1, just woke up from a nap. i'll read it now.
23:24:38jaekwon: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:54jcb1: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:26jcb1:jaekwon: perhaps I need to include an example if I haven't it explained my thinking well