<unnamed>

Public Key

npub13r7ua6p7uk2et9m3v40zr5t3qf8gu9mytng7387k7dx0587hz2lqkz3z25

Profile Code

nprofile1qqsg3lwwaqlwt9v4jack2h3p69csyn5wzaj9e50gnlt0xn86rlt390spp4mhxue69uhkummn9ekx7mq2qgpmm

Publishing to

nos.lol

Last Notes

2023-06-07 15:14:53 UTC

- reply

📅 Original date posted:2014-03-07
📝 Original message:I think a reputation network is more complicated than is needed for
this. This can be solved by the market.
What is needed is a simple method for each individual user to mark
certain merchant as trusted. For example, if your device gets an
untrusted payment request, it'll make a small sound, light up the screen
and ask the user to authorize the payment. The user then has the choice
of adding the merchant to trust list, authorizing just a single
transaction or not paying (and perhaps adding to the user's publicly
shared untrusted list?).
This way, even lacking a trust architecture, only the first payment to a
merchant needs to take several seconds. If trust is granted, the next
payments will be swift.
The lack of chargebacks presents a clear risk to the customer, though,
so a need for a third party that can keep the merchants honest exists.
This opens up markets for transaction insurance companies. Even though
bitcoin transactions are final, if a transaction insurance company
offers to cover your losses in the event of fraudulent charge, the risk
is practically eliminated.
Such an insurance company would have a strong incentive to make sure the
merchants they insure for behave. Otherwise they'll suffer the losses. I
think this would result in an equally trustworthy but more decentralized
system than with credit cards.
- Joel
On 06.03.2014 16:20, Brooks Boyd wrote:
>
>
> On Mar 6, 2014 3:47 AM, "Mike Hearn" <mike at plan99.net
> <mailto:mike at plan99.net>> wrote:
> >
> > I just did my first contactless nfc payment with a MasterCard. It
> worked very well and was quite delightful - definitely want to be
> doing more of these in future. I think people will come to expect this
> kind of no-friction payment experience and Bitcoin will need to match
> it, so here are some notes on what's involved.
> >
> > 3) Have some kind of decentralised reputation network. I spent some
> time thinking about this, but it rapidly became very complicated and
> feels like an entirely separate project that should stand alone from
> Bitcoin itself. Perhaps rather than try to make a global system,
> social data could be exchanged (using some fancy privacy preserving
> protocols?) so if your friends have decided to trust seller X, your
> phone automatically trusts them too.
>
> A reputation network might be an interesting idea, or several
> different networks with different curators (to prevent complete
> centralization), like how the US credit score system has three main
> companies who track your score. Something like a GPG ring of trust,
> with addresses signing other addresses would work well, if some sort
> of Stealth address or HD wallet root was the identity gaining the
> reputation, then address re-use wouldn't have to be mandatory.
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140307/335b10cd/attachment.html>

2023-06-07 15:14:38 UTC

- reply

📅 Original date posted:2014-03-08
📝 Original message:If both parties insist on seeing a hash of the other party's public key
before they'll show their own public key, they can be sure that the
public key is not chosen based on the public key they themselves presented.
Although, I have to wonder, why not just use multisig?
- Joel
On 08.03.2014 10:51, Edmund Edgar wrote:
> On 8 March 2014 17:10, Alan Reiner <etotheipi at gmail.com
> <mailto:etotheipi at gmail.com>> wrote:
>
>
> I create a new keypair, <c_pub> with <c_priv> which I know (it can
> be any arbitrary key pair). But I don't give you <c_pub>, I give
> you <b_pub> = <c_pub> minus <a_pub> (which I can do because I've
> seen <a_pub> before doing this).
>
> Sure, I don't know the private key for <b_pub>, but it doesn't
> matter... because what
>
> <b_pub> + <a_pub> = <c_pub> (mine)
>
> You have no way to detect this condition, because you don't know
> what c_pub/c_priv I created, so you can only detect this after
> it's too late (after I abuse the private key)
>
>
> Thanks Alan and Forrest, that makes sense. So to salvage the situation
> in the original case, we have to make sure the parties exchange their
> public keys first, before they're allowed to see the public keys
> they'll be combining them with.
>
> --
> --
> Edmund Edgar
> Founder, Social Minds Inc (KK)
> Twitter: @edmundedgar
> Linked In: edmundedgar
> Skype: edmundedgar
> http://www.socialminds.jp
>
> Reality Keys
> @realitykeys
> ed at realitykeys.com <mailto:ed at realitykeys.com>
> https://www.realitykeys.com
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140308/a1e71327/attachment.html>