00:11:48justanot1eruser:justanot1eruser is now known as justanotheruser
00:13:15justanot1eruser:justanot1eruser is now known as justanotheruser
01:11:22justanot1eruser:justanot1eruser is now known as justanotheruser
03:38:23lechuga_:gmaxwell: ack strictder
03:47:28fanquake_:fanquake_ is now known as fanquake
03:59:19rusty:andytoshi: I'd like to see a more comprehensive appendix describing all the mistakes made in altcoins... I keep learning of new ones which everyone else seems to know about.
05:42:03fanquake_:fanquake_ is now known as fanquake
06:24:04op_mul:rusty: there's so many altcoin mistakes that it's hard to keep up with them. there's an endless stream of grindable Proof Of X, failed difficulty adjustments, too fast blocks, insane proof of stake stuff, ridiculous centralisation, total lack of consensus
06:25:28op_mul:a new one I saw recently is "proof of time", where somehow consensus is gained by watching the uptime of every other peer in the network. because peers can't trust each other, every node connects to every other node (who the hell knows what happens if a peer is behind NAT).
06:26:37nsh:sounds pretty profound tbh
06:27:09op_mul:there's "proof of storage", where nodes instead of mining do partial lookups on huge rainbow tables of precomputed work. only problem is that nodes can trivially grind blocks to find winning chains just like in proof of stake.
06:28:09nsh:and catastrophic failure of consensus shouldn't hold anyone back... cf. https://www.stellar.org/blog/safety_liveness_and_fault_tolerance_consensus_choice/
06:28:50op_mul:one alcoin tried to make a non outsoureable proof of work system that queries the UTXO of the node.. only they query it and then append the nonce. the end result is just that there's stratum servers pumping out megabytes a minute of work and causing even more centralisation than before.
06:29:20tacotime_:oh, speaking of which
06:29:46tacotime_:spreadcoin does a thing that tries to provide a non-outsourceable puzzle as opposed to regular header hashing
06:30:01tacotime_:where you have to fill the block with garbage, signed the entire thing, then hash it
06:30:25op_mul:more altcoins than I can count have tried to "improve" the difficulty system by adding rapid adjustments (even down to every block), either resulting in huge swings in block time or trivial attacks. it has a fancy name, "gravity well"
06:30:46tacotime_:and then no one is supposed to be able to pool because you need to sign the entire block with the same key as the coinbase tx
06:32:49op_mul:what happens if there's more than one key in the coinbase transaction?
06:32:49tacotime_:but i keep feeling like i'm not sure that works
06:33:03tacotime_:i think you can only have one key
06:34:00op_mul:it's possible they just didn't think of that.
06:34:40tacotime_:yeah. but in the event that that is true, i guess my question would be, could you make pools still?
06:35:31op_mul:on the face of it I don't see how you could
06:36:19tacotime_:it seems like such a simple modification that if it were to work, i imagine satoshi would have thought of it
06:36:34op_mul:why can't these altcoins ever fork from bitcoin core. this source is like. 0.6 vintage.
06:37:27tacotime_:and not having pools doesn't necessarily mean that mining is decentralized. probably it ends up still centralized in a bunch of bigger miners.
06:37:59op_mul:return error("CheckSignature() : coinbase doesn't have exactly one output");
06:38:18tacotime_:so they did think of it
06:39:15tacotime_:there's a padding thing they do for the blocks that they claim encourages people to fill the blocks with tx or some bs
06:39:35tacotime_:which is just a recursive formula that you can probably run iteratively
06:40:35op_mul:hm, they don't resign every nonce, just every 64 nonces.
06:40:47tacotime_:oh, that's weird
06:42:14tacotime_:i think the padding thing is probably not doing what the author thinks it does, but the super simple non outsourceable puzzle might be a neat idea if no one can figure out how to break it
06:42:16op_mul:* op_mul rolls eyes
06:42:24tacotime_:i keep feeling like it should be obvious and i'm missing something
06:42:27op_mul:of course. it's based on darkcoin. that's why it's full of nonsense.
06:43:06tacotime_:could be worse. cryptonite's code is a pretty confusing trainwreck.
06:43:23op_mul:yeah. want to know why I don't run it?
06:43:35fluffypony:well its better now, the refactored blockchainDB class is amazing compared to the uncommented crap we had before
06:43:48op_mul:well. just the code scares me. '
06:43:57tacotime_:fluffypony: not us, i mean the mini blockchain thing
06:44:09tacotime_:that decided to use the same name as our hashing algo
06:44:18tacotime_:op_mul: ah
06:44:26fluffypony:oh yes
06:44:28tacotime_:i'm surprised it even runs
06:44:42op_mul:that they went down the path of "M7" proof of work is just nuts.
06:45:17op_mul:nesting hashes is too common, lets *multiply* them for super secure hashing.
06:45:51tacotime_:lol. xor 10000x for enhanced s3cur1ty
06:47:26fluffypony:I'll never understand this obsession with chaining hashes
06:47:55fluffypony:I read a comment the other day espousing Darkcoin's PoW as being "low power"
06:48:09tacotime_:fluffypony: everyone is determined to see how long it takes for someone to make an asic with an instruction cache
06:48:09fluffypony:heaven forbid you point out that "low power" == "not running at full efficiency"
06:48:33fluffypony:* fluffypony already has one
07:00:01op_mul:op_mul is now known as op_yiff
07:01:27op_yiff:op_yiff is now known as op_mul
07:02:32bosma_:bosma_ is now known as bosma
09:05:15wolfe.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
09:05:15wolfe.freenode.net:Users on #bitcoin-wizards: andy-logbot erasmospunk damethos delll paveljanik coiner bosma hashtag_ Mably PRab_ hktud0 fanquake TheSeven GAit zooko ryanxcharles NewLiberty Emcy v3Rve Dr-G2 p15 justanotheruser hashtag ebfull spinza booly-yam-5194__ Guest32269 Aquent grandmaster MoALTz Hunger- jgarzik imposter mortale [d__d] koshii_ platinuum jbenet mappum Graftec devrandom [\\\] maaku Luke-Jr Dyaheon PaulCapestany kinlo andytoshi gwillen gnusha burcin a5m0 Fistful_of_Coins
09:05:15wolfe.freenode.net:Users on #bitcoin-wizards: jcorgan Anduck btcdrak sneak wumpus BrainOverfl0w hguux_ yoleaux BigBitz midnightmagic lnovy sdaftuar tromp_ SubCreative deego warptangent TD-Linux NikolaiToryzin d9b4bef9 jaromil Starduster_ berndj crescend1 Taek azariah eric BlueMatt go1111111 livegnik isis asoltys_ LarsLarsen brand0 dasource Krellan pigeons catlasshrugged fluffypony kanzure heath poggy lclc_bnc dansmith_btc petertodd espes__ Keefe JonTitor mr_burdell sl01 yrashk fenn Adrian_G
09:05:15wolfe.freenode.net:Users on #bitcoin-wizards: nickler_ throughnothing helo Graet brad___ harrow` coryfields_ wiz cryptowest earlz optimator_ MRL-Relay comboy_ Iriez phedny bbrittain HM2 CryptOprah Muis michagogo Apocalyptic so nanotube lechuga_ gribble phantomcircuit ahmed_ otoburb forrestv warren hollandais davout stonecoldpat wizkid057 gavinandresen ajweiss ryan-c waxwing Oizopower dgenr8 null_radix epscy luny kumavis artifexd Alanius Xzibit17 @ChanServ grubles iddo nsh cfields huseby
09:05:15wolfe.freenode.net:Users on #bitcoin-wizards: starsoccer smooth nuke1989 EasyAt samson_ Meeh bepo sipa copumpkin thrasher` PFate btc___ nick1234abcd__ catcow amiller jaekwon DoctorBTC s1w mkarrer c0rw1n xabbix le_killer roasbeef_ qwopqwop_ tromp__ tacotime_ gmaxwell Eliel Cory morcos_ K1773R BananaLotus
09:33:52fanquake_:fanquake_ is now known as fanquake
09:34:56lclc_bnc:lclc_bnc is now known as lclc
10:26:13lclc:lclc is now known as lclc_bnc
11:05:38lclc_bnc:lclc_bnc is now known as lclc
11:46:06Algar:Algar has left #bitcoin-wizards
12:41:15lclc:lclc is now known as lclc_bnc
13:06:45lclc_bnc:lclc_bnc is now known as lclc
14:23:25lclc:lclc is now known as lclc_bnc
15:08:29kanzure:"Large information processing objects have some serious limitations due to signal delays and heat production." http://aleph.se/andart2/megascale/just-how-efficient-can-a-jupiter-brain-be/
15:09:55_meta:_meta has left #bitcoin-wizards
15:17:53[46bit]:Hi. kanzure invited me.
15:20:01lclc_bnc:lclc_bnc is now known as lclc
16:15:12andytoshi:rusty: alts.pdf was supposed to be a "comprehensive description of all the mistakes made in altcoin" :) and this is still the plan ... but there are so many! and a lot of the new consensus stuff is too technical to make it worth analyzing
16:18:36andytoshi:plus i feel that i've written all that i need to on consensus (though i may have to add an annendum discussing "long range attacks" to the proof-of-stake stuff :/ this distinction occured to me when writing and i dismissed it because it didn't actually solve anything, but now it's been "invented" by vitalik or somebody and it's the most common thing i "didn't address")
16:20:48instagibbs:andytoshi: please please please address the "well software is social, so why not choosing forks?" thing. Both Vitalik and Bytemaster are using this to address long range attacks of PoS
16:22:59justanotheruser:instagibbs: how do you choose a fork?
16:23:14instagibbs:justanotheruser: I use PoW.... ;)
16:23:25kanzure:right... i think there needs to be a much stronger section about "it's okay if you are not interested in byzantine agreement and consensus, here's a wonderful list of centralized stuff from you to pick from"
16:23:33instagibbs:kanzure: exactky
16:23:44kanzure:"You can achieve many orders of magnitude of performance by using centralized solutions. Many PoS implementations are unnecessary given the existence of relational databases."
16:23:46justanotheruser:instagibbs: sorry, I thought you were a PoSer
16:23:53gavinandresen:justanotheruser: you trust the fork that the exchange or merchant processor that you use trust. Because you want to sell or spend your coins
16:23:55kanzure:like, it is wrong to expect your readers to be aware of this
16:24:11instagibbs:gavinandresen: Well literally people will just use BC.info's fork
16:24:14instagibbs:or whatever
16:24:20andytoshi:sure, but idgaf about any of that. i'd like to talk about ripple/stellar too for that matter but i've never taken the time to learn how that stuff is purported to work
16:24:24justanotheruser:gavinandresen: For Walmartcoin?
16:24:38gavinandresen:Use Walmartcoin and get 10% off!
16:24:41kanzure:andytoshi: the reason why you should care is because otherwise people will continue to apply inappropriate arguments to your document
16:24:43instagibbs:I can't believe Vit is peddling such garbage. I honestly am not sure he thinks it works
16:24:56kanzure:andytoshi: redirecting them to something else is a good and honest way to deal with their totally wrong criticism
16:25:12kanzure:andytoshi: otherwise you will be deflecting "but honesty!!!!" for the next 1,000 years of your life
16:25:24andytoshi:kanzure: i'll think about it. itsm they are being paid to shill and i'm not, and them applying inappropriate arguments feels like deliberate dishonesty on their part
16:25:45andytoshi:and i don't see that i can counterargue "deliberate funded dishonesty" no matter what i write
16:25:47instagibbs:these systems will immediately centralize even without the presence of an attacker. That's the thing that's making me rip my hair out
16:26:11justanotheruser:instagibbs: I think he thinks it works. I've talked to him on reddit and he has some ideas that demonstrate a complete lack of understanding of PoW. For example, he wanted a deterministically generated hashing algorithm.
16:26:37kanzure:andytoshi: they may be dishonest, but they are probably also widely ignorant of the existence of alternative implementations and solutions
16:26:58kanzure:andytoshi: literally nobody has written down "Hey databases exist" so it is easy to see how that ignorance can exist here
16:27:06instagibbs:Anyways, it really needs to be rebuffed in an obvious manner. Vitalik's recent blog post is always posted as the "rebuttal" to PoS criticism.
16:27:12kanzure:andytoshi: which might also present itself as dishonesty. but perhaps i am just optimistic.
16:27:20justanotheruser:... he also suggested that individuals include hashcash with their tx instead of a fee dubbing it "TaPoW"
16:27:25andytoshi:btw there is a standing offer to -wizards (the subset that i know, which is everyone speaking now at least) that if anyone wants commit access to the alts.pdf repo (it is LaTeX source) i will give it to them
16:27:40kanzure:i'll take that
16:27:54andytoshi:kk one sec kanzure i'll pm
16:27:56instagibbs:justanotheruser: boy it would be really nice if there was a way to store up hashcash for future use... hmmmmmmmm
16:28:23andytoshi:instagibbs: my current response is "what is the actual counterexample to the NaS claim" and the response is always "uhhh i didn't read pos.pdf"
16:28:36kanzure:the response is "vitalik read it for me and posted this blog post"
16:28:41instagibbs:hehe true
16:28:47instagibbs:kanzure: +1
16:29:09andytoshi:instagibbs: "it's too technical" "you're just protecting your bitcoins" (wtf) "you're a shill for the core devs" etc.
16:29:18andytoshi:i do wanna make these fixes, it's just a low priority because of these things
16:29:47kanzure:they say you're a shill because they literally think that a blockchain is the only possible implementation for storing data
16:29:49justanotheruser:andytoshi: "the paper doesn't specifically mention this implementation of PoS"
16:30:17kanzure:so from that perspective it is easy to see how they might think that: it is intuitively obvious that a blockchain can be relaxed into other consistent datastores under centralization. so from their perspective, you are totally a shill.
16:30:30kanzure:but this is largley from ignorance, because nobody (including vitalik) has an incentive to tell them aobut databases and such (except you, now)
16:30:42andytoshi:meanwhile the harm i perceive from these guys is actually pretty low. naive PoS has not been proposed since i put out the paper and the new stuff sounds (correctly) like technobabble to the public, who won't trust it
16:31:03sipa:andytoshi: public trusts technobabble
16:31:14kanzure:alright this is decending into pessimism
16:31:16jcorgan:andytoshi: the public sends their bitcoin to pretty websites, they seem to believe anything
16:31:24kanzure:circlejerk that way ---->
16:31:36justanotheruser:hey guys
16:31:40kanzure:if you truly believed that then you wouldn't have written any paper at all
16:31:53kanzure:and it fails to explain the existence of any thoughtful individual ever
16:32:35andytoshi:reddit is not "the public", the public are people i meet in public who ask how bitcoin works and go "ehhhh why aren't the banks using it if this actually works?" and clearly do not trust my claims that i can protect their money with technical means
16:33:11kanzure:if that was true, then why would they think money was a good idea?
16:33:37instagibbs:kanzure: wasnt trying to circlejerk myself. I'm struggling to decide whether writing up a "response" to this new brand of PoS is worth it or just redundant
16:33:43andytoshi:i wrote the paper because people were in -here- arguing PoS at lot. that doesn't happen anymore. now the adversary is vitalik et al, but they are arguing on blogs and stuff, out of my face
16:33:56kanzure:instagibbs: a general response to systems that have broken consensus is totally necessary and nobody has done it yet
16:34:09andytoshi:instagibbs: it's definitely worth it, but i don't have the time for it
16:34:24kanzure:you don't need to respond to those particular arguments from vitalik's blog post (because they are nonsense)
16:34:27jcorgan:kanzure: pessimism because bitcoin is actually not that hard to understand for an honestly motivated individual willing to learn. <-- not many
16:34:37kanzure:you do need to respond to "broken consensus is better than centralization" or something
16:35:08kanzure:or "broken consensus is better than working consensus" is also a thing oyu need to respond to
16:35:34kanzure:sorry, i forget the exact formulation of their argument, it's something like "working consensus doesn't matter, and things that are centralized and pretending to be decentralized are clearly superior"
16:35:54instagibbs:kanzure: indeed. I think a much more general post like andytoshi said would be more useful. I'm not qualified to make it though
16:37:10justanotheruser:Can't the response just be "Centralization allows you to make and accept payments by trusting a party. Broken consensus means you can't be sure you were paid no matter who you trust"
16:37:37instagibbs:Consensus will be broken AND/OR centralized under these schemes. It's a mashing up of issues.
16:38:16gavinandresen:I DO think Vitalik’s “exponentially subjective scoring” concept might be useful for preventing surprise 51% attacks: https://gist.github.com/gavinandresen/630d4a6c24ac6144482a <— WARNING: partially baked thoughts....
16:38:32kanzure:yes but you have been known to propose totally broken stuff before
16:38:38kanzure:well, so have i
16:38:46kanzure:that's not a very interesting observation for me to make hehe
16:40:21justanotheruser:gavinandresen: so instead of reorging we just break consensus?
16:40:22kanzure:"Network-wide splits lasting more than a few tens of minutes never happen" hm how would a node observe whether or not something is network-wide
16:41:19instagibbs:While the long re-org WARNING may make sense, no reason to touch consensus rules
16:41:42instagibbs:software still achieved consensus even if you as a user is confused as hell and know there's malicious forking going on
16:42:54gavinandresen:justanotheruser: consensus is not broken for continuously connected nodes— they would all refuse to reorg onto the surprise chain (and warn loudly, in case there WAS an actualy network split)
16:43:49instagibbs:they'd have to know they were continuously running on the "true" chain, whatever that means
16:43:50gavinandresen:Basically, using the well-connected graph of nodes as another piece of consensus information.
16:44:30gavinandresen:instagibbs: sure. If you are Sybil’ed away from the real chain then all bets are off. But that is true no matter what.
16:45:31lclc:lclc is now known as lclc_bnc
16:45:47kanzure:sybil is not a bad thing in bitcoinland
16:45:49justanotheruser:gavinandresen: I'm not a networking expert by any means, but I think this would allow 51% + sybil to break consensus.
16:46:22instagibbs:but once we "break out" we realize the "true" state of the ledger. In other case you're lost forever (modulo picking forks by hand).
16:46:24gavinandresen:justanotheruser: if you have 51% you have consensus anyway
16:47:33sipa:this means a temporary 51% could make the network stuck on a fork
16:47:43sipa:which makes it equivalent to a permanent 51%
16:47:47justanotheruser:sipa: if you sustain it anyways
16:47:52justanotheruser:gavinandresen: **
16:48:03sipa:and yes, nodes will complain, which is the useful part
16:48:15instagibbs:Bottom line this gains you almost nothing and can break consensus. Sudden emerging forks means you need to be careful with your funds(true regardless of this change or not).
16:48:33sipa:but you can accomplish the same thing with wallets that complain and go into a emergency mode when seeing a long fork
16:48:45instagibbs:sipa: +1
16:48:59gavinandresen:sipa: that’s basically what I’m suggesting
16:49:21gavinandresen:sipa: .. I just think miners should complain and refuse to switch to the surprise long fork, too.
16:49:30sipa:no, you're suggesting changing the best-chain picking rule into something that is not consistent anymore (what chain you choose depends on which other chains you've seen)
16:49:59sipa:the warning part is useful, but is orthogonal to this
16:50:17gavinandresen:yes, but only if you believe you are well-connected to the network. Meaning you’ve been seeing N days of blocks with the expected Poisson distribution given current hash rate.
16:50:28justanotheruser:gavinandresen: miners not going to an attacking fork may be interesting since at least consensus isn't broken if they win
16:51:11kanzure:requiring knowledge about previous seen chains will make bitcoin sybil-incompatible i think
16:51:25kanzure:at the moment it is mostly sybil-compatible or sybil-compliant (i don't know the right term)
16:51:57gavinandresen:kanzure: yes, that is a risk that needs Deep Thought. I ran this by gmaxwell and his concern was that it increases the incentive to Sybil
16:52:07kanzure:it's not a risk, it looks obvious
16:52:25sipa:yes, i'm really very hesitant about changing the clear and nicely-analysable "accept the longest valid chain you know about" to "accept the longest valid chain you know about, except those which are incompatible with something you've seen in the past"
16:52:27gavinandresen:I’m not sure I see the risk, though. If you Sybil a miner, then they should notice the drop in hash rate and warn
16:52:33instagibbs:Going slightly -dev: what does Core do today under a large reorg?
16:52:44sipa:instagibbs: it should reorg
16:52:44gavinandresen:Actually, Sybil any full node and they should notice sudden drop in hash rate and alert
16:52:53sipa:gavinandresen: no doubt about that
16:52:56instagibbs:sipa: does a warning light go off or something
16:53:08gavinandresen:sipa: and yet that code has never been written…. (it’s on my short TODO list)
16:53:14kanzure:sybil is not just about sybiling individual nodes, i think
16:53:19instagibbs:or do we assume people are building analytical layers on top, for their own warning
16:53:37gavinandresen:kanzure: if you can Sybil the whole network… well then double-spending is easy!
16:53:46kinlo:reorgs are part of the normal flow, so unless they are "large"... which is an arbitrary definition
16:53:47sipa:instagibbs: it alerts when there are >7 long forks, afaik
16:53:57sipa:that code needs a good look and tests, though
16:54:08sipa:it can probably be improved significantly now with headers-first
16:54:13lclc_bnc:lclc_bnc is now known as lclc
16:54:21kanzure:gavinandresen: providing false bootstrapping data (somehow) would be a trivial way of attacking more than just an individual node
16:54:24kanzure:in that scheme
16:54:35zooko:* zooko reads https://gist.github.com/gavinandresen/630d4a6c24ac6144482a
16:54:40yoleaux:kanzure: Sorry, that command (.title) crashed.
16:54:41kanzure:oh right
16:54:43kanzure:ame link
16:54:53instagibbs:kinlo: i think user-defined levels makes most sense.
16:55:02sipa:zooko: thanks for your comments on DERSIG; i'll respond soon, but travelling today
16:55:07gavinandresen:kanzure: I don’t follow how false bootstrapping data would help anything.
16:55:11kanzure:it wouldn't help!
16:55:24gavinandresen:kanzure: you will get the real chain assuming you connect to at least one ‘real’ node
16:55:27kanzure:but since a node has seen those other blocks, it would therefore not correctly reorg to the greater network
16:55:28kinlo:instagibbs: dunno, a re-org is after the facts, you should know beforehand that a large reorg is going to happen
16:55:43kanzure:*to the actual blockchain
16:55:56zooko:sipa: sure thing! I commented because gmaxwell requested comments in this channel.
16:55:56kanzure:ah i might be confused about the actual data provided by bootstrap.dat
16:55:57instagibbs:kinlo: assuming there is a lot of dark hashing power out there or a partition you have no clue
16:56:05gavinandresen:kanzure: … and any blocks from a bootstrap source would be in the “I have no idea when these first appeared on the network” timestamp
16:56:31zooko:"Assuming the Bitcoin networks is densely, redundantly connected (is this true? I'm pretty certain it is, would be good to see research)" ← I think amiller might be working on something like that.
16:56:40kinlo:instagibbs: true, but exactly that is the only thing you want to know, no?
16:56:47gavinandresen:zooko: yes, I need to update the gist, amiller gave me comments a few weeks ago
16:56:55dgenr8:why are we worried about a "surprise 51% attack" in the first place
16:56:57kinlo:the moment you're doing that large reorg, its usually already too late :)
16:57:32instagibbs:kinlo: i mean a really long KNOWN fork means battling miners or something.
16:57:43instagibbs:alerts for all these situations is impt
16:57:46gavinandresen:dgenr8: I’m not really worried— but it is a ‘tail risk’ that I think we should mitigate. A 10,000-block-long re-org would be a good way for a State Actor to destroy confidence in Bitcoin
16:58:23dgenr8:for 2 weeks ... with the usual limitations on what a 51% attacker can accomplish ... plus possible wetware intervention
16:58:33instagibbs:kinlo: True but you probably need to stop business anyhoo! stop the bleeding
16:59:07zooko:gavinandresen: https://gist.github.com/gavinandresen/630d4a6c24ac6144482a sounds very like the defense that I proposed to you on a videochat a while back.
16:59:26gavinandresen:IF this is a good idea (many of my half-baked ideas turn out to be stupid), then it will be a “never happens because attacker knows it won’t work” thing
16:59:28zooko:Although https://gist.github.com/gavinandresen/630d4a6c24ac6144482a talks about it in totally different terms -- in terms of network connectivity, and what I proposed to you talked about it interms of a PKI-like thing.
16:59:44zooko:But, I think both of those approaches might boil down to almost or exactly the same protocol. So I approve. ☺
16:59:52gavinandresen:zooko: cool
17:00:10zooko:gavinandresen: Yeah, that's also what you said about my idea on the videochat -- if we did it and it worked then it would never get exercised. ;-)
17:05:06dgenr8:wonering how often that +- 300% difficulty cap has been triggered
17:14:33dgenr8:+300% / -75%. sorry, it was just hanging out there
17:19:38lclc:lclc is now known as lclc_bnc
17:21:39midnightmagic:gavinandresen: the contrapositive of your logic is that when the network is temporarily attacked, we are accepting the attacker's blocks permanently.
17:22:08lclc_bnc:lclc_bnc is now known as lclc
17:22:22midnightmagic:or semi-permanently, presuming there's some kind of recovery protocol to prevent a permanent cut in the consensus graph
17:23:45zooko:I favor a "emergency circuit breaker" design, where if something is detected that *could* be a massive catastrophe, then the software simply goes into refusenik mode.
17:24:10zooko:No further transactions/blocks are processed until a human -- not a computer -- decides what to do about the situation.
17:24:11midnightmagic:autonomous nodes could no longer be presumed to exist
17:24:38zooko:The downside of the emergency circuit breaker design should be limited to a temporary outage of service, which can hopefully occur never or only under very rare circumstances,
17:24:41instagibbs:zooko: that should always be the case, yes. Doesn't touch consensus though
17:24:58zooko:and the upside is that we don't have to try to write an algorithm today to handle attacks that will come out tomorrow. :-)
17:24:59instagibbs:human based consensus is broken until we phone each other up or whatever
17:25:29zooko:I'm planning to implement this in one of my own projects, with a very simple rule:
17:25:50zooko:If I've ever seen a reorg deeper than 6 blocks, since I started, then I simply refuse to make any further moves until my human comes and tells me what to do.
17:26:34instagibbs:"moves" meaning transactions/etc?
17:26:52kanzure:why would a human be better at deciding that than pre-existing reorg rules
17:27:32zooko:instagibbs: yes, anything that could commit you, or that could be used against you.
17:27:41midnightmagic:and as instagibbs says, what if humans decide differently because a human is not well-connected to the consensus graph
17:27:48zooko:instagibbs: basically, don't do anything except possibly monitor the situation in order to log and to report to your human what you see.
17:28:18midnightmagic:then we're offloading another future decision point
17:28:34instagibbs:we can have machine consensus and still have human consensus about Bitcoin shattered.
17:28:39instagibbs:that's ok
17:29:21op_mul:kanzure: if you are serious about updating altcoins.pdf the proof of storage one might be a fun one to add under proof of stake. it suffers very similar issues (stake grinding, kinda) but it's not mentioned anywhere outside of this channel as far as I can find.
17:30:14dgenr8:after you reject a specific reorg, what next? there's still a load of dark hash power out there ready to mess with you
17:30:14instagibbs:op_mul: if you point me to sources id appreciate.
17:30:55midnightmagic:dgenr8: and the degenerate form of a 51% attack remains, and what has the effort been worth?
17:32:14op_mul:instagibbs: there's none, really other than reading the burstcoin whitepaper. the general gist is that you can grind block solutions until you find a chain that suits you, and you don't have to do any proof of work in order to be able to do this.
17:32:38instagibbs:Regardless any sort of consensus screwing is completely unnecessary because you would *still* have to cease operations in the presence of a seen large re-org.
17:32:50instagibbs:or react to it
17:34:10instagibbs:op_mul: i dont mind writing but kind of groaning at the idea of reading another "white paper"
17:34:44zooko:dgenr8: that's a really good question.
17:35:14op_mul:I find the whole 'what to do in a massive reorg' thing to be a bit distasteful. it's what proof of stake altcoins use to "fix" problems in their lack of understanding. NXT and a few others simply refuse to reorganise deeper than X blocks.
17:35:34nsh:there are only specific reorgs from a subjective (node's) point-of-view, right?
17:35:45kanzure:op_mul: no i'm not going to update alts.pdf at the moment or any time soon, although i reserve the right to spontaneously decide to fix something or push a branch
17:35:57op_mul:kanzure: noted.
17:36:20op_mul:instagibbs: just read the announcement thread. it gives you all you need to know in order to attack their consensus model.
17:36:25justanotheruser:op_mul: I'm more concerned with how they obscure the issue by using new words. It's called "cementing"
17:36:40kanzure:they can call it whatever they want
17:36:54kanzure:they are vulnerable and that's up to them
17:37:27op_mul:it doesn't matter so long as you can get people believing that you're not.
17:37:29instagibbs:op_mul: In consensus rules, totally agree that nothing should be done. All machines not completely sybiled should be agreeing.
17:37:31dgenr8:the security assumption is that friendly hash power has come on line first; it's worked so far and i don't think we have a better idea yet
17:37:34justanotheruser:well it's a tool to trick people mostly
17:37:51instagibbs:human layer is where the ugly hacks happen
17:38:37op_mul:yes. at this point in time you don't need to mine blocks to double spend against someone. you just need to convince blockchain.info to lie to people and then you're home free. ugly human hacks.
17:39:05instagibbs:heh. that too!
17:39:31instagibbs:praise be to the gods that there are lower hanging fruit to attack than core consensus mechanisms....
17:40:42op_mul:a large number of companies actually use blockchain.info's wallet as their backend.
17:40:51kanzure:op_mul: don't remind me :/
17:40:54kanzure:it is painful
17:41:28justanotheruser:op_mul: what big names?
17:41:29op_mul:they have a JSON-RPC emulation layer where the user passes their wallet ID and passport, and blockchain.info decodes it server side. as far as I can tell the reason their KDF was so piss poor was to reduce the load on the server doing wallet decryption.
17:41:30midnightmagic:i think it would make the blockchain's expansion into space also quite a bit more fragile
17:41:34instagibbs:op_mul: .... what
17:42:04kanzure:so, i think that the misinformation can be reduced if you explain to users that decentralizaiton is not the only feasible implementation for maintaining a ledger, and then tell them about databases or something
17:42:10kanzure:instagibbs seems to agree partly?
17:42:19kanzure:whta would be the other necessary conditions for this sort of explanation to reduce misinformation
17:42:22kanzure:or disinformation for that matter
17:42:28kanzure:er, by conditions i mean content
17:43:05instagibbs:Yes. possibly have to mention the obvious like "phoning a friend isn't distributed consensus"
17:43:24kanzure:right... and there's nothing "wrong" with phoning a friend, outside the context of distributed consensus.
17:43:40kanzure:if they want to phone friends then they are certainly welcome to, but they shouldn't conflate that with the novel contribution that bitcoin offers.
17:43:41instagibbs:is thre a nice solid def of consensus in the explanation
17:43:59kanzure:there's one in alts.pdf
17:44:01kanzure:at least
17:44:21instagibbs:see maybe you're right. if it's there it means people aren't actually reading it
17:44:30instagibbs:let me skim again
17:44:50kanzure:it mentions that definition ,but it does not really redirect people to alternatives if they are not interested in distributed consensus
17:45:16kanzure:i mean, ideally it should not be the goal of a document like alts.pdf to inform people about non-distributed-consensus systems, but in this case it seems to be necessary due to the huge amounts of disinformation floating around....
17:45:25nsh:incidentally, has anyone ran with the conceptualization of bitcoin consensus as a dynamic-membership multi-party signature scheme? or the latter concept in isolation?
17:46:03nsh:seemingly not, per google
17:46:49instagibbs:i don't really see a real clear-cut def of distributed consensus in the doc. Just references to it.
17:46:57instagibbs:maybe im missing it
17:47:11kanzure:page 8 section 6
17:47:16instagibbs:oh nvm
17:47:20instagibbs:got it
17:47:55kanzure:there might also be some weird confusion around the meaning of "agreement" heh
17:48:18instagibbs:perhaps. Agreemnet in the computer sense not human :)
17:48:23instagibbs:state of the machine
17:49:35instagibbs:Ok, "lack of identities" is the assumption being broken for these schemes.
17:50:15kanzure:although i like the term "agreement" it should probably be elaborated to refer to things like consistency and equivalents
17:51:09op_mul:instagibbs: people still try to do "voting" systems with bitcoin.
17:51:34op_mul:and they never realise why it's as good of an idea as a egg powered car.
17:51:35instagibbs:Found the spot to point to in the alt.pdf. You can say "If you don't want distributed consensus, fine, there are cheaper DBs out there"
17:51:56instagibbs:op_mul: well yes, blockchain technology uber alles
17:52:08op_mul:> muh sybil
17:52:12instagibbs:it runs my toaster now too
17:52:18nsh:* nsh imagines Uber adopting blockchains
17:54:16op_mul:a while ago I started tracking which connections were made to my nodes all from the same peer. the original idea was to see if I could actually sybil someone just by chance.
17:54:45op_mul:turns out the problem with that idea is that everyond and their dog is trying to connect to every node in the network.
17:56:24nsh:for useful values of 'problem' :)
17:56:36op_mul:high water mark for SPV nodes is two, if anybody was curious.
17:56:56nsh:how do you mean? most connected at any time?
17:57:12op_mul:one SPV client connected to two of my nodes at once.
17:57:13instagibbs:meaning an spv node connected to two of your nodes?
17:57:20instagibbs:oops scrolled too late
17:58:30op_mul:sort of no point in that, worst I could do to an SPV client is tell them there's no blocks. I can't mine an invalid block at the top of a hat (and attacking people's nodes isn't really the game, just for interest)
18:26:35lclc:lclc is now known as lclc_bnc
18:44:46dansmith_btc:is bitcoin script flexible enough to where a coin can be spent only if two signatures for the same output are provided. (motivation: preventing double-spends)
18:45:10sipa:that's just 2-of-2 multisig
18:45:26sipa:and it does not prevent double spending
18:48:04op_mul:sipa: well, it can sort of assure you that a double spend is improbable in the case of greenaddress.it.
18:48:06dansmith_btc:right. In the context of impulse operator - in order to prevent him from doublespending, what if he is required to make such a security deposit spendable when his 2 sigs are presented.
18:48:27op_mul:dansmith_btc: look into how greenaddress.it works.
18:53:02gmaxwell:op_mul: he's asking about a bonded operation; which we cannot currently do. It's not clear how to make it that useful though; because an attacker can effectively doublespend his bond by doublespending many people at once.
18:53:18gmaxwell:Also he can collect his own bond (after all, he's in a privledged position to know when he has cheated. :) )
18:53:45gmaxwell:op_mul: the idea he's talking about is making a scriptpubkey which could be redeemed by _anyone_ presenting any to signatures with a particular pubkey.
18:53:53gmaxwell:s/any to/any two/
18:54:36op_mul:that would suck if you wanted to double spend with a higher fee.
18:54:47amiller:you could make the bond pay out 0.1x to whoever presents it and 0.9x of it is deleted forever
18:55:06amiller:it would also be nice to be able to take the bond collateral back after some time but you can't do that without checklocktimeverify
18:55:45op_mul:I really hope people don't try and have wallets see stuff with checktimelockverify as IsMine().
18:58:20andytoshi:nsh: adam and i were going to write a paper elaborating the DMMS stuff. there is no eta on us starting :)
18:59:41andytoshi:in particular i want the bytecoin paper done and out before starting that, and there isn't an eta on that either (but there is progress, the main block is right now i need to spend a couple hours grinding algebra)
19:00:00dansmith_btc:gmaxwell, is it useful to have the bond spendable only to a provably unexisting address?
19:00:10gmaxwell:op_mul: with powerful enough script you could exclude 'honest' double spends.
19:01:08gmaxwell:dansmith_btc: well where this has been discussed before we'd talked about a portion of the bond being destroyed.. which helps but doesn't address the unbounded doublespending of it.
19:01:12kanzure:'honest double spends' certainly exist (giving someone a second transaction because a reorg was experienced that mutated the input txid)
19:01:28kanzure:wait, disregard
19:01:35kanzure:for many reasons
19:02:00gmaxwell:e.g. say I have a 10 BTC bond that people respect for up to 1 BTC instant payments... but okay, fine, I just make 100 concurrent theft transactions; doesn't matter if I lost the bond...
19:02:40gmaxwell:so while useful, the usefulness is perhaps bounded. There is also an issue of lack of incentive to report: miners will likely take any payout from canceling the bond... so if you're not a miner why report it?
19:04:18dansmith_btc:maybe 90% goes to the black hole and 10% goes to whoever reported - there's the incentive.
19:04:34andytoshi:in some particular cases we can maybe use a NIZK to report which would not give a miner enough info to steal (though i cannot think of one off the top of my head except if you have the double-spender's keys)
19:04:38gmaxwell:dansmith_btc: goes to the miner, not the reporter. You cannot make it go to the reporter. :(
19:04:46gmaxwell:right, not without a NIZK.
19:05:04gmaxwell:Trying to avoid brews involving ground unicorn bones.
19:05:35gmaxwell:NIZK nicely solves that one still leaves you with the double-spends.
19:10:26dansmith_btc:so, I take it, bitcoin script is not flexible to where the reporter (not the miner) can present 2 sigs spending the same output + his reward address (the reward for reporting the doublespend) ?
19:10:33GAit:unrelated to the above but you may find interesting the suddent p2sh spike and drop http://i.imgur.com/8usxslN.png
19:11:13andytoshi:dansmith_btc: that's correct, and it's not clear that it's even -possible- to do this so that the miner can't steal
19:11:52kanzure:perhaps that spike was bitstamp transferring to p2sh
19:11:59dansmith_btc:true, the miner could steal but that'd be a diff disussion
19:12:28GAit:kanzure: i think it was sarutobi
19:12:36nsh:andytoshi, i look forward to it whenever it manifests :)
19:14:06dgenr8:bitcoin makes successful respends increasingly unlikely with time. it would be some trick to make that serve as the foundation for a system instantly secure against them.
19:15:25GAit:dgenr8: is that true? i thought that miners having different policies makes it more likely not less likely
19:16:15nsh:it always gets harder to double-spend, as the total PoW on competing blockchain tips is monotonically increasing
19:17:20nsh:so the sum of work to maintain an alternate history has to be greater than the sum of work of the part of the network with the 'legitimate' spend
19:17:53GAit:sorry i thought we were talking about unconfirmed double spends not confirmed
19:18:55gmaxwell:dansmith_btc: thats not a script question: the miner can steal in that case because the presentation isn't zero knoweldge. If you show me two spends then _I_ know two spends. :)
19:32:39zooko:BTW, I think that a bond-against-multispend combined with PoW can actually achieve quantitatively better defense than pure PoW.
19:32:51zooko:But, I don't know how to fit it into Bitcoin, and I'm not currently working on it.
19:35:22gmaxwell:there isn't anything complicated to do to fit it into bitcoin; just requires a somewhat more expressive Script. That it might be somewhat better isn't the important question; the important one is if it's enough better than anyone would really care to use it.
19:36:38gmaxwell:Adoption of co-signer based anti-doublespend is very low right now; which suggests to me that the interest isn't there; but it's hard to say.
19:39:13zooko:There's one particular detail about how much better it could be that you missed or glossed over above --
19:39:52zooko:unless I'm misremembering, anti-double-spend-bond combined with PoW can make it so that to multispend 100 times, you would have to do 100 PoW's, e.g. mine 100 blocks.
19:40:11zooko:I.e., if your recipient requires at least one confirmation, in addition to requiring an anti-multi-spend-bond.
19:40:24gmaxwell:oh I'd forgotten the line of thinking of boosting single confirm to prevent the double spending.
19:40:36zooko:That was Nikita Borisov's contribution to my idea.
19:40:44zooko:IIRC, which is questionable. ☺
19:41:08zooko:But I agree with you that the bottom line is, it isn't clear if it is important enough.
19:41:22zooko:In particular, *I'm* currently treating it as insufficiently important, meaning I'm not working on it.
19:41:29gmaxwell:Indeed, it's a fair point. Most of the interest in that space is zero confirms; but you're right that it's a big improvement at one confirm. (and then not so much of an improvement at .. say.. 8 confirms)
19:41:38zooko:But I would be happy if someone else published the idea, implemented it, etc.
19:41:52zooko:gmaxwell: Yeah! I think that was Nikita's contribution. It's pretty cool.
19:42:29zooko:It sort of suggests you could have 1-confirm transactions with a bond, with perhaps comparable safety to the current, 6-confirm, 0-bond txns.
19:42:39gmaxwell:so some context there is that the complaint I made that the bond can be double spent is more or less untrue at one confirm... since double spending there would require making N simultaniously 1 confirm forks. Even if you can network isolate your victims (realistic e.g. for a non-network-connected spv vending machine), there is still a huge cost to scaling that attack.
19:42:52gmaxwell:(I'm just explaining more for the room)
19:52:56dgenr8:what is that idea? somehow reducing multiple-spends in a single block?
19:58:41dgenr8:greenaddress, impulse etc. have a huge adoption hurdle. it's hard enough getting businesses to adopt bitcoin itself.
20:01:13fluffypony:dgenr8: meh, that's like saying "how will businesses ever accept credit cards, they'll need to have a terminal at the shop and everything"
20:02:46dgenr8:okey dokey
20:03:02andytoshi:fluffypony: or maybe it's like getting chip-and-pin accepted in the US...even with visa/MC using their near-monopoly to push this and the fact that they have had working systems deployed for like 40 years, it's still a hard sell
20:06:34nsh:is this guy associated with sidechains thingumy, corporate nonsense, whatever it's called? https://fi.linkedin.com/in/joukosalonen
20:06:54nsh:Yurohs.com is building a global DAC ERP on top of blockchain. DAC refers to a metaphor - "Decentralized autonomous corporation" or "Distributed Autonomous Corporation" (check http://coinwiki.info/en/Decentralized_autonomous_corporation for details). "ERP" in this context includes a question: how does enterprise resource planning happen in the context of DACs / IoT and cruptocurrencies? Blockchain is one of the key elements in this. In enables dynamic mem
20:06:55nsh:bership, multiparty signature system, non-trust PoW & PoC structures, smart contracts, prediction market consensus based supply chains and networked accounting.
20:06:55nsh:Yurohs is in stealth "zero to one" mode, we do concept design, we test and we fail.
20:07:10nsh:seems to have read the paper at least
20:08:14maaku:love how "we fail!" is a selling point
20:09:45nsh:* nsh smiles
20:17:10fluffypony:andytoshi: you should come to South Africa, we've had chip-and-pin terminals in play for like 10+ years...I actually can't remember the last time I've seen a terminal that didn't have a keypad and a chip reader
20:20:50andytoshi:fluffypony: ditto in canada, actually :) for 5+ years anyway
20:21:20fluffypony:sometimes I think the USA just needs a hug and a pat on the back
20:23:10op_mul:fluffypony: most still accept swipe cards though. like SSL, there's an insecure fallback.
20:24:28fluffypony:op_mul: yes they do, I mean that I haven't seen any that are swipe-only
20:24:49andytoshi:op_mul: not in canada, very few will let you swipe (maybe the merchant can override this?)
20:24:59andytoshi:it says "PLEASE INSERT CHIP"
20:25:08op_mul:andytoshi: you have to fail the chip several time and then the machine will ask you to swipe instead.
20:25:48op_mul:I had a broken chip for a while and couldn't get it replaced. every payment I had to do a few fails of the chip, then I could swipe
20:25:50fluffypony:also if the card doesn't have a chip
20:25:56fluffypony:then it will accept a plain swipe
20:26:32op_mul:must be a market in the swipe data that says "I HAVE A CHIP TRY THAT FIRST"
20:29:39belcher_:belcher_ is now known as belcher
20:36:27rhadamanthus:rhadamanthus has left #bitcoin-wizards
21:40:26pigeons:i've been traveling to canada a lot the past several months and i've been able to swipe
21:45:24andytoshi:pigeons: you can definitely swipe US cards, i think op_mul is right that canadian ones have a marker in the magstripe data
21:47:05fluffypony:there are two components to it
21:47:17fluffypony:1. the mag-stripe can contain a flag that indicates it has a chip
21:47:31fluffypony:but 2. the reader will ignore that if it doesn't have a chip reader
21:47:34smooth:credit cards bootstraped by requiring almost no investment from the merchants. at low volume even an imprinter wasn't required they could just write the number on check
21:48:00smooth:from there everything was incremental though the card-and-pin increment in the us shows even that isn't always easy
21:48:05fluffypony:with the load shedding our national power agency has been having some merchants have been hauling out their imprinters again
21:48:34smooth:but a huge amount of network effect was built without pushing barriers on the adopters
22:07:19adam3us:pigeons: the chip n pin thing suffers from version roll back attack :) if u look up ross anderson card security they did some security paper on it, and its horrible. you can bypass the chip just by some simple mechanism (disable/opt out/tamper/cover with sticky tape ... something stupid), and the reader cant tell
22:07:49adam3us:pigeons: u maybe looking at second gen that even has a marker , that'd count as "innovation"; i see it still fails open though!
22:07:52adam3us:adam3us has left #bitcoin-wizards
22:57:35justanot1eruser:justanot1eruser is now known as justanotheruser
23:00:03justanot1eruser:justanot1eruser is now known as justanotheruser
23:11:03Pan0ram1x:Pan0ram1x is now known as Guest34424