| 00:11:48 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 00:13:15 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 01:11:22 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 03:38:23 | lechuga_: | gmaxwell: ack strictder |
| 03:47:28 | fanquake_: | fanquake_ is now known as fanquake |
| 03:59:19 | rusty: | 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:03 | fanquake_: | fanquake_ is now known as fanquake |
| 06:24:04 | op_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:28 | op_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:37 | nsh: | sounds pretty profound tbh |
| 06:27:09 | op_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:09 | nsh: | 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:50 | op_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:20 | tacotime_: | oh, speaking of which |
| 06:29:46 | tacotime_: | spreadcoin does a thing that tries to provide a non-outsourceable puzzle as opposed to regular header hashing |
| 06:30:01 | tacotime_: | where you have to fill the block with garbage, signed the entire thing, then hash it |
| 06:30:09 | tacotime_: | s/signed/sign |
| 06:30:25 | op_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:46 | tacotime_: | 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:49 | op_mul: | what happens if there's more than one key in the coinbase transaction? |
| 06:32:49 | tacotime_: | but i keep feeling like i'm not sure that works |
| 06:33:03 | tacotime_: | i think you can only have one key |
| 06:34:00 | op_mul: | it's possible they just didn't think of that. |
| 06:34:40 | tacotime_: | yeah. but in the event that that is true, i guess my question would be, could you make pools still? |
| 06:35:31 | op_mul: | on the face of it I don't see how you could |
| 06:36:19 | tacotime_: | it seems like such a simple modification that if it were to work, i imagine satoshi would have thought of it |
| 06:36:34 | op_mul: | why can't these altcoins ever fork from bitcoin core. this source is like. 0.6 vintage. |
| 06:37:27 | tacotime_: | 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:59 | op_mul: | return error("CheckSignature() : coinbase doesn't have exactly one output"); |
| 06:38:15 | tacotime_: | ah |
| 06:38:18 | tacotime_: | so they did think of it |
| 06:39:15 | tacotime_: | 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:35 | tacotime_: | which is just a recursive formula that you can probably run iteratively |
| 06:40:13 | tacotime_: | s/iteratively/imperatively |
| 06:40:35 | op_mul: | hm, they don't resign every nonce, just every 64 nonces. |
| 06:40:47 | tacotime_: | oh, that's weird |
| 06:42:14 | tacotime_: | 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:16 | op_mul: | * op_mul rolls eyes |
| 06:42:24 | tacotime_: | i keep feeling like it should be obvious and i'm missing something |
| 06:42:27 | op_mul: | of course. it's based on darkcoin. that's why it's full of nonsense. |
| 06:42:32 | tacotime_: | hahahaha |
| 06:43:06 | tacotime_: | could be worse. cryptonite's code is a pretty confusing trainwreck. |
| 06:43:23 | op_mul: | yeah. want to know why I don't run it? |
| 06:43:34 | tacotime_: | why? |
| 06:43:35 | fluffypony: | well its better now, the refactored blockchainDB class is amazing compared to the uncommented crap we had before |
| 06:43:48 | op_mul: | well. just the code scares me. ' |
| 06:43:57 | tacotime_: | fluffypony: not us, i mean the mini blockchain thing |
| 06:44:09 | tacotime_: | that decided to use the same name as our hashing algo |
| 06:44:18 | tacotime_: | op_mul: ah |
| 06:44:26 | fluffypony: | oh yes |
| 06:44:28 | tacotime_: | i'm surprised it even runs |
| 06:44:28 | fluffypony: | lol |
| 06:44:42 | op_mul: | that they went down the path of "M7" proof of work is just nuts. |
| 06:45:17 | op_mul: | nesting hashes is too common, lets *multiply* them for super secure hashing. |
| 06:45:51 | tacotime_: | lol. xor 10000x for enhanced s3cur1ty |
| 06:47:13 | fluffypony: | hah |
| 06:47:26 | fluffypony: | I'll never understand this obsession with chaining hashes |
| 06:47:55 | fluffypony: | I read a comment the other day espousing Darkcoin's PoW as being "low power" |
| 06:48:09 | tacotime_: | fluffypony: everyone is determined to see how long it takes for someone to make an asic with an instruction cache |
| 06:48:09 | fluffypony: | heaven forbid you point out that "low power" == "not running at full efficiency" |
| 06:48:33 | fluffypony: | * fluffypony already has one |
| 06:48:36 | fluffypony: | :-P |
| 07:00:01 | op_mul: | op_mul is now known as op_yiff |
| 07:01:27 | op_yiff: | op_yiff is now known as op_mul |
| 07:02:32 | bosma_: | bosma_ is now known as bosma |
| 09:05:15 | wolfe.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:15 | wolfe.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:15 | wolfe.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:15 | wolfe.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:15 | wolfe.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:52 | fanquake_: | fanquake_ is now known as fanquake |
| 09:34:56 | lclc_bnc: | lclc_bnc is now known as lclc |
| 10:26:13 | lclc: | lclc is now known as lclc_bnc |
| 11:05:38 | lclc_bnc: | lclc_bnc is now known as lclc |
| 11:46:06 | Algar: | Algar has left #bitcoin-wizards |
| 12:41:15 | lclc: | lclc is now known as lclc_bnc |
| 13:06:45 | lclc_bnc: | lclc_bnc is now known as lclc |
| 14:23:25 | lclc: | lclc is now known as lclc_bnc |
| 15:08:29 | kanzure: | "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:01 | lclc_bnc: | lclc_bnc is now known as lclc |
| 16:15:12 | andytoshi: | 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:36 | andytoshi: | 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:48 | instagibbs: | 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:59 | justanotheruser: | instagibbs: how do you choose a fork? |
| 16:23:14 | instagibbs: | justanotheruser: I use PoW.... ;) |
| 16:23:25 | kanzure: | 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:33 | instagibbs: | kanzure: exactky |
| 16:23:44 | kanzure: | "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:46 | justanotheruser: | instagibbs: sorry, I thought you were a PoSer |
| 16:23:53 | gavinandresen: | 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:55 | kanzure: | like, it is wrong to expect your readers to be aware of this |
| 16:24:11 | instagibbs: | gavinandresen: Well literally people will just use BC.info's fork |
| 16:24:14 | instagibbs: | or whatever |
| 16:24:17 | gavinandresen: | yup |
| 16:24:20 | andytoshi: | 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:24 | justanotheruser: | gavinandresen: For Walmartcoin? |
| 16:24:38 | gavinandresen: | Use Walmartcoin and get 10% off! |
| 16:24:41 | kanzure: | andytoshi: the reason why you should care is because otherwise people will continue to apply inappropriate arguments to your document |
| 16:24:43 | instagibbs: | I can't believe Vit is peddling such garbage. I honestly am not sure he thinks it works |
| 16:24:56 | kanzure: | andytoshi: redirecting them to something else is a good and honest way to deal with their totally wrong criticism |
| 16:25:12 | kanzure: | andytoshi: otherwise you will be deflecting "but honesty!!!!" for the next 1,000 years of your life |
| 16:25:24 | andytoshi: | 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:45 | andytoshi: | and i don't see that i can counterargue "deliberate funded dishonesty" no matter what i write |
| 16:25:47 | instagibbs: | 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:11 | justanotheruser: | 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:37 | kanzure: | andytoshi: they may be dishonest, but they are probably also widely ignorant of the existence of alternative implementations and solutions |
| 16:26:58 | kanzure: | andytoshi: literally nobody has written down "Hey databases exist" so it is easy to see how that ignorance can exist here |
| 16:27:06 | instagibbs: | 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:12 | kanzure: | andytoshi: which might also present itself as dishonesty. but perhaps i am just optimistic. |
| 16:27:20 | justanotheruser: | ... he also suggested that individuals include hashcash with their tx instead of a fee dubbing it "TaPoW" |
| 16:27:25 | andytoshi: | 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:40 | kanzure: | i'll take that |
| 16:27:54 | andytoshi: | kk one sec kanzure i'll pm |
| 16:27:56 | instagibbs: | justanotheruser: boy it would be really nice if there was a way to store up hashcash for future use... hmmmmmmmm |
| 16:28:23 | andytoshi: | 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:36 | kanzure: | the response is "vitalik read it for me and posted this blog post" |
| 16:28:41 | instagibbs: | hehe true |
| 16:28:47 | instagibbs: | kanzure: +1 |
| 16:29:09 | andytoshi: | instagibbs: "it's too technical" "you're just protecting your bitcoins" (wtf) "you're a shill for the core devs" etc. |
| 16:29:18 | fluffypony: | lol |
| 16:29:18 | andytoshi: | i do wanna make these fixes, it's just a low priority because of these things |
| 16:29:47 | kanzure: | they say you're a shill because they literally think that a blockchain is the only possible implementation for storing data |
| 16:29:49 | justanotheruser: | andytoshi: "the paper doesn't specifically mention this implementation of PoS" |
| 16:30:17 | kanzure: | 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:30 | kanzure: | 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:42 | andytoshi: | 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:03 | sipa: | andytoshi: public trusts technobabble |
| 16:31:14 | kanzure: | alright this is decending into pessimism |
| 16:31:16 | jcorgan: | andytoshi: the public sends their bitcoin to pretty websites, they seem to believe anything |
| 16:31:24 | kanzure: | circlejerk that way ----> |
| 16:31:36 | justanotheruser: | hey guys |
| 16:31:40 | kanzure: | if you truly believed that then you wouldn't have written any paper at all |
| 16:31:53 | kanzure: | and it fails to explain the existence of any thoughtful individual ever |
| 16:32:35 | andytoshi: | 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:11 | kanzure: | if that was true, then why would they think money was a good idea? |
| 16:33:37 | instagibbs: | 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:43 | andytoshi: | 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:56 | kanzure: | instagibbs: a general response to systems that have broken consensus is totally necessary and nobody has done it yet |
| 16:34:09 | andytoshi: | instagibbs: it's definitely worth it, but i don't have the time for it |
| 16:34:24 | kanzure: | you don't need to respond to those particular arguments from vitalik's blog post (because they are nonsense) |
| 16:34:27 | jcorgan: | kanzure: pessimism because bitcoin is actually not that hard to understand for an honestly motivated individual willing to learn. <-- not many |
| 16:34:37 | kanzure: | you do need to respond to "broken consensus is better than centralization" or something |
| 16:35:08 | kanzure: | or "broken consensus is better than working consensus" is also a thing oyu need to respond to |
| 16:35:34 | kanzure: | 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:54 | instagibbs: | 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:10 | justanotheruser: | 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:37 | instagibbs: | Consensus will be broken AND/OR centralized under these schemes. It's a mashing up of issues. |
| 16:38:16 | gavinandresen: | 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:32 | kanzure: | yes but you have been known to propose totally broken stuff before |
| 16:38:38 | kanzure: | well, so have i |
| 16:38:46 | kanzure: | that's not a very interesting observation for me to make hehe |
| 16:40:21 | justanotheruser: | gavinandresen: so instead of reorging we just break consensus? |
| 16:40:22 | kanzure: | "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:19 | instagibbs: | While the long re-org WARNING may make sense, no reason to touch consensus rules |
| 16:41:42 | instagibbs: | software still achieved consensus even if you as a user is confused as hell and know there's malicious forking going on |
| 16:42:54 | gavinandresen: | 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:49 | instagibbs: | they'd have to know they were continuously running on the "true" chain, whatever that means |
| 16:43:50 | gavinandresen: | Basically, using the well-connected graph of nodes as another piece of consensus information. |
| 16:44:30 | gavinandresen: | 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:31 | lclc: | lclc is now known as lclc_bnc |
| 16:45:47 | kanzure: | sybil is not a bad thing in bitcoinland |
| 16:45:49 | justanotheruser: | gavinandresen: I'm not a networking expert by any means, but I think this would allow 51% + sybil to break consensus. |
| 16:46:22 | instagibbs: | 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:24 | gavinandresen: | justanotheruser: if you have 51% you have consensus anyway |
| 16:46:32 | sipa: | wut? |
| 16:47:33 | sipa: | this means a temporary 51% could make the network stuck on a fork |
| 16:47:43 | sipa: | which makes it equivalent to a permanent 51% |
| 16:47:47 | justanotheruser: | sipa: if you sustain it anyways |
| 16:47:50 | justanotheruser: | err |
| 16:47:52 | justanotheruser: | gavinandresen: ** |
| 16:48:03 | sipa: | and yes, nodes will complain, which is the useful part |
| 16:48:15 | instagibbs: | 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:33 | sipa: | but you can accomplish the same thing with wallets that complain and go into a emergency mode when seeing a long fork |
| 16:48:45 | instagibbs: | sipa: +1 |
| 16:48:59 | gavinandresen: | sipa: that’s basically what I’m suggesting |
| 16:49:21 | gavinandresen: | sipa: .. I just think miners should complain and refuse to switch to the surprise long fork, too. |
| 16:49:30 | sipa: | 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:59 | sipa: | the warning part is useful, but is orthogonal to this |
| 16:50:17 | gavinandresen: | 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:28 | justanotheruser: | gavinandresen: miners not going to an attacking fork may be interesting since at least consensus isn't broken if they win |
| 16:51:11 | kanzure: | requiring knowledge about previous seen chains will make bitcoin sybil-incompatible i think |
| 16:51:25 | kanzure: | at the moment it is mostly sybil-compatible or sybil-compliant (i don't know the right term) |
| 16:51:57 | gavinandresen: | 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:07 | kanzure: | it's not a risk, it looks obvious |
| 16:52:25 | sipa: | 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:27 | gavinandresen: | 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:33 | instagibbs: | Going slightly -dev: what does Core do today under a large reorg? |
| 16:52:44 | sipa: | instagibbs: it should reorg |
| 16:52:44 | gavinandresen: | Actually, Sybil any full node and they should notice sudden drop in hash rate and alert |
| 16:52:53 | sipa: | gavinandresen: no doubt about that |
| 16:52:56 | instagibbs: | sipa: does a warning light go off or something |
| 16:53:08 | gavinandresen: | sipa: and yet that code has never been written…. (it’s on my short TODO list) |
| 16:53:14 | kanzure: | sybil is not just about sybiling individual nodes, i think |
| 16:53:19 | instagibbs: | or do we assume people are building analytical layers on top, for their own warning |
| 16:53:37 | gavinandresen: | kanzure: if you can Sybil the whole network… well then double-spending is easy! |
| 16:53:46 | kinlo: | reorgs are part of the normal flow, so unless they are "large"... which is an arbitrary definition |
| 16:53:47 | sipa: | instagibbs: it alerts when there are >7 long forks, afaik |
| 16:53:57 | sipa: | that code needs a good look and tests, though |
| 16:54:08 | sipa: | it can probably be improved significantly now with headers-first |
| 16:54:13 | lclc_bnc: | lclc_bnc is now known as lclc |
| 16:54:21 | kanzure: | gavinandresen: providing false bootstrapping data (somehow) would be a trivial way of attacking more than just an individual node |
| 16:54:24 | kanzure: | in that scheme |
| 16:54:35 | zooko: | * zooko reads https://gist.github.com/gavinandresen/630d4a6c24ac6144482a |
| 16:54:40 | kanzure: | .title |
| 16:54:40 | yoleaux: | kanzure: Sorry, that command (.title) crashed. |
| 16:54:41 | kanzure: | oh right |
| 16:54:43 | kanzure: | ame link |
| 16:54:45 | kanzure: | *same |
| 16:54:53 | instagibbs: | kinlo: i think user-defined levels makes most sense. |
| 16:55:02 | sipa: | zooko: thanks for your comments on DERSIG; i'll respond soon, but travelling today |
| 16:55:07 | gavinandresen: | kanzure: I don’t follow how false bootstrapping data would help anything. |
| 16:55:11 | kanzure: | it wouldn't help! |
| 16:55:24 | gavinandresen: | kanzure: you will get the real chain assuming you connect to at least one ‘real’ node |
| 16:55:27 | kanzure: | but since a node has seen those other blocks, it would therefore not correctly reorg to the greater network |
| 16:55:28 | kinlo: | instagibbs: dunno, a re-org is after the facts, you should know beforehand that a large reorg is going to happen |
| 16:55:43 | kanzure: | *to the actual blockchain |
| 16:55:56 | zooko: | sipa: sure thing! I commented because gmaxwell requested comments in this channel. |
| 16:55:56 | kanzure: | ah i might be confused about the actual data provided by bootstrap.dat |
| 16:55:57 | instagibbs: | kinlo: assuming there is a lot of dark hashing power out there or a partition you have no clue |
| 16:56:05 | gavinandresen: | 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:31 | zooko: | "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:40 | kinlo: | instagibbs: true, but exactly that is the only thing you want to know, no? |
| 16:56:47 | gavinandresen: | zooko: yes, I need to update the gist, amiller gave me comments a few weeks ago |
| 16:56:55 | dgenr8: | why are we worried about a "surprise 51% attack" in the first place |
| 16:56:57 | kinlo: | the moment you're doing that large reorg, its usually already too late :) |
| 16:57:32 | instagibbs: | kinlo: i mean a really long KNOWN fork means battling miners or something. |
| 16:57:43 | instagibbs: | alerts for all these situations is impt |
| 16:57:46 | gavinandresen: | 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:23 | dgenr8: | for 2 weeks ... with the usual limitations on what a 51% attacker can accomplish ... plus possible wetware intervention |
| 16:58:33 | instagibbs: | kinlo: True but you probably need to stop business anyhoo! stop the bleeding |
| 16:58:51 | kinlo: | true |
| 16:59:07 | zooko: | 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:26 | gavinandresen: | 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:28 | zooko: | 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:44 | zooko: | But, I think both of those approaches might boil down to almost or exactly the same protocol. So I approve. ☺ |
| 16:59:52 | gavinandresen: | zooko: cool |
| 17:00:10 | zooko: | 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:06 | dgenr8: | wonering how often that +- 300% difficulty cap has been triggered |
| 17:14:33 | dgenr8: | +300% / -75%. sorry, it was just hanging out there |
| 17:19:38 | lclc: | lclc is now known as lclc_bnc |
| 17:21:39 | midnightmagic: | gavinandresen: the contrapositive of your logic is that when the network is temporarily attacked, we are accepting the attacker's blocks permanently. |
| 17:22:08 | lclc_bnc: | lclc_bnc is now known as lclc |
| 17:22:22 | midnightmagic: | or semi-permanently, presuming there's some kind of recovery protocol to prevent a permanent cut in the consensus graph |
| 17:23:45 | zooko: | 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:10 | zooko: | No further transactions/blocks are processed until a human -- not a computer -- decides what to do about the situation. |
| 17:24:11 | midnightmagic: | autonomous nodes could no longer be presumed to exist |
| 17:24:38 | zooko: | 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:41 | instagibbs: | zooko: that should always be the case, yes. Doesn't touch consensus though |
| 17:24:58 | zooko: | 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:59 | instagibbs: | human based consensus is broken until we phone each other up or whatever |
| 17:25:29 | zooko: | I'm planning to implement this in one of my own projects, with a very simple rule: |
| 17:25:50 | zooko: | 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:34 | instagibbs: | "moves" meaning transactions/etc? |
| 17:26:52 | kanzure: | why would a human be better at deciding that than pre-existing reorg rules |
| 17:27:32 | zooko: | instagibbs: yes, anything that could commit you, or that could be used against you. |
| 17:27:41 | midnightmagic: | and as instagibbs says, what if humans decide differently because a human is not well-connected to the consensus graph |
| 17:27:48 | zooko: | 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:18 | midnightmagic: | then we're offloading another future decision point |
| 17:28:34 | instagibbs: | we can have machine consensus and still have human consensus about Bitcoin shattered. |
| 17:28:39 | instagibbs: | that's ok |
| 17:29:21 | op_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:14 | dgenr8: | 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:14 | instagibbs: | op_mul: if you point me to sources id appreciate. |
| 17:30:55 | midnightmagic: | dgenr8: and the degenerate form of a 51% attack remains, and what has the effort been worth? |
| 17:32:14 | op_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:38 | instagibbs: | 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:50 | instagibbs: | or react to it |
| 17:34:10 | instagibbs: | op_mul: i dont mind writing but kind of groaning at the idea of reading another "white paper" |
| 17:34:44 | zooko: | dgenr8: that's a really good question. |
| 17:35:14 | op_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:34 | nsh: | there are only specific reorgs from a subjective (node's) point-of-view, right? |
| 17:35:43 | op_mul: | yes. |
| 17:35:45 | kanzure: | 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:57 | op_mul: | kanzure: noted. |
| 17:36:20 | op_mul: | instagibbs: just read the announcement thread. it gives you all you need to know in order to attack their consensus model. |
| 17:36:25 | justanotheruser: | op_mul: I'm more concerned with how they obscure the issue by using new words. It's called "cementing" |
| 17:36:40 | kanzure: | they can call it whatever they want |
| 17:36:54 | kanzure: | they are vulnerable and that's up to them |
| 17:37:27 | op_mul: | it doesn't matter so long as you can get people believing that you're not. |
| 17:37:29 | instagibbs: | op_mul: In consensus rules, totally agree that nothing should be done. All machines not completely sybiled should be agreeing. |
| 17:37:31 | dgenr8: | 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:34 | justanotheruser: | well it's a tool to trick people mostly |
| 17:37:51 | instagibbs: | human layer is where the ugly hacks happen |
| 17:38:37 | op_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:05 | instagibbs: | heh. that too! |
| 17:39:31 | instagibbs: | praise be to the gods that there are lower hanging fruit to attack than core consensus mechanisms.... |
| 17:40:42 | op_mul: | a large number of companies actually use blockchain.info's wallet as their backend. |
| 17:40:51 | kanzure: | op_mul: don't remind me :/ |
| 17:40:54 | kanzure: | it is painful |
| 17:41:28 | justanotheruser: | op_mul: what big names? |
| 17:41:29 | op_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:30 | midnightmagic: | i think it would make the blockchain's expansion into space also quite a bit more fragile |
| 17:41:34 | instagibbs: | op_mul: .... what |
| 17:42:04 | kanzure: | 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:10 | kanzure: | instagibbs seems to agree partly? |
| 17:42:19 | kanzure: | whta would be the other necessary conditions for this sort of explanation to reduce misinformation |
| 17:42:22 | kanzure: | or disinformation for that matter |
| 17:42:28 | kanzure: | er, by conditions i mean content |
| 17:43:05 | instagibbs: | Yes. possibly have to mention the obvious like "phoning a friend isn't distributed consensus" |
| 17:43:24 | kanzure: | right... and there's nothing "wrong" with phoning a friend, outside the context of distributed consensus. |
| 17:43:40 | kanzure: | 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:41 | instagibbs: | is thre a nice solid def of consensus in the explanation |
| 17:43:59 | kanzure: | there's one in alts.pdf |
| 17:44:01 | kanzure: | at least |
| 17:44:21 | instagibbs: | see maybe you're right. if it's there it means people aren't actually reading it |
| 17:44:30 | instagibbs: | let me skim again |
| 17:44:50 | kanzure: | it mentions that definition ,but it does not really redirect people to alternatives if they are not interested in distributed consensus |
| 17:45:16 | kanzure: | 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:25 | nsh: | 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:03 | nsh: | seemingly not, per google |
| 17:46:49 | instagibbs: | i don't really see a real clear-cut def of distributed consensus in the doc. Just references to it. |
| 17:46:57 | instagibbs: | maybe im missing it |
| 17:47:11 | kanzure: | page 8 section 6 |
| 17:47:16 | instagibbs: | oh nvm |
| 17:47:20 | instagibbs: | got it |
| 17:47:55 | kanzure: | there might also be some weird confusion around the meaning of "agreement" heh |
| 17:48:18 | instagibbs: | perhaps. Agreemnet in the computer sense not human :) |
| 17:48:23 | instagibbs: | state of the machine |
| 17:49:35 | instagibbs: | Ok, "lack of identities" is the assumption being broken for these schemes. |
| 17:50:15 | kanzure: | although i like the term "agreement" it should probably be elaborated to refer to things like consistency and equivalents |
| 17:50:33 | kanzure: | *equivalency |
| 17:51:09 | op_mul: | instagibbs: people still try to do "voting" systems with bitcoin. |
| 17:51:34 | op_mul: | and they never realise why it's as good of an idea as a egg powered car. |
| 17:51:35 | instagibbs: | 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:56 | instagibbs: | op_mul: well yes, blockchain technology uber alles |
| 17:52:08 | op_mul: | > muh sybil |
| 17:52:12 | instagibbs: | it runs my toaster now too |
| 17:52:18 | nsh: | * nsh imagines Uber adopting blockchains |
| 17:52:45 | zooko: | *laugh* |
| 17:54:16 | op_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:45 | op_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:24 | nsh: | for useful values of 'problem' :) |
| 17:56:36 | op_mul: | high water mark for SPV nodes is two, if anybody was curious. |
| 17:56:56 | nsh: | how do you mean? most connected at any time? |
| 17:57:12 | op_mul: | one SPV client connected to two of my nodes at once. |
| 17:57:13 | instagibbs: | meaning an spv node connected to two of your nodes? |
| 17:57:17 | nsh: | ah |
| 17:57:20 | instagibbs: | oops scrolled too late |
| 17:58:30 | op_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) |
| 17:58:44 | op_mul: | s/top/drop/ |
| 18:26:35 | lclc: | lclc is now known as lclc_bnc |
| 18:44:46 | dansmith_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:44:56 | dansmith_btc: | ? |
| 18:45:10 | sipa: | that's just 2-of-2 multisig |
| 18:45:26 | sipa: | and it does not prevent double spending |
| 18:48:04 | op_mul: | sipa: well, it can sort of assure you that a double spend is improbable in the case of greenaddress.it. |
| 18:48:06 | dansmith_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:27 | op_mul: | dansmith_btc: look into how greenaddress.it works. |
| 18:53:02 | gmaxwell: | 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:18 | gmaxwell: | Also he can collect his own bond (after all, he's in a privledged position to know when he has cheated. :) ) |
| 18:53:45 | gmaxwell: | 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:53 | gmaxwell: | s/any to/any two/ |
| 18:54:36 | op_mul: | that would suck if you wanted to double spend with a higher fee. |
| 18:54:47 | amiller: | you could make the bond pay out 0.1x to whoever presents it and 0.9x of it is deleted forever |
| 18:55:06 | amiller: | 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:45 | op_mul: | I really hope people don't try and have wallets see stuff with checktimelockverify as IsMine(). |
| 18:58:20 | andytoshi: | nsh: adam and i were going to write a paper elaborating the DMMS stuff. there is no eta on us starting :) |
| 18:59:41 | andytoshi: | 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:00 | dansmith_btc: | gmaxwell, is it useful to have the bond spendable only to a provably unexisting address? |
| 19:00:10 | gmaxwell: | op_mul: with powerful enough script you could exclude 'honest' double spends. |
| 19:00:30 | dansmith_btc: | s/address/pubkey |
| 19:01:08 | gmaxwell: | 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:12 | kanzure: | 'honest double spends' certainly exist (giving someone a second transaction because a reorg was experienced that mutated the input txid) |
| 19:01:28 | kanzure: | wait, disregard |
| 19:01:35 | kanzure: | for many reasons |
| 19:02:00 | gmaxwell: | 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:40 | gmaxwell: | 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:18 | dansmith_btc: | maybe 90% goes to the black hole and 10% goes to whoever reported - there's the incentive. |
| 19:04:34 | andytoshi: | 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:38 | gmaxwell: | dansmith_btc: goes to the miner, not the reporter. You cannot make it go to the reporter. :( |
| 19:04:46 | gmaxwell: | right, not without a NIZK. |
| 19:05:04 | gmaxwell: | Trying to avoid brews involving ground unicorn bones. |
| 19:05:35 | gmaxwell: | NIZK nicely solves that one still leaves you with the double-spends. |
| 19:10:26 | dansmith_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:33 | GAit: | unrelated to the above but you may find interesting the suddent p2sh spike and drop http://i.imgur.com/8usxslN.png |
| 19:11:13 | andytoshi: | 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:52 | kanzure: | perhaps that spike was bitstamp transferring to p2sh |
| 19:11:59 | dansmith_btc: | true, the miner could steal but that'd be a diff disussion |
| 19:12:28 | GAit: | kanzure: i think it was sarutobi |
| 19:12:36 | nsh: | andytoshi, i look forward to it whenever it manifests :) |
| 19:14:06 | dgenr8: | 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:25 | GAit: | dgenr8: is that true? i thought that miners having different policies makes it more likely not less likely |
| 19:16:15 | nsh: | it always gets harder to double-spend, as the total PoW on competing blockchain tips is monotonically increasing |
| 19:17:20 | nsh: | 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:53 | GAit: | sorry i thought we were talking about unconfirmed double spends not confirmed |
| 19:18:55 | gmaxwell: | 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:39 | zooko: | BTW, I think that a bond-against-multispend combined with PoW can actually achieve quantitatively better defense than pure PoW. |
| 19:32:51 | zooko: | But, I don't know how to fit it into Bitcoin, and I'm not currently working on it. |
| 19:35:22 | gmaxwell: | 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:38 | gmaxwell: | 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:38:20 | zooko: | *nod* |
| 19:39:13 | zooko: | There's one particular detail about how much better it could be that you missed or glossed over above -- |
| 19:39:52 | zooko: | 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:11 | zooko: | I.e., if your recipient requires at least one confirmation, in addition to requiring an anti-multi-spend-bond. |
| 19:40:24 | gmaxwell: | oh I'd forgotten the line of thinking of boosting single confirm to prevent the double spending. |
| 19:40:36 | zooko: | That was Nikita Borisov's contribution to my idea. |
| 19:40:44 | zooko: | IIRC, which is questionable. ☺ |
| 19:41:08 | zooko: | But I agree with you that the bottom line is, it isn't clear if it is important enough. |
| 19:41:22 | zooko: | In particular, *I'm* currently treating it as insufficiently important, meaning I'm not working on it. |
| 19:41:29 | gmaxwell: | 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:38 | zooko: | But I would be happy if someone else published the idea, implemented it, etc. |
| 19:41:52 | zooko: | gmaxwell: Yeah! I think that was Nikita's contribution. It's pretty cool. |
| 19:42:29 | zooko: | 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:39 | gmaxwell: | 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:52 | gmaxwell: | (I'm just explaining more for the room) |
| 19:42:52 | zooko: | Exactly. |
| 19:52:56 | dgenr8: | what is that idea? somehow reducing multiple-spends in a single block? |
| 19:58:41 | dgenr8: | greenaddress, impulse etc. have a huge adoption hurdle. it's hard enough getting businesses to adopt bitcoin itself. |
| 20:01:13 | fluffypony: | 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:46 | dgenr8: | okey dokey |
| 20:03:02 | andytoshi: | 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:34 | nsh: | is this guy associated with sidechains thingumy, corporate nonsense, whatever it's called? https://fi.linkedin.com/in/joukosalonen |
| 20:06:54 | nsh: | -- |
| 20:06:54 | nsh: | 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:55 | nsh: | bership, multiparty signature system, non-trust PoW & PoC structures, smart contracts, prediction market consensus based supply chains and networked accounting. |
| 20:06:55 | nsh: | Yurohs is in stealth "zero to one" mode, we do concept design, we test and we fail. |
| 20:06:57 | nsh: | -- |
| 20:07:10 | nsh: | seems to have read the paper at least |
| 20:08:14 | maaku: | love how "we fail!" is a selling point |
| 20:09:45 | nsh: | * nsh smiles |
| 20:17:10 | fluffypony: | 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:50 | andytoshi: | fluffypony: ditto in canada, actually :) for 5+ years anyway |
| 20:21:20 | fluffypony: | sometimes I think the USA just needs a hug and a pat on the back |
| 20:23:10 | op_mul: | fluffypony: most still accept swipe cards though. like SSL, there's an insecure fallback. |
| 20:24:28 | fluffypony: | op_mul: yes they do, I mean that I haven't seen any that are swipe-only |
| 20:24:49 | andytoshi: | op_mul: not in canada, very few will let you swipe (maybe the merchant can override this?) |
| 20:24:59 | andytoshi: | it says "PLEASE INSERT CHIP" |
| 20:25:08 | op_mul: | andytoshi: you have to fail the chip several time and then the machine will ask you to swipe instead. |
| 20:25:19 | andytoshi: | ah |
| 20:25:44 | fluffypony: | yeah |
| 20:25:48 | op_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:50 | fluffypony: | also if the card doesn't have a chip |
| 20:25:56 | fluffypony: | then it will accept a plain swipe |
| 20:26:32 | op_mul: | must be a market in the swipe data that says "I HAVE A CHIP TRY THAT FIRST" |
| 20:26:39 | op_mul: | s/market/marker/ |
| 20:29:39 | belcher_: | belcher_ is now known as belcher |
| 20:36:27 | rhadamanthus: | rhadamanthus has left #bitcoin-wizards |
| 21:40:26 | pigeons: | i've been traveling to canada a lot the past several months and i've been able to swipe |
| 21:45:24 | andytoshi: | 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:05 | fluffypony: | there are two components to it |
| 21:47:17 | fluffypony: | 1. the mag-stripe can contain a flag that indicates it has a chip |
| 21:47:31 | fluffypony: | but 2. the reader will ignore that if it doesn't have a chip reader |
| 21:47:34 | smooth: | 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:47:43 | fluffypony: | yeah |
| 21:48:00 | smooth: | from there everything was incremental though the card-and-pin increment in the us shows even that isn't always easy |
| 21:48:05 | fluffypony: | with the load shedding our national power agency has been having some merchants have been hauling out their imprinters again |
| 21:48:34 | smooth: | but a huge amount of network effect was built without pushing barriers on the adopters |
| 22:07:19 | adam3us: | 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:49 | adam3us: | 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:52 | adam3us: | adam3us has left #bitcoin-wizards |
| 22:57:35 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 23:00:03 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 23:11:03 | Pan0ram1x: | Pan0ram1x is now known as Guest34424 |