Topic: Poll: Bitcoin as a backbone to which low-latency complementary technology? (Read 2399 times)

The Ripple system would do that for you as long as it has a well connected user base. As its biggest problem, the Ripple Project has yet to develop a decentralized model. A Ripplypay user can't send an IOU to a Rain Droplet one. I think the Ripple Project might benefit from integrating with or borrowing ideas from the Diaspora project.

Instawallet front-end on blindbitcoin backend = win?

https://www.instawallet.org

https://blindbitcoin.com/

for small/medium private transactions and always on-line holdings.

Yes -- normally you will lose control over them, and the server will gain control over them.  But that is the state of things BEFORE my special new protocol gets involved. The new protocol I mentioned is what fixes this problem.


This depends on which instrument you are using for payment.

==> If the instrument is cash, then Alice sends the cash to Bob, who then deposits or exchanges it with the server. (See the notarizeDeposit function in the OT API.)
     (ALICE GETS NO RECEIPT FROM OT, OTHER THAN HER WITHDRAWAL RECEIPT. SHE MUST TRUST BOB TO GIVE HER A PURCHASE RECEIPT.)

==> If the instrument is a cheque or voucher, then Alice sends it to Bob, who then deposits it at the server (See notarizeDepositCheque.)
     (Bob gets a deposit receipt, which includes a copy of the cheque, and Alice gets a cheque receipt in her inbox, which also includes a copy of the cheque.)

==> If the instrument is "account transfer", then Alice initiates a transfer to Bob, who receives a notice in his inbox. (The funds by this point have already left her account.) Bob signs to accept it, and that's when the funds hit his account.
     (Alice gets one receipt when she initiates, and she gets a transfer receipt in her inbox when Bob accepts. Bob, meanwhile, gets the AcceptReceipt when he accepts.)

If, instead, markets were used, then Alice and Bob would both get an initial receipt when they placed their market offers, and they would also get Trade receipts in their inboxes whenever those offers are traded against other offers on the market.

I don't know enough specifics of the technologies that you mention to choose one of them, but I agree that a low-latency complementary technology would be useful in many practical cases. Bitcoin is a great system, but not really suited very well for some purposes; for example, large amounts of microtransactions.

On the other hand you have paypal-like sites such as mtgox but they rely on a single party. Which is a single point of failure, and to send between two such sites it'll again have to go through the bitcoin network itself. Also there is no generic API, every site has their own.

Just became aware of this - pretty cool and related to what we are discussing here. A site that implements blind signing to launder Bitcoins: https://blindbitcoin.com/index.html .

Can you elaborate on how this will work? If I send my Bitcoins somewhere, to back an account, I presumably have lost control over them, haven't I?

Also: Could you describe how the communication flow would look like, when a merchant accepts an OT currency for payment? I assume there is communication with a OT server involved during the payment process?

+10 for mesh networking.  We are paying ISPs (/wireless providers) because they own the license to the spectrum, and .gov enforces that ownership.  

Mesh networking + pirate radio + bitcoin = ultimate solution.

I had not heard of the Serval Project.  The site seems light on info.  Maybe someone can ask them to accept bitcoin donations..


EDIT: 4G Mesh Tech

Hmm I somehow missed this.  Open Transactions seems promising.

"Open-Transactions Financial Crypto System and Bitcoin Integration"

Hi all,

Open Transactions does not aim to be a "centralized server".

Rather, Open-Transactions aims to become a loosely-affiliated federation of low-trust servers, wherein the server cannot forge your receipt, and the server cannot change your balance--nor the issuer's--without signed permission, (and the server also cannot disappear and abscond with your funds.)

Since your account IS your receipt, and since you must sign the receipt before the server can countersign it, and since the server cannot forge your signature, this means the server can never issue a receipt that you haven't first authorized.

-----

One gaping hole is this: Though the server is on the hook for the issuer's receipt, and is also on the hook for all of the users' receipts, this by itself doesn't prevent the server from creating additional, illicit accounts, and false-signing their counterfeit withdrawals. (Meaning the classical Chaumian implementation requires trusting the server... which was always a big problem, and for good reason.)

AUDITS
However, if those counterfeit funds are to be spent, they will necessarily flow into known accounts and thus be discovered upon the next audit. (Therefore regular audits are necessary whenever issuers are involved.)

When an audit happens, the users can send in their receipts (which their wallets should store between audits.) The issuer is thus able to re-issue the same currency onto a different transaction server, and no one has lost any funds!

I've got a protocol worked out for this, as well as a Bitcoin version for BTC-backed accounts on OT that I've been working on with one of you. (Meaning: if the server is hacked, they still can't steal your bitcoin. If the server is malicious, they still can't steal your bitcoin. Etc)

Think of it like the department of Pre-Crime.

Folks, we need to design the future such that you can process instruments even on an anonymous server you don't trust.  Anyone who is not moving in that direction is misallocating their resources, IMO. What happens when thugs bust in to your server operation?

------

And same thing with your social networking:  Some Diaspora-style solution, with some kind of Tahoe-LAFS storage and I2P sort of communications.  That's how it needs to go, if you don't want to end up in a police state. You should not have to trust your Facebook. You should have a federated system.

------

Same thing with your router:  WHY are we all paying ISPs?  All of our routers should just talk to each other and eliminate the ISP entirely, replacing it with a mesh network. (A network where nodes connect to each other, and pop in and out of the network unexpectedly.) If you think about it, this is coming soon, anyway, due to robotics.

You should not have to trust your ISP.  You should not even have an ISP.

------

Same thing with your cell phones.  Can't they just go on the same mesh network?  Why is everyone paying AT&T $300 per month? Has anyone donated to the Serval project recently?

Why is everyone giving AT&T, Apple, Google, Uncle Sam, Chinese Govt Hackers, and God Knows Who Else searchable access to our location and movements, our text messages, and our voice calls?

Tell me: How long until your own personal deadline, until you have an entirely open-source, open-hardware, meshed, Jitsi'd, cell phone? (Network communicator device?)  How long are you willing to wait before you will go down to Best Buy and put together the hardware yourself, and download the experimental protocol from MIT?

------

I commit to you now, not to purchase another router unless it has mesh capability. Consider it my civic duty.

How about you guys?

Sure, that's an option too. But PayPal knows if Bob pays at a sex toy store with PayPal. So what I'm saying is: If you do go for a centralized component, then you might as well push it as far as possible and use the existing technology in this field - like blind signatures to protect privacy.

I like the idea of Fast Transaction Coins.

Why not just a website that runs like Paypal to do instant payments between its users - exactly like Mt Gox.

People can withdraw their bitcoins at any time - like Mt Gox.

I has a great API.

Bitcoin is, as far as I know, unique among digital currencies because of its decentralized nature, where you don't need to trust anyone in particular, but just need to trust that 51% of the hashing power is honest. It does have however serious scaling challenges and the ever-present problem of delays before transactions are confirmed.

Many other solutions instead require a trusted mint to issue coins, which then allows to do very fast transactions. Lots of thinking and cryptography has gone into these systems to give them additional nice properties. Especially "Chaumian blinding" is a key technique here, as far as I can tell, which prevents the central mint from knowing too much about the people that it issues coins to: If Bob gets some coins from the mint, then buys something at a sex toy shop and the shop then redeems the coins with the central mint, then Chaumian blinding prevents the mint from concluding that Bob was shopping at the sex toy shop.

The Ripple project is yet another approach to the trust problem: Here a trust chain between people needs to exist. (I trust a friend who trusts the person I want to pay.)

I think Bitcoin will pretty quickly face serious scaling issues and it seems to me, that some of these technologies could be a great complementary solution. Imagine having a (more-or-less) trusted central mint, where you could exchange Bitcoins for Fast-Transaction-Coins. With those coins you can now do fast mobile payments and extrem micropayments and whatnot, and at the end of the day (quite literally) exchange them back to Bitcoins. If you only keep a small amount of Fast-Transaction-Coins at any given time (like petty cash), you don't even need to have that much trust in the central mint, because you would have limited losses should the mint disappear or abuse its position.

So my question is: Which project would you consider the best fit to interface with Bitcoin in such a way? I guess it would make sense to leverage existing open source code in building something like that. Here is a nice overview of various digital currency projects: http://disattention.com/78/digital-currencies-crypto-finance-and-open-source/

My personal thoughts on this:

I think Ripple is very interesting, but I am not convinced that the "trust chain" works well enough for arbitrary situations. I just want to buy something from some random online shop without needing to figure out a trust path to them.

Open Transactions seems like a very interesting project, but suffers a little bit from too much complexity. Because of that, I haven't fully understood it and have the feeling, it tries to do too many things at the same time. But maybe a simple subset of Open Transaction would be a good start. And I believe the author has started on some "Bitcoin to Open Transaction" solutions already: see https://github.com/FellowTraveler/Moneychanger/wiki

Links to the options mentioned in the poll:
Open Transactions: https://github.com/FellowTraveler/Open-Transactions/wiki
Ripple: http://ripple-project.org/
Lucre: http://anoncvs.aldigital.co.uk/lucre/
OpenCoin: http://opencoin.org/
Loom: http://loom.cc/

What are your thoughts on this? Do you think making Bitcoin the backbone system too a low-latency, high-volume counterpart is a worthwhile goal, even if it introduces one or several centralized exchange points?