Topic: The Holy Grail! I wish I could kiss the author of Bitmessage on his face. - page 13. (Read 92725 times)

Very excited about this. Watching with great interest.

Love this idea, writing about it right now for a blog post on p2pconnects.us

Have you heard of / considered Tent.io? https://tent.io/

BitMessage seems great as is, but it's just something else to consider if BitMessage ends up having limitations that Tent.io doesn't.

Keep up the good work, this sounds brilliant

Thank you fellowtraveler and all who are working on this!

Admired and appreciated. Please continue. 2btc sent.

More step-by-step...

1. Wallet uploads BTC to voting pool, in order to trade them around on an OT server.
    -- AND/OR --
1. Wallet uploads colored coins to voting pool, in order to trade them around on an OT server.

Also notice that the colored coin issuer does not directly issue anything onto an OT server. Issuers can issue directly onto OT servers, but I suggest using colored coins and voting pools in order to break that link.

2. From this point, it's easy to use Open-Transactions for escrow, and for market trading, on that OT server.
   (Server is unable to forge receipts internally, nor steal from multi-sig pools externally.)

3. Using a discovery layer (Bitmessage, IRC, etc) users who are not already on the same OT server can discover each other, and select a server to meet on, to complete the trade / escrow. (This can all be automated inside the client software.)

4. The same discovery layer makes it easy to wire funds from one server to another, through other users.

5. The same discovery layer makes it easy for users to discover each other for SEPA transfers, facilitated by OT's escrow capabilities.

6. These SEPA transfers could also be performed by services, who are themselves just "other users." (This is the basic concept of Ripple "gateways" as far as I can tell.) OT escrow is used here to remove trust.

7. Even credit lines could be issued cross-server, now that the discovery layer is solved.

The specifics of the discovery/OT protocol are in the paste bins at the top of this thread.

All conversions for a particular user are performed by his own wallet, in a user-centric fashion.

We need to move away from a provider-centric mindset, and instead become provider-independent -- demoting servers from "authorities" to mere "cloud commodities." (For examples of this concept, see Diaspoa and Tahoe.)

Thanks for developing this tool. Truly amazing. 3btc sent!

0.53201 sent.

Thank you for this - I don't see anything more important happening anywhere in bitcoinland.

This is really great news. Hope to see it moving forward. I'll be sending a smallish donation later. Keep up the good work guys!

Yes.

Where can i donate for this project?

Is this correct address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ

Excellent work, folks. I have donated and I hope everyone else here will too, when they realize the immense potential of this unique combination of protocols.

This is innovation at its finest!


 

Well, not like I'm not already halfway down the rabbit hole, I guess I don't mind if it gets a little deeper

Miner_Willy, this is an excellent point. However, there's no reason why the users can't just cash out colored coins with each other WITHOUT using SEPA. Which they can do, as long as they trust the colored coin issuer to perform redemption "of last resort."

And then the actual "last resort" redemptions (through the issuer himself) can all be legitimate (non-reversible) and can occur through bank wires and AML/KYC.

Therefore I believe this solution still stands, even without SEPA.

P.S. I agree with you about the usefulness of a reputations system. How about Monkeysphere? (I will have to defer to the experts on this...)

Excellent reading, fellowtraveler! The flaw that springs to mind is with SEPA (ACH may be similar).

Problem: The SEPA protocol allows for refunds, so allowing both Alice and Jorg to profit through subverting the OT process.

As at [1]: "Payment service providers originating an SCT can request a recall of duplicate or erroneous transactions."

An SCT is a "SEPA Credit Transfer", the kind of transfer I think we're thinking of when we think of using OT to transact. As at [2]: "A recall can be requested by originator bank on behalf of its customer to cancel a SEPA Credit Transfer already settled at EBA. This must be initiated within 10 banking business days after execution date of the SEPA Credit Transfer subject to the recall. Before initiating the originator bank has to check if the SCT is subject to duplicate sending, technical problems resulting in erroneous SCT or fraudulent originated Credit Transfer."

(An SCT is distinct from an SDD - "SEPA Direct Debit" - which allows much longer recalls, as at [3]: "For unauthorised transactions, this right to a refund extends to 13 months after the due date.")

Abuses:
[1] Jorg abuses both Alice and Bob. While we might assume that we can detect that Jorg paid Bob via a SEPA call, Jorg could wait until receiving his payment and then contest that payment was made fraudulently thus retrieving the value deposited to Bob. Alice would then be faced with having to re-pay a settled bill.
[2] Jorg and Alice collude to abuse Bob. Alice wants to buy two silver coins from Bob. Alice pays Jorg, Jorg pays Bob, a SEPA call shows Bob as paid. Bob ships the two coins and provides Alice a shipping number. Alice, knowing the coins are now irretrievable to Bob, informs Jorg who disputes the SEPA transfer, receiving back the whole value sent. Alice also disputes the SEPA payment arrived and so the escrow mechanism divides her payment to Jorg in two, and returns her half. (Although note: Jorg could agree to return an arbitrary amount even subsequent to escrow completion.) Alice now has two silver coins at half price, Jorg has profited by pocketing the other half of that price as well as his transaction fee, and Bob is down by the whole price.

Solutions:
1. If a SEPA call and the protocol also allows for the status of an old transfer to be detected (not clear from my research), this would allow an automatic input into both the reputation system about Jorg (and potentially automated contact to Alice and Bob, if they could elect for such);
2. This puts greater urgency on the reputation system, and also a first approximation of the reputation increase cycle - that is, 'noob' for at least ten days following the first transfer;
3. A system by which payments are made through a client-initiated federation of actors: Bob requires Alice to pay via 3 intermediaries. Alice's client randomly chooses and pays Jorg and Carol and Ted all of whom then pay Bob. This reduces Bob's risk of total loss and increases Alice's risk of being caught by a good actor;
4. Extending (3) above, support for confederations of actors. Alice & Bob may request that only a guild matching certain parameters handle payments, where a guild is decided on (say) a volume basis ("traded $1m+ in last 30+10 days, >99.5% uncontested transactions in those 30"). The guild would be in charge of their own arrangements for membership and distribution of work/reward. A single trader with a large volume would also count as a guild, but is unlikely to have the highest rating but either way a guild is unlikely to risk that whole business abusing Alice and Bob's trivial sum. A guild might well (for instance) choose to incorporate in one or more jurisdictions and use this as a selling point, even though it may well mean higher transaction fees in return. As part of that business, they may well elect to insure Bob against Alice colluding with one of their members.

Cheers!

[1] http://www.paymentscouncil.org.uk/files/payments_council/sepa/shortcut_to_sepa_credit_transfer_%28sct%29%5B1%5D.pdf
[2] http://www.rbs.nl/docs/MIB/Country.../SEPA_FAQs_RBS_NL_v2_2012.xls
[3] http://www.ukpayments.org.uk/files/payments_council/sepa/epc222-08_version_2.0_shortcut_sepa_direct_debit.pdf

A colored coin issuer can demand KYC info from anyone converting in/out directly through that issuer.

Therefore the issuer is compliant. (Consult an attorney -- that's my opinion, and it's not legal advice.)

This is no different than MtGox is today: users are giving each other BTC all the time outside of MtGox -- but only the ones who cash out through a MtGox bank wire actually have to cough up their identification info.

Similarly, people could be giving each other colored coins all the time -- but only the ones who actually cash out through the colored coin issuer will actually have to cough up their identification info. (The coins that circulate outside their reach are comparable to dollars which circulate outside the reach of the Fed.)

... So for example, users could utilize local meetups...

...Or as I have proposed, users could use OT escrow in combination with SEPA to directly redeem...

Open-Transactions is always going to be about a wallet-centric solution, not a provider-centric solution. We want provider independence.


As long as the issuer performs redemptions "of last resort" then technically, you could move fiat in/out through any other user.


This is similar to what I have proposed. Stick the BTC in a multi-sig voting pool for safety, and then use Open-Transactions escrow and Open-Transactions markets for the actual exchanges.

(Except in my proposal, everything is automated.)

From there, Bitmessage provides discovery layer. But there's no reason why OT itself couldn't have its own broadcast net, nor why we couldn't use something like IRC to serve that same purpose.


Well in my proposal, I wrote: The above protocols can be implemented inside OT wallet GUIs, such that they are automated and transparent to users.

Why does that not sound very user-friendly?

People have often complained that OT was "too complicated" -- but I guarantee you they are wrong. (These complaints predate the high-level API.)

For example, see the high-level API -- most financial actions can be done in a single line of code. Developers couldn't ask for easier.

And see the screenshots for the upcoming iPhone app -- Users couldn't ask for easier.

I was trying to be nice by giving everyone a few years head start on creating their own OT clients... That doesn't mean easy clients aren't possible, because I personally haven't released one yet. It just means I wanted to allow others the chance to release them first. (So I could focus on the core library...)


I should point out that most of the solution was latent inside Open-Transactions itself. I'm actually surprised no one else thought of it before -- I mentioned the idea on my FAQ years ago.

Bitmessage is very useful as the discovery layer -- but there's no reason why you couldn't swap in a different discovery layer.

For example, the same solution is basically just as easy to do by using IRC as the discovery layer.


I can't speak for Ripple (I haven't seen their code) but OT doesn't contain central points of failure.

Open-Transactions is user-centric, not provider-centric.

Read the paper, it's addressed.

Bitmessage sounds a bit unscalable, the white paper says you are attempting to decrypt every single message that comes in over the wire with all of your local keys... That would quickly get wasteful and cpu intensive

Very interesting! Great work you're doing. I've got to read up on all this; I think this work might benefit something I've been working on myself

Wow... this is big!!

The only problem is this doesn't sound very user friendly. How can it all be turned into a simple web app?