Escrow does require trust, with eBay, you have to trust that they're not
colluding with the seller, the silkroad and stuff like that aren't quite so
easy, since the parties are anonymous, you have to trust that the middleman
isn't colluding with the seller (or that they're the same person).

Also it was trivial for a seller to create numerous buyer accounts and
flood themselves with positive feedback, paying only a small % fee for each
rating.

This is easier to do in a decentralised system when there are no fees for
creating a user and leaving feedback. Create multiple buyers and sellers,
all giving each other good feedback, spotting things like this in the data
is difficult, unless graphing techniques for the ratings are used.




On 17 March 2014 01:27, Manfred Karrer <mk@???> wrote:

> Interesting project, but I am not sure anymore if reputation is really
> necessary. Maybe it creates more problems than it solves.
>
> *justusranvier <https://bitcointalk.org/index.php?action=profile;u=14492>:*
> Quote from: sirius on 25-02-2014, 09:59:29<https://bitcointalk.org/index.php?topic=130137.msg5357022#msg5357022>
> Escrow requires trust in the arbitrator.
>
> Does it really have to, or is that just the way people have always done it
> before?
>
> Quote from: sirius on 25-02-2014, 09:59:29<https://bitcointalk.org/index.php?topic=130137.msg5357022#msg5357022>
> Reputation is valuable in basically all human interaction. Airbnb,
> couchsurfing and Uber are practical examples of the power of reputation
> systems.
>
> Reputation systems give you a limited and imperfect method of predicting
> intentionally malicious behavior.
>
> Insurance provides recourse that covers both intentional and unintentional
> damages. Properly implemented insurance systems offer a strict superset of
> the functionality provided by reputation systems and also don't require
> privacy compromises.
> https://bitcointalk.org/index.php?topic=130137.msg5357486#msg5357486
>
>
> To provide measurable data is one thing, to derive from that data
> qualitative statements is problematic.
> As example see the bitcointalk "reputation" categories like "Hero Member",
> etc...
> It does not mean really much that one is categorized as "Hero Membe". It
> only means he has posted a lot. So better to display only that naked data
> and not derive any unprovable statements.
>
> br,
> Manfred
>
> Am 16.03.2014 um 18:27 schrieb Robert Williamson <bobalot@???>:
>
> Sure, I'll read through when I get a chance.
>
> See this project by sirius, he's trying to actually implement a
> distributed identity system.
>
> http://identifi.org/
>
>
> On 15 March 2014 22:52, Manfred Karrer <mk@???> wrote:
>
>> Hi Robert,
>>
>> Recently I was also trying to find out more about Satoshis original P2P
>> market ideas for bitcoin (from his first source code). I asked a few
>> bitcointalk members from the old days and got 2 answers.
>>
>> *theymos <https://bitcointalk.org/index.php?action=profile;u=35>:*
>> "Mike Hearn knows most about that. You might try asking him.
>> My understanding is that Satoshi's plan was to have people broadcast
>> their trade offers across the network in the same way that transactions
>> are. To handle trust (and maybe to prevent spamming), you'd link a
>> pseudonymous identity with every Bitcoin block you mine. The more blocks
>> you mine, the higher your trust score. But if someone rates you as
>> untrustworthy, you lose some of these proof-of-work points. (The person
>> rating as trustworthy would probably have to spend some of their own
>> proof-of-work points to do this.) Nowadays, individuals almost never mine
>> blocks, so the proof-of-work would have to be modified. Satoshi probably
>> also intended 2-of-2 multisig to play a part."
>>
>> *Mike Hearn <https://bitcointalk.org/index.php?action=profile;u=2700>:*
>> "Heya,
>> Satoshi's integrated marketplace was abandoned after he realised that his
>> time was better spent on the JSON-RPC API and outsourcing it to web
>> developers.
>> What code did exist was basically a kind of pubsub "meet in the middle"
>> system for broadcasting product offers over the p2p network. Some of the
>> pubsub code was there but I'm not sure it was ever tested.
>> ..."
>>
>> I am working on a P2P Fiat-BTC exchange using also identity and
>> reputation:
>>
>> https://docs.google.com/document/d/1d3EiWZdaM89-P6MVhS53unXv2-pDpSFsN3W4kCGXKgY
>> Reputation is represented as a kind of colored coins and there is
>> a specialized coin mixer to solve the privacy issues (unlink history of all
>> trades).
>> To prevent spam a fee can be used and can be spent to the actual traders
>> (see chapter market maker in the paper).
>> The bank account will be considered as scarce resource and the identity
>> is linked to that back account (privacy not leaked), so sock puppets become
>> more difficult at least. A fee for account (identity) creation is used as
>> well to make sock puppets more expensive.
>> Reputation is derived from a successful trade (an output from the payout
>> tx) so a reputation increase is part of the protocol for a succesful trade.
>> The self-trade problem to increase reputation is difficult to solve, as
>> with the history unlinking (mixing) the possibilities to filter out self
>> trades is eliminated as well. You could consider a rule that one trades
>> with one peer only is valid for increase the reputation, so cheating the
>> reputation would need also creation of many new accounts, associated with
>> costs. But with mixing you cannot see anymore the identities of past trades
>> so that does not work anymore....
>> One possible solution could be to use a minimum offer period. So a trade
>> need to be in the order book at least 1 block to be considered valid for a
>> reputaion increase. That way a reputation fraudster will run into the risk
>> that a real trader accept the offer. If he cancel he will lose his offer
>> fee and has to start over again. For more details about all that see the
>> paper...
>>
>> Discussion is here as well:
>> https://bitcointalk.org/index.php?topic=462236
>> and on IRC freenode #bitsquare
>>
>> Would be great to get some input from you, as I am considering to use
>> Dark Wallet as code base to build on and you have contributed to dark
>> wallet AFAIK.
>>
>> br,
>> Manfred
>>
>>
>>
>>
>> Am 14.03.2014 um 02:38 schrieb Robert Williamson <bobalot@???>:
>>
>> Posting here, since darkwallet mailing list seems to have some problems.
>>
>> I've been thinking for sometime about how to implement a decentralised
>> marketplace, more importantly a method for decentralised reputation and
>> more recently I found out satoshi tried to do it first.
>>
>> Silkroad was more than just a site for listing products, it handled
>> reputation, acted as a middleman for payments (keeping them fairly
>> anonymous via mixing) and ensured that a seller couldn't easily "cheat" and
>> give them a falsely positive reputation without having to pay an amount of
>> fees. All of this is assuming the website or any of its employees don't
>> collude to edit the centralised database and add false entries.
>>
>> You come down to the issue of privacy vs verifiability.
>>
>> We can easily assign a reputation to a certain public key and have that
>> reputation stored inside a the blockchain/twister/dht, however without
>> proof of payment (and some proof of sacrifice/fees), it's easy for a seller
>> to create many orders to themselves and give themselves fake feedback.
>>
>> One simple way to do this is signing a statement with a pgp key or well
>> known ecdsa key.
>>
>> ================
>> Send 1BTC to 1AbCdEf..., and i'll send you x product
>> ================
>> signature
>> ================
>>
>> This way the buyer and seller have an agreement in place, if the seller
>> does not keep to his word, the buyer can release this statement and
>> signature publicly (potentially compromising the privacy of them both).
>> This is pretty much what the payment protocol wants to do except with X.509
>> certs.
>>
>> This doesn't help you establish if the buyer is a genuine person or not.
>> Even if this is in the clear net, it's trivial to get a signed cert for a
>> domain which people would automatically trust (green padlock is good am i
>> rite?)
>>
>> One option is to use mpks, or BIP32 master keys as identity management.
>> BIP32 can always create a new branch from the same level to get a new,
>> clean identity.
>>
>> Buyer and seller do diffie hellman with a nonce, to get a shared secret.
>> (this shared nonce could be the last block hash or something else which
>> can't be easily lost) we ec multiply this shared secret by G, to get a
>> shared public key and embed that into the payment tx using OP_RETURN.
>>
>> 1BTC ------> 1AbCdEf
>> OP_RETURN <shared pubkey>
>>
>> tx gets confirmed, seller performs his side of the contract and buyer can
>> take the tx hash, write a review and sign it with his master key and the
>> shared key, seller can also do the same with his key and the shared key,
>> these reviews can then be published to twister/dht/sellers website where
>> anyone can see.
>>
>> The diffie hellman is necessary to prevent the buyer or seller just
>> signing any transaction in the chain.
>>
>> Problems with this,
>> payment tx becomes public knowledge,
>> ability to bloat the database by people mass creating reviews.
>> buyer can change the shared key embedded meaning the seller cant write a
>> review.
>>
>>
>>
>> Out of curiosity, I decided to look up the source for the first release
>> of Bitcoin to see what the code was like before my first look at it in
>> early 2011.
>>
>> I was surprised to find Bitcoin 0.1 originally shipped with classes for
>> CProduct, CReveiw and CMarket in market.h and market.cpp, complete with UI
>> elements, until they were removed by satoshi in 2010, due to what looks
>> like it would be a massive dos flaw. It was a lot more than the pay to IP
>> system I was expecting.
>>
>> There is some code for connecting to a node directly to fetch more
>> information about a product (hence no anonymity), some html being rendered
>> to display to the user, relaying reviews and handling orders.
>>
>>
>> This commit is where the market.cpp was removed.
>>
>>
>> https://github.com/bitcoin/bitcoin/commit/5253d1ab77fab1995ede03fb934edd67f1359ba8
>>
>> See connecting to seller,
>>
>> https://github.com/bitcoin/bitcoin/commit/5253d1ab77fab1995ede03fb934edd67f1359ba8#diff-22c86ca5909919c8a75ddb5678188bc1L2946
>>
>> and showing html for products and reviews
>>
>> https://github.com/bitcoin/bitcoin/commit/5253d1ab77fab1995ede03fb934edd67f1359ba8#diff-22c86ca5909919c8a75ddb5678188bc1L3000
>>
>>
>> signing a review,
>>
>> https://github.com/bitcoin/bitcoin/commit/5253d1ab77fab1995ede03fb934edd67f1359ba8#diff-22c86ca5909919c8a75ddb5678188bc1L3285
>>
>>
>>
>>
>> _______________________________________________
>> unSYSTEM mailing list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>
>>
>>
>> _______________________________________________
>> unSYSTEM mailing list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>
>>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>