01:04:54 | zooko`: | zooko` is now known as zooko |
01:58:26 | SubCreative: | SubCreative is now known as just |
01:58:36 | just: | just is now known as SubCreative |
01:58:57 | SubCreative: | SubCreative is now known as just |
01:59:03 | just: | just is now known as SubCreative |
02:21:28 | bramc: | There's something I'm not understanding about the time warp attack: https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 |
02:22:17 | bramc: | How does the attacker get their total work to be higher? It seems like it should be easy for them to drive up their block numbers, but the total work should always trail, unless there's something I'm not understanding about the total work calculation |
02:22:17 | moa: | a jump to the left? |
02:22:28 | bramc: | moa, not sure what you mean |
02:22:28 | moa: | or the skip to the right? |
02:22:36 | moa: | srry couldn't resist |
02:23:18 | bramc: | I don't get it |
02:23:35 | moa: | https://www.youtube.com/watch?v=vBHONx9vTtI |
02:23:50 | gwillen: | bramc: the Time Warp song from Rocky Horror |
02:24:42 | bramc: | I've never actually seen rocky horror |
02:25:06 | moa: | me either weirdly but that song gets rolled out at weddings, etc |
02:26:01 | bramc: | I've heard the refrain from it somewhere before |
02:27:45 | bramc: | But seriously, there's something about how the difficulty per period is calculated and added up which I'm not getting |
02:30:01 | bramc: | For any given period there's a certain number which you need to find a hash less than it to succeed. For the purposes of work difficulty the 'obvious' ways to calculate that are either the reciprocal of what the work had to be or what the work actually was. Either one should be very effective at keeping an attacker from ever winning on work put in, but that post seems to say that an attacker can get ahead on the actual amount of work difficulty done |
02:33:15 | moa: | it is a 51% attack |
02:34:01 | jgarzik: | bramc, yes, it requires sufficient mining power to execute |
02:35:12 | phantomcircuit: | bramc, the more annoying attack is to generate a stream of diff=1 blocks with timestamps manipulated such that diff remains 1 forever |
02:35:31 | phantomcircuit: | this isn't very effective with headers first though |
02:35:44 | bramc: | Oh, that makes it a lot less interesting |
02:36:41 | moa: | it was done on namecoin before merge-mining was implemented ... not sure if it was ever done before that on bitcoin (artforz would know) |
02:36:46 | bramc: | phantomcircuit, Not sure what you mean. If others have the majority of mining power and they put in the max timestamp allowed they'll eventually win |
02:37:20 | phantomcircuit: | bramc, yes but not before i've forced you to process a bunch of nonsense |
02:37:34 | bramc: | define 'bunch of nonsense' |
02:37:59 | phantomcircuit: | bramc, 1MB blocks which are a fork |
02:38:04 | phantomcircuit: | it's a dos attack |
02:38:27 | andytoshi: | fluffypony: do you have a link to that shadowcash paper that isn't behind cloudflare? (alternately, i can just use a non-tor browser, if you've checked it out and it seems like it's worth the trouble) |
02:38:32 | bramc: | If somebody's mining they can make 1MB blocks, how is that a fork? |
02:39:10 | bramc: | What is everybody's issue with cloudflare? |
02:39:45 | andytoshi: | bramc: it blocks pages, you get this "please type the captcha" page with a captcha that won't load unless you tell your requestpolicy that $random_mitm'd_site can connect to google |
02:41:08 | phantomcircuit: | bramc, i can mine 1MB blocks from the genesis block upto the first checkpoint and an infinte number of forks of that |
02:41:17 | phantomcircuit: | then make you validate those blocks |
02:41:22 | phantomcircuit: | which aren't in the mainchain |
02:41:26 | phantomcircuit: | and which cost me almost nothing |
02:41:53 | moa: | i noticed the mytrezor webwallet loads a JS from cloudflare |
02:41:58 | bramc: | It doesn't check the work weight before validating the signatures? |
02:44:03 | moa: | srr grau |
02:44:22 | phantomcircuit: | bramc, the difficulty is correct |
02:44:34 | phantomcircuit: | anyways this is basically completely irrelevant with headers first |
02:44:34 | bramc: | It sounds like a good idea to design the protocol so that it's possible to send just the hashes so a counterparty can validate those before requesting whole messages |
02:44:42 | phantomcircuit: | and is really just mildly annoying |
02:45:10 | bramc: | Does 'headers first' mean that the receiving side can check work difficulty before requesting all the messages? |
02:45:36 | phantomcircuit: | bramc, it means you can check the headers before checking all the transactions |
02:45:55 | phantomcircuit: | and it makes it easier to get them from multiple sources potentially in duplicate |
02:45:58 | bramc: | It's probably reasonable for the receiving side to also have a sanity check on the overall height they'll accept based on the current time |
02:46:15 | bramc: | phantomcircuit, Thanks, I understand that, goes on my list of gotchas to avoid |
02:46:18 | kanzure: | (that doesn't work for regtest) |
02:46:26 | kanzure: | (not that regtest matters) |
02:55:23 | bramc: | What is regtest? |
02:57:01 | phantomcircuit: | bramc, testnet but with even more relaxed rules |
02:57:27 | bramc: | Ah |
02:57:59 | phantomcircuit: | setgenerate true basically finds a block instantly |
02:58:03 | phantomcircuit: | iirc it's always with diff=1 |
02:58:11 | phantomcircuit: | or maybe it's less than 1 |
02:58:14 | phantomcircuit: | cant remember |
03:00:33 | tacotime: | less than 1 |
03:00:48 | tacotime: | powlimit = 0x207fffff |
03:00:49 | isis: | andytoshi: the shadowcash paper isn't really worth reading, in my opinion, but it's here if you want it: https://github.com/isislovecruft/library/tree/master/cryptography%20%26%20mathematics/cryptocurrencies |
03:01:16 | tacotime: | the shadowcash paper is really just a rerelease of the cryptonote whitepaper in a different font |
03:03:55 | isis: | precisely, and i have the same complaints against its probablistic, dwindling anonymity sets as i do with monero |
03:13:58 | duuude: | hi. I have a question on the original C++ code written by Satoshi. is there a copy somewhere? |
03:14:05 | duuude: | also, does it have a mix of styles/endianness etc that strongly suggests it was not one person but multiple sharing a pseudonym? |
03:19:39 | tacotime: | i don't think anyone really believes one person wrote it |
03:20:05 | tacotime: | different components are in different coding styles, and the build number upon first release was astronomical |
03:20:56 | duuude: | tacotime - I am interested in this (I dont care about identities or anything) |
03:20:57 | rusty: | duuude: google lead me to https://bitcointalk.org/index.php?topic=68121.0 pretty fast... |
03:21:00 | tacotime: | isis: anonymity sets in monero shouldn't be dwindling as long as there's reasonable traffic on the network, and are constantly feeding into each other |
03:21:30 | gmaxwell: | bramc: yea, the reason we haven't bothered fixing timewarp is that it requires a hashpower majority, so it's relatively low priority (if someone started doing it, it could likely just be fixed hot) |
03:22:18 | duuude: | tacotime - do you have presonal experience with this? I can code in C (and C++) and would like to know exactly what you mean by "different components are in different coding styles", i.e. specific examples (such as two guesses I listed, like endinanness, for loops, cast styles, etc). |
03:22:57 | duuude: | I want to form my own opinion. I've also coded in a mix of styles - for example if i completely refactor and rework working example code I get from somewhere. I might keep its style even though it's not how I would have written it (while changing everything including what it does.) |
03:23:24 | duuude: | I mean if I google a code snippet. |
03:23:30 | tacotime: | duuude: i'm with conformal, so i know some of the people personally who did the refactor into Golang. it was their opinion, and they've been coding much longer than i have. i can't give you specific examples because i wasn't involved in most of the original composition of btcd. |
03:23:35 | duuude: | As a result of working off of a google phrase in the end my code can be a mix. |
03:24:10 | duuude: | tacotime, do you know someone you can refer to me to who would give me the most 'obvious' example (like cast style, or whatever) |
03:24:16 | tacotime: | you can talk to davec on the conformal irc server if you're curious for more info |
03:24:21 | duuude: | yes, thanks. |
03:24:44 | duuude: | I'll try to connect there as well, I think this client supports it if not I might get disconnected from here. thanks |
03:25:51 | duuude: | can you give me the server details for conformal network? |
03:25:52 | tacotime: | (i guess refactor isn't even the right work, reimplementation rather) |
03:26:06 | duuude: | yes, I got that |
03:26:16 | andytoshi: | duuude: https://download.wpsoftware.net/bitcoin/bitcoin-0.1.0.tgz is an old source release, i don't think it's the earliest but it's back there |
03:26:21 | duuude: | it doesn't really matter, as long as they looked at hte original code and formed an opinion. I'm sure they recall some things I can judge. |
03:26:32 | duuude: | andytoshi thanks |
03:28:08 | gmaxwell: | duuude: bitcoin core was very clearly written by a single person; it has all the (positive and negative) hallmarks of a single person project. ... though I dunno that origin stuff is very interesting; unlikely other systems Bitcoin's reality is just it itself, you don't have to trust the creator of the system. |
03:28:33 | gmaxwell: | So while that stuff might be historically interesting, it's ultimately trivial that doesn't have a lot of relevance today. |
03:29:13 | duuude: | gmaxwell, sorry, are you saying you clearly disagree with the third-hand source? (tacotime's summary of davec's opinion) |
03:29:49 | duuude: | i.e. whereas davec (according to tacotime) says it was clearly written by multiple people (stylistically), you say having looked at the code that it's clearly a single-person project and consistent with that? (to you)? |
03:30:34 | gmaxwell: | duuude: I have no clue why davec would have been looking at a many years old copy of Bitcoin rather than current versions on the network. |
03:30:57 | duuude: | oh |
03:31:02 | gmaxwell: | And current versions were very much written by multiple people, most of the original code has been replaced. |
03:31:10 | kanzure: | andytoshi: i think that was originally a .rar file, http://diyhpl.us/~bryan/irc/bitcoin-satoshi/bitcoin-0.1.0.rar |
03:31:13 | duuude: | okay, so what version did you base your judgment on? |
03:31:20 | duuude: | yes, I have that rar open |
03:31:29 | kanzure: | why |
03:31:31 | gmaxwell: | The original software. |
03:31:34 | andytoshi: | kanzure: maybe, tbh i don't remember where i got that. i had thought, from sourceforge |
03:31:39 | gmaxwell: | But as I said, I don't think it's very interesting. |
03:32:11 | pigeons: | not relevant here at least |
03:33:39 | gmaxwell: | It's tabloid and history books stuff, it doesn't have any bearing on the system itself today... and certantly not tomorrow. |
03:33:47 | duuude: | gmaxwell - do you know what specific "mix of styles" people were referring to? |
03:34:03 | gmaxwell: | duuude: nope, no clue. |
03:34:29 | duuude: | gmaxwell - so, I'm interested because I am arguing for a 'lone genius' possibility on hacked-together projects (such as one of my own). I'd like to rebut someone saying the original bitcoin wasn't written by 1 person. |
03:34:41 | kanzure: | oh, wrong channel for that |
03:34:45 | duuude: | gmaxwell, I agree with you based on this rar file that it has all the hallmarks of being written by one person |
03:34:46 | duuude: | Oh, I know |
03:34:48 | duuude: | I didn't mean here. |
03:34:52 | andytoshi: | i think #bitcoin-satoshispeculation might still be open.. |
03:34:59 | tacotime: | hah |
03:35:03 | duuude: | no, I didn' tmean I wanted to do this here. |
03:35:05 | andytoshi: | if not ask in #bitcoin pls, it's OT there as well but at least it's not logged :) |
03:35:26 | kanzure: | OT has too many ambiguous conflicting meanings |
03:35:29 | kanzure: | you should just say off-topic |
03:35:39 | duuude: | kanzure - what else does it mean on IRC? |
03:35:46 | gmaxwell: | well only one meaning has production deployment. :P |
03:35:48 | tacotime: | oh yeah, market.cpp. almost forgot about that. |
03:35:48 | duuude: | (or in bitcoin or in programming) |
03:36:06 | kanzure: | gmaxwell: "original topic" |
03:36:10 | kanzure: | the point is, get out |
03:36:25 | duuude: | market.cpp is hilarious. Look: |
03:36:25 | duuude: | /// later figure out how these are persisted |
03:36:26 | duuude: | map mapMyProducts; |
03:36:35 | kanzure: | that is not hilarious |
03:36:39 | duuude: | "later figure out how these are persisted". No, it is. :) |
03:36:47 | kanzure: | that's a totally normal comment to make |
03:36:48 | BlueMatt: | duuude: seriously, off-topic |
03:36:50 | BlueMatt: | just stop |
03:36:56 | tacotime: | yeah, anyway. |
03:37:03 | gmaxwell: | duuude: that just means "how to persist these" |
03:37:17 | duuude: | I've been asked to stop discussing this. thanks for the help guys. |
03:37:35 | kanzure: | you've been asked to leave, not to stop discussing this |
03:37:46 | kanzure: | or, if not to leave, then to take the discussion to #bitcoin |
04:21:30 | wallet421: | wallet421 is now known as wallet42 |
04:32:11 | adam3us: | gavin on scalability live stream https://www.youtube.com/watch?v=7K5AQdbo0nY |
04:32:34 | adam3us: | (well answering questions from audience) |
04:34:12 | kanzure: | .title |
04:34:13 | yoleaux: | SF Bitcoin Meetup @ Geekdom December 16, 2014 [Live] - YouTube |
04:51:09 | adam3us: | hmm no barrier to entry… try a few $100m for 150PH + data center + power + lead time? |
04:51:35 | gmaxwell: | yea, kinda funny in that he's pointed out before that he hasn't touched mining himself for ~years~. |
04:52:01 | gmaxwell: | :) |
04:52:38 | gmaxwell: | In the abstract it's a reasonable point; ... and there is only so much you can cover in front of a big room. |
04:53:46 | gmaxwell: | (there are a bunch of things he's saying that he has much more complex thoughts about. He does a good GWB impression of sounding simple about complex subjects that he really does understand. :) ) |
04:55:37 | adam3us: | definitely.does a good job on saying things in an accessible way |
05:01:33 | adam3us: | i suppose it depends on how determined the cartel is to stamp out competition. i think generally things get ugly and unpredictable if bitcoin ended up there so its hard to argue for or against. certainly from other spheres you see companies willing to lose money short-term to kill a new entrant with intent to undercut them. |
05:08:38 | Emcy: | missed gavin speaking i assume |
05:09:08 | adam3us: | you can watch it as a regular youtube vid now. (watching the beginning that i missed) |
05:09:21 | Emcy: | some sort of bitcoin "compliance" panel on now......uuuuuuggggghhhhh |
05:09:32 | adam3us: | yeah so skip forward 1/2hr or so |
05:09:44 | Emcy: | ok |
05:10:56 | Emcy: | gavin speaks quite well publicly for laymen considering he is supposed to be a pure tech guy |
05:11:02 | Emcy: | i usually enjoy his talks |
05:11:35 | adam3us: | i guess 1h10 mark. |
05:11:51 | Emcy: | welp he has a beard now |
05:11:52 | [\\\\]: | [\\\\] is now known as [\\\] |
05:12:03 | Emcy: | haha reminds me of evil spock :> |
05:12:28 | op_mul: | it's unfortunate that all of the youtube suggestions on this video seem to be block chain related technobabble. |
05:13:30 | Emcy: | ehhhhhhhhh he still seems to think scaling blocksize "8x will take no effort". Yeah maybe not for hosted nodes |
05:14:40 | op_mul: | 8x would be the limit for me I suspect. |
05:20:15 | Emcy: | i wonder if the foundation could make a grant for bitcoins confs to buy a decent mic/audio path for the speakers :( |
05:23:12 | BlueMatt: | heh |
05:35:31 | fluffypony: | andytoshi: I'll lower Cloudflare's aggression so you can view it |
05:35:51 | fluffypony: | ok done |
05:37:29 | Emcy: | aggression? |
05:37:41 | Emcy: | "only a cached copy for you, fucko" |
05:37:45 | fluffypony: | lol |
05:37:50 | kanzure: | accurate |
05:38:00 | fluffypony: | no, they have a whole section for how aggressive you want the security to be |
05:38:11 | fluffypony: | like when it pops up that captcha-based challenge |
05:38:27 | fluffypony: | or has a JS interstitial snippet that checks to see if you're a real browser or a bot |
05:38:48 | fluffypony: | (which is actually really nice for preventing automated fuzzing tools) |
05:39:37 | bramc: | gmaxwell, I don't follow how timewarp is any more powerful than a 51% attacker just making their own fork and orphaning everything by everybody else |
05:39:57 | fluffypony: | because a timewarp attack doesn't require 51% |
05:40:24 | bramc: | fluffypony, That's different from what people said earlier |
05:41:07 | fluffypony: | in the classic timewarp attack it does require 51% |
05:42:16 | fluffypony: | what the timewarp attack did was exploit an off-by-one bug in Bitcoin to make the damage worse than just a fork |
05:43:25 | bramc: | Oh, what's the off by one? |
05:43:57 | fluffypony: | there's stuff on btct about it, lemme see if I can find something relevant |
05:44:18 | fluffypony: | https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 |
05:44:37 | fluffypony: | https://litecoin.info/Time_warp_attack |
05:45:34 | bramc: | Oh, now I understand |
05:45:47 | bramc: | That's a really bad off by one bug |
05:48:57 | fanquake: | heh I was just reading the same timewarp post. Although came from https://en.bitcoin.it/wiki/Hardfork_Wishlist |
05:49:54 | bramc: | fanquake, That's where I came across it as well |
05:50:11 | Emcy: | eh this block pre-announce thing gavin is talkiing about seems like it would only be good for the big miners |
05:50:13 | bramc: | I didn't realize on first reading that it's based off an outright bug |
05:50:33 | Emcy: | as in if everyone used it the netowrk would be flooded with crap |
05:51:11 | bramc: | Emcy, What block pre-announce thing? |
05:51:20 | Emcy: | he sounds like he has totally given up on node software running on consumer hardware |
05:51:42 | Emcy: | bramc miners pre announcing theri block template i guess |
05:52:01 | bramc: | What is the point of that? |
05:53:02 | Emcy: | help block racing amongst the big boys |
05:53:18 | Emcy: | something about zero conf assurance too |
05:54:54 | bramc: | Oh, yeah, it can do that. It would be better if everything was a canonically designed sorted list and peers could communicate diffs |
05:55:06 | bramc: | using merkle tree diffs |
05:56:31 | bramc: | That potentially creates a few round trips but dramatically reduces the amount of data which needs to be sent out for a new block to be accepted |
05:56:50 | Emcy: | um the only canonical source of txn ordering is a block |
05:57:50 | bramc: | You could have a convention that if peers sort the transactions in their block then they're more likely to win a race. Would do a good job of getting peers to actually do that. |
06:07:36 | dgenr8: | i don't really get the pre-announce idea. It's the kind of thing that is regularly lambasted right here, as a useless security half-measure |
06:09:38 | bramc: | If the thing I just said was implemented properly it would be a simple network bandwidth optimization and latency improvement |
06:09:51 | dgenr8: | agreed on that, but not security |
06:10:03 | dgenr8: | as gavin alluded to |
06:10:06 | lechuga_: | propagating lower difficulty share-blocks seems like it just makes more potential for congestion |
06:10:13 | bramc: | Not really security, but having races have clearer winners would be a good thing |
06:17:56 | gmaxwell: | I mean, it's not really worse than "erase everything" but it doesn't require quite an extreme outcome, which is in one sense worse. |
06:18:30 | gmaxwell: | Also, really I wish no one had ever uttered the words "51% attack" because thats incredibly confusing. It makes 51% sound like a magic number, it ignores how long the attack goes on, and what precisely the attack is doing. |
06:21:42 | fluffypony: | gmaxwell: precisely |
06:22:03 | bramc: | Given that peers are already fairly synced at all times, a peer could tell another one about a block which was reasonably canonically made by giving it the headers and saying which transactions were newly added and which ones were skipped, that would be a nice bandwidth optimization and not add any round trips at all |
06:22:21 | op_mul: | it's also not ideal from the perspective of that people think a "51%" attack is.. a thing. they utter it without following up with that they are using their majority to do. it's not like the network would explode if you hit that magic number. |
06:22:45 | fluffypony: | op_mul: it's also not like a pool that's at 25% can't perform the exact same attack |
06:22:57 | op_mul: | are they withholding blocks? trying to stop other people getting rewards? double spending? |
06:23:09 | op_mul: | fluffypony: that too. |
06:23:19 | gmaxwell: | In the abstract it's possible for a majority hashpower to just replace the chain, which is pretty awful, but a simple 1% majority would take 20 years to outpace the network. Not really an interesting attack. Inflating the currency some by speeding up subsidy is more interesting, though probaly too easily addressed by magical-layer-8-processes to actually be interesting. |
06:25:21 | bramc: | gmaxwell, A 1% majority couldn't redo history, but they could easily hijack new work and in two weeks get the overall work rate to be lower so they could keep everything for themselves |
06:25:49 | bramc: | Also could start jacking up transaction fees heavily |
06:26:16 | gmaxwell: | well technically 1% can't reasonably do it, because of timestamp constraint the attack has to fork the chain about two weeks back to start with. |
06:26:49 | gmaxwell: | But sure in that space. But it results in a moronic pattern of timestamps, e.g. jumping back two weeks every so many blocks to keep the median window from rolling forward. |
06:28:04 | bramc: | Not following you. A mining pool with 1% majority could just start orphaning everybody else, and after 50 or so blocks they'd be way ahead |
06:28:11 | gmaxwell: | bramc: if they're an actual majority (well 1% is not stable enough a majority, too much variance) then they can happily do the transaction fee imposing and such, no time warp anything required. All the timewarp adds to that is cranking out the subsidy faster. |
06:28:21 | gmaxwell: | bramc: thought you were speaking specifically to timewarp. |
06:28:39 | bramc: | No, I was talking in general. Timewarp is only annoying because of that stupid off by 1 bug |
06:29:08 | bramc: | Not sure what would be a proper countermeasure for that but I have a feeling that the cure would be worse than the disease. |
06:30:12 | gmaxwell: | For the off by one? you can just have a second median window to constrain timestamps, then you can't do the back and forth jumping. It's not hard to craft a rule thats never been violated on the network as is, but prevents use of it. Proving that it has no other negative consequences is harder. |
06:43:04 | bramc: | Dumb question: When comparing two different blocks, is their height determined by the difficulty threshold for them or the difficulty threshold they actually managed to overcome? |
06:44:23 | bramc: | I think it's the first one, although the second one would have some advantages, like doing tiebreaks |
06:46:40 | gmaxwell: | the second leads to immediate enormous attacks. |
06:46:45 | op_mul: | their achieved difficulty would be very very nasty to use. if it was the case, you could grind at block 1, suddenly get lucky and overwrite the entire chain. |
06:46:57 | gmaxwell: | (it's the first, because that is what _actually_ is the statistical metric for work in the block) |
06:47:32 | gmaxwell: | what op_mul said. Also even if it were just tiebreaks, you can see you get a lucky tiebreaker and then keep your block secret, comfortable that you'll win if you announce it later. |
06:47:47 | gmaxwell: | (this creates an increased expected return for large miners) |
06:49:34 | op_mul: | back in august the best preimage was 00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a for a "achieved difficulty" of 391,895,084,984,304. not enough to ripe out the whoel chain I don't think. |
06:50:37 | lechuga_: | lol |
06:50:43 | op_mul: | actually at the time it would have been. from gmaxwell's post the total work at the time was 79.97 bits and the block was 80.4. |
06:52:12 | lechuga_: | i noticed that subtlty in the protocol but didnt spend anytime thinking about why but now it's obvious |
06:58:43 | gmaxwell: | lechuga_: The difference between committed target and apparent target are covered in varrious pre-bitcoin papers on hashcash at least. |
07:04:30 | lechuga_: | bitcoin 2.0 is particularly amusing when you consider core is @ 0.10 |
07:04:41 | lechuga_: | too bad april 1st is kinda far |
07:05:36 | op_mul: | pull request. bump version to 3.0. |
07:06:20 | lechuga_: | :) |
07:06:52 | gmaxwell: | Bitcoin 11. (this one goes to 11; ... gavin would approve) |
07:07:05 | lechuga_: | lol |
07:07:27 | Luke-Jr: | lechuga_: software != protocol |
07:07:38 | Luke-Jr: | I think we're at the point where it's okay to call the consensus protocol "1.0" |
07:07:50 | op_mul: | // make sure the version number has sufficient entropy |
07:07:56 | lechuga_: | lol |
07:07:58 | Luke-Jr: | it's not ideal, but it is pretty stable |
07:08:09 | gmaxwell: | lechuga_: I expect we'll here some amount of outrage when the version after 0.9 is 0.10 (we heard a little previously) |
07:08:31 | op_mul: | gmaxwell: should make it tonal and really piss people off. |
07:08:52 | Luke-Jr: | op_mul: too late for that |
07:08:56 | Luke-Jr: | could do hex though |
07:09:17 | gmaxwell: | #if 0 ver=rand(); /*turned out to not have enough entropy*/ #elif 0 ver=arcfour(); /*oops*/ #else ver=getrandom... |
07:09:23 | Luke-Jr: | (unless we adopt a new version system altogether - Eligius has traditionally used tonal primes for versions) |
07:09:26 | op_mul: | v0.A.0 |
07:09:34 | op_mul: | ^ I'd ACK that |
07:09:55 | Luke-Jr: | op_mul: also note we've had 0.x.10 before IIRC |
07:10:02 | Luke-Jr: | s/IIRC/definitely/ |
07:10:09 | lechuga_: | version numbers should be unique/uniform but deterministic imho |
07:10:34 | Luke-Jr: | seriously, though, 0.10.0 is good |
07:11:42 | lechuga_: | seems fine |
07:11:46 | gmaxwell: | surprisingly users don't like referring to software by cryptographic hash. |
07:12:10 | Luke-Jr: | gmaxwell: that's probably the biggest annoyance with git .. |
07:12:16 | Luke-Jr: | enough that people invented git describe |
07:12:24 | op_mul: | gmaxwell: maybe we should hash the software, add it to namecoin, and then use a centralised website to resolve the version names to the hashes. |
07:12:34 | Luke-Jr: | … |
07:12:42 | gmaxwell: | I should start doing that. "I has having an issue with foxtrot zero alpha bravo two seven nine charlie bravo..." |
07:13:09 | Luke-Jr: | heh |
07:13:21 | lechuga_: | ha |
07:13:23 | Luke-Jr: | when I try to spell things out with words, I tend to end up with a random assortment of unusual words |
07:14:18 | gmaxwell: | There is a standard. It works better than adhoc words. |
07:14:20 | lechuga_: | 'aardvark, baloney, op_code, tango, juliet' |
07:14:27 | gmaxwell: | (NATO phonetic alphabet) |
07:14:41 | gmaxwell: | You can memorize it in a couple hours across a few days and you'll remember it forever. |
07:15:20 | Luke-Jr: | gmaxwell: I know there is, but I've never taken the time to learn it |
07:15:29 | gmaxwell: | I just made a little python quiz tool that showed me a letter and then I hit a key and it showed the right answer. |
07:15:38 | gwillen: | "M as in Mancy!" |
07:15:48 | moa: | Mike |
07:16:07 | gwillen: | I know, it's from Archer |
07:16:18 | gwillen: | * gwillen learned the NATO alphabet more or less by accident |
07:16:33 | gmaxwell: | op_mul: re software in namecoin, https://en.bitcoin.it/wiki/User:Gmaxwell/update_checking_requirements |
07:16:37 | moa: | base58 takes on a ne life |
07:18:24 | op_mul: | gmaxwell: *nods* my comment was a dig at onename.io, the namecoin resolver which encourages users to trust namecoin data blindly. NACK anti jamming sounds like a difficult problem to solve. |
07:20:17 | bramc: | Huh, apparently 'whisky tango foxtrot' really is NATO |
07:20:33 | moa: | roger |
07:20:33 | gmaxwell: | yea, really the only tools I know of are thresholds and having each message commit to all the messages they know about. |
07:20:41 | gmaxwell: | moa: no, romeo |
07:20:52 | moa: | over |
07:20:57 | gmaxwell: | oscar |
07:21:03 | moa: | lol |
07:21:06 | gmaxwell: | lima |
07:21:12 | gwillen: | c.c |
07:21:13 | moa: | gtfu |
07:21:16 | gmaxwell: | golf |
07:21:20 | gmaxwell: | heh |
07:21:38 | gmaxwell: | "He's gone NATO"... Yea, so the words are perhaps not optimal, but when the far end knows them it works so much better. |
07:21:54 | gwillen: | crucially, the words are designed to be easily distinguishable from one another |
07:21:58 | moa: | yep, it's hard to shake once you start using it |
07:22:01 | gwillen: | especially with the suggested pronunciations though few people use them |
07:22:11 | gwillen: | (e.g. papa is supposed to be "pa-PA".) |
07:22:20 | gmaxwell: | gwillen: I imagine that we could probably brute force a superior list, but you can't replace people knowing it. |
07:22:24 | gwillen: | right |
07:22:30 | bramc: | Oddities: Apparently 9 is pronounced 'niner' and 3 is pronounced 'tree', which is really odd because my kids pronounce it 'free' |
07:22:34 | gwillen: | and confusability with the standard list is almost as bad as confusability within your list |
07:22:37 | gwillen: | especially to start with |
07:22:52 | op_mul: | gwillen: same problem with BIP39. |
07:23:05 | moa: | bravi india papa |
07:23:48 | gmaxwell: | I'm a little out of practice and will stutter some while using it... but even still: my bank largely serves military people, and any time I need to relay data to them I switch to nato and they're super fluent and it goes very smoothly. |
07:23:49 | gwillen: | op_mul: oh, I have an alternative I strongly prefer to BIP39-style wordlists, although I never knew BIP39 was a thing |
07:24:24 | gmaxwell: | If only others didn't know it was a thing. :) |
07:24:24 | op_mul: | I enjoyed haiku encoded IPv6 addresses a lot. not practical, but fun. http://gabrielmartin.net/projects/hipku/ |
07:24:39 | rusty: | (See, it's an irregular verb. "I am being witty" / "You are wandering off topic" / "He is unwelcome on this channel" :) |
07:24:46 | gwillen: | op_mul: I prefer to divide the bits to be memorized into chunks of equal length, then represent each chunk by a user-selected word whose (last n bits of your favorite hash) are that value |
07:24:59 | gwillen: | op_mul: my current implementation uses (MD5, 12) for the parameters and seems to work well |
07:25:11 | op_mul: | gwillen: please use a proper KDF. |
07:25:14 | gwillen: | huh? |
07:25:21 | op_mul: | (it's a joke) |
07:25:25 | gwillen: | oh, bahahahaha |
07:26:00 | gwillen: | anyway I prefer my scheme to fixed-wordlist schemes, because you can always reconstruct the bits from the words without knowing the wordlist |
07:26:09 | gwillen: | and you can use whatever wordlist you like in constructing the phrase |
07:26:18 | gmaxwell: | sort of an odd constraint on the wordlist, distinct partial hash values. obviously you need a semantic dicationary and a dynamic programming solver to find the solution set of words that are most sensible. :P |
07:26:44 | bramc: | gwillen, But you're using md5, which is horribly insecure. Better to use 5-ripemd-160 |
07:26:52 | gwillen: | gmaxwell: the point is you don't need a fixed wordlist; you can use any wordlist you want and any choice you want for each word (from the set that matches) |
07:27:04 | gmaxwell: | I made some tools a while back that build word lists for visual distinctiveness, I had a constrant that each three letter prefix had to be distinct; so you could resolve things based just on the first letters. |
07:27:12 | gwillen: | * gwillen nods |
07:27:30 | gwillen: | a disadvantage of my scheme is that it's easy to accidentally (as the user) choose a confusable word |
07:27:40 | gwillen: | and of course whatever word you confuse it with will not have the same hash |
07:27:47 | gmaxwell: | gwillen: you stil have state too, in that you must rember the hash function and number of bits. |
07:27:48 | gwillen: | unless you use some canonicalization scheme first (like stemming) |
07:28:12 | gwillen: | well, that's pretty minimal state; I would generally expect that if this were to be standardized, you'd at least fix the hash function, and probably fix the bits too |
07:28:32 | gwillen: | there are only so many common english words, so there are very few reasonable values for the bits parameter |
07:28:44 | moa: | sit in seat XXF on airplanes and see if the hostess refers to you as 'Fox' or 'Foxtrot' |
07:28:56 | gmaxwell: | it would still probably be best to have a standard dictionary, to allow recovery if some words are corrupted. |
07:29:10 | gwillen: | yeah, that would be ideal |
07:29:25 | gwillen: | in fact, ideally you would be able to use autocomplete on your passphrase |
07:29:34 | gwillen: | so as not to have to type all the goddamn words out completely |
07:29:49 | gmaxwell: | that was my three character prefix uniqueness constraint. |
07:29:59 | gwillen: | obviously you would not want to use this scheme with a learning autocomplete |
07:30:00 | gmaxwell: | it actually was pretty burdensome. |
07:30:04 | gwillen: | huh, *nods* |
07:30:15 | gwillen: | how big a dictionary were you picking? |
07:30:15 | gmaxwell: | lol. "autocomplete leaked my password" |
07:30:18 | gwillen: | I really like 12 bits |
07:30:59 | op_mul: | I don't think passwords really matter. |
07:31:02 | gmaxwell: | gwillen: trying to go for 9 bits (pgp wordlist length), with a simple english dictionary input. (in order to reduce confronting non-native speakers with uncommon words) |
07:31:12 | gwillen: | * gwillen nods |
07:31:17 | gwillen: | looks like BIP39 used 11 |
07:31:30 | gwillen: | and first-four-letters-unique |
07:31:34 | op_mul: | for web based services rate limiting makes even weak passwords fine, if somebody is on my box enough to get an encrypted wallet then they can just snarf the keys from memory next time they are there. |
07:31:41 | gmaxwell: | doesn't really use any, the spec is mostly a crappy brainwallet in disguise. |
07:31:52 | gmaxwell: | The disguise thinly slathered on because of the huge pushback. |
07:32:41 | op_mul: | I'm more upset BIP38 seems to have become a "standard" |
07:32:43 | gwillen: | well, it eliminates the first most serious problem with brainwallets, by not allowing the user to pick an arbitrary password and turn it into a key |
07:32:54 | gmaxwell: | gwillen: not so. |
07:33:08 | gwillen: | oh? Using a fixed wordlist appears to eliminate that possibility. |
07:33:55 | gmaxwell: | gwillen: no, the decoder is basically a brainwallet decoder, nothing is required to use the 'recommended' encoding procedure. |
07:34:25 | gwillen: | oh, I see that you are correct |
07:34:30 | gmaxwell: | with a loltastic 2048 rounds of PBKDF2. |
07:35:42 | gmaxwell: | So there was an original scheme based on the electrum stuff that had an encode and decode. The trezor guys wanted to make it a brainwallet. There was a heated argument. They eventually compromised with the upfront encoding scheme which I think they and many people do not use. The electrum author asked his name to be removed from the document, just the usual fun in bitcoin land. |
07:36:37 | gmaxwell: | We have no process to control for inadvisable specifications, if their authors are strong willed and not convincable. |
07:38:16 | bramc: | What's the current lightweight wallet protocol? Is that electrum? |
07:38:43 | op_mul: | no. |
07:39:09 | op_mul: | electrum is a sort of similar system, but uses servers run by the community rater than other nodes in the network for SPV. |
07:39:16 | fluffypony: | SPV is the current protocol |
07:39:49 | op_mul: | same privacy model. you connect to random people and they get to know everything about you and your wallet. Electrum has SSL though, so it's probably more private from passive observation. |
07:40:09 | gmaxwell: | bramc: "bitcoin".. the bitcoin protocol includes a lightweight mode. though electrum is another one. (it grew out of a more centeralized original design. the author is super responsive to security criticism and has done a lot to make it similar to SPV wallets in security, in some ways a bit worse, some ways a bit better) |
07:40:51 | gmaxwell: | We know tools to make them better yet, but those aren't implemented so far. |
07:42:47 | moa: | has there been a documented instance of a malicious electrum server yet? |
07:43:02 | op_mul: | define malicious. |
07:43:23 | gmaxwell: | how would you even know if it was malicious? malicious could be coorelating all your addresses and selling the info to the highest bidder years down the road. |
07:43:28 | moa: | not doing what is supposed to i guess |
07:43:40 | gmaxwell: | unfortunately some kinds of misbehavior leave no evidence. |
07:43:56 | moa: | yeah that's why i said 'documented' |
07:44:01 | gmaxwell: | There have been broken ones before. e.g. that were forked off the blockchain and would cause you to miss transactions. |
07:44:22 | op_mul: | electrum servers and nodes acting for SPV clients can both lie as much as they want by omission. I doubt anybody would notice that happening though. |
07:44:54 | gmaxwell: | Fortunately the security model was upgraded to spv like long ago to one where most of the obvious profitable forms of evil are precluded. |
07:45:03 | gmaxwell: | The remaining ones are mostly DOS attacks and privacy related. |
07:45:42 | moa: | so doing what it says on the tin for now |
07:45:48 | op_mul: | electrums privacy risk is a bit higher because they use a small set of servers which are randomly used. the more you run the client, the higher chance that every node will know everything about your wallet. |
07:46:18 | op_mul: | while that's true for bitcoin SPV too, there's a much larger set (thousands versus like, 10) |
07:46:23 | gmaxwell: | it's unfortunate there too, because it would be easy to strenghten that with PIR. Though it doesn't appear that anyone is working on that. |
07:46:53 | gmaxwell: | op_mul: well also bitcoin spv clients usually use the bloom which has slightly better privacy (or at least can if used better, though it commonly isn't) |
07:47:27 | gmaxwell: | (all in all the bloom filtering may just have too high a snake oil factor and is actually net privacy negative) |
07:47:50 | op_mul: | did you read the paper about that? it concluded that even with stupidly high FP rates the privacy of bloom filters was zero. |
07:48:37 | gmaxwell: | I did, hm, didn't walk away with the conclusion that it was zero. only _MOSTLY_ zero. :P |
07:48:49 | op_mul: | bitcoinj filters for example aren't deterministic, so you can intersect two filters from one peer to remove the junk. and even without that trick, the number of matches that could be excluded was very high. |
07:49:49 | gmaxwell: | There is a big difference between _MOSTLY_ zero and all zero. Mostly zero is slighly non-zero. |
07:50:54 | op_mul: | I don't feel it matters that much. even a fuzzy privacy leak can be made concrete with other information sources. given how unprivate the rest of bitcoin transactions are, another source isn't hard to find. |
07:51:21 | gmaxwell: | Yea, I'm mostly being silly, don't mind me. I know it's awful. |
07:51:42 | gmaxwell: | This is also why I really was not happy about the bloom bait stuff on 'stealth' addresses. |
07:52:05 | gmaxwell: | Esp since a normal desktop cpu can ECDH at many times the speed of the network anyways. |
07:52:50 | gmaxwell: | (about 10,000x the speed of the network, in fact) |
07:53:20 | op_mul: | I'm not sure stealth addresses are a good thing. I can see them being tacked onto a chronically address reusing wallet and that being called a solution. I know change addresses still leak information, I've done a lot of work with that fact, but it's a lot harder than straight up googling. |
07:55:16 | op_mul: | one of the main problems are just merging, and the fact that humans like round numbers. for the most part that seems to play out quite well for the privacy destroying side of things. |
07:56:02 | gmaxwell: | It's a bandaid, no doubt. |
07:56:32 | op_mul: | in a lot of ways it might have been better to keep bitcoin only visible down to four places for the time being, leaving the rest for later use. bunches of satoshi outputs are very identifying. |
07:56:40 | gmaxwell: | But is it more snake oil than bandaid? I don't ... think.. so? then again expirence shows users are just going to give their scanning keys to some server who will then log them. |
07:57:13 | gmaxwell: | op_mul: it was originally only exposed to two places in wxbitcoin |
07:57:26 | op_mul: | yes, I think Luke-Jr changed that. |
07:57:49 | gmaxwell: | but well, lots of fud about zomg what happens if bitcoin goes up in value. really most things use round amounts ... except miners. |
07:58:10 | gmaxwell: | I had a little campaign to try to get pools to use round payout amounts in 2011, no luck. |
07:58:44 | op_mul: | people also use values mapped to USD, which is why a lot of things are paid istupid granularity. |
07:59:13 | gmaxwell: | well you can do that at finite precision, e.g. bitpay uses four places after the dot. |
07:59:57 | op_mul: | I wasn't aware of that. |
08:00:38 | Emcy: | gmaxwell that guy is flapping in #bitcoin again |
08:00:59 | Emcy: | jesus i have i havent been logging joins/parts for 4 years |
08:01:43 | Luke-Jr: | gmaxwell: bitpay uses 6 places now |
08:02:06 | Luke-Jr: | gmaxwell: I advocated against rounding miner payouts, FWIW. I always found it annoyign as a miner, and actively switched pools to get away from it. |
08:02:45 | gmaxwell: | Luke-Jr: I don't think anyone ever did it. There were places that had a threshold minimum payout, but not ones that would make numbers round. |
08:02:57 | gmaxwell: | (and yes, I recall you wouldn't do it) |
08:02:57 | Luke-Jr: | gmaxwell: slush always did when I used it.. |
08:03:30 | phantomcircuit: | gmaxwell, why? |
08:03:57 | Luke-Jr: | I wish bitpay would use all 8, tbh |
08:03:59 | gmaxwell: | phantomcircuit: why did I want it? |
08:04:25 | gmaxwell: | Because ending up with tiny dust means you must merge coins which is bad for privacy, or end up with zillions of tiny useless outputs. |
08:04:55 | gmaxwell: | (which is bad for the network, and also bad for privacy if you let your wallet ever use them) |
08:05:36 | phantomcircuit: | why round numbers, isn't thresholding good enough? |
08:05:37 | Luke-Jr: | it's not that often you get paid exactly the same amount you want to pay. |
08:05:37 | op_mul: | some wallets seem to use high precision fees too, which is weird. |
08:09:12 | gmaxwell: | phantomcircuit: because thresholding means you get paid 1.12345678 and since you'll pretty much never spend exactly that amount you eventually end up with a 0.00005678 change. Which is identifying. |
08:09:52 | phantomcircuit: | oh |
08:09:55 | phantomcircuit: | shrug |
08:10:05 | phantomcircuit: | pretty much you'll never end up spending exact amounts |
08:13:42 | gmaxwell: | oh after getting rid of the initial dust, actually things end up quite round. |
08:26:08 | phantomcircuit: | gmaxwell, hmm |
08:35:45 | lclc_bnc: | lclc_bnc is now known as lclc |
08:48:21 | bramc: | A good way to get rid of dust is to do a coinswap with a massive aggregator who collects dust and gives big units change and then takes all the dust they've collected and makes it into a single big utxo in one big transaction |
08:51:01 | gmaxwell: | There ist dustbegone which basically just coinjoins dust from many people into a single all-fee (no output) transaction. |
08:57:29 | bramc: | Well that isn't terribly useful |
08:57:59 | bramc: | The advantage of coinswap is that it can use a vastly larger pool, basically letting the pool pile up until it's collected enough. |
09:05:14 | sinisalo.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:14 | sinisalo.freenode.net: | Users on #bitcoin-wizards: andy-logbot jb55_ soundx vmatekole Dr-G2 grau d1ggy fanquake adlai davejh69 cbeams aburan28 woah nuke1989 RoboTeddy waxwing NewLiberty nullbyte coiner maraoz [\\\] op_mul grandmaster TheSeven go1111111 Graet_ Transisto copumpkin adam3us moa pi07r koshii bbrittain Aquent hashtag_ bitbumper atgreen hashtag jasonw22 huseby gues Shiftos Baz___ spinza DoctorBTC Graftec BananaLotus joris dansmith_btc Apocalyptic phantomcircuit EasyAt tromp PRab_ |
09:05:14 | sinisalo.freenode.net: | Users on #bitcoin-wizards: tlrobinson Guest22767 isis espes___ jbenet SDCDev null_radix GAit hollandais midnightmagic Muis Luke-Jr BlueMatt ebfull grishnakh__ starsoccer Guest12706 gavinandresen postpre OneFixt danneu catcow TD-Linux ryan-c roasbeef amiller smooth optimator_ mmozeiko Alanius Emcy epscy prodatalab kobud GnarSith dgenr8 bosma JonTitor Hunger- MRL-Relay devrandom fluffypony jgarzik mr_burdell mkarrer samson_ HaltingState btc__ NikolaiToryzin CryptOprah |
09:05:14 | sinisalo.freenode.net: | Users on #bitcoin-wizards: mappum Iriez c0rw1n_ kanzure warren Krellan nanotube fenn otoburb LarsLarsen coutts bobke jchp nsh_ SubCreative asoltys_ sl01_ arowser K1773R nickler_ a5m0 PaulCapestany @ChanServ Meeh wumpus comboy btcdrak ahmed_ lnovy tdlfbx heath eordano luny nsh gribble gwillen Nightwolf Anduck Dyaheon cfields digitalmagus8 stonecoldpat gmaxwell pigeons andytoshi lechuga_ artifexd hguux_ michagogo kumavis warptangent Fistful_of_Coins HM2 paperbot maaku |
09:05:14 | sinisalo.freenode.net: | Users on #bitcoin-wizards: Cory Guest38445 coryfields iddo kinlo azariah yoleaux Logicwax berndj lclc s1w Eliel_ sneak harrigan sipa AdrianG livegnik burcin wizkid057 tromp_ poggy Taek throughnothing petertodd crescendo so [d__d] BigBitz jaromil helo Keefe phedny BrainOverfl0w harrow |
09:05:14 | sinisalo.freenode.net: | [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp |
09:20:03 | lclc: | lclc is now known as lclc_bnc |
09:49:36 | lclc_bnc: | lclc_bnc is now known as lclc |
10:18:39 | GnarSith: | GnarSith has left #bitcoin-wizards |
10:55:27 | lclc: | lclc is now known as lclc_bnc |
11:25:56 | lclc_bnc: | lclc_bnc is now known as lclc |
11:36:43 | Eliel_: | gmaxwell: unless massive coinjoin transactions are organized for cleaning up the dust you don't want to use :P |
12:56:12 | nsh: | did gmaxwell explain his probabilist payment (re)invention? |
12:56:17 | nsh: | -ic |
13:07:02 | Emcy: | GENTLEMEN |
13:07:17 | op_mul: | don't you dare. |
13:07:33 | Emcy: | fuck you im doing it |
13:07:58 | Emcy: | https://en.wikipedia.org/wiki/List_of_British_banknotes_and_coins we start naming major releases of core after world coinage, past and current |
13:09:24 | Emcy: | internal codenames i mean |
13:10:37 | Emcy: | this is actually a feild of study called numismatics, wow |
13:17:35 | Emcy: | https://en.wikipedia.org/wiki/List_of_historical_currencies |
13:21:57 | nsh: | * nsh does not disapprove, as long as one of them is the Pengo |
13:23:52 | lclc: | lclc is now known as lclc_bnc |
13:53:53 | vdo: | vdo is now known as vdo_ |
13:54:02 | vdo_: | vdo_ is now known as vdo |
13:54:47 | wallet42: | wallet42 is now known as Guest56328 |
13:54:47 | wallet421: | wallet421 is now known as wallet42 |
14:15:55 | Eliel_: | Does a signed git commit contain enough information that you could use that to generate a bitcoin address that only the committer could generate a private key for? |
14:16:37 | sipa: | if you would sign it using a cryptosystem compatible with secp256k1... |
14:16:43 | sipa: | which afaik gpg does not have |
14:17:26 | nsh: | heh |
14:21:24 | Eliel_: | (there's someone here very enthusiastically trying to work out how to create a changetip for git commits) |
14:21:57 | sipa: | i don't believe it is possible |
14:22:34 | nsh: | there was a thread earlier this year: http://lists.gnupg.org/pipermail/gnupg-devel/2014-January/028137.html |
14:24:43 | Eliel_: | we also played some ball on how worldwide git commits could perhaps be used as a "blockchain" with the commits themselves functioning as proof of work. |
14:25:30 | Eliel_: | It wouldn't quite have the same security properties as bitcoin blockchain, but I suspect it'd be very difficult to manipulate without getting caught. |
14:25:49 | sipa: | why would it not have the same security? |
14:27:08 | Eliel_: | I suspect it'd have better security in some respects. However, I doubt it could be as reliable with just automated verification |
14:27:27 | sipa: | well it's just sha1 |
14:27:35 | sipa: | but if you don't care about that, there is really no difference |
14:27:57 | sipa: | you'd need to restrict yourself to only the leftmost parent or something, as otherwise it forms a dag instead of just a chain |
14:29:37 | Eliel_: | I don't think you should try to make it into a blockchain. Better to keep it as a crosslinked web. |
14:30:00 | sipa: | i don't think so either; it would be less efficient |
14:30:08 | sipa: | but there's no reason why it couldn't be done |
14:30:52 | Eliel_: | it might have slower convergence than bitcoin has though |
14:31:16 | op_mul: | Eliel_: have you considered that changetip is actually a negative? |
14:31:35 | Eliel_: | op_mul: nope, why's that? |
14:32:50 | op_mul: | I find it pretty insulting, really. it's people putting a value on something I've contributed just because I could. there's a big difference between "I wrote this because I could", and "I wrote this and somebody values it to be worth 17c". |
14:34:37 | sipa: | plus it can lead to really skewed incentives (talking about commits specifically, like tip4commit does)... where people end up creating tons of small commits, object against squashing, try to "fix" the tiniest amounts possible |
14:34:52 | nsh: | * nsh nods |
14:35:21 | op_mul: | yes, for code it boils everything down to Minimum Viable Tippable Commit. |
14:35:59 | sipa: | op_mul: fun nickname, though i hope you don't mean to imply you're disabled :) |
14:37:06 | op_mul: | sipa: it's a reference to Mastering Bitcoin, which instructs people getting started in the world of Bitcoin to create scripts without signatures, containing arithmetic using OP_MUL as an example. |
14:37:14 | sipa: | hahaha |
14:37:28 | sipa: | anyway, my complaint is mostly about automated tips |
14:37:44 | sipa: | when humans are involved to decide on tip value, that's not really a problem |
14:38:17 | sipa: | it's a cultural thing i guess - tipping is very different around the world |
14:38:35 | hearn: | op_mul: doh. who wrote that book? |
14:38:39 | sipa: | in some places it mandatory, in some places completely optional, and afaik in some places just insulting |
14:38:48 | sipa: | hearn: antanana something |
14:38:51 | sipa: | poulos |
14:39:00 | hearn: | oh yes. the former blockchain.info security chief :) |
14:39:05 | op_mul: | hearn: andreas antonopoulos, published by o'reilly. |
14:40:20 | op_mul: | sipa: yes, I can't speak for other cultures but I don't think I've ever tipped a person before. I've been tipped by foreigners (americans) and it was incredibly awkward. |
14:40:31 | sipa: | op_mul: where are you from? |
14:40:44 | op_mul: | eh, rather not say sorry. |
14:40:46 | sipa: | ok |
14:40:48 | sipa: | np |
14:41:27 | fluffypony: | "Minimum Viable Tippable Commit" |
14:41:29 | fluffypony: | I love that |
14:41:48 | hearn: | i think micropayments can be very interesting, but people should opt in to receiving them |
14:42:15 | sipa: | here in switzerland it seems mostly normal to let a waiter keep the change or something, but certainly not weird if you don't |
14:42:19 | sipa: | agree |
14:42:37 | fluffypony: | we decided to stop doing any and all bounties with Monero, much to the chagrin of many, and the reasoning is because bounties most often attract a class of developers who will do the minimum work required to receive the bounty, and then abandon it and never maintain it |
14:43:13 | hearn: | one thing i'd like to play with some day is a p2p wallet + rich text editor + doc viewer hybrid, so people can publish interesting articles and essays, with a preview of the first few paragraphs, then there is an "instant buy" button that reveals the article immediately and makes a micropayment in the background |
14:43:33 | hearn: | i read tons of news and would absolutely pay for more, if i could impulse buy :) |
14:44:00 | Emcy_: | how does that help with the clickbait problem |
14:44:05 | op_mul: | it's hard to quantify the value of a change, too. a single line alteration could take days of research, but on the face of it might not be particularly arduous. |
14:44:22 | hearn: | don't press buy on articles that start with "I knew pets could be crazy but this will BLOW YOUR MIND" |
14:44:25 | hearn: | problem solved |
14:44:40 | sipa: | hearn: i should stop reading facebook then? what? |
14:45:01 | fluffypony: | op_mul: or the change consists of 45 lines, but then you suddenly realise you can distill those down to 4 lines, and then everyone thinks it was solved in 4 lines :-P |
14:45:14 | hearn: | sipa: well, you should stop clicking on news feed items that involve ten weird tricks ;) |
14:45:25 | fluffypony: | "number 7 will shock you!" |
14:46:03 | Emcy_: | 0heh |
14:46:14 | Emcy_: | levity aside clickbait is killing the fabric of society |
14:46:43 | Emcy_: | anything that gets away from the page impressions at all costs model has to help with that |
14:47:02 | Emcy_: | thats why i consider adblock a moral imperative pretty much |
14:47:17 | Eliel_: | op_mul: I find that a weird (to me anyway) way to think about money. Somehow feels like there's some overly complex thinking behind it. |
14:48:46 | sipa: | Eliel_: ever seen http://www.youtube.com/watch?v=u6XAPnuFjJc ? |
14:49:55 | Eliel_: | sipa: but yes, I've seen that. |
14:50:13 | AdrianG: | Emcy_: adblock is a black budget project from google |
14:50:29 | Eliel_: | for that reason, I wouldn't ever use really big bounties on code. |
14:50:34 | Emcy_: | ok m8 |
14:50:54 | op_mul: | Eliel_: that's entirely possible. I can't really assert that my views are sane, I endlessly fail to justify my own use of currency. I think that in the case of change tip, a "thanks" would be a lot easier and a lot better received. |
14:50:59 | AdrianG: | Emcy_: think about it. adblock can cement their pole position in search. |
14:51:28 | kanzure: | didn't i ban you |
14:51:43 | Emcy_: | chemtrails |
14:51:53 | AdrianG: | kanzure: you simply dislike my unorthodox ideas and thinking outside the box |
14:52:01 | AdrianG: | google could take down adblock any minute from their app store. |
14:52:14 | Emcy_: | google isnt in the search business m8. thats the loss leader |
14:52:26 | AdrianG: | Emcy_: without their search - they are dead. |
14:52:33 | AdrianG: | its just a tool to harvest data and direct ads. |
14:52:38 | AdrianG: | relevant ads you will not even consider ads. |
14:53:06 | Eliel_: | op_mul: Well, I do find it very weird to begin with that you'd think getting a donation for your work assigns a value to it. |
14:53:21 | fluffypony: | nah, AdBlock is obviously a CIA black ops project |
14:53:23 | fluffypony: | duh |
14:53:38 | hearn: | ads are a working form of micropayments |
14:53:40 | AdrianG: | see, on android it would interfere, and thus was removed |
14:53:41 | AdrianG: | https://adblockplus.org/blog/adblock-plus-for-android-removed-from-google-play-store |
14:53:42 | hearn: | they aren't related to clickbait. |
14:53:56 | AdrianG: | yet, chrome extension is kept in the play store. why? |
14:54:31 | Emcy_: | thats different hearn |
14:54:47 | AdrianG: | besides. adblock/ads is one thing. |
14:54:48 | Emcy_: | with ads the site gets paid even if the content was a pile of shit |
14:54:55 | AdrianG: | half of content you see online is pure clickbait |
14:55:02 | AdrianG: | "10 reasons why you should never irc" |
14:55:14 | AdrianG: | "a list of things you can never do unless..." |
14:56:01 | op_mul: | Eliel_: if your neighbour asks you to move some bricks, and they pay you $2 at the end, doesn't that put a value on the work you did? they've qualitatively looked at the situation and decided that value is right given the circumstances. |
14:56:05 | AdrianG: | Emcy_: some of that content is comissioned anyway, and ads wouldnt matter |
14:56:26 | AdrianG: | for the right amount of $ you can publish your content almost verbatim on leading blogs. |
14:56:40 | helo: | if you build and launch a space shuttle to mars, and someone pays you $2, is that what the work was worth? |
14:56:54 | AdrianG: | helo: thats some expensive $2 |
14:56:55 | Pan0ram1x: | Pan0ram1x is now known as Guest3112 |
14:56:56 | Eliel_: | op_mul: if the work you did was something they asked for, certainly. However, in the case of a donation, you did it on your own initiative. |
14:57:48 | Eliel_: | op_mul: also, another difference is that in the case of software, your work benefits more than just that one person. |
14:58:21 | op_mul: | that's the bit I don't like. I've decided that I will do something for free, for whatever internal reason, and then somebody else has applied a value to it after the fact. |
14:59:02 | helo: | they paid you some of what they could based on some emotional motivation |
14:59:15 | Eliel_: | op_mul: how do you know they intended to apply value to it? How do you know they didn't just want show you some appreciation? |
14:59:34 | fluffypony: | op_mul: so when you have someone round for supper and they bring a bottle of wine as a gift, does that bottle of wine apply value to the meal you've made? |
14:59:45 | AdrianG: | sounds like op_mul is against donations. i agree, i think its immoral on some level. |
15:00:10 | sipa: | in general, when people give gifts, they are seen as an 'additional reward'; if they give money, it is seen as compensation |
15:00:34 | sipa: | for example, in hospitals if you donate blood, they don't pay you, but they may offer drinks/snacks/... |
15:00:38 | op_mul: | yes. |
15:00:53 | op_mul: | well, the blood bit is so people don't faint as much |
15:01:25 | sipa: | if they would pay instead, even a significantly larger amount, people wouldn't do it anymore if the amount wasn't something they would see as 'wage' |
15:02:35 | sipa: | though to be honest, commit tips do not have that effect for me |
15:03:11 | hearn: | nor me |
15:03:28 | hearn: | i like people saying thanks (a lot), but if someone sends me enough money to buy my next cup of tea, i also appreciate that a lot |
15:03:42 | hearn: | it's just a social thing. tipping is hard with today's technologies, only cash works really, so most people never receive tips for anything |
15:03:44 | hearn: | so it feels weird |
15:04:01 | hearn: | bitcoin suddenly makes tipping available for everyone, i think people will get used to it |
15:04:06 | sipa: | i've often refused tips after helping people |
15:04:44 | hearn: | changetip is nice because it lets people specify amounts in terms of real, useful objects, like coffees or beers |
15:04:55 | hearn: | it's easier to appreciate a free beer than a 0.000353 btc tip |
15:05:17 | sipa: | how does it know the price of a beer where i live? :D |
15:05:34 | hearn: | yeah in switzerland you need to get two beers or two coffees worth of tips :) |
15:06:23 | op_mul: | vast majority of changetip transactions I see are for inane amounts like 100 satoshi though. |
15:06:52 | sipa: | at least they don't result in individual blockchain transaction (afaik?) |
15:07:00 | hearn: | changetip is basically a bank, yes |
15:07:05 | op_mul: | no they don't. |
15:07:13 | sipa: | that's fine for an application like this, imho |
15:08:57 | op_mul: | sure. |
15:09:48 | Eliel_: | sipa: people really do have strange behaviours when it comes to money that don't really make sense if you take some distance and reduce the situation to it's essential contents. |
15:14:05 | op_mul: | Eliel_: humans are squishy and irrational. |
15:15:42 | Eliel_: | op_mul: I know, I have firsthand experiences about it every day. Yes, even when I'm by myself :P |
15:17:43 | AdrianG: | so is changetip gaining traction? |
15:17:49 | AdrianG: | or is it still their viral campaign? |
15:19:09 | kanzure: | ask in #bitcoin |
18:14:59 | kanzure: | "Another caveat is that in any anonymity system in which client churn is present AND users maintain long-lived pseudonyms of any kind, client churn can be used by a smart attacker to de-anonymize clients via intersection attacks. This basically means that if you want "the strongest possible" anonymity protection, you basically either have to (a) never maintain pseudonyms or use time-linkable communication sessions at all (difficult!), ... |
18:15:05 | kanzure: | ... or (b) eliminate client churn completely (also difficult!). Our Buddies paper explores this tradeoff and the (admittedly limited, so far) practical defenses that we can build against intersection attacks: " |
18:15:09 | kanzure: | from https://news.ycombinator.com/item?id=8762219 |
18:15:49 | kanzure: | "Dissent does not specify or care how exactly a group is formed, and the sybil/sockpuppetry attack protection it provides is inevitably only as strong as the group formation mechanism. Dissent's accountability guarantee basically means that - unlike most anonymity protocols - it is not any more vulnerable to sybil or sockpuppetry attacks than (say) an otherwise-comparable group communication protocol offering no anonymity." |
18:26:17 | Eliel_: | kanzure: couldn't you defend against intersection attacks by preparing some chaff in the form of random messages that will make it look like you're online even though you aren't? At least in certain kinds of systems. |
18:26:42 | gmaxwell: | you can't be online if you have no power. |
18:27:10 | Eliel_: | naturally, you'd need to leave them with third parties in such a case |
18:27:17 | gmaxwell: | (IOW, your apparent onlineness can never be statistically indpendant of your ability to be online) |
18:28:39 | Eliel_: | you don't need to succeed too often at seemingly being online even when you aren't to make analysis orders of magnitude harder |
18:44:42 | Dr-G: | Dr-G is now known as FBI-Agent |
19:08:00 | luke-jr_: | luke-jr_ is now known as Luke-Jr |
19:43:24 | FBI-Agent: | FBI-Agent is now known as Dr-G |
20:01:10 | fluffypony: | http://hackingdistributed.com/2014/12/17/changetip-must-die/ |
20:05:45 | Taek: | I do find it annoying to find threads littered with 10 cent tips. But changetip is already halfway to being a micropayment hub, maybe they can pivot? |
20:06:17 | fluffypony: | maybe |
20:06:44 | fluffypony: | how much of a need is there for micropayments? |
20:07:00 | fluffypony: | catching a minibus taxi here in South Africa costs between R10 - R15 |
20:07:11 | fluffypony: | which is like $0.90 to $1.40 or so |
20:08:13 | fluffypony: | so with BTC, Electrum tells me the fee would be 0.000129 on that transaction |
20:08:56 | fluffypony: | so ~5% of an actual micro-transaction in fees |
20:12:03 | tacotime: | well, i think the locktime thing from peter todd is supposed to enable them with smaller fees. there's a writeup on it somewhere on BCT iirc. |
20:13:28 | fluffypony: | yeah, which I imagine would give changetip less value as a micropayment hub |
20:15:07 | Taek: | Also relevent: http://www.drdobbs.com/architecture-and-design/farewell-dr-dobbs/240169421 |
20:16:11 | Taek: | imagine paying something like 1 cent to read a blog post. You'd have to be careful about abuse, but it could be superior to ad revenue |
20:16:23 | kanzure: | isn't the changetip thing more suitable for #bitcoin |
20:16:43 | Taek: | yeah probably |
20:16:45 | tacotime: | probably |
20:17:15 | kanzure: | as for micropayments, i suspect that the interesting designs there will involve extensions or alternatives to the microchannel hub and spoke model |
20:17:26 | kanzure: | rather than individual payments |
20:19:23 | Taek: | probably more relevant: if you've got a server that uses micropayments as a primary source of revenue, at what point does repeated signature verification become cumbersome? |
20:19:42 | Taek: | If you're serving a 45kb page in return for a signature, will cpu cost start to exceed bandwidth cost? |
20:21:55 | gmaxwell: | I have a new scheme for probablistic payments that works in the current network. ::shrugs:: but I think the "theoretical interest" in many of these things is more than the actual interest. |
20:23:03 | kanzure: | probabilistic-on-threshold payments may be interesting |
20:23:33 | kanzure: | what's probabilistic about your probabilistic payments? |
20:24:01 | gmaxwell: | It seems to me that people are weirdly spazzy about chance. They'll gamble in one turn, with negative expectation, but not like their 1 cent micropayment song purchase to be probablistic. |
20:24:38 | kanzure: | probably because they are trying to listen to that specific song? |
20:24:53 | gmaxwell: | kanzure: You pay someone, or don't. Unknown to you, only the reciever. With some known odds. It allows very small average payments with reduced transaction volume. There have been schemes forever for it in bitcoin, prior ones didn't work in the existing network. |
20:25:13 | gmaxwell: | Well you prove you tried. So the seller accepts your attempt as payment. |
20:26:02 | Taek: | probabilistic payments might make more sense for something like a bittorrent download |
20:26:09 | kanzure: | also, i don't know how important this sort of level of pedanticism is, but mostly you would be buying a license to the song rather than buying a song itself (buying data doesn't work very often) |
20:26:23 | Taek: | if you make a payment every 32kb or whatever, but download 3GB, your variance is going to be low |
20:28:41 | gmaxwell: | kanzure: thats not helpful here. But noted. :P |
20:29:10 | gmaxwell: | (and really I didn't even mean the licensing! since you're going to be pedantic, I mean buying the service of sending it to me!) |
20:38:59 | kanzure: | well i think the difference does matter, because then you know to look for ways to make payment contingent on receipt or non-reciept of data. not sure. |
20:42:52 | phantomcircuit: | gmaxwell, probabalistic payments work if im paying for a website paywall |
20:43:00 | phantomcircuit: | not so much for minibux taxi in SA |
20:43:22 | phantomcircuit: | oops gtg |
20:43:23 | phantomcircuit: | 3 |
21:29:50 | nuke__: | nuke__ is now known as nuke1989 |
22:17:58 | luny`: | luny` is now known as luny |
22:34:11 | kanzure: | i don't understand this part "Any fork in publication is obvious as it would require different Bitcoin addresses to be used" maybe they are using multiple outputs already, how would i know? |
22:34:38 | kanzure: | (from |
22:34:54 | kanzure: | s/multiple outputs/different pubkeys |