| 00:06:15 | gmaxwell: | I think if you try to analyize it as a dmms you find that it's broken as one. |
| 00:10:55 | andytoshi: | yeah, but when i try to formalize dmms i seem to find that either the security property is way too permissive (and doesn't provide any protection against bad histories) or it's tight enough that it excludes PoS for reasons that feel like technicalities |
| 00:11:09 | andytoshi: | maybe i'm just not being creative enough |
| 00:13:41 | Eliel: | gmaxwell: have you taken a look at BitShares lately? (since last august or so) If so, I'd be curious to hear your opinion on the technical choices they've made and if you think the result is viable. |
| 00:14:48 | Eliel: | (other peoples' thoughts are welcome too, of course) |
| 00:24:30 | andytoshi: | it's fine, i think i want to define dmms so that (a) "dmms -> consensus in absense of central parties" can be shown; (b) "dmms does not imply an absense of central parties" is not true, to prevent centralization you need a bunch of technical features (cf asic-faq.pdf) and some hope; (c) might not be true that dmms is -required- for distributed consensus; (d) pos is not a secure dmms, though not for |
| 00:24:32 | andytoshi: | particularly interesting reasons; (e) you cannot get consensus from pos alone |
| 00:24:51 | andytoshi: | if any of those statements contradict peoples' intuition about DMMS or consensus i'm interested to hear about it |
| 00:25:21 | gmaxwell: | Eliel: not latey, I kinda wrote off that camp after their initial stunts which were really reprehensible. |
| 00:25:23 | andytoshi: | oops, (b) should be true |
| 00:25:47 | gmaxwell: | After hoskins abandoned it to go start ethereum I sort of expected it to fade out. Have a particular citation on something I might find actually interesting? |
| 00:27:44 | Eliel: | gmaxwell: I also lost interest in that camp quite a while ago. However, having looked their stuff over lately, it's quite intriquing. I'll dig up a link for you, a moment. |
| 00:29:38 | phantomcircuit: | andytoshi, i kind of suspect there's an edge case in making forks part of the consensus algorithm |
| 00:29:50 | phantomcircuit: | but i couldn't figure out how to do that without it being trivial to DoS |
| 00:32:06 | andytoshi: | phantomcircuit: oh, thx, that's a good intuition (since i doubt "dos resisistance" will have anything to do with consensus-primitive definitions i'll bet there is a counterexample there to anything i come up with) |
| 00:33:01 | phantomcircuit: | also i think gmaxwell had something to say that |
| 00:35:23 | kyletorpey: | kyletorpey has left #bitcoin-wizards |
| 00:37:30 | gmaxwell: | well "dos resistance" can also mean "given finite bandwidth between nodes, the system will converge in acceptable time, even with some nodes byzantine" |
| 00:37:32 | Eliel: | gmaxwell: I've got a few links now. A couple on the technical aspects and one that outlines the history of the project, as well as what mistakes they made along the way and why those were mistakes. |
| 00:38:05 | gmaxwell: | (*in acceptable time with acceptable probablity) |
| 00:38:07 | Eliel: | gmaxwell: here's tech overview http://wiki.bitshares.org/index.php/DPOS http://wiki.bitshares.org/index.php/TITAN |
| 00:38:13 | phantomcircuit: | yeah to be clear when i say dos issues i mean it wouldn't work because you can make each peer do a nearly infinite amount of work at little to no real cost |
| 00:38:39 | phantomcircuit: | although there's an incentives argument that it is at a real (opportunity) cost |
| 00:38:43 | phantomcircuit: | but im not sure that works |
| 00:38:48 | Eliel: | and this is the history http://wiki.bitshares.org/index.php/BitShares/History |
| 00:39:52 | phantomcircuit: | this is actually why i was asking about proof of work functions that had forward progress before |
| 00:40:01 | phantomcircuit: | you might be able to mitigation the dos issues with one |
| 00:40:14 | phantomcircuit: | or that might horribly break consensus |
| 00:40:21 | phantomcircuit: | i couldn't quite figure that out |
| 00:41:04 | Eliel: | gmaxwell: there's also all kinds of information in the articles on this blog by the founder. http://bytemaster.bitshares.org/ |
| 00:42:27 | phantomcircuit: | oo neat |
| 00:42:38 | Eliel: | http://bytemaster.bitshares.org/article/2015/01/20/The-Minimal-Requirement-for-Decentalization/ |
| 00:42:50 | phantomcircuit: | i've got a bitcoin node with -proxy=127.0.0.1:9050 (tor) |
| 00:42:57 | phantomcircuit: | ALL of the peers are .onion |
| 00:43:06 | phantomcircuit: | that seems a bit fishy to me |
| 00:46:54 | gmaxwell: | Eliel: well it's not really good that that 'dpos' page really says nothing about security model except a few 'Disincentives for attacks' lines at the bottom, which seems limited to the 'random number' generation. Delegation for POS was suggested by me (and I'm sure others) in the earliest POS threads but it was pointed out that delegation creates moral hazard (e.g. the people who own the coins a |
| 00:47:00 | gmaxwell: | ren't the people making the consensus, so more incentive to attack and run, who cares if the coins are worthless) undermining the original argument for POS in the first place... would kinda be nice if they addressed that. It also seems that the existing delegates can just freely block someone new from joining. I can't tell from the page how many are required to jam it. |
| 00:47:42 | gmaxwell: | I mean, it just doesn't have any real substantive information needed to understand any of the edge conditions; maybe some of the links at the bottom are helpful. |
| 00:58:09 | Eliel: | gmaxwell: yes, well organized in depth information is not easy to find. |
| 00:59:50 | Eliel: | gmaxwell: but as for the incentive for the delegates in this case is that they're kind of considered employees of the network and receive income for keeping themselves part of the 101 delegates. |
| 01:00:10 | MRL-Relay: | [othe] Eliel, Titan is basically just stealth addresses renamed to a fancy marketing name with a flawed aliasing system |
| 01:00:41 | Eliel: | othe: Yes, it's said pretty directly on the wiki page I linked to. |
| 01:01:48 | Eliel: | well, aside from calling it the aliasing system flawed. |
| 01:02:38 | MRL-Relay: | [othe] it will end like the domain squatting scene |
| 01:05:30 | bramc: | What was meant by dmms and PoS in the above conversation? |
| 01:07:01 | Eliel: | othe: I'd love to see a proper decentralized aliasing system that didn't require global consensus, but it doesn't appear to be a simple problem. The squatting is at least a manageable problem. |
| 01:07:40 | MRL-Relay: | [smooth] bramc dmms is a fancy name for mining |
| 01:08:33 | Eliel: | fancy or not, I'd also be curious to know what those letters are initials for :P |
| 01:08:36 | bramc: | andytoshi, I don't understand your question, are you asking why/whether proofs of storage can be used in mining? |
| 01:08:56 | MRL-Relay: | [smooth] Eliel look in sidechains paper, something about distributed multiparty |
| 01:09:02 | bramc: | 'dynamic memory multiparty signature' |
| 01:09:13 | MRL-Relay: | [smooth] oh 'dynamic' right |
| 01:09:18 | bramc: | no, 'dynamic membership multiparty signature' |
| 01:13:21 | bramc: | andytoshi, It's possible to make a PoS system which doesn't get destroyed by grinding, it needs to have proofs of time though and some very careful use of canonicalization |
| 01:15:10 | bramc: | andytoshi, I read your treatise on altcoins and found your comment about not being able to find a rigorous proof that PoS can't be used amusing. You can't prove what isn't true :-) |
| 01:15:59 | bramc: | andytoshi, There are caveats of course. There are attacks when someone has a faster proof of time server, and there's some amount of bonus for pooling which can be mitigated but not made zero |
| 01:17:44 | OneFixt_: | OneFixt_ is now known as OneFixt |
| 01:25:27 | brisque: | with regards to the flawed alias system, there's quite a few of them around now. |
| 01:29:30 | gmaxwell: | they're easy to implement and sound like useful features. actual utility, not so much. |
| 01:30:07 | brisque: | I imagine for NXT their key value store will be annoying come pruning time |
| 01:31:08 | bramc: | gmaxwell, But how are you supposed to use bitcoin when you don't have access to a computer? |
| 01:35:46 | phantomcircuit: | bramc, maths in your head and morse code |
| 01:42:19 | bramc: | A thought about scaling and raising the block size: As peers get faster with faster connections, if you don't raise the block size limit then wallets could start running full nodes instead of spv nodes |
| 01:43:59 | phantomcircuit: | bramc, the limit is largely cpu power |
| 01:44:42 | phantomcircuit: | 32 core system with everything in ram AND signature checks disabled |
| 01:44:47 | phantomcircuit: | ~50mbps |
| 01:45:31 | brisque: | phantomcircuit: tell that to my 70KB/s upload :< |
| 01:45:39 | bramc: | phantomcircuit, All the stuff about raising limits is talking about computers being a lot faster with much faster net connections in the future |
| 01:46:41 | phantomcircuit: | bramc, im not sure assuming consumer cpus are going to get substantially faster is a great bet |
| 01:47:02 | brisque: | syncing bitcoin core is pretty much single threaded isn't it? |
| 01:48:03 | phantomcircuit: | brisque, not really |
| 01:48:27 | phantomcircuit: | if you disable signature checks it looks single threaded but is actually just ping ponging between threads |
| 01:48:29 | brisque: | with checkpoints on, I mean. |
| 01:48:34 | brisque: | ah |
| 01:48:34 | gmaxwell: | brisque: signature checking is very parallel. The 50mbit/s phantomcircuit is talking about is likely from heap allocator overhead, but thats not that worth addressing because signature checking is a much bigger bottlenext generally. |
| 01:48:46 | bramc: | phantomcircuit, I'm not making the argument! Just pointing out that we're already running up against scaling limits. When people start running full nodes on wallets because it's cheap enough then it's time to think about raising. |
| 01:53:11 | phantomcircuit: | bramc, oh |
| 01:53:12 | phantomcircuit: | ok then |
| 01:55:44 | bramc: | Although I haven't heard anyone other than Gavin be particularly enthusiastic about raising the limit |
| 01:56:14 | bramc: | I for one want to see the limit hit so that everybody fixes their shit to be able to handle transaction fees |
| 01:56:54 | brisque: | there's lots of people on bitcointalk and reddit who support it. |
| 01:57:20 | brisque: | I saw a lovely diagram that describes anybody who doesn't want 20MB blocks as functionally impaired. |
| 01:58:07 | bramc: | brisque, My sample is of course a bit warped, being mostly of people who do actual development |
| 01:58:35 | bramc: | 'It's liked on reddit and the forums' is not generally a good reason for making technical decisions. |
| 01:59:10 | brisque: | ah here we go. https://i.imgur.com/h7kJDH7.jpg |
| 01:59:55 | phantomcircuit: | brisque, gavin is literally the only technical person i've ever heard suggest it's a good idea |
| 02:02:58 | kanzure: | brisque: mto hit the limit then i suggest lowering the block size limit |
| 02:03:27 | kanzure: | wow i don't now what went wrong there with my message |
| 02:03:45 | kanzure: | bramc: my suggestion for hitting the limit is to lower the block size limit, not increase the block size limit |
| 02:04:56 | bramc: | kanzure, I've heard that suggested as well, to force the issues to be fixed before they really really have to be fixed |
| 02:05:41 | bramc: | Sounds like a good idea to me, although it is a bit like price fixing by miners, and it requires their collusion, which unfortunately probably won't happen |
| 02:07:25 | kanzure: | *know |
| 03:00:51 | Taek: | gavin doesn't seem too opposed to the idea of only enthusiests with powerful computers and connections being able to run nodes |
| 03:04:08 | Taek: | which, from a really high level, might be all you need |
| 03:05:47 | Luke-Jr: | Taek: once we have decent SPV wallets, maybe |
| 03:06:10 | phantomcircuit: | sooo not anytime soon? |
| 03:06:29 | phantomcircuit: | i dont consider an spv client to be sufficient for that without fraud proofs |
| 03:06:48 | phantomcircuit: | which im still not convinced can be done without hugely complex DoS mitigation |
| 03:07:14 | Taek: | You'd want a fraud proof to propagate in less time than people take to confirm a transaction |
| 03:09:21 | Luke-Jr: | phantomcircuit: I'd want to see at least gitian determinism and a decent UI (in other words, Bitcoin Core quality) |
| 03:09:47 | Luke-Jr: | phantomcircuit: how do you prevent fraud proof DoS? |
| 03:10:12 | phantomcircuit: | Luke-Jr, kill peers that give you bad fraud proofs would be the first thing |
| 03:10:14 | bramc: | What do you mean by 'fraud proof'? |
| 03:10:18 | phantomcircuit: | but it's really just heuristics |
| 03:10:34 | Luke-Jr: | phantomcircuit: no, I meant legit fraud proofs spammed because of real frauds |
| 03:10:41 | Luke-Jr: | but in this context maybe it doesn't matter |
| 03:10:46 | phantomcircuit: | bramc, evidence that a block violates the rules |
| 03:10:49 | Luke-Jr: | bramc: proof of a better blockchain than the one with the tx |
| 03:10:50 | Luke-Jr: | or that |
| 03:11:00 | phantomcircuit: | Luke-Jr, you'd need to make the fraud proofs 1:1 |
| 03:11:16 | phantomcircuit: | with the serialization |
| 03:11:21 | Luke-Jr: | hm |
| 03:11:32 | bramc: | Isn't a fraud proof usually a chain back to a conflict? |
| 03:11:33 | phantomcircuit: | it costs something to generate something that would even need to be proven fraudulent |
| 03:11:40 | phantomcircuit: | so there's a limited set of possibilities |
| 03:11:41 | Luke-Jr: | * Luke-Jr ponders if a fraud proof for "block too large" would need to be the block size |
| 03:12:15 | Taek: | Luke-Jr: it does not |
| 03:12:17 | bramc: | Luke-Jr, It wouldn't if sizes were included in the hashing-together process |
| 03:12:20 | phantomcircuit: | Luke-Jr, you'd have to process the entire block |
| 03:12:22 | phantomcircuit: | fun |
| 03:12:35 | Luke-Jr: | bramc: this assumes the block is valid in the first place |
| 03:12:49 | Luke-Jr: | I was thinking of using the SHA256 lengths, but those can be forged too |
| 03:13:15 | bramc: | Luke-Jr, If the nodes leading to the transaction root included sizes then there would of necessity be a short proof of a root which lied about total size |
| 03:13:17 | Taek: | If the leaves of the merkle tree are formed from the hashes of transactions, and you have a minimum legal size for a transaction |
| 03:13:46 | Luke-Jr: | bramc: what stops it from lying in those steps too? ;) |
| 03:13:48 | bramc: | Maybe I should exhaustively work through all the ways invariants could be violated and how proofs of them could be short |
| 03:13:49 | phantomcircuit: | Taek, doesn't prove anything |
| 03:13:56 | phantomcircuit: | there's a massive space beyond min and max |
| 03:14:23 | bramc: | Luke-Jr, If you lie about the size of the root, then either you didn't hash together the two things below it properly, or you lied about the size of one of them |
| 03:14:36 | Luke-Jr: | exactly |
| 03:14:47 | Luke-Jr: | if someone is crafting an invalid block, they *would* do that |
| 03:16:09 | Taek: | hm |
| 03:16:14 | Luke-Jr: | phantomcircuit: it's maybe even impossible to create a fraud proof for a block you've never seen (best chain is not better than the fraud) |
| 03:16:36 | Luke-Jr: | with that in mind, perhaps the only fraud proof that matters is "I have a better chain" |
| 03:18:22 | phantomcircuit: | Luke-Jr, for an extensive implementation |
| 03:18:26 | Taek: | what if the merkle root is a random set of bytes? |
| 03:18:40 | Taek: | how do you build a fraud proof for that? You can't prove that nothing builds to that hash |
| 03:18:54 | phantomcircuit: | you'd basically just need the merkle tree branch and a "this is broken" possibly with another branch to a conflicting transaction |
| 03:19:02 | phantomcircuit: | except for block size limits |
| 03:19:11 | phantomcircuit: | i think you need to have the full block |
| 03:19:41 | Luke-Jr: | phantomcircuit: but if the fraud chain is longer than the real one, the fraud won't publish his false block |
| 03:20:38 | phantomcircuit: | Luke-Jr, true |
| 03:20:57 | phantomcircuit: | Luke-Jr, eh it's so much easier to parse the full chain over a high bandwidth link |
| 03:21:09 | phantomcircuit: | it's really not that much data :| |
| 03:21:20 | Luke-Jr: | phantomcircuit: original topic was increasing block size :P |
| 03:21:26 | phantomcircuit: | even then |
| 03:22:01 | Luke-Jr: | I don't have a high bandwidth link available. |
| 03:22:29 | Luke-Jr: | and my USB Armory took like a month to IBD :p |
| 03:23:32 | phantomcircuit: | Luke-Jr, eh you'd basically want to do what bitcoin core does if fScriptchecks=false alayws |
| 03:23:34 | phantomcircuit: | alwyaS* |
| 03:24:21 | Luke-Jr: | phantomcircuit: what? convince ghashio to mine with fScriptChecks=false? :D |
| 03:24:54 | phantomcircuit: | and bitcoin cores implementation of that is fast but certainly not optimal |
| 03:32:15 | bramc: | Luke-Jr, it's always possible to trace it all the way down to the leaf which has the error, and that's a short path |
| 03:32:58 | Taek: | I'm still stuck on the withholding problem. If 51% mining power decides to withhold information on each block |
| 03:33:10 | Luke-Jr: | bramc: what if that leaf is 1 GB in reality? or not known to anyone? |
| 03:33:11 | Taek: | all of the full nodes will reject the blocks they produce, but all of the SPV nodes will accept them |
| 03:36:27 | bramc: | Oh, yeah, proving 'there's nothing with this hash' is a bit of a problem |
| 03:40:59 | bramc: | By definition there are infinitely many things with a given hash |
| 04:00:43 | Taek: | wrt to the recent exit scam, sztorc (truthcoin) proposed that making reputation fungible and sellable is one potential way to prevent exit scams |
| 04:01:03 | Taek: | the idea being that if you commit an exit scam, your reputation becomes worthless |
| 04:01:25 | Taek: | and you could have made more money by instead just selling it |
| 04:05:02 | gmaxwell: | see also the very first discussion in this channel with respect to fidelity bonds. Though these schemes have common faults though. |
| 04:05:49 | gmaxwell: | For example, say ther is some small ding coming on your reputation (e.g. you screwed up and accidentally screwed someone over a bit), suddenly its hugely profitable to sell your reputation to a scammer who will _slam_ as many people as they can as hard and as fast as they can. |
| 04:12:49 | Taek: | because the small ding will reduce your reputation by X% and the scammer will be able to make a profit greater than 1-X%? |
| 04:12:56 | phantomcircuit: | not to mention it's gonna be hard to find a buyer for a darknet admin reputation for 100k+ BTC |
| 04:13:12 | Taek: | other darknet admin hopefuls |
| 04:13:28 | bramc: | fungibility of reputation is generally speaking bad for the value of the reputation |
| 04:14:15 | phantomcircuit: | yeah lots of issues with that one |
| 04:14:23 | phantomcircuit: | but well |
| 04:14:31 | phantomcircuit: | there's no reason for this to even be possible |
| 04:14:37 | phantomcircuit: | multisg escrow is a thing that works |
| 04:15:22 | gmaxwell: | Taek: generally reputation hits have to be 'overstated' http://xkcd.com/325/ or they're easily whitewashed out with fair transactions at parity. |
| 04:18:16 | Taek: | I think that would depend on what the reputation is for |
| 04:18:46 | Taek: | if 97% approval means that you can expect to lose 3% of the financial value in your dealings with this party |
| 04:18:59 | Taek: | that might be a reasonable risk to take |
| 04:20:48 | gmaxwell: | I guess you lots tons to pirate40 and aethero (which both had 97% like reputations in bitcoin otc before they vanished with all the moniez) |
| 04:21:50 | Taek: | did they vanish with less than 3% of all the money that had ever passed through them? |
| 04:23:39 | gmaxwell: | no probably much more... because the exposure is tail loaded as they hyped up on their snowballing reputation at the end; but even if it was 3%... so? all the people with 100% losses on their trades are not thanking you and using your system again. |
| 04:25:29 | Taek: | * Taek wonders if you could insure this sort of thing |
| 04:26:36 | Taek: | I think any worthwhile reputation system built within the next 5 years would have to be inside of a rather sterile environment |
| 04:27:16 | Taek: | which might limit it's initially usefulness, but even Bitcoin was essentially useless for a long time |
| 04:27:24 | Taek: | *initial |
| 04:34:12 | gmaxwell: | We have rather large reputation systems (otc and btc) each with many hundreds of active users, and in my view they are more or less failures. One way of looking at your example is, ignoring the tail loading and sybils and such. lets say that it really did mean that you'd lose everything 3% of the trades there, that means you could never trade with that party with positive expectation unless you |
| 04:34:18 | gmaxwell: | planned to make >3% on the sale... which means in a competative enviroment no one would probably wouldn't trade with them at all. |
| 04:36:14 | Taek: | my understanding is that otc opens up a market where none otherwise exists |
| 04:36:19 | bramc: | Let's use this reputation system known as 'banking licenses' |
| 04:36:40 | Taek: | if 3% (+ a 2% fee or whatever) is the only way to get bitcoins, you may decide that 5% overall expected fee is a worthwhile expense |
| 04:36:50 | Taek: | certainly doesn't compare to Coinbase's 1% |
| 04:37:08 | Taek: | but Coinbase isn't ubiquitous |
| 04:37:59 | gmaxwell: | Taek: but someone with a 3% negative reputation is 3% distant to everyone using the system. It doesn't matter what they'll accept, I mean they're suffering a 3% disadvantage on any resource that goes into them, and a 3% disadvantage on any that comes out. |
| 04:38:44 | gmaxwell: | So effectively, except where they have special connectivity they'd just become disconnected from the ecconomy if we really were to optimize this by the numbers and assume rational agents and yadda yadda. |
| 04:41:36 | Taek: | I don't quite follow. How does a 3% disadvantage on every trade result in a disconnection from the economy? |
| 04:41:50 | Taek: | It makes sense if you assume that there's a way to avoid the 3% disadvantage |
| 04:41:51 | bramc: | 'build a reputation system' generally doesn't work. It only sort of works when there's a highly centralized authority overseeing everything |
| 04:42:15 | Taek: | bramc: I certainly don't have an example of a working reputation system |
| 04:42:45 | Taek: | but I haven't given up on the idea that one might be possible |
| 04:42:48 | bramc: | ebay and amazon's reputations systems work okay |
| 04:43:07 | Taek: | *decentralized reputation system |
| 04:43:45 | gmaxwell: | I think ebay's only works in that it doesn't have much to do, lots of bitcoiners have been ripped off via ebay. It's not as much of a failure as bitcoin-otc, but its pretty thin protection. |
| 04:44:22 | bramc: | If you use bitcoin on ebay you're opting out of much of the protections they provide you |
| 04:52:48 | gmaxwell: | bramc: not bitcoin, but things like mining equipment. |
| 04:53:35 | bramc: | gmaxwell, 'Had JCF enabled, would not buy again' |
| 05:01:03 | bramc: | gmaxwell, 'Value per hash immediately dropped after I bought this equipment. Not trustworthy.' |
| 05:45:02 | MRL-Relay: | [smooth] /win6 |
| 06:50:44 | bramc: | Nobody seemed interested in my signature-based approach to supporting lighthouse functionality |
| 06:53:03 | nubbins`: | bummer |
| 07:23:55 | bramc: | There are two ways of doing it, and I'm not sure which is better. An individual contributor can say 'this output needs to be part of the transaction' or it can say 'this other input needs to be part of the transaction' thus deferring its judgement to that other thing. |
| 07:24:04 | bramc: | or both |
| 07:28:08 | bramc: | I think the currently supported thing is to specify the output, and it can't specify a partial of the output, the only option is to require the output be just the one thing |
| 07:33:17 | fluffypony: | bramc: I don't agree with your eBay analogy |
| 07:33:30 | fluffypony: | s/analogy/conclusion |
| 07:33:49 | fluffypony: | I think the OTC WoT *does* work, but there are two problems with it: |
| 07:33:53 | bramc: | fluffypony, Not sure what you mean, a bunch of what I said was cracking jokes |
| 07:34:13 | fluffypony: | oh about the highly centralised authority :) |
| 07:34:14 | bramc: | also, not sure what 'otc' and 'wot' are acronyms for |
| 07:34:25 | fluffypony: | OTC = Over The Counter (ie. #bitcoin-otc) |
| 07:34:28 | fluffypony: | WoT = Web of Trust |
| 07:34:43 | fluffypony: | here, for instance: http://bitcoin-otc.com/viewratingdetail.php?nick=fluffypony |
| 07:35:01 | bramc: | I'm not sure what the deal is with #bitcoin-otc, there was discussion earlier which seemed to imply that it's a failed thing where somebody made off with the goods |
| 07:35:15 | fluffypony: | no, the failed thing was Evolution, a darknet market |
| 07:35:26 | fluffypony: | the discussion is more around reputation systems in general |
| 07:35:38 | fluffypony: | you're right in saying that eBay's system works |
| 07:36:08 | fluffypony: | but (imho) wrong in concluding that you need a centralised authority |
| 07:36:20 | fluffypony: | the centralised authority in that model takes action on behalf of the users |
| 07:36:28 | fluffypony: | but that's because users aren't empowered to take much action themselves |
| 07:36:54 | fluffypony: | what I have noticed is that any seller with a rating <99% has a sales drop-off |
| 07:37:05 | fluffypony: | people view it as "possibly untrustworthy" |
| 07:37:10 | bramc: | I didn't exactly say that you need centralized authority, just that all the examples of it working seem to involve centralized authority |
| 07:37:18 | fluffypony: | which goes back to gmaxwell's point about reputation hits being amplified |
| 07:37:36 | fluffypony: | so what I was going to say about the OTC WoT is that it's great *in principle* |
| 07:37:45 | fluffypony: | buuuut the two problems I've identified are: |
| 07:38:12 | bramc: | The problem with a decentralized thing is that it's hard to iterate on when there are problems, which tends to be a cat and mouse game whenever there's a reason for having a reputation system in the first place |
| 07:38:19 | fluffypony: | 1. everyone takes "total ratings" as some measure of trustworthiness, forgetting about *who* rated the person and *when* they were rated |
| 07:38:43 | bramc: | Yes, it's a lot easier to flood positive reviews than negative |
| 07:39:01 | fluffypony: | 2. ratings are generally expressed in terms of "X gave Y a rating of N" instead of an expression of a "path" of trust |
| 07:39:26 | fluffypony: | which I suppose is a problem systemic to the fact that ratings are given as X gave Y a rating of N |
| 07:39:41 | fluffypony: | ;;gettrust gmaxwell |
| 07:39:42 | gribble: | WARNING: Currently not authenticated. Trust relationship from user fluffypony to user gmaxwell: Level 1: 0, Level 2: 2 via 7 connections. Graph: http://b-otc.com/stg?source=fluffypony&dest=gmaxwell | WoT data: http://b-otc.com/vrd?nick=gmaxwell | Rated since: Mon Jul 25 13:49:45 2011 |
| 07:40:03 | fluffypony: | people used to use ;;getratings all the time |
| 07:40:06 | fluffypony: | until it was removed |
| 07:40:12 | bramc: | That was experimented with on advogato, predating friendster |
| 07:40:45 | fluffypony: | bramc: so sort of like Facebook's social graph stuff? |
| 07:40:48 | bramc: | In the end you want a general rating based on the system as a whole, which tends to be fairly consistent |
| 07:41:17 | bramc: | Not sure what you mean about facebook's social graph stuff |
| 07:41:27 | fluffypony: | Facebook has this social graph thing in the back |
| 07:41:34 | bramc: | These things were literally worked on in 2002 |
| 07:41:44 | fluffypony: | where they can tell that Alice is friends with Bob who is friends with Sue |
| 07:41:49 | bramc: | And you can see what became of them - everything is on facebook |
| 07:41:55 | fluffypony: | and they can build up a graph of friendships and relationships |
| 07:42:06 | fluffypony: | so they know who is connected to whom...because everyone is telling them |
| 07:42:22 | bramc: | the usability of a simple 'friend' relationship beats everything, and a centralized system can be tweaked and despammed in a resaonable way |
| 07:42:30 | fluffypony: | yeah |
| 07:42:50 | fluffypony: | the great thing about trust "paths" is that it virtually eliminates most Sybil attacks |
| 07:42:59 | fluffypony: | because sock-puppet accounts are just circle-jerk rating each other |
| 07:43:18 | bramc: | If you assume that sock-puppets are less than half of the total accounts you don't really need to find paths |
| 07:43:39 | bramc: | or rather, you can look at the median rating of someone across everybody else and that gives you a pretty good idea of what's going on. |
| 07:44:28 | fluffypony: | I still like the idea of paths being a natural extension of the way we interact IRL |
| 07:45:02 | fluffypony: | like I introduce you to Bob at a party, and because you and I are friends there's already an implied trust between you and Bob |
| 07:45:15 | bramc: | If you use facebook you quickly realize that there's essentially no utility to a foafoaf relationship |
| 07:45:50 | fluffypony: | if later on I go up to you and say that Bob is a douchebag, then your opinion of Bob changes because you don't really know him, so you're basing your view of him off what I say |
| 07:45:51 | bramc: | but on facebook you can quickly see a complete list of all the friends in common you have with someone, which tells you a surprising amount about them and makes it easy to ask for references |
| 07:46:11 | fluffypony: | yep, Facebook has got it down to a pay wrt to the way they display this stuff |
| 07:46:40 | bramc: | Well, I can tell you that peter is an asshole, but you knew that already |
| 07:46:44 | fluffypony: | I'm convinced that the general failure of the OTC WoT is down to the way the tooling expresses things |
| 07:47:15 | fluffypony: | the failure of the PGP WoT, on the other hand, is because people were signing PGP keys at parties for no real reason and no real purpose other than to say "yeah! I signed someone's key!" |
| 07:47:26 | fluffypony: | RIP PGP WoT |
| 07:48:06 | bramc: | the pgp web of trust didn't solve a problem anybody actually had, in a way which was usable to anybody |
| 07:48:58 | bramc: | I hated pgp from the beginning |
| 07:49:43 | fluffypony: | it's incredibly chunky |
| 07:53:38 | bramc: | We're happily conversing in this channel with effectively no authentication. |
| 07:54:11 | bramc: | If an FBI agent came to me tomorrow and asked for information about Mr. Pony I would hardly be able to tell them anything about your identity, but we still have some useful communication |
| 07:54:21 | go1111111: | random idea: is it possible to create a worthwhile reputation system where people try to predict the trustworthyness of other people, and benefit/lose accordingly as in a prediction market? |
| 07:54:32 | bramc: | I wish people would use slightly more identifying handles in here so I could keep everybody straight |
| 07:54:46 | bramc: | go1111111, no it isn't |
| 07:55:24 | bramc: | it's too many layers of abstraction removed from the eventual effect |
| 07:55:27 | fluffypony: | * fluffypony wonders how that conversation would go down |
| 07:55:39 | fluffypony: | "so then Mr. Pony spoke to you on IRC, correct?" |
| 07:56:06 | bramc: | And making it distributed would make it collapse under its own weight |
| 07:56:44 | go1111111: | bramc: and that is bad because it's just too complex? how confident are you that such a system wouldn't work? |
| 07:57:04 | bramc: | go1111111, Nobody's gotten even much simpler systems to 'work' in the sense of being useful for anything |
| 07:58:57 | bramc: | The whole point of bitcoin is that it *doesn't* require a reputation system |
| 07:59:07 | bramc: | And simultaneous transfer doesn't either |
| 08:00:01 | fluffypony: | Bitcoin doesn't, but dealing with people on the Internet really does |
| 08:00:17 | fluffypony: | especially as their transparency or anonymity should be their prerogative |
| 08:01:15 | go1111111: | simultaneous transfer of cryptocurrenies doesn't, but if I hire you to draw me a picture of a giraffe for 1 BTC, some reputation system would be useful |
| 08:03:35 | bramc: | Yes reputation systems are useful, but my advice for anyone wanting to have a reputation system is to set it up centralized and be prepared to change the rules on the fly as people try to game it any way they can |
| 08:05:18 | asimov.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 |
| 08:05:18 | asimov.freenode.net: | Users on #bitcoin-wizards: andy-logbot Mably phiche pgokeeffe koeppelmann sl01 orik coiner RoboTeddy prodatalab Transisto SDCDev user7779078 NewLiberty [7] realcr zwischenzug toffoo maraoz moleccc Dr-G stevenroose LeMiner p15x d1ggy bramc fanquake x98gvyn arubi moa luny justanotheruser waxwing melvster dc17523be3 binaryatrocity antgreen PaulCapestany huseby dignork Cory airbreather gavinandresen cornus_ammonis adam3us1 kefkius OneFixt go1111111 thrasher` maaku Pan0ram1x |
| 08:05:18 | asimov.freenode.net: | Users on #bitcoin-wizards: jgarzik sneak coblee Starduster nuke__ Luke-Jr SwedFTP aakselrod EasyAt GAit larraboj spinza mkarrer gmaxwell midnightmagic lnovy Iriez nsh bosma forrestv Adlai MoALTz JustAnotherVogon iddo hylyt face jonasschnelli p15 berndj gabridome bedeho s1w dgenr8 PRab Apocalyptic copumpkin DoctorBTC espes__ jaekwon_ grandmaster HM adams_ SubCreative AdrianG roasbeef jcorgan Tiraspol harrow tromp_ [d__d] kyuupichan NikolaiToryzin ahmed_ betarigs_admin |
| 08:05:18 | asimov.freenode.net: | Users on #bitcoin-wizards: Visheate phedny yorick amiller_ petertodd kanzure michagogo yrashk catcow Muis cfields Zouppen coryfields_ alferz gribble LarsLarsen cryptowest_ ajweiss kinlo Logicwax crescendo wizkid057 otoburb wumpus GreenIsMyPepper phantomcircuit BlueMatt jaromil gwillen dasource fenn tromp eordano nickler Alanius BananaLotus guruvan ryan-c ebfull sdaftuar veorq helo Hunger- runeks null_radix epscy nanotube andytoshi bliljerk101 starsoccer comboy Taek |
| 08:05:18 | asimov.freenode.net: | Users on #bitcoin-wizards: livegnik optimator fluffypony Meeh cursive yoleaux dansmith_btc morcos Fistful_of_Coins dardasaba isis smooth Xzibit17 artifexd kumavis mariorz Krellan platinuum Oizopower catlasshrugged Keefe eric mappum jbenet wiz heath gnusha warren lechuga_ jessepollak BrainOverfl0w so hguux__ MRL-Relay azariah btc___ throughnothing @ChanServ brand0 davout NeatBasis mr_burdell d9b4bef9 a5m0 Anduck CryptOprah leakypat TD-Linux K1773R indolering warptangent |
| 08:05:18 | asimov.freenode.net: | Users on #bitcoin-wizards: veox Eliel Graet |
| 08:09:21 | bramc: | Related to that, the dread pirate roberts choosing that name seems to indicate that he actually thought people would buy his bizarre defense that he'd long since sold off the dread pirate roberts identity to someone else. |
| 08:09:42 | bramc: | reputation can be non-fungible in both the good and the bad directions |
| 08:11:01 | fluffypony: | yeah you can't really prevent reputation/identity theft or selling |
| 08:11:14 | fluffypony: | (in a decentralised system I mean) |
| 08:13:51 | sl01: | bramc: what about a marketplace for reputation ledgers? |
| 08:17:14 | bramc: | sl01, I can't tell if you're joking |
| 08:18:22 | sl01: | bramc: i mean like... have people subscribe (paid?) to services which track reputation, and let reputation services compete, so the one who tracks reputations as closely to reality as possible profits most? |
| 08:18:50 | bramc: | Still can't tell if you're joking |
| 08:18:55 | sl01: | not joking :( |
| 08:19:50 | justanotheruser: | I think it's a reasonable idea, don't see a reason for a ledger though |
| 08:20:05 | sl01: | sorry by ledger i just meant database basically |
| 08:20:16 | sl01: | and maybe you have to pay per query |
| 08:20:55 | justanotheruser: | it's not quite a decentralized solution though |
| 08:21:14 | sl01: | there could be some standard protocol so users could use different rep. services interchangeably wherever they are needed |
| 08:22:21 | bramc: | Needs a paid vendor of analytics for whether peoples's reputation monitoring accurately reflects later behaviors |
| 08:23:43 | wumpus: | reputation management for reputation management vendors? |
| 08:23:54 | wumpus: | s/management/monitoring/ |
| 08:24:22 | bramc: | I give up. Parody is dead. |
| 08:24:42 | fluffypony: | Google Reputation, Powered by Google Blockchain (tm) |
| 08:25:23 | wumpus: | turtles all the way down |
| 08:54:02 | fanquake_: | fanquake_ is now known as fanquake |