MoAT is a concept that occurred to me a week or two ago, and after a little discussion and thinking, I wanted to share with the community for reactions, ideas and general interest....
TL;DR = what if we built a protocol forwarding all trust inquiries to everyone we trust and they do the same and guess anyone who receives it is at least somewhat trustworthy?
For a little background, I imagine that the 10-60 minutes wait time on transaction validations may become problematic for any realtime web-based transactions where bitcoin would otherwise be useful, and so I was playing with ideas for how you could trust somebody as soon as you receive the indication of transfer without waiting for a new block, let alone 6 new blocks, to verify the transaction.
I see a number of issues with this proposal, but imagine maybe the community can help me refine it and/or decide if it's worth pursuing a reference implementation of a protocol along these lines... I initially imagined it as a web based federated series of servers, but that might be overcomplicating/unnecessary, I dunno... read on and you all tell me :-)
So let's start by assuming each user generates a brand new keypair just for MoAT*... Anyone who trusts this user completely adds their public key to their level 0 MoAT keyring, if they trust them strongly let's say they go on level 1, and higher levels equal gradually less complete trust... I think any context differentiated trust would be indicated by a separate keyring, like work and personal, but I guess there could be named levels too, dunno.
When engaging in a transaction (bitcoin is a usecase, but not the only one) with someone who may choose to remain anonymous, and I wish to know if I can trust, I generate, let's say a UUID-like token, and I encrypt and send this token to everyone I trust at the level I wish to validate this transaction (more important/sensitive, lower level, less important, higher level), and perhaps set a time-to-live paramter or number of degrees separation for how many degrees of forwarding this token should undergo (less forwarding = more trusted, much like lower level, though might set to opposite direction as level to increase odds of success, dunno...). The token is marked somehow so the anonymous transactee can recognize it if they receive it... perhaps it's signed with their public key, or encrypted with it, or with a one-time key for this transaction that they'll attempt to unlock every payload that they receive after I send it with.**
Every agent who receives a token sent to them and encrypted with their key decrypts it and forwards and reencrypts it to everyone in their level N "MoAT" as long as it has time-to-live count remaining after they subtract one.
If the transactee is able to pass me back the matching UUID-token I sent out, we've established one-directional trust (according to whatever parameters we used and those we trusted used), while (I beleive) preserving true (or at least significant) anonymity. If he can do the same in reverse then it'd bidirectional.
Questions/Issues/etc***...
1. Is it actually useful/desirable enough that anyone would use it?
2. Should we define a protocol so that it can be an open federation of servers implemented however people want, and then do a reference implementation?
3. Does it need to be transacted online by the system for each transaction, or is it possible for each user to simply carry a series of tokens signed by everyone they trust out to various depths, and then any individual transaction can simply check whether there's a valid signature on this token that they trust? Is this complicated by a desire to preserve secrecy about who exactly I trust, since trust is asymmetric and no one should ever be tempted to give someone "social" or reciprocal trust?
4. Are the differences from an ordinary public key signing web of trust clear and relevant enough?
Just in case anyone really likes the idea and wants to tip for it, and because I'm curious if people really tip to these addresses:
19ceWpswS9NSbjZqWkML7dv4gTxQXkkzKT
Also, if people are interested, I'll make that address or another a pool for a bounty to pay for a working implementation of some protocol along these lines...
*I'd actually kind of like it to be a valid GPG key for email too, but mostly so that you would incidentally gain a useful keyring for secure communication with people you trust who might not otherwise bother having a public key... this could work in some scenarios, but for now we'll assume it's only used for this, so that they'd be a little more comfortable trusting it to a server, and/or so that it can be psedonomyous/anonymous... users who wish to trust you could send a request and you could configure to either a) automatically respond with your public key, b) auto-generate a new public key for each request, or c) personally authorize each key request from people you know and wish to allow the option of trusting you.
**Alternately, it may make more sense to assume that all transactions are sent out to everyone you trust, but each trust level is sent out with a level-specific signature, and 0 gets all levels, 1 gets all but zero, and so on, and each additional transfer increments a counter, so you're almost guaranteed the recipient may receive the transfer, but the particular version they receive and the count on the increment counter indicate two metrics related to how trustworthy your trust-network deems them...
*** I had something in here that I think I've decided can't work, but I'll put some notes here just in case anyone has ideas on how to make something like this workable/useful, assuming the rest of the system is worthwhile and works similar to above description.... I'm pretty sure it doesn't work in any really useful way as described though so you can safely ignore if getting tired of reading all this :-)
t may make sense to keep a kind of record of every UUID/transaction a node engages in, so that if someone feels defrauded on a "trusted" transaction, they can send out a kind of alert on that particular UUID, though I'm not sure how this will work in terms of utility. The history of alerts along various chainpaths may serve as a kind of feedback for how dependable these branches have been? or the alert may be essentially meaningless for carriers who had high TTL when they handled it, but increasingly noteworthy for lot TTL nodes? Though most of them will have nothing to do with the actual recipient, and will by network effect be more numerous than higher TTL nodes, so maybe this doesn't make sense at all, or maybe there's some optional pseudonymity token that a transactee can opt-in to offer that would allow nodes connected to him to identify if the other party feels defrauded somehow... That may be a whole different can of worms..
