--- Log opened Tue Dec 31 00:00:42 2013
00:03 < brisque> that's bold, announcing that you're exploiting people's hardware on a public forum.
00:05 < brisque> depending on the country that's most certainly illegal, akin to breaking and entering. if they get charged for doing it or not is a whole different matter.
00:05 < CodeShark> it's not announcing it that's illegal - it's doing it that's illegal
00:06 < brisque> certainly, but announcing that you did it is foolhardy
00:07 < brisque> oh dear. the user has also posted their KNC order number on the forums, and their country.
00:14 < brisque> who connects an embedded device directly to the internet anyway?
00:19 < phantomcircuit> brisque, people putting them in a dc who dont pay attention
00:20 < brisque> right. forgotten people might be doing that.
00:37 < gmaxwell> hey, could be worse, he could have posted instructions for making it look like one 1/4 of the hardware failed, while sending the 1/4 of the hashrate to himself.
00:39 < brisque> not even that, just skimming 5% of the hash power wouldn't be noticed. over 1000 units they claim to have found, that's uh.
00:39 < brisque> 30TH.
00:40 < gmaxwell> well he only got into 28 of them I think.
00:40 < brisque> the "disclosure" is shit because we know that most of these units won't be patched in a reasonable timeframe. there's a lot that are now going to be under attack by people hoping to make a quick buck.
00:45 < gmaxwell> brisque: they don't need to be 'patched' they just need to have their password changed to something not crackable.
00:49 < brisque> gmaxwell: haven't brainwallets showed that users, even technical ones, can't make secure passwords to save their own money?
00:50 < gmaxwell> brisque: brainwallets add the extra expectation that they'll remember those passwords.
00:50 < gmaxwell> No need to remember these... just write them down.
00:51 < brisque> the point is more that people won't no matter what is being told to them. protecting $10000 of mining equipment is a difficult job when they're advertising what they are at connect time.
00:53 < gmaxwell> brisque: uh? all my miners have 128 bit passwords...
00:53 < brisque> you're not an average user.
00:53 < gmaxwell> (even though they're not internet exposed, just a standard practice. If I weren't a chickenshit I'd turn off the web interfaces entirely, but I'm a bit afraid of getting locked out.)
00:54 < gmaxwell> brisque: in any case, it's easy to give good advice for this.  Well, give a little credit: An average user doesn't own a $10,000 asic miner.
00:58 < brisque> I suspect a lot of miners are in the hands of casual users though, which is why there's exposed KNC miners in DCs in the first place.
01:03 < gmaxwell> how casual can you be with a $10k device in a data center? come on— signing up for the colocation is more complicated than using a password generator and a text file. :P
02:27 < midnightmagic> ha ha ha
02:31 < midnightmagic> It would be great if that were gobbles.
02:52 < BlueMatt> I'm assuming this has been seen already: http://miki.it/pdf/BitIodine_presentation.pdf
02:53 < gmaxwell> anyone try out their software?
02:53 < gmaxwell> I queued that presentation for reading and forgot about it
02:53 < brisque1> they did a hell of a lot os scraping
02:53 < brisque1> s/os/of
02:54 < BlueMatt> it looks like they've actually thought coin analysis through, unlike most of the shit we've seen so far
02:54 < BlueMatt> mostly because of the huge amount of scraping they did
02:55 < justanotheruser> BlueMatt: "When a transaction has multiple input addresses, we can safely assume that those addresses belong to the same wallet, thus to the same user."
02:55 < justanotheruser> biggest flaw I found
02:56 < BlueMatt> yea, they didnt get that right, at least they could have said "we can usually safely assume"
02:56 < BlueMatt> because, realistically, today, you can
02:56 < brisque1> justanotheruser: generally a safe assumption, especially with some online wallets reusing addresses for change.
02:56 < brisque1> in that case you don't even have to assume.
02:57 < gmaxwell> oh wow, the presentation is kinda worthless.
02:58 < gmaxwell> BlueMatt: nah, even today a really substantial fraction of txn on the network are shared wallet transactions.
02:58 < gmaxwell> so you can't do the common inputs = same user thing.
02:58 < justanotheruser> "If multiple outputs, change is never the last output. Fixed only in January 2013!"
02:59 < justanotheruser> Most interesting thing I learned
02:59 < gmaxwell> justanotheruser: I like how it's like "software is flawed" except it was fixed long before their work. Should say 'was' but oh well.
02:59 < brisque1> you can often tell what is change just from the values. if there's a 0.1BTC output another with 8 places, you know certainly which is the change.
02:59 < gmaxwell> Gavin introduced the bug in .. what, 2010?  Hal found the bug at the end of 2012.
03:00 < gmaxwell> brisque1: yea, thats a somewhat helpful hurestic. though not always true.
03:00 < BlueMatt> gmaxwell: true, though you can safely assume that the users are using the same shared wallet (which is likely the intended meaning here, though its not explicitly stated)
03:00 < gmaxwell> e.g. when the amount I move is up to me, I make the third party get the change like amount sometimes.
03:01 < gmaxwell> BlueMatt: eh. but thats strictly less useful. Because you may not know either of the users are using a shared wallet at all.
03:01 < BlueMatt> oh, sure, but its still more than nothing
03:01 < BlueMatt> and if you know which shared wallet, you can sometimes tell via other things (coinbase does some dumb double-tx shit to make the "from" address work)
03:02 < brisque1> …
03:02 < gmaxwell> yea, coinbase does dumb stuff. Strongcoin does dumb stuff.
03:02 < gmaxwell> (strongcoin makes every transaction pay some donation address of theirs)
03:02 < brisque1> seriously? coinbase wants to have "return" addresses?
03:03 < gmaxwell> brisque1: dude not just that, coinbase's merchant thing was randomly "refunding" things when it wasn't expecting a payment. (and causing people to lose bitcoin forever, dunno if its fixed yet— I assume)
03:03 < gmaxwell> brisque1: every transaction into or out of coinbase result in two transactions. Except sometimes it doesn't
03:04 < brisque1> gmaxwell: that's not giving me the warm fuzzy feeling their "safe and secure" animation says I should.
03:04 < gmaxwell> BlueMatt: in any case, share wallets are still a huge source of noise and uncertanty in this kind of analysis.
03:05 < gmaxwell> BlueMatt: just because until you have evidence that its a shared wallet you'll be falsely merging some users.
03:05 < BlueMatt> gmaxwell: yes, but I'd like to see these guys figure out ways to analyse coinbase txn to link them too, etc
03:06 < _ingsoc> brisque1: What animation?
03:07 < brisque1> _ingsoc: coinbase.com has a sort of flip clock thing that says "safe and secure" when you visit the page.
03:07 < _ingsoc> Ah, thank you. I like animations.
03:07 < gmaxwell> BlueMatt: I still think we should have some switch you can set when sending coins that lets it round up to x amount more to eliminate or round-off change.
03:08 < BlueMatt> gmaxwell: I still think all wallets should work together to make this kind of analysis impossible (coinjoin et al), but until the analysis gets amazingly accurate, we may not see that
03:14 < gmaxwell> certantly I think it's useful if the publically disclosed analysis is as powerful as any privately held analysis may be.
06:38 < jtimon> hello, does anyone has what was talked after this?
06:38 < jtimon> [02:36:09] <gmaxwell> 17:35 < maaku> or in a server-to-server consensus mechanism
06:38 < jtimon> [02:36:43] <gmaxwell> yea... except dear gods, the bitcoin blockchain is NOT a communications mechenism for your server to server consensus!  _global broadcast network_
06:38 < jtimon> [02:36:52] <maaku> gmaxwell: using the public chain as a semaphore for two-phase commit of a distributed transaction over multiple private asset servers
06:38 < jtimon> [12:08:31] <-- jtimon (~quassel@87.pool85-53-148.dynamic.orange.es) has quit (No Ping reply in 180 seconds.)
07:05 < jtimon> a pastebin would do it
07:06 < brisque> I'd help you out but I don't have scrollback that far. someone will surely have logs.
11:19 < andytoshi> jtimon: i have logs at http://download.wpsoftware.net/bitcoin/wizards/2013-12-31.txt which cover what you want
12:13 < jtimon> cool andytoshi thank you
12:23 < phantomcircuit> gmaxwell, bitcoin.org was moved to a dedi and the dedi died under the load
12:23 < phantomcircuit> wat
12:23 < phantomcircuit> it's like
12:23 < phantomcircuit> all static content
12:23 < phantomcircuit> how is that even
12:25 < jtimon> I'm not sure I understand this part:
12:25 < jtimon> 01:38:28 <maaku> gmaxwell: you need to hit the public chain for public<-->private txns
12:25 < jtimon> 01:39:11 <maaku> (e.g. atomic swaps of freicoins for private assets)
12:25 < jtimon> 01:39:27 <gmaxwell> For anything like that you have a small number (because multisig scalablity) of known-in-advance servers. Which means you can do a regular n-of-m consensus totally external to bitcoin. E.g. an initatior proposes a distributed database update and get a supermajority of the servers to sign off on it.
12:26 < jtimon> freimarkets options also need expiries
12:27 < jtimon> but the first use case when it was reallly necessary are transitive (ripple-like) trasactions involving several in-chain and off-chain assets
12:28 < jtimon> when all the asset are off-chain you can just use a regular timestamping server all the private chains agree upon
12:29 < jtimon> what we used to call "registries" in 2PC Ripple http://archive.ripple-project.org/Protocol/RegistryCommitMethod
12:32 < jtimon> I don't know how can you implement my example "5.6.3 Hybrid Transitive transaction" (pubA -> pubB -> privC -> privD -> pubE -> userA) without block expiries
12:32 < jtimon> of course, whether you think that's an important use case or not is another question
12:34 < jtimon> as for the "dangers of expiries" the way I see it, the responsability to decide how many blocks to wait to consider a transaction "safely buried" should ALWAYS rely on the recipient
12:34 < jtimon> 6 blocks is just an orientation
12:35 < jtimon> it depends much more on the quantity than in previous transactions or expiries
12:36 < jtimon> well, it will usually will, but it's still the payee's problem
12:38 < jtimon> in fact all of the examples in our off-chain transactions section rely on expiries (the all off-chain asset transaction example is missing, but it's basically 2PC Ripple)
12:57 < andytoshi> jtimon: the problem is that it the whole transaction sub-DAG is risky .. IMO requiring 100 blocks before any nExpiresTime output can be spent would solve this, and it'd be better than having no expiry time
12:58 < andytoshi> as for the weird miner incentives, i'd really have to think about that
13:50 < Emcy> "BitTorrent Sync was designed with privacy and security in mind. The system uses SRP for mutual authentication and for generating session keys that ensure Perfect Forward Secrecy. All traffic between devices is encrypted with AES-128 in counter mode, using a unique session key. Modification requests are all verified using Ed25519 signatures and only systems with full access keys can generate valid modification requests."
13:51 < Emcy> that seems ok right. apart from the closed source ofc
14:02 < gmaxwell> lol
14:02 < gmaxwell> "Hmm. Low fat. Low Sodium. That seems ok right. apart from the gives you cancer part ofc"
14:07 < Emcy> but bt sync is so usable.....
14:09 < maaku> jtimon: having transactions expire is a requirement of the system we are building. no way around that
14:11 < Emcy> i did notice in the android client sync gives you the option to email somewhere that nifty shared secret string you just generated
14:11 < Emcy> derp derp
14:11 < maaku> Emcy: that email is PGP encrypted, of course? :P
14:12 < Emcy> of course not, just uses whatever email handler you have in android. Liekly gmail
14:13 < Emcy> they should take that out and add the QR reader to the desktop app instead. The android client can already scan a QR produced by the desktop program, dont know why its not both ways
14:13 < Emcy> i guess thats why its still beta
14:18 < phantomcircuit> Emcy, i dont see any really good reason why you couldn't implement bittorrent sync with nothing more than a private tracker and a shared key
14:18 < phantomcircuit> it shouldn't even be that difficult
14:19 < Emcy> i think thats essentially what theve done
14:20 < Emcy> theyve just automated the hashing and .torrent publishing parts, and have some sort of metadata files hanging around so the nodes dont get confused about timestamps and such
14:21 < Emcy> it seems to be really quite usable though so far
14:21 < phantomcircuit> Emcy, depending on whether you trust the filesystems modification timestamp you can do all of this very very efficiently
14:21 < Emcy> its not quite dropbox level of brain absentia though
14:21 < phantomcircuit> im surprised it took them this long to do it actually
14:22 < Emcy> yeah well no one wanted to do anything with torrent tech because muh piracy
14:22 < phantomcircuit> if they wanted to make it really fast they could share the block hashes for all the files
14:23 < phantomcircuit> so you have 2 files that are 90% identical you only transfer the diff blocks
14:23 < phantomcircuit> but i bet they didn't do that and have each file setup as basically a torrent with private peering
14:23 < Emcy> i think there was actually a BEP for that for normal bittorrent
14:24 < Emcy> a thing which could maybe bring avail. <1 torrents back fromthe dead by matching data blocks from seeders of other torrents
14:26 < jtimon> maaku I though gmaxwell was proposing an alternative with multisig, but probably not the same use case
14:27 < jtimon> andytoshi, I'm not sure what you mean by "the whole transaction sub-DAG is risky", but I don't see how the 100 block wait is necessary
14:30 < jtimon> I'm not very informed on the bittorrent sync topic, but wouldn't a tahoe-LAFS GUI be better?
14:31 < andytoshi> jtimon: if a tx gets expired as a consequence of some reorg, the receiver of the btc loses out -- and so does everyone he spent to, and everyone they spent to, and so on
14:31 < andytoshi> the whole transaction chain is invalidated, so the risk model is the same as that for coinbase transactions
14:31 < andytoshi> hence the 100 block wait
14:31 < jtimon> that's the receiveer problem, why didn't he wait for reorgs to be unlikely?
14:32 < maaku> jtimon: they like the fact that any non-coinbase tx that hits the chain can only be made invalid by malicious/buggy clients
14:32 < jtimon> or by a later double-spend
14:32 < andytoshi> jtimon: because he's an spv node and he didn't know that there was an nExpiresTime tx 2 layers back in the blockchain
14:32 < maaku> jtimon: that falls under the malicious category
14:33 < jtimon> can SPV wait less confirmation than rational people just because they have less information about the global state?
14:33 < maaku> as you say, it is trivially solved by having the receiver wait 100 blocks, then you have the same security as other transactions
14:33 < andytoshi> jtimon: and actually, if people are doing this sort of analysis when considering whether to receive coins, then the coins are non-fungible
14:33 < andytoshi> (at least temporarily)
14:33 < jtimon> why 100? where that number comes from?
14:33 < maaku> or, alternatively, tracing inputs back 100 blocks to show that they are not expiring soon
14:33 < maaku> coinbase maturity
14:34 < andytoshi> jtimon: 100 is arbitrary, just to be consistent with coinbases
14:34 < maaku> i'm just saying that would get you to the same level - right now any bitcoin transaction could get reversed in a reorg of >100 blocks
14:34 < jtimon> if you wait 50 blocks you are probably pretty secure despite previous coinbases or expiries
14:34 < maaku> well not *any* txn, but as a SPV node you don't know which ones
14:35 < adam3us> jtimon: thanks for the url btw i was unable to find "original ripple" before archive.ripple-project.org! all other urls and history redirects to ripple.com which maybe moderately different
14:36 < maaku> adam3us: significantly different
14:37 < jtimon> adam3us that link was to the 2PC distributed Ripple protocol, which is radically different from ripple.com
14:38 < maaku> jtimon: you know i think this is a non-issue, but it falls in a similar category as refheights
14:38 < maaku> you have to change your behavior slightly, and maybe adjust how clients/wallets work
14:38 < jtimon> everything is "off-chain" and you can actually trade 2PC assets for bitcoins (not btc denominated IOUs) atomically
14:38 < jtimon> if there wasn't expiries
14:39 < jtimon> all clients should probably determine the "secure number of confirmations" from the value of the transaction received
14:40 < jtimon> my point is that with expiries, transaction value is still the more important criterion
14:40 < jtimon> for both SPV and non-SPV clients
14:41 < maaku> jtimon: the ~100 blocks of security becomes a concern during network-wide problems like the March fork
14:41 < maaku> where opportunistic people can build chains off of expiring transactions on the bad fork, and cause merchants to lose money
14:41 < jtimon> maybe some miners
14:41 < jtimon> sorry
14:41 < maaku> but there are solutions that could be put in place on the merchant and wallet side to fix that
14:42 < maaku> by estimating nethash you'd be able to see the drop in hash power that would signal a fork, and delay/postpone any irreversable actions
14:43 < jtimon> march fork was exceptional, it was an unexpected hardfork
14:43 < jtimon> what are the chances of that happening again?
14:44 < maaku> pretty high, just not on a regular basis
14:44 < maaku> or you can make 100 confirms, or something as absurdly high the norm for high-value transactions
14:45 < maaku> and let clients/wallets use old coins with short proofs showing that they can't be reversed in less than N blocks
14:45 < jtimon> "high-value" doesn't exist in chain
14:45 < maaku> it's not something you have to reach consensus over
14:45 < jtimon> value is only in our heads, thus outside the chain
14:46 < jtimon> oh, I see
14:46 < jtimon> client policies
14:46 < maaku> i'm just saying the merchant waits until processing your gateway withdrawal or shipping your order or whatever
14:46 < maaku> yeah
14:46 < jtimon> yeah, I'm with client policies as well
14:46 < maaku> unless your client used old coins and provided proof, which could even be made the default behavior with little more than a UI checkbox for "expediatd transaction"
14:47 < jtimon> in certain way I'm with miners policies too I don't like "non-standard fees" for the long run
14:48 < maaku> so my position is that like refheights this is a developer education problem
14:48 < maaku> but what we get out of it is absolutely worth it
14:48 < maaku> what do you mean?
14:48 < jtimon> I still I don't see how unexpected hardforks can be common anyway
14:49 < gmaxwell> who cares if its common, if you play your cards right its world ending.
14:49 < jtimon> and although I think the devs did the right thing, they could have been chosen the other solution
14:49 < gmaxwell> As in .. some event happens and it can never be recovered.
14:50 < jtimon> it was the ref implementation which wasn't following the protocol specification
14:51 < jtimon> we could have had much lower hashrates until the ref implementation was fixed
14:51 < gmaxwell> ... thats what we did.
14:51 < gmaxwell> we fixed the ref implementation to match the old.
14:51 < jtimon> that's the opposite of what I'm saying
14:52 < gmaxwell> uh.
14:52 < maaku> gmaxwell: you get just as much gloom and doom from a >100 block reorg now, and merchant policies can limit their exposure to be the same
14:52 < jtimon> we said "the rules aren't the specification, the rules were the old implementation"
14:52 < gmaxwell> jtimon: something like 80% of nodes were on the other fork including every major merchant, it would have been a non-issue except for the fact that 3 upgraded miners constuted >60% of the hashpower.
14:52 < jtimon> we could have as well said "the rules are the specification, fuck the old implementation for not following it"
14:52 < gmaxwell> maaku: yes, >100. But the events we've had have been <20.
14:53 < maaku> "merchant policies can limit their exposure to be the same"
14:53 < maaku> the only guys who got screwed are the ones who weren't doing adequate coin safety
14:53 < gmaxwell> jtimon: gee thats nice, except for the 80% of nodes including all major merchants who were actively being defrauded.
14:54 < jtimon> exactly, the decision was taken (sanely) counting miners and merchants, instead of being strict with the defined rules
14:54 < gmaxwell> jtimon: not to mention the utterly insane risk of rapidly forcing everyone onto bleeding edge software... including god knows how many people who had highly customized code who are _still_ on 0.7.x with patches.
14:54 < adam3us> the 2pc ripple seems a bit like OpenTranscations security model also... get signed/timestamped receipts from servers, users audit servers, if they detect malicious server, they have proof, and can rebuild server state with the receipts (in theory though maybe the rebuild part may not be automated yet)
14:55 < gmaxwell> jtimon: the decision was simply "the deployed software is the spec"
14:55 < jtimon> I'm not saying the decision was wrong
14:55 < jtimon> but I hate that justification
14:56 < jtimon> I prefer to justify it as "following the specs instead of the ref code would have had worse consequences"
14:56 < gmaxwell> jtimon: You can point at a stack of paper and say "but the rules!" all day... but the paper doesn't do shit. The behavior of the participants is what defines the rules in a consensus system.
14:57 < gmaxwell> jtimon: well of course, it's not like we say "the deployed software is the spec" because God gave that to us on a tablet,— rather, its the necessary thing to achieve good outcomes in 99.99% of cases.
14:57 < jtimon> agreed, of ALL the participants, not just miners
14:57 < jtimon> as some seemed to imply at the time
14:57 < gmaxwell> absolutely not just miners, and double absolutely not hashpower.
14:57 < jtimon> let me put it another way
14:57 < gmaxwell> Those implying that are not competent.
14:58 < jtimon> if 90% of the hash power was in the old code and 90% of merchants and users are on the specs (I know that wasn't the case), what's the right chain?
14:58 < gmaxwell> (And as you may note, in that hardfork the majority of hashpower was the new behavior... due to the fact that hashpower is controlled by basically 3-4 people, and they'd upgraded faster than the rest of the network due to the competative incentive of orphaning reduction)
14:59 < jtimon> yeah, ok, good point
14:59 < gmaxwell> Merchants and users would be the right chain generally.
14:59 < adam3us> i suppose this is another reason pooled mining can be a problem
14:59 < jtimon> the majority of hash was on the specs back then and we went with users
15:00 < adam3us> and economies of scale in mining
15:00 < jtimon> I agree, merchants and users are the right chain
15:00 < gmaxwell> (90% hashpower might just be 50 people that need to fix themselves)
15:00 < gmaxwell> (but even ignoring that, I think its reasonable and prudent that mining basically takes more of the risk, and pratically every miner whos thought about any of this would agree)
15:01 < adam3us> gmaxwell: how do u think that fork would've played out if there was no pooled mining and mostly decentralized mining power?  better or worse?  (more distributed consensus on sw upgrade, maybe slower reaction time)
15:01 < jtimon> adam3us, 2PC is similar to OT in some senses, but simpler (not so many instruments) and...in OT all atomic stuff occurs in a single server, with 2PC, there's atomic trades involving an arbbitrary number of independent servers that don't necessarily trust each other
15:01 < gmaxwell> adam3us: I don't think the fork would have happened, in fact.
15:02 < gmaxwell> (well, it would have self resolved)
15:02 < adam3us> gmaxwell: well wasnt the fork the result of the level db bug? how would it have self-resolved... a few people early would've noticed problems
15:02 < adam3us> gmaxwell: and been outvoted anyway, and then the bug backed-out?
15:02 < maaku> adam3us: It would have been much harder to side with the users
15:02 < gmaxwell> adam3us: it would have been hashpower overtaken
15:02 < maaku> if there weren't any big miners you could get to switch chains
15:03 < gmaxwell> maaku: there wouldn't have been an artificial miner/user split there.
15:03 < adam3us> jtimon: i think OT also has a concept called voting pools like k of n pools have to agree for a tx to complete
15:03 < gmaxwell> most _miners_ were also on old code at the time too.
15:03 < maaku> gmaxwell: yes there would. miners-set doesn't overlap well with user-set
15:03 < gmaxwell> it's just that most hashpower was on the new stuff.
15:03 < adam3us> gmaxwell: we could really do with direct mining protocol for that reason also.  difficult to make that work though.
15:04 < adam3us> gmaxwell: a lesson therefore without decentralization, is the centralized parties need to use intelligence and gradual phase in
15:04 < gmaxwell> maaku: at the time most of p2pool's hashpower stayed on the 0.7 side.. though it was complicated by the fact that 0.7 didn't reliably reject the new chain.
15:04 < adam3us> gmaxwell: however i think from views expressed here that most of the mining power has very limited "intelligence" applied to it at all
15:04 < gmaxwell> (it wasn't a real hard fork, it was a softboiled fork. :P )
15:05 < maaku> adam3us: iirc Luke does a good job of this. he runs blocks past multiple node versions
15:05 < gmaxwell> yes, it would be easier for more to do that if we'd merged luke's patches for that.. but they were pretty invasive.
15:07 < jtimon> adam3us, but that's not more scalable, that's like a "shared server" much like ripple.com's consensus mechanism
15:09 < adam3us> maaku: yes Luke-Jr is a rare example of pool intelligence
17:15  * andytoshi-logbot is logging
17:17 < andytoshi> hey, it came back on its own :)
18:42 < gmaxwell> but ... now it seems to have a droopy leg and a strange interest in brains.
19:44 < justanotheruser> Is there any trustless way to pay someone in BTC to mine an altchain that is inherently worthless? (specifically I was wondering if you could subsidize merged mining of a votecoin))
19:49 < Emcy> i suppose you could make some shitty system that bloats the fuck out of bitcoin because they wont merge mine a specialised votecoin
19:50 < Emcy> but i dont think we really know how reluctant the poolops are to merge mine something decent because no ones ever tried
19:51 < justanotheruser> Emcy: I don't really want to use the bitcoin blockchain. A new blockchain could be created cheaply and be disposable.
19:51 < Emcy> well thats a refreshing attitude
19:53 < justanotheruser> Emcy: anonymous voting would require many coinjoins and coinswaps. If there were millions of voters, the election could cost millions of dollars in bitcoins
19:54 < justanotheruser> with all the transaction costs. Not much of a point.
19:54 < Emcy> i wonder how much those shitty diebold contracts cost
19:54 < Emcy> did you work out how to issue votes anonymously
19:55 < Emcy> *issue ballots
19:56 < justanotheruser> Emcy: everyone gets a vote, everyone has a public bitcoin address associated with their name.
19:56 < justanotheruser> Coinswaps and coinjoins are used to anonymize the votes
19:56 < justanotheruser> then when everyone has sufficient anonymity, they to 1ALGORE or 1GEORGEBUSH
19:56 < justanotheruser> *they pay to
19:57 < justanotheruser> I just wish I could pay someone automatically in bitcoins for finding a block without a central authority
20:00 < Emcy> what about vote selling
20:00 < gmaxwell> justanotheruser: thats really dumb. sorry, it's often repeated enough you should have seen other people calling it out.
20:00 < gmaxwell> Bitcoin is not a jamming resistant network. Congrats you just let the miners decide the election outcomes.
20:01 < justanotheruser> gmaxwell: What do you mean by jamming resistant
20:01 < justanotheruser> Emcy: That is possible without decentralized voting (but I agree, this makes it easier)
20:02 < Emcy> oh yeah hes right
20:02 < petertodd> gmaxwell: timelock crypto can be used to circumvent miner censorship of votes in some conditions
20:02 < Emcy> i think when i first brought up some sort of votecoin was years ago back when i still thought every responsible citizen could have a miner in the cupboard
20:02 < justanotheruser> Blocks could be rejected if they didn't include a certain number of transactions
20:04 < Emcy> justanotheruser when youre talking about elections there are incentives which easily override money concerns
20:04 < petertodd> justanotheruser: now you've turned pow mining into a weird pow/proof-of-stake/proof-of-sacrifice combo, doesn't necessarily help re: elections
20:04 < Emcy> in the money/power chicken and egg game, power always came first
20:05 < justanotheruser> petertodd: What? How is there any prooof of stake/sacrifice?
20:05 < petertodd> justanotheruser: the transactions - how do you distinguish a "legit" tx from one the miner made?
20:06 < justanotheruser> petertodd: network rule that only allows a coin to be transacted a certain number of times
20:07 < petertodd> justanotheruser: right, so by including a transaction you have sacrificed someone, hence, it's proof-of-sacrifice
20:08 < justanotheruser> petertodd: how have a sacrificed someone?
20:08 < petertodd> justanotheruser: you sacrificed something, coinage, or coins, or whatever scheme you decide to use
20:09 < justanotheruser> petertodd: to get a block you have to have done a PoW with a certain number of transactions. The miners have no sacrifice
20:10 < petertodd> justanotheruser: something was sacrificed, or miners can stuff the block full of their own transactions at zero cost
20:10 < petertodd> justanotheruser: anyway, this works for voting: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03524.html
20:10 < justanotheruser> petertodd: The miners can only have a limited number of transactions
20:11 < petertodd> justanotheruser: limited how?
20:11 < justanotheruser> petertodd: because everyone only gets one votecoin and they only can be transacted 100 times from the coinbase
20:12 < gmaxwell> justanotheruser: dude, wtf. you are trying to employ bitcoin to do one of the things it doesn't really do at all— antijamming.  If you can assign ballots to people the voting process is largely done, nothing hard remains.
20:12 < justanotheruser> gmaxwell: anonymizing remains
20:12 < petertodd> justanotheruser: there are much better ways to anonymize votes
20:12 < gmaxwell> (well, except anti-coercion is basically impossible in a online voting context)
20:13 < gmaxwell> anonymizing is kinda pointless if you don't generally have anti-coercion, but anonymizing is trivial, go look up "reencryption mix"
20:13 < justanotheruser> petertodd: anything other than zerocoin of a central authority?
20:13 < gmaxwell> electronic voting is a _very_ well studied subject.
20:13 < petertodd> justanotheruser: this has been a "sexy" problem in crypto for years, and people way smarter than any of us have spent whole phds on the subject
20:14 < gmaxwell> invoking bitcoin for it is just a redneck suggesting his trusty shotgun as a solution to multivariet calculus. :P
20:14 < gmaxwell> Bitcoin solves an entirely unrelated problem, and it doesn't solve the important problems in voting.
20:14 < petertodd> justanotheruser: if you need decentralized consensus about the results of a vote then blockchain's can make sense, but rarely do you need that
20:14 < justanotheruser> Is there another decentralized voting method?
20:14 < petertodd> justanotheruser: so why is this vote required to be "decentralized", and what do you mean by that term?
20:15 < justanotheruser> petertodd: I would like it to be decentralized because it prevents vote manipulation and what's happening in Russia.
20:15 < gmaxwell> justanotheruser: what you were suggesting didn't sound decenteralized. But assuming you get as far as somehow giving ballots to voters, there are systems which are no less decenteralized than bitcoin.
20:15 < gmaxwell> justanotheruser: how do you plan on giving each person one ballot without someone getting 500 in a decenteralized manner?
20:16 < petertodd> justanotheruser: right, so you're applying this voting scheme to a typical thing where the list of voters is already defined by a central authority, so you don't need blockchains - existing crypto works just fine
20:16 < justanotheruser> gmaxwell: That is centralized, but you can verify that someone isn't getting too many votes, no votes, or that imaginary people are getting votes.
20:16 < petertodd> justanotheruser: you can't with crypto - those are all human problems
20:16 < gmaxwell> okay if you can do that you can just apply the mountains of evoting lit.
20:17 < justanotheruser> petertodd: Yes it is
20:17 < justanotheruser> *Yes they are
20:17 < petertodd> justanotheruser: I mean, once you solve the problem of figuring out who the voter list is, you can start using crypto, but you already have a central authority so standard algorithms and techniques work - they don't use blockchains
20:18 < gmaxwell> and blockchains don't work, because you get crap like "a majority of hashpower can rig the election" which is undesirable to a high degree.
20:19 < petertodd> gmaxwell: yes, unless the voter list is defined in terms of hashing power :P
20:19 < gmaxwell> I do kinda like idea of using OWAS to create a jamming proof communications mesh, I don't think I've seen that proposed outside of #-wizards.
20:19 < gmaxwell> petertodd: yea okay, sure you can just leave out the voters list then... miners decide. :P
20:19 < petertodd> gmaxwell: more seriously, with my timelock thing you *can* do a vote with well-defined limits for how easy it is to rig the election
20:20 < fagmuffinz> OWAS?
20:20 < justanotheruser> gmaxwell: yes, that was my original problem, I wanted to have the merged mining to be paid it bitcoin somehow. This would increase the number of miners and prevent 51% (hopefully)
20:20 < gmaxwell> fagmuffinz: One Way Aggregatable signatures.
20:20 < fagmuffinz> donka
20:20 < gmaxwell> fagmuffinz: cryptographic signatures which you can merge and still validate, but you cannot unmerge.
20:21 < gmaxwell> fagmuffinz: so e.g. you give me your vote and I merge in the vote I have (which is a merge of petertodd and mine) and then we pass it on.. and someone can't later pick apart our votes to only includ yours in the election, unless they get a clean copy of yours from you.
20:22 < fagmuffinz> I looked up your previous explanation =]
20:22 < fagmuffinz> Would be decent for building the mesh
20:23 < gmaxwell> well my though is that politics often follow social lines, so you could still perhaps rig, but it would be highly detectable when virtually all of the votes for one candidate disappear. :P
20:24 < maaku> petertodd: but how do you have a timelock system that isn't at the DoS-mercy of the person running the timelock?
20:24 < fagmuffinz> Yea, still, it's not quite the long-term solution yet
20:24 < fagmuffinz> There's probably no good way, without centralized trust, to resolve that issue
20:25 < gmaxwell> fagmuffinz: oh nah, in most cases the voting systems don't really need jamming free communication. what they do is make it easy to check what votes are included before the count, and then trust that if your vote is omitted you will scream from the hilltops.
20:25 < fagmuffinz> Yea, that'd be sufficient
20:25 < gmaxwell> e.g. disencranchisement is detectable.
20:25 < fagmuffinz> Assuming good citizenry
20:25 < fagmuffinz> Yea
20:25 < maaku> which works in democracy, but not automated consensus systems
20:25 < petertodd> maaku: read the paper, it's not a central timelock, just a sequantial hard algorithm
20:26 < fagmuffinz> Yea, guaranteeing that your vote made it after the count is sufficnet
20:26 < fagmuffinz> sufficient ***
20:26 < petertodd> maaku: obviously cracking the timelock is computationally intensive of course
20:26 < fagmuffinz> petertodd: Is a timelock explanation above?
20:27 < maaku> fagmuffinz: only if there is repercussions for cheating
20:27 < midnightmagic> if a citizen doesn't care if his vote is counted, it's not really disenfranchisement.
20:27 < maaku> in some applications - PoS vote on validation rules, for example, it is useless to complain
20:27 < fagmuffinz> Voting is a social system
20:28 < fagmuffinz> Separate from guaranteeing existence in something
20:28 < maaku> the votes drive some consensus process, and there's no way to back out other than to abondon the whole system, which would be a successful DoS outcome
20:29 < fagmuffinz> DoS is a universal threat that you have to accept upon automating this shit
20:29 < fagmuffinz> The only sure way of mitigating DoS is having enough infrastructure
20:30 < justanotheruser> fagmuffinz: not necessarily in a decentralized system
20:30 < justanotheruser> for example: Bitcoin is very difficult to DoS
20:30 < maaku> petertodd: ok i understand, it just maks decrypting have a cost
20:30 < fagmuffinz> Hence you're trying to use it for voting
20:31 < fagmuffinz> Correct?
20:31 < justanotheruser> fagmuffinz: that's not the reason I want to use it for voting. It's more to verify that everyone who got a vote had their vote counted.
20:32 < maaku> petertodd: if some joker puts a ballot in that is ill-formed, junk, or encrypted with different key, it would be nice to have a compact, quickly verified proof of that
20:35 < petertodd> maaku: yeah, that's a very interesting crypto problem actually, I suspect it may be incompatible with the sequential-hard scheme
20:36 < fagmuffinz> justanotheruser: Are you just inquiring or do you have some partial plan?  I'm thinknig about what gmaxwell put forward in terms of aggregating a single score for verification...
20:36 < maaku> petertodd: i have a rather near term application if a jamming-resistant proof-of-stake voting scheme can be found
20:36 < fagmuffinz> You could tell your vote made it into the list
20:37 < petertodd> maaku: of course the whole thing is dependent on the fact that the fastest sequential implementations of a lot of algorithms are reasonable close to each other in performance - off-the-shelf is basically the best you can get within an order of magnitude
20:37 < petertodd> maaku: oh yeah?
20:37 < fagmuffinz> You'd need to take additional steps to ensure the list was properly counted
20:37 < justanotheruser> fagmuffinz: Is is possible to do that anonymously?
20:37 < maaku> yeah, demurrage distribution - "repbulicoin". i forget if I've told you about it already
20:38 < petertodd> maaku: ah yeah, that'd work
20:38 < maaku> demurrage distributed according to forced coinbase payments determined by a proof-of-stake vote on a jamming-free ledger
20:39 < petertodd> maaku: damn expensive those in terms of cpu-power
20:39 < maaku> i got it worked out up to the jamming-free part :\
20:39 < petertodd> s/those/though/
20:39 < maaku> yeah, hence the need for cheap verification..
20:40 < maaku> i'm okay with votes being expensive, but validating nodes that count the votes need to be cheap
20:40 < petertodd> yup, and I'm pretty sure that's been proven to be impossible
20:40 < maaku> well you could do it with gmaxwell's ticking timelock pow for example
20:40 < petertodd> obviously you can easily pass around the decryption keys proving a vote exists, but not the other way around
20:40 < maaku> so there's an existence proof
20:40 < maaku> oh you mean the cheap validation
20:41 < maaku> darn
20:41 < petertodd> well keep in mind that part of the reason why the scheme can work if embedded in otherwise-normal looking transactions is that miners would (in theory) find it too expensive to just block all transactions
20:42 < petertodd> the moment you have a "well-known" place where the vote would be recorded it becomes much easier for miners to rig the vote
20:48 < maaku> yes it would have to be either steganographically encrypted, or taken out of the miners hands
20:50 < fagmuffinz> justanotheruser: you could have people agree to some protocol that would operate the same way some central authority would, and if compliance with that protocol can be algorithmically guaranteed, then you could decentralize it
20:50 < fagmuffinz> Thinking on that algorithm
20:55 < fagmuffinz> I mean, you don't need a proof of work for it at all
20:55 < fagmuffinz> If you actually count the vote right...
20:55 < fagmuffinz> There's no incentive to keep recounting it
20:55 < fagmuffinz> All you care about is verification
20:55 < fagmuffinz> Which is easily agreeable in a shared protocol
20:56 < justanotheruser> fagmuffinz: how do you do this anonymously?
20:56 < justanotheruser> while verifying that everyone who started with a vote, and only those that started with a vote are counted
20:56 < fagmuffinz> That's harder
20:56 < fagmuffinz> First part is easy, just random key generation every time
20:57 < fagmuffinz> Now you're asking about assigning people keys
20:57 < fagmuffinz> Let's say...
20:57 < fagmuffinz> Everyone agreed to do a shamir's secret sharing algo
20:57 < fagmuffinz> And you could generate M keys...
20:57 < justanotheruser> fagmuffinz: If the central authority can make 10000000 votes for themselves, then it is no better than the current situation
20:58 < fagmuffinz> The M keys could be applicable to use, then, for signing given enough length
20:59 < fagmuffinz> Thinking about retooling shamir's
21:00 < fagmuffinz> I think this would work...
21:00 < justanotheruser> When assigned keys, you either need to say who you gave them to, which would remove anonymity, or not say, which would allow them to make as many votes as they wanted
21:00 < fagmuffinz> Is it important to outside parties to verify the result of an election?
21:00 < fagmuffinz> No
21:00 < fagmuffinz> I've already gotten past that
21:01 < justanotheruser> What, using shamir?
21:01 < fagmuffinz> Yea
21:01 < fagmuffinz> I've got it actually
21:01 < fagmuffinz> As long as outside parties don't need to vote
21:01 < fagmuffinz> Or verify
21:01 < fagmuffinz> Whatever
21:01 < justanotheruser> How would you use shamirs for voting?
21:01 < fagmuffinz> lmfao
21:02 < fagmuffinz> God, that's gorgeous
21:02 < fagmuffinz> Ok
21:02 < fagmuffinz> Let's say there's a blockchain that starts with some initial seed
21:02 < fagmuffinz> Everyone shamir's secrets that seed
21:02 < fagmuffinz> And generates M keys to vote with
21:02 < fagmuffinz> Encrypt this initial seed with the key Shamir's secret sharing generates
21:03 < fagmuffinz> Save it as the next seed for the next "voting block"
21:03 < fagmuffinz> Everyone who's in knows it
21:03 < fagmuffinz> Those people then use their M keys to cast a vote
21:03 < fagmuffinz> Moot after that point
21:04 < fagmuffinz> You could add people potentially
21:04 < fagmuffinz> Everyone agrees that each key also gets to elect one new person to join
21:05 < fagmuffinz> Eh...
21:05 < fagmuffinz> Fuck
21:05 < fagmuffinz> Sec
21:06 < justanotheruser> fagmuffinz: Wouldn't everyone know everyone elses votes if there was a shared seed that was the other half of everyones secret?
21:06 < fagmuffinz> Yea
21:06 < fagmuffinz> But you can make that pseudononymous
21:07 < justanotheruser> So there are pseudonyms associated with the votes? Meaning the votes aren't guaranteed to be associated with a person?
21:07 < fagmuffinz> Correct
21:07 < fagmuffinz> The issue I'm running into right now mentally...
21:08 < fagmuffinz> Is ensuring the keys generated that suffice shamir's secret sharing...
21:08 < fagmuffinz> Can be isomorphic to a private/public key pair...
21:08 < fagmuffinz> Or guarantee some private/public key pair
21:12 < fagmuffinz> If p and q were your public/private key pair
21:12 < fagmuffinz> You could do something like...
21:12 < fagmuffinz> G = p^q
21:12 < fagmuffinz> Then sign G with p
21:13 < fagmuffinz> Or...
21:13 < fagmuffinz> One of the M keys
21:13 < fagmuffinz> Sign (G,p)
21:13 < fagmuffinz> All of this modulo some N
21:21 < fagmuffinz> K, scratch part of that.  All that's necessary to ensure that whoever had the key actually cast the vote is signing off an (p,N) message with one of the shamir's keys, for a p/q mod N public/private key pair.  I currently have no way of guaranteeing good behavior to those included in the vote, aside from the protocol penalizing them during the next voting round(s)
21:27 < fagmuffinz> Is that sufficient?
21:40 < justanotheruser> sorry, I was away, you still there fagmuffinz
21:40 < fagmuffinz> yea
21:41 < justanotheruser> I don't really understand what you mean by penalizing them
21:42 < justanotheruser> brb
23:40 < fagmuffinz> I'm not exactly sure what I mean either thinking about it
23:40 < fagmuffinz> Or any good way of enforcing it
23:40 < fagmuffinz> The issue is in verifying everyone else's key in the SSS (Shamir Secret Sharing), you could easily use any of their keys to vote
23:41 < fagmuffinz> So you're assuming good behavior amongst the voting population
23:41 < fagmuffinz> That's probably a no-no
--- Log closed Wed Jan 01 00:00:44 2014