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
>
>