Bitcoin Forum
March 19, 2024, 11:37:26 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: 1 2 3 [All]
  Print  
Author Topic: A proposal for fast POS transactions with Bitcoin  (Read 8406 times)
cjp (OP)
Full Member
***
Offline Offline

Activity: 210
Merit: 124



View Profile WWW
July 13, 2011, 06:02:47 PM
Last edit: July 13, 2011, 06:40:27 PM by cjp
 #1

This diagram shows some additions I want to make to the Bitcoin architecture. An explanation follows below the image.


Normal Bitcoin transactions follow the black arrows:
2. The buyer instructs his PC to publish the transaction on the Bitcoin
network. For this, the PC uses the seller address and the amount (both
transferred in an non-standardized way outside the Bitcoin network),
and the buyer's private keys, which are stored on the buyer's device.
6. Miners pick up unverified transactions to put them in new blocks.
7. Approximately 10 minutes later, a miner manages to construct a new
block with the transaction in it, and adds it to the block chain.
8/9. Both the buyer and seller can follow the verification process by
monitoring the block chain. After approximately one hour, the
transaction is buried under 6 blocks in the chain, which is the moment
when most Bitcoin users consider the transaction verified.

Depending on the required verification confidence, the whole process
can take up to an hour. This is definitely too long for application
in POS (Point Of Sale) transactions, where transactions must not
take more than a few seconds.

The 'classical' approach would be to accept a lower quality of
verification. For POS transactions, even waiting for a single block
would take too much time, so the only classical verification method
would be to monitor the pool of unverified transactions, to check
whether there is any double-spending. This method is not guaranteed
to work, and especially in a very large Bitcoin network, where
it takes more than a few seconds for transactions to reach all network
nodes, this creates a risk for the seller.

For fast, reliable and convenient POS transactions, I propose an
addition to the Bitcoin architecture, which consists of the red arrows.
The figure assumes that the buyer uses a smart phone or some other
portable, programmable device. The device needs a connection with the
Bitcoin network: this can either be an independent connection (e.g.
using mobile Internet), or it can be tunneled through the Internet
connection of the seller.

The first addition is arrow 1. I propose to make one or a small
number of standardized ways to transfer transaction information
(such as seller Bitcoin address, and the amount) between the POS
terminal and the buyer device. NFC or QR codes would be suitable
media for this.

The buyer confirms the transaction by publishing the transaction in
the Bitcoin network (2). There, the transaction follows the normal
"slow" verification route (6/7/8/9).

The second addition allows to speed up the verification process.
In addition to publishing the transaction (2), the buyer also signs
the transaction, and (3) sends it to a node in the "Fast Verification
Network", which will be described later. Nodes in the Fast
Verification Network quickly check the transaction against the
existing transactions (4), and if it is OK, it is signed and
transferred further through the network, until it reaches the POS
terminal (5). The signatures received with the transaction through
the Fast Verification Network give the seller an initial verification
within a few seconds. Final verification reaches buyer and seller in
the classical way (8, 9).

The reason why the signature received through (5) can act as
verification is that nodes in the Fast Verification Network do not
connect to each other randomly: instead, a link is only made when
the two nodes trust each other. If a node signs a transaction and
sends it to a neighbor, and later the transaction turns out to be
a rejected double-spend, the node is obliged to pay the corresponding
amount of bitcoins to the same neighbor. This means that, even if
the payment turns out to be a double-spend, the seller can still
receive his payment by requesting it from his nearest neighbor in the
Fast Verification Network. As long as all nodes are honest towards
their direct neighbors, this means that eventually the buyer will
have to do the payment to his access point in the Fast Verification
Network.

Normally, when a node sends a signed transaction to another node,
the receiving node has to trust the sending node. Trust can be
reversed if the sending node sends a certain amount of bitcoins to
the receiving node PRIOR to establishing the connection. If the
receiving node has no trust at all in the sending node, this prior
payment creates a maximum for the value of transactions that can be
sent simultaneously over the link.

Trust can be obtained in a number of different ways, e.g. knowledge of
the real-world identity of a neighboring node, or an online reputation
rating system.

So, what do you think? Is this a useful addition to the Bitcoin
infrastructure? Do you see any issues, or possible improvements?

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
1710848246
Hero Member
*
Offline Offline

Posts: 1710848246

View Profile Personal Message (Offline)

Ignore
1710848246
Reply with quote  #2

1710848246
Report to moderator
1710848246
Hero Member
*
Offline Offline

Posts: 1710848246

View Profile Personal Message (Offline)

Ignore
1710848246
Reply with quote  #2

1710848246
Report to moderator
1710848246
Hero Member
*
Offline Offline

Posts: 1710848246

View Profile Personal Message (Offline)

Ignore
1710848246
Reply with quote  #2

1710848246
Report to moderator
The forum strives to allow free discussion of any ideas. All policies are built around this principle. This doesn't mean you can post garbage, though: posts should actually contain ideas, and these ideas should be argued reasonably.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
riush
Member
**
Offline Offline

Activity: 73
Merit: 10


View Profile
July 13, 2011, 07:04:01 PM
 #2

This is pretty much how I imagine established banks, which already have a way to manage trust towards one another, will be using bitcoin one day Smiley

As long as all nodes are honest

Trust can be obtained in a number of different ways, e.g. knowledge of
the real-world identity of a neighboring node, or an online reputation
rating system.

IMHO this is the real issue that needs to be solved in a distributed and decentralized way.

Edit: Maybe Open Transactions can help here, unfortunately I haven't had the time to look into that in more detail...

1MKKiJhUJgqKyfCLeo7bB1bvELNEM8wUbz
cjp (OP)
Full Member
***
Offline Offline

Activity: 210
Merit: 124



View Profile WWW
July 13, 2011, 07:20:38 PM
 #3

As long as all nodes are honest

Trust can be obtained in a number of different ways, e.g. knowledge of
the real-world identity of a neighboring node, or an online reputation
rating system.

IMHO this is the real issue that needs to be solved in a distributed and decentralized way.

If one of the nodes is not honest, that does not make the system completely useless. Only the node who decided to trust the dishonest node will lose money; the other nodes will not be at risk. I think the system will generally be self-correcting: nodes will warn each other for dishonest parties, and close down links or make links to unreliable nodes more expensive.

What would a routing protocol for this network look like? I suppose it will be something like TCP/IP, with some discovery system to find out which nodes are on which side of the network...

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
July 13, 2011, 07:24:37 PM
 #4

IMHO this is the real issue that needs to be solved in a distributed and decentralized way.

Edit: Maybe Open Transactions can help here, unfortunately I haven't had the time to look into that in more detail...

Trust could be established by paying in advance or something.

Also, all nodes don't actually need to be honest.  The requirement is that the nodes just need to honour their commitments.

In the verification process, there needs to be a trust link between buyer and the seller.  The bitcoin network is used as a clearing system rather than a transaction system.

I assume that process is something like

A -10-> B -50-> C -20-> D

The number in the arrow is how many bitcoins of trust exist.

A trusts B for up to 10 bitcoins.

If D wants to send A one bitcoin, a routing system is used to find a chain that has at least that much trust (so detects the above path).

D says to C "I will pay you 1 BTC unless the transaction is accepted within 90 mins".  C says the same to B and then B says the same to A.

A now knows that he can accept the transaction.  Trust has been stressed by 1 BTC along the chain, so now it is

A -9-> B -49-> C -19-> D

If C decides to not pay B, then B will still pay A, since he promised.  B would also probably remove C from his trust list.

When the transaction gets 6 confirms, then promise ends and the trust chain goes back to full strength.

A -10-> B -50-> C -20-> D

These trust links could be anyone.  Someone could list a few of their close friends as trusted for up to say BTC 2-3.

The client would automatically update the trust system and pay promised amounts through the trust system.  Leaving your client connected to the internet would get you fees, if people send their money though your trust links.

To stiff your friends would require that you modify the default client.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
July 13, 2011, 07:35:15 PM
 #5

IMHO this is the real issue that needs to be solved in a distributed and decentralized way.
This does solve this in a distributed and decentralized way. Each node only has to trust those nodes it has a direct relationship with. The system of trust as a whole is distributed and decentralized. You can only be ripped of by someone you chose to trust.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
July 13, 2011, 08:31:13 PM
Last edit: February 22, 2013, 11:22:01 PM by gmaxwell
 #6

So, what do you think? Is this a useful addition to the Bitcoin
infrastructure? Do you see any issues, or possible improvements?

Congrats, you've invented Ripple: http://ripple-project.org/(2013 Edit: The ripple name was acquired and the new ripple is nothing like the old ripple. Any comments I made about ripple prior to Feb 2013 apply to the old system.)

I hadn't considered using it this way. I think thats very cool

But what it doesn't do is reduce the block-chain volume of transactions for small payments.  In a world where bitcoin is being used for POS that kind of transaction hiding is also valuable. Bitcoin's security comes from the fact that everyone sees everything.  That kind of security is justified for the whole wealth of the world— not so justified for soda-pop transactions.   We can usually trust centralized institutions enough to handle our soda pop purchases without funny business. Smiley

So, really I think you've added something else useful to the ecosystem of ways to address fast transactions:

(1) Wait, don't do things fast.
(2) Take a risk
(3) Use a third party insurance service who uses good network visibility and miner relationships to gauge risk and have them approve it.
(4) Use escrow transactions to bind funds to a third party approver who is trusted not to sign double spends.
(5) Use a classic centralized processor that you keep deposits with. (this will be essential early on as we still need to interface with classic payment networks). Also has the huge advantage of hiding its internal transactions from bitcoin, all the network sees is periodic settlements.
(6) Your ripple(see edit above)-esq solution

I expect that all of these things will exist in various places, at various times, and in various mixtures. (In some ways, I guess your solution is a distributed version of (3)) Diversity is a good thing. Smiley

From recent discussion on bitcoin-dev:
(7) When a node sees a second transaction trying to spend an input which is already used by an in-memory-pool transaction (attempted double spend), it generates a double-spend-warning message per affected input which identifies the first two observed transactions using this input.  The warning is flooded (and validated by each node), and can be used to reduce the risk in option (2) above.
JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
July 13, 2011, 09:20:12 PM
 #7

But what it doesn't do is reduce the block-chain volume of transactions for small payments.  In a world where bitcoin is being used for POS that kind of transaction hiding is also valuable. Bitcoin's security comes from the fact that everyone sees everything.  That kind of security is justified for the whole wealth of the world— not so justified for soda-pop transactions.   We can usually trust centralized institutions enough to handle our soda pop purchases without funny business. Smiley
It could be adjusted to reduce transaction volume. If the nodes settle up with each other, there's no need to perform the actual transaction. Ripple could use bitcoin to settle up, settling only when rippling failed or asymmetries built up that exceeded the trust levels.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
July 13, 2011, 09:59:25 PM
 #8

Ripple could use bitcoin to settle up, settling only when rippling failed or asymmetries built up that exceeded the trust levels.

Exactly, if you have a +/- 2 BTC trust link with someone, you could use the main network to move the account back to 0, only if it exceeds +/- 1.5 BTC.

If the flow through the link it reasonably balanced, you mightn't have to settle up very often at all.

In fact, by adjusting the fees you could bias the flow back to zero without any need to settle.

However, with bitcoin to settle the account cheaply, there isn't much point in trying to keep it balanced, unless transaction fees earned are less than the bitcoin transaction fees to balance the link.

It looks like there was a suggestion in February on both this forum and the Ripply google group that the 2 systems work well together, but doesn't look like much happened.

Ripple doesn't seem to do all the transactions at once.  You effectively give your friends IOUs which they can trade, even if you are offline.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
July 14, 2011, 01:21:12 AM
Last edit: February 22, 2013, 11:23:44 PM by gmaxwell
 #9

Ripple could use bitcoin to settle up, settling only when rippling failed or asymmetries built up that exceeded the trust levels.

It looks like there was a suggestion in February on both this forum and the Ripply google group that the 2 systems work well together, but doesn't look like much happened.

Ripple doesn't seem to do all the transactions at once.  You effectively give your friends IOUs which they can trade, even if you are offline.

Hm. Yea, I've been pretty skeptical of ripple in general, but backed with bitcoin and automatic true-ups (why not settle frequently?) that seems like a pretty compelling combination...

I liked the proposal where here where the secured transaction is exposed to the fast network rather than just using the blind IOUs of ripple(Edit 2013: Ripple's name was sold to a new, largely unrelated system).  Trust for someone to not double spend funds that they appear to have is quite different from general credit. Though it could be done in some other way where the unspent bitcoin balance secures the ripple activity, without actually being turned into a bitcoin transaction (still allowing transaction hiding to reduce the load on bitcoin). But there might be interesting privacy challenges with that.

Now mix in something namecoinish to have persistent bound identities to hang trust on...

jav
Sr. Member
****
Offline Offline

Activity: 249
Merit: 251


View Profile
July 14, 2011, 09:34:08 AM
 #10

Hm. Yea, I've been pretty skeptical of ripple in general, but backed with bitcoin and automatic true-ups (why not settle frequently?) that seems like a pretty compelling combination...

I agree. I think that a Bitcoin-specific Ripple system has lots of promise. I haven't really tried Ripple much, but I always worry that maximum credit level might quickly be reached on some routes and then the system doesn't work until a manual debt settle. For example a popular online store will probably mostly have flowing cash towards them and quickly reaching the credit limit with the nodes that trust the store.

Since Ripple supports arbitrary currencies it can't really do automatic debt settlement. But if you would limit it to Bitcoin you could occasionally do automatic Bitcoin payments.

Unfortunately the Ripple project doesn't have all that much software written. They only have centralized servers (so all the trust connections are maintained on a single server) which is nice to play around with, but ultimately it should be decentralized. They are working on a decentralized version, but its mostly in the design phase and I'm not holding my breath, because it's a very hard problem. Since you need to be able to find trust paths connecting different people that might be registered on different servers etc.

An idea I was toying around with: Maybe go for a simple prototype first where routes are manually. So you would have to tell the system specifically that you want to route your payment through alice@server1 -> bob@server1 -> claire@server2 (assuming there is trust between alice<->bob and bob<->claire). The system would keep track of the credit limits alice<->bob and bob<->claire and would occasionally settle the debt with a standard Bitcoin payment.

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
July 14, 2011, 10:11:11 AM
 #11

Hm. Yea, I've been pretty skeptical of ripple in general, but backed with bitcoin and automatic true-ups (why not settle frequently?) that seems like a pretty compelling combination...

Settling requires the payment of the bitcoin transaction fee.

At worst, it would require a transaction for every link in the chain.  This could cause an increase in the load on the bitcoin network.

Sending the money to a distant node could be used to balance all links along the way.  There could be a problem with trust for that though.  

If A owes money to B, who owes to C, who owes to D, then A just needs to send money to D.

A would then own an IOU from D, which isn't someone he actually trusts.  

The IOU would need to say "D owes the bearer BTC 1, on condition that transaction <hash> is incorporated into the bitcoin chain before block number <number>".

A could get C to swap the IOU with one that says "C owes ...." and then B to swap that one for "B owes ...." and finally cash that one with B directly.

Once B has given the IOU, A would then submit the payment to the bitcoin network.  If someone along the chain refuses to transfer the IOU, then A just doesn't submit the transaction and it expires when the bitcoin chain hits that block number + 6.

How does Ripple normally handle double spending of IOUs?  If the first person to cash in the IOU gets it, then offline verification of IOUs is impossible.

Quote
I liked the proposal where here where the secured transaction is exposed to the fast network rather than just using the blind IOUs of ripple.  Trust for someone to not double spend funds that they appear to have is quite different from general credit.

When you sign a transaction, you are at risk that the person will somehow double spend.  There does need to be a link of trust.

If miners published the blocks that they are currently working on, then you could verify that 90%+ of the mining power is committed to including the transaction.  Miners may not want to be spammed by users asking about transactions, but aggregators should be able to pay to get their current transaction list.  They could then operate the fast network.

If the transaction is covered by 90% of the miners, then it is likely to be accepted.

Quote
Though it could be done in some other way where the unspent bitcoin balance secures the ripple activity, without actually being turned into a bitcoin transaction (still allowing transaction hiding to reduce the load on bitcoin). But there might be interesting privacy challenges with that.

If Ripple switched to issuing Chaum blind signatures, then the IOUs would be more difficult to trace.

Since bitcoin is inherently online, is the Chaum system overkill?  The whole idea was that it would cover double spending in offline networks.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
July 14, 2011, 10:25:56 AM
 #12

I agree. I think that a Bitcoin-specific Ripple system has lots of promise. I haven't really tried Ripple much, but I always worry that maximum credit level might quickly be reached on some routes and then the system doesn't work until a manual debt settle. For example a popular online store will probably mostly have flowing cash towards them and quickly reaching the credit limit with the nodes that trust the store.

Exactly.  The problem is that for a system like Paypal most nodes are either sources or sinks (buyers or sellers).  This means that you need an out of channel payment system for settling, but then why not just use that directly.

Ripple + bitcoin gets fast transactions from ripple with bitcoin acting as the clearing system.

Quote
But if you would limit it to Bitcoin you could occasionally do automatic Bitcoin payments.

As long as there are people willing to exchange bitcoins for cash, you could still use the bitcoin system for handling the clearing system, as long as the two ends of the transaction have links to a local exchange.

Quote
An idea I was toying around with: Maybe go for a simple prototype first where routes are manually. So you would have to tell the system specifically that you want to route your payment through alice@server1 -> bob@server1 -> claire@server2 (assuming there is trust between alice<->bob and bob<->claire). The system would keep track of the credit limits alice<->bob and bob<->claire and would occasionally settle the debt with a standard Bitcoin payment.

I think manual routing is worse than having a central server do it (unless the central server goes offline).

Routing could work like IP routing.  However, that means that each routing node needs to store a table entry for every other node.  As an added complication, the size of the link needs to be taken into account.

For example, if there were two paths from A to B, then it isn't clear which one you should add to the routing table.

A -10-> B
A -100-> C -100-> B

If A wants to send 1 BTC, then it can send via the first link, but for more than 10, it has to use the second link.

The routing tables would adjust much more often, as with every transaction the size of the link changes.

The routing system could be hierarchical.  A number of nodes which have good connections to each other could form a group and then top level routing would contain routes between groups rather than routes between individual nodes.  This would work like the network/sub-net system on the internet.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
July 14, 2011, 10:26:37 AM
 #13

How does Ripple normally handle double spending of IOUs?  If the first person to cash in the IOU gets it, then offline verification of IOUs is impossible.
These issues not that difficult to solve. Everybody who takes IOUs keeps track of what IOUs they have paid. Every payment on an IOU is signed by the recipient.

Say I trust you to owe me up to 20 bitcoins and you currently owe me 10 bitcoins. You present an IOU. I pay you 10 bitcoins. You send me a receipt. We now have a zero balance.

If you present me the IOU again, I can present to you the receipt proving I paid it.

If I pay you and you refuse to provide me an IOU, then you are breaching the trust I extended to you. Non-receipting is treated the same as non-payment, it's a breach.

To avoid having to track IOUs and receipts forever, two nodes could mutually sign a balance certificate. If you claim I owe you 10 BTC from a receipt dated last year, I can present a signed certificate of zero balance from last week to prove it must have been settled. Refusing to sign balance certificates could also be considered a breach of trust.

Offline verification of IOUs is not needed. This is fundamentally an online processing system where each node decides to extend trust. If you're not online, you can't do anything until you are. If you stay offline and refuse to redeem IOUs, you are again breaching trust.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
jav
Sr. Member
****
Offline Offline

Activity: 249
Merit: 251


View Profile
July 14, 2011, 11:49:22 AM
 #14

Quote
An idea I was toying around with: Maybe go for a simple prototype first where routes are manually. So you would have to tell the system specifically that you want to route your payment through alice@server1 -> bob@server1 -> claire@server2 (assuming there is trust between alice<->bob and bob<->claire). The system would keep track of the credit limits alice<->bob and bob<->claire and would occasionally settle the debt with a standard Bitcoin payment.

I think manual routing is worse than having a central server do it (unless the central server goes offline).

When you say central server, are you thinking of a server that does only the routing or also the automatic Bitcoin debt settlement? If it's the latter, that already exists: MyBitcoin.com, with the added benefit, that no trust connections are necessary. Everybody can pay everybody else on MyBitcoin.com instantaneously as long as they have an account there with enough Bitcoins.

If the central server only does the routing and the automatic debt settlement is done by the individual nodes then that can be seen as an addon to my proposal. Which seems indeed like a good idea: Have a decentralized system that only supports manual routes and then have a well-known directory server where everybody publishes their trust connections and can query for routes.

At some later stage that directory server can then be replaced by a mechanism that figures out the routes without requiring a central server.

On using Internet-like routing: That is a good suggestion! Although I wonder about privacy and whether it would be possible to do all that and still allow participants to not reveal all the people they trust. That might be too much to ask for, giving the complexity of the problem already, but maybe some of the other requirements could be eased (like not requiring the algorithm to find an optimal path, but use some kind of heuristic to have a good chance of finding a decent path). To me it seems like there are a lot of tradeoffs to consider.

On that note, I wonder how much of this discussion has already happened within the Ripple community. I haven't gone through their archives in much detail, but for those who are interested, I think much of the discussion regarding Ripple systems is happening over here: https://groups.google.com/group/rippleusers .

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
July 14, 2011, 12:17:06 PM
 #15

Quote
I think manual routing is worse than having a central server do it (unless the central server goes offline).

When you say central server, are you thinking of a server that does only the routing or also the automatic Bitcoin debt settlement?

I was thinking of a server that sets up the routing instead of having to manually enter the routes.

A distributed routing system is preferred to manual routing or a central server though.

Quote
Have a decentralized system that only supports manual routes and then have a well-known directory server where everybody publishes their trust connections and can query for routes.

Sounds reasonable.

Quote
On using Internet-like routing: That is a good suggestion!

Maybe solving a hash gets you the right to create a group and therefore a link in the routing tables.

These could expire.  All members of the group would need to do some processing to keep the group's ID code valid.

With a hierarchical system, each member would support the group and the group that the group is a sub-group of etc.

Quote
Although I wonder about privacy and whether it would be possible to do all that and still allow participants to not reveal all the people they trust. That might be too much to ask for, giving the complexity of the problem already, but maybe some of the other requirements could be eased (like not requiring the algorithm to find an optimal path, but use some kind of heuristic to have a good chance of finding a decent path). To me it seems like there are a lot of tradeoffs to consider.

If the trust links are created based on RL friendships, then it doesn't seem that easy to keep things secret.

You could create trust links with random people if you are willing to risk it.  This would allow the creation of an anonymous node.

For example, if I send you 0.1 BTC and ask you to send it back to me, then if you do, I know you are trustworthy for at least that much. 

If there are reasonable fees for providing trust links, then it might even be worth does it at random.  Effectively, if there are a shortage of links, then it is worth spamming random nodes to create links.

Broadcasting a promise to pay (and incorporating it in the chain) would allow nodes to build up general trust levels.

Quote
On that note, I wonder how much of this discussion has already happened within the Ripple community. I haven't gone through their archives in much detail, but for those who are interested, I think much of the discussion regarding Ripple systems is happening over here: https://groups.google.com/group/rippleusers .

I had a quick look and some there think bitcoins are a bubble Smiley.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
rfugger
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile WWW
July 14, 2011, 01:51:30 PM
 #16

Hi.  I'm the founder of the Ripple project.  Nice to see Ripple being discussed as a real-time transaction overlay for Bitcoin.  I think the two are complementary -- Bitcoin is decentralized virtual gold, and Ripple is decentralized virtual banking. 

I'm working on a generic Ripple server to support the next version of Ripplepay.com that I intend to release as open source.  It won't be distributed at first, but it would work as a central server to query for routes (and also to process transactions atomically, which is probably actually a harder problem than routing in a distributed setup).  My design for a distributed Ripple protocol is here:

http://ripple-project.org/Protocol/Protocol05

Comments and suggestions are welcome.  If anyone is interested in helping with this, or just interested in implementing some kind of Bitcoin banking on top of it, let me know.

Thanks,
Ryan
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
July 14, 2011, 02:40:32 PM
 #17

and also to process transactions atomically, which is probably actually a harder problem than routing in a distributed setup

Yeah, I was wondering how you were planning to handle that.  A node could end up holding an IOU to the last link and then suddenly the transaction is canceled and he has an IOU from someone he doesn't trust.

Making the IOUs conditional on a transaction occurring in the bitcoin block-chain would resolve that, but would have a 1 hour or so delay before a transaction can be confirmed expired.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
rfugger
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile WWW
July 14, 2011, 02:52:37 PM
 #18

Yeah, I was wondering how you were planning to handle that.  A node could end up holding an IOU to the last link and then suddenly the transaction is canceled and he has an IOU from someone he doesn't trust.

The mechanism is that each node first promises the one ahead that it will pass an IOU in exchange for a commit token signed by a certain key, determined by the last node (the payment recipient).  Once all the promises are made, the recipient generates a commit token and passes it back to the previous node in exchange for an IOU, and so on back to the first node (the payer).

This is enough if all the nodes remain online and they are all well-behaved, but in case not, I've proposed a system of commit registries as an extension that should be fairly robust against node failure and cheating:

https://groups.google.com/forum/#!msg/rippleusers/Ruy_QIb0AAY/fUF5bGNJWXkJ

Ryan
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
July 14, 2011, 03:11:26 PM
 #19

This is enough if all the nodes remain online and they are all well-behaved, but in case not, I've proposed a system of commit registries as an extension that should be fairly robust against node failure and cheating:

https://groups.google.com/forum/#!msg/rippleusers/Ruy_QIb0AAY/fUF5bGNJWXkJ

I think that is similar to the suggestion to use the bitcoin chain itself as register.

You promise to pay subject to the bitcoin payment actually happening before a certain block number.  The bitcoin block chain can also be used to add arbitrary messages into the block chain, though this is discouraged.  These are effectively permanently timestamped as part of the bitcoin transfer system.

That means that each ripple transaction has to be matched by a bitcoin transaction.

For small payments, it should be possible to only reset the chain every few ripple transactions.  This prevents the bitcoin chain being used to certify that the main transaction took place.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
July 14, 2011, 03:13:56 PM
 #20


You should add a packet length field to your message system.

This allows older clients to ignore (or forward) any new packet types.  It also allows clients to use non-standard packets.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
rfugger
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile WWW
July 14, 2011, 04:07:27 PM
 #21

I think that is similar to the suggestion to use the bitcoin chain itself as register.

Sure, except it happens in real-time.

You should add a packet length field to your message system.

Each frame header has a length field.

Quote
This allows older clients to ignore (or forward) any new packet types.  It also allows clients to use non-standard packets.

For this I have frame version and type fields in the frame header, and message type in the message header...  I don't think I need message length, because the frames should be reliably reassembled into messages, and the messages should be signed if their content is important.  Am I still missing something? 

Thanks,
Ryan
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
July 14, 2011, 04:21:39 PM
 #22

Hm.

How about this:

I'm A, I want to pay one btc to B with fast validation.   I have a preexisting relationship with C, and B has a pre-existing relationship with B.

I give C a signed transaction with an nlocktime somewhat in the future, covering the the amount, any fees C is charging me, and any BTC txn fees.  C gives a similar open transaction to B.    

If there are more exchanges between any of the parties we replace the transactions with updated versions that reflect the new outstanding balances. All of the is hidden from the blockchain until the locktime runs out.  After some time has passed without any changes, the lock time arises and the latest version of the transactions are published, settling the accounts.

A<->C can settle independently of B<->C.

Parties are vulnerable to double spending of the committed funds, but thats why they have a pre-existing trust relationship. They are assured that their activities are backed by funds their trusted peer has— at least fractionally (in the case of double spending).

This obviously works when C is a chain of parties too.

Now the fun part is working out the bitcoin script commitment so that the bitcoin transactions are only valid when an IOU exists, so that if C tries to cheat A by reducing the reducing A's balance via an IOU payment, but then settles using the old open transaction instead of an updated one, that A can prove C cheated by presenting the sequence of IOUs.

enmaku
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500


View Profile
July 14, 2011, 04:35:46 PM
 #23

So my big question is: what percent of all transactions go to 0/unconfirmed and never actually verify? Is there any way to find this number and compare it to the percent of all credit card transactions which are reversed, transaction fees and CC fraud?

Most merchants are pretty accustomed to a plethora of possible fees and reversal scenarios for CC payments and as such have typically rolled an amount of expected loss into their business plans. The point of bitcoin is to make reversals impossible and blockchain errors rare - no matter what we do there will still always be a margin of error and a small bit of fraud. What's important isn't creating a flawless system, what's important is creating a BETTER system. If we can (provably) show that the expected rate of loss for BTC is drastically lower than credit card transactions and make it easy to use, merchants will adopt it more readily.
rfugger
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile WWW
July 14, 2011, 04:43:29 PM
 #24

So my big question is: what percent of all transactions go to 0/unconfirmed and never actually verify? Is there any way to find this number and compare it to the percent of all credit card transactions which are reversed, transaction fees and CC fraud?

Most merchants are pretty accustomed to a plethora of possible fees and reversal scenarios for CC payments and as such have typically rolled an amount of expected loss into their business plans. The point of bitcoin is to make reversals impossible and blockchain errors rare - no matter what we do there will still always be a margin of error and a small bit of fraud. What's important isn't creating a flawless system, what's important is creating a BETTER system. If we can (provably) show that the expected rate of loss for BTC is drastically lower than credit card transactions and make it easy to use, merchants will adopt it more readily.

The problem is that if merchants are told to just trust transactions that haven't been confirmed, then there is the possibility that the losses will be quite high.  The face that only a small percentage (zero?) of transactions are currently double spending isn't relevant, because no one out there is trusting transactions until they've been confirmed, so double-spending isn't a viable exploit.
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
July 14, 2011, 04:47:11 PM
 #25

Sure, except it happens in real-time.

There must be some kind of timeout.  If I promise to pay X, then I need to reserve that portion of the trust link.  If the IOU isn't cashed in, then I can purse the funding lock.

Quote
Each frame header has a length field.

Sorry must have missed it.

Quote
For this I have frame version and type fields in the frame header, and message type in the message header...  I don't think I need message length, because the frames should be reliably reassembled into messages, and the messages should be signed if their content is important.  Am I still missing something? 

Not sure.  Ideally, a proxy server should be able to skip/pass on messages/frames that it doesn't understand and just scan for the ones that it is interested in.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
July 14, 2011, 04:58:26 PM
 #26

The problem is that if merchants are told to just trust transactions that haven't been confirmed, then there is the possibility that the losses will be quite high.  The face that only a small percentage (zero?) of transactions are currently double spending isn't relevant, because no one out there is trusting transactions until they've been confirmed, so double-spending isn't a viable exploit.
If you set up a few "is this transaction pending" servers at well-known locations and only accept a transaction when it shows up at a majority of such locations (and no conflicting transactions show up at any of them) your vulnerability to a double-spend attack is so close to zero as to be negligible. (For the applications for which people routinely take credit cards or use cash.)

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
rfugger
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile WWW
July 14, 2011, 05:07:06 PM
 #27

Hm.

How about this:

I'm A, I want to pay one btc to B with fast validation.   I have a preexisting relationship with C, and B has a pre-existing relationship with B.

I give C a signed transaction with an nlocktime somewhat in the future, covering the the amount, any fees C is charging me, and any BTC txn fees.  C gives a similar open transaction to B.    

If there are more exchanges between any of the parties we replace the transactions with updated versions that reflect the new outstanding balances. All of the is hidden from the blockchain until the locktime runs out.  After some time has passed without any changes, the lock time arises and the latest version of the transactions are published, settling the accounts.

A<->C can settle independently of B<->C.

Parties are vulnerable to double spending of the committed funds, but thats why they have a pre-existing trust relationship. They are assured that their activities are backed by funds their trusted peer has— at least fractionally (in the case of double spending).

This obviously works when C is a chain of parties too.

That's pretty cool, but I'm not sure I see the benefit of the open transactions if you need to fully trust the other party anyway.  Why can't they just send normal transactions when it's time to settle?
rfugger
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile WWW
July 14, 2011, 05:11:48 PM
 #28

There must be some kind of timeout.  If I promise to pay X, then I need to reserve that portion of the trust link.  If the IOU isn't cashed in, then I can purse the funding lock.

Yes.  It should be possible to have a timeout on the order of seconds, though, since that's how long a successful transaction should take.
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250


View Profile
July 14, 2011, 08:48:20 PM
Last edit: July 14, 2011, 10:35:44 PM by fellowtraveler
 #29

Open-Transactions (https://github.com/FellowTraveler/Open-Transactions/wiki) is perfect for the "Fast Verification Network" piece of your diagram above...

At the simplest level, you bail the BTC into the OT server, and then OT processes all the transactions for as long as you want (you can use accounts, transfers, untraceable cash, cheques, markets/trades, signed receipts, etc.)
Then the user just bails back out into BTC again, whenever he wants back off of the server.

Benefits?
1) Untraceable transactions
2) Easy convertibility to other currencies on the OT market.
3) Instant finality of settlement
4) The server cannot forge transactions, or change balances without the user's signature.
5) All parties need only to store the last signed receipt, and they can prove their current balance, as well as prove which instruments are valid and which transactions are open or closed.
6) No worries about running out of space on the block chain.


===> YOU MIGHT ASK: But what if I don't want to TRUST the OT server with my Bitcoins? What if it steals them, or disappears, or gets hacked?

===> Based on conversations with Bitcoin developers, I believe I have found the solution to this. I've got the protocol figured out, but I haven't coded everything yet...

===> I've hinted at this before, but I've got a bit more free time now, so here it is:


THE GIST:   LOW-TRUST SERVERS (For Bitcoin on OT. The protocol is different with non-crypto-currencies.)

1) Basically, instead of bailing the BTC into a single server, you bail it into a VOTING POOL of maybe 50 different servers (or however many.) These will operate like a secure escrow in the blockchain. Many of you already have discussed this concept.

2) In my own protocol, the wallet signs the bail-in request, including the amount, the relevant IDs, etc, then the server countersigns it and sends you the receipt. (All the server is doing here is verifying everything in your request, and then signing it, too.)

3) Then your client GUI sends that receipt to the voting pool AND sends the Bitcoins to the pool. (There is no single recipient on the blockchain, but a pool of recipients at once.)

4) This same process happens in reverse when bailing back out. But this time, after the pool members verify that both parties have signed the bail-out request, they then vote on the blockchain to transfer BTC out to the recipient on that request, with a 3/4ths vote (or whatever) which is what actually effects the BTC transfer back to you. Rules can also be enforced here, involving inbox notification, time delays, maximum daily transfers, or whatever we decide.

5) The "vote" between the pool members occurs on the blockchain itself, using the built-in Bitcoin script language. Normally all votes will always be 100% in the same direction, since they will always agree on the truth. So we set it to 3/4ths or 9/10ths, whatever, so that it really takes a supermajority to do any bailment out, yet still leaves enough wiggle-room for the pool to prevent the loss of any BTC, and return it to the rightful owner, even if a server disappears or fails an audit.

6) If a receipt is ever submitted to the pool that's NOT properly signed, then the pool members simply vote to reject the receipt. (And probably to distrust the bad actor who submitted it.)

7) In the event that an OT server disappears, your BTC is still safe in the pool, and it's still possible to send a signed recovery request to the pool members, get your 3/4ths vote, and have your BTC transferred back to you.


There's more to it than that, and it involves the OT audit protocol as well, which is slightly different for issuer-based digital assets than it is for BTC-based digital assets (on OT.)

...But you get the general idea.

I've already got all the code I need on the Bitcoin side, I think, and I've got the new protocol figured out on the OT side (not coded yet).

I think I can swing this with the existing Bitcoin codebase (no changes to Bitcoin itself), and with the existing mining groups, though I'll have to include some Bitcoin code into OT for everything to work. I hope to be able to demonstrate this protocol soon. (Frankly I'm shocked no one else has done this yet.)

-------------------------------------

FYI, the "Point of Sale" and "Cell Phone" devices in your diagram above (as I picture them) are simply OT-API clients -- using the OT financial instruments to send payments to each other. (Cheques, cash, transfers, receipts etc.)  Each GUI is different, which is why OT-client side is an API. That way you can focus on your point-of-sale system, and let the OT-API do all the heavy lifting.

-------------------------------------

Bitcoin adds value to OT as well, in these ways:
1) BTC is a distributed, decentralized, reserve commodity that cannot be confiscated, counterfeited, or shut down.
2) BTC has all (most?) of the unique monetary properties of gold, which properties historically always cause gold, by operation of the invisible hand of the free market, to be used as money, in all cases where force and fraud have not perverted it. (Bitcoin being transferrable p2p, recognizable, limited, homogenous, fungible, divisible, and an efficient store of value in space and time.)
3) Bitcoin has an existing network of exchangers in/out of the various fiat currencies, in the various jurisdictions.
4) Bitcoin can be a "UNIVERSAL MEDIUM" between OT servers... users will be able to store funds in gold, but then convert to BTC on OT markets, whenever they want to hop to another server. This makes Bitcoin very very very useful even for goldbug users.
5) Such transfers will also occur through DGC issuers, who are presumably already at both ends, and more importantly, through Ripple, which is being built into the OT test GUI, Moneychanger. (Thus, I also see this as a potential bridge between Bitcoin and Ripple.)
6) Bitcoin makes it possible to run transaction servers, and other darknet servers, anonymously yet at a profit. That is very useful to OT.






co-founder, Monetas
creator, Open-Transactions
becoin
Legendary
*
Offline Offline

Activity: 3431
Merit: 1233



View Profile
July 18, 2011, 06:45:49 AM
 #30

following this
cjp (OP)
Full Member
***
Offline Offline

Activity: 210
Merit: 124



View Profile WWW
July 18, 2011, 05:14:10 PM
 #31

First of all: I thank all of you for your replies. I received some useful ideas and new inspiration from them.

About the ripple project:
I've heard about it, but I never found any good resources, so I never managed to understand it (until now). I worked out the principles on my own, and later I combined it with the Bitcoin idea into the concept of my original post. If there is a Ripple development forum, I think some of the ideas are better discussed over there. But for now, I will post my ideas in this thread.

About the Open Transactions project:
I still don't quite understand it. How centralized is it? I see there can be multiple OT servers, but can they form a network? If some shop only connects to a single OT server, can I still do payments if that OT server refuses to connect to me?

About using the fast verification network for reducing the number of Bitcoin transactions:
Originally, I didn't think of that, but it might be a very useful feature.

The problem is: you effectively end up accepting IOUs for payments, and that opens the road to fractional reserve "banking". How do you know that the person you trust is capable of paying his debts? Of course this can be part of the 'trust' as well, but this kind of trust doesn't stay local. If person A trusts person B, who gives IOUs to A, and backs his IOUs with IOUs from person C, then a bankruptcy of person C might affect person A, because B's IOUs are no longer backed. See the current financial problems in the world for an example on how not to do things.

I like the idea of using the block chain to prove that you own a certain amount that backs your IOUs. However, there is still the risk that a person uses one Bitcoin account for the backing multiple connections. Can this be solved with some sort of Bitcoin script? Maybe two 'trust-linked' parties can create a shared amount of bitcoins, which can only be spent if both of them agree? Then, these bitcoins can only be used for backing on that particular link, and they can be used for backing in both directions. And, having to work together to be able to spend the coins might give an incentive for staying honest and keeping the link up.

Naturally, the 'backing account' should not be modified for every transaction that flows through the link, or otherwise we would create a huge number of Bitcoin transactions, which is what we tried to avoid in the first place. Instead, it should be modified once in a while to correct for long-term transaction unbalance. Effectively, the meaning of IOUs becomes "this part of the backing account belongs to you, and the rest belongs to me".

Also, to reduce Bitcoin load even more, the IOU inbalance could be settled by detecting and eliminating IOU 'loops' in the network. Maybe this is not necessary if transactions are always sent to the 'best-quality' link: then, loops will automatically be reduced by new transactions.

About the routing problem, anonymity and atomic transactions:
For me, anonymity is an essential feature, so the question is how to do routing without letting everyone know who you trust.

First of all: your 'trust partner' (let's call him your friend) knows that you share a trust link, and he could inform the rest of the world about it. I don't think you can fix that, so you'll just have to trust him for respecting your privacy. Or you can try to make friends pseudonymously.

For establishing a link through the network, the receiving side needs to be listed in routing tables through the entire network, so that the 'link initiation message' can always be sent in the right direction. The receiving side can not be completely anonymous, but he can be 'pseudonymous'. Compare it e.g. to a TOR hidden service. This is already more anonymity than typically needed, because in real life, shops are typically not anonymous at all. Only customers can have high anonymity expectations. So, I think the customer needs to be the party who initiates the link, and the shop is the party who is listed in the routing tables.

I don't think the intermediate nodes in the link need to be known to each other. If necessary, they can create temporary pseudonyms for each transaction, and send a signed message to their friends to indicate that whatever is signed by the pseudonym, is approved by them. Having signatures from all nodes in a link might be a requirement for accepting a payment atomically, but if all signatures are made with temporary pseudonyms, then only your friends know that it's you who provided the signature.

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
cjp (OP)
Full Member
***
Offline Offline

Activity: 210
Merit: 124



View Profile WWW
August 17, 2011, 06:04:15 PM
 #32

I managed to write down what I conceptually want to create. You can read the description here.

Notice the difference with the Ripple, in the use of a shared Bitcoin wallet to back IOUs.

I don't know whether this can be implemented on the Ripple network. I suspect it is not possible: if I am correct, there are only a limited number of message types in the Ripple protocol, and some of the things I want to do probably don't fit in these message types.

After writing this, I suspect that it might be possible to add arbitrary-currency transactions to my concept, while keeping the shared wallets based on Bitcoin. However, that is something that still needs to be investigated, and it is almost certainly going to cause some trouble and require important design choices.

My next goals are:
  • have a detailed network protocol specification
  • have a architectural diagram for the first implementation

But first, I am going to make some quick prototypes, to find out what works and what doesn't.

In the future, you can expect me to release a prototype with a web interface, that works with testnet. Then I want to invite the white-hat hackers in this community to tell me what's wrong with it.

In fact, if you already spot some problems in the conceptual description of my design, please tell me ASAP.

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
jtimon
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


View Profile WWW
August 18, 2011, 12:30:11 PM
 #33

I see the instawallet green address approach as the most promising one right now, but I should read this thread more deeply.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
cjp (OP)
Full Member
***
Offline Offline

Activity: 210
Merit: 124



View Profile WWW
August 18, 2011, 07:51:48 PM
 #34

I see the instawallet green address approach as the most promising one right now, but I should read this thread more deeply.

Your forum signature seems to indicate that you are familiar with the Ripple. So, to get you started with understanding my idea: it is a variation on the Ripple.
Or, more accurately: two variations. One idea is in the first post of this thread, but based on the replies I've made another idea, which has the advantage of reducing the number of transactions in the Bitcoin block chain.

About instawallet:
I see what you mean, but that approach is not really decentralized. If merchants accept only instawallet green address transactions, and instawallet suddenly stops operating properly, you have a problem. Of course you can have multiple instawallet services, but merchants will never trust more than just a few of them. What you need is a network of such services, and that brings you back to the Ripple concept.

About open transactions:
I am still trying to understand the Open Transactions project. I think the problem is that the open transactions website is mostly busy in explaining what it can be used for and what its advantages are, and fails to explain the basic principles of its technology. Is this OT project well known within the Bitcoin community?

From what I understand now, OT is basically a programming library for creating digital contracts, exchanging these contracts, signing them, checking signatures & so on. Is that correct? As such, it could be an interesting low-level layer, on top of which my ideas could be implemented. But as long as I don't understand it, I can't use it as a programmer...

I need a name for my project
Does someone have a suggestion? With a name, I can create a website, make my design documents a bit clearer, and so on.

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
becoin
Legendary
*
Offline Offline

Activity: 3431
Merit: 1233



View Profile
August 18, 2011, 08:40:14 PM
 #35

I need a name for my project
Does someone have a suggestion? With a name, I can create a website, make my design documents a bit clearer, and so on.
If it is about POS transactions the name of such a project can be poscoin. But first, let me tell you that your efforts are much appreciated. This is the right direction to follow.

I agree that the major challenge ahead would be creating a distributed system based on trust. I also agree that ripple project is a good base but a lot of additional work has to be done. Not so much about technicalities but about theory, because we shall enter into uncharted territory. My advice to you would be not to go into too much technical details at this phase. A lot of theoretical questions need to be answered first. Tomorrow I'll try to post some of my considerations.
rfugger
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile WWW
August 19, 2011, 06:57:55 AM
 #36

I managed to write down what I conceptually want to create. You can read the description here.

Notice the difference with the Ripple, in the use of a shared Bitcoin wallet to back IOUs.

I don't know whether this can be implemented on the Ripple network. I suspect it is not possible: if I am correct, there are only a limited number of message types in the Ripple protocol, and some of the things I want to do probably don't fit in these message types.

You could certainly build this on top of Ripple as a particular kind of trust account (shared bitcoin wallet).  Nothing about the payment routing would be affected as far as i can see.

Ryan
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250


View Profile
August 19, 2011, 11:41:11 AM
Last edit: August 19, 2011, 11:52:05 AM by fellowtraveler
 #37

About open transactions:
I am still trying to understand the Open Transactions project. I think the problem is that the open transactions website is mostly busy in explaining what it can be used for and what its advantages are, and fails to explain the basic principles of its technology. Is this OT project well known within the Bitcoin community?

From what I understand now, OT is basically a programming library for creating digital contracts, exchanging these contracts, signing them, checking signatures & so on. Is that correct? As such, it could be an interesting low-level layer, on top of which my ideas could be implemented. But as long as I don't understand it, I can't use it as a programmer...

You are correct that OT is a library. Additionally, it is also a server, a client API, and a GUI test client (in Java.)

You described its functions thusly: "for creating digital contracts, exchanging these contracts, signing them, checking signatures & so on. Is that correct?"

Yes, but much more...
OT enables you to issue CURRENCIES based on those contracts,
and it enables anyone else to open ACCOUNTS in those currency types.

It also enables users to withdraw in untraceable digital CASH.
Users may even operate CASH-ONLY (without accounts.)
OT also enables users to take advantage of OTHER INSTRUMENTS,
such as CHEQUES, CASHIER'S CHEQUES, ACCOUNT TRANSFER, etc,
the same as they would normally at the bank down the street.

Users can even trade their digital assets on MARKETS against other
asset types, the same as they do now on sites like MtGox.

OT also does these things with SIGNED RECEIPTS, in such a way that not
even a server can forge a transaction, or change your balance, without
first getting your signature. (The server cannot forge your signature on a
receipt.)

---------------------------------------------------------------


Quote
But as long as I don't understand it, I can't use it as a programmer...

The client API, with comments, is here:
https://github.com/FellowTraveler/Open-Transactions/wiki/API

Instructions for using the client API are here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases

A sample implementation (in Java) of a test GUI, using the OT API:
https://github.com/FellowTraveler/Moneychanger

I am, of course, available to answer questions, and there is also a mailing list: open-transactions-subscribe@rayservers.com

So that anyone who pleads ignorance is without excuse.

---------------------------------------------------------------

Quote
I think the problem is that the open transactions website is mostly busy in explaining what it can be used for and what its advantages are, and fails to explain the basic principles of its technology.

The basic principles of its technology?

1) Ricardian Contracts. The contracts are Ricardian-style contracts, and they are used to denote the servers as well as the asset types. Any new currency on OT is issued by the issuer uploading that currency to any OT server. (The currency will have the same ID across all servers.)
You can see a sample currency contract here:  https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Currency-Contract
The functionality of OT is similar to Ricardo, which is described here (with pictures!):  http://www.systemics.com/docs/sox/overview.html
Here is the Ian Grigg URL on Ricardian Contracts: http://iang.org/papers/ricardian_contract.html

2) Triple-Signed Receipts are employed, so that servers are unable to forge transactions or change balances. (The server cannot forge your signature on the receipt. The receipt is the account.) The core transaction engine is designed in this way, so that the same protection is afforded to all instruments (such as market receipts, cheque receipts, etc.)

3) Destruction of Account History. For its core account system and financial instruments, Open-Transactions uses balance agreement and transaction numbers on every receipt, in such a way that the parties to any transaction can prove their balances, and which instruments are valid, without having to store their entire transaction history, and instead by simply producing their last signed receipt.
I describe how it all works right here:  https://github.com/FellowTraveler/Open-Transactions/wiki/Triple-Signed-Receipts
A similar protocol (Truledger) is very well described here, with examples:  http://truledger.com/doc/plain-english.html

4) Untraceable digital cash. Open Transactions uses Chaumian Blinding to offer the untraceable cash.
You can read about the technology here:
http://www.cs.bham.ac.uk/~mdr/teaching/modules06/netsec/lectures/DigitalCash.html
Here is a sample piece of OT cash and an article: https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Cash
There are various digital cash libraries floating around out there. Currently I am using this one: http://anoncvs.aldigital.co.uk/lucre/

5) Many Financial Instruments. Cheques, Cash, Markets, Payment Plans (recurring), Withdrawals and Deposits, Account-to-account transfer, Receipts, Inboxes, Contracts, etc. More coming.
Article:  https://github.com/FellowTraveler/Open-Transactions/wiki/Instruments

6) Federated Servers. Instead of a centralized model, OT tries to federate its services wherever possible. For example:
--- The same currency could be issued at multiple servers.
--- The same currency would have the same ID across all servers.
--- The same Nym would have the same ID across all servers.
--- Server-to-server transfers are possible through the issuer, since the issuer already has a presence on every server where he's issued.
--- Users can trade in basket currencies, which distribute risk across multiple issuers.
--- (coming soon) OT Servers will implement voting pools for Bitcoin, meaning a hacker could not steal your Bitcoin from a server unless he'd also hacked 90 of the other servers in the pool, and gotten their private keys and their passphrases.
--- A clever wallet software could distribute the assets of a single "account" across multiple servers, and abstract that away in the user interface.
Article: https://github.com/FellowTraveler/Open-Transactions/wiki/CENTRALIZED
Diagram: http://billstclair.com/ot/ot-diagram.jpg

So if you were to ask me the principles behind Open Transactions, in a nutshell I'd say:
Ricardian Contracts
Signed Receipts
Unforgeable Balances
Destruction of Account History
Chaumian Blinding (Untraceable Cash)
Many Financial Instruments
Federated Servers

Feel free to ask if you have any other questions.

-FT





co-founder, Monetas
creator, Open-Transactions
becoin
Legendary
*
Offline Offline

Activity: 3431
Merit: 1233



View Profile
August 20, 2011, 04:00:24 PM
 #38

A group of people under the name "Satoshi" showed us it is possible. Thank you! I'm going to explain, however, that this is just a fraction of what needs to be done if a bitcoin economy is the final goal. I feel sick to read this forum day after day and see how much time, resources and talent are wasted chasing barren ideas. Current thread is the closest match to some of my own ideas.

Part I - Bitcoin is not digital currency.

Although bitcoin concept is far from being flawless it can still serve well as digital gold. I would personally like to see competing block chains like digital silver, digital platinum, digital palladium or (why not) digital diamonds, and so on. All digital money must be open source distributed p2p applications and defer not only by the name but by initial distribution, cryptographic principles, network protocol specifications, mining methods, transaction fees and how they are defined, etc. All they must have floating exchange rates towards one another which will change in line with how efficiently over time they fulfill well known money functions:

"Money is a matter of functions four, a medium, a measure, a standard, a store."

Store of value
Unit (measure) of account
Medium of exchange
Standard of deferred payment

http://en.wikipedia.org/wiki/Money

During last 5000 years gold served well as money. With the advent of Industrialization and mass markets it became apparent that physical gold is not very suitable to be medium of exchange. Contradiction was resolved by issuing paper certificates of gold ownership by private banks or governments. We all know many examples of how this was abused. The most successful system used was kind of mixture - bilateral or multilateral trade agreements where unit of account for every purchase was gold but only final outstanding balances were cleared through physical delivery of gold. Yet it was (and still is) expensive drill. Takes couple of days to prepare and move gold bars and coins from one point to another using train, plane or battleship. Until 1971 when some people decided they can play God and removed the gold standard. Only 40 years later we are where we are... in front of a major economic disaster.

Bitcoin concept (arguably) is a major step forward compared to gold. Instead of train, plane or battleship and couple of days preparations now it takes Internet connected computer and 1 hour of time (6 blocks). But still, it takes 1 hour to move bitcoin (digital gold) from one address to another. Given nowadays shopping habits not just 1 hour, but even 1 minute is too much!

Conclusion:
Bitcoin is a major improvement but still is digital gold, kind of. Complimentary payment system needs to be developed based on bitcoin (digital gold) as clearing currency. I would not use terms like fast bitcoin and slow bitcoin transactions, because this suggests overlapping parts of payment instruments, systems, block chains, or network protocols. THIS MUST BE AVOIDED AT ANY COST!

Next: Dichotomy
cjp (OP)
Full Member
***
Offline Offline

Activity: 210
Merit: 124



View Profile WWW
August 22, 2011, 09:13:47 PM
 #39

I updated the concept description, and converted it to PDF. You can find the most recent one here. Please watch the date: I'll overwrite the document when I finish a new version. If you want to keep the current version, please keep a back-up on your own system.

I would not use terms like fast bitcoin and slow bitcoin transactions, because this suggests overlapping parts of payment instruments, systems, block chains, or network protocols. THIS MUST BE AVOIDED AT ANY COST!

Is this an advice on how to name this system? In that case, thanks for the help. However, suggestions like "do something like this" are more useful than "don't do something like this".

About Open Transactions
I think that Open Transactions is a much broader concept than my payment system. It seems to have more features, but having more features also has a disadvantage: if it also makes the software more complex, this makes it more difficult to have the source code reviewed by independent parties. I believe that having independent code reviews, and hence having clear, simple, publicly available source code are very important for building trust in software.

Maybe OT solves certain problems in a different way than the concept described by me. In that case: please point me to the disadvantages / flaws in my approach, and explain me how to do better.

Maybe OT can solve certain problems in the same way as I do. In other words: maybe my concepts can be implemented on top of OT. Even if that is the case, I will initially not use OT, for the sake of simplicity (see above reasoning). However, I will make the software layered in such a way that the top-level layer can easily be re-used on top of another bottom-layer. For instance, if an implementation on top of OT turns out to be a popular request from the community, I might decide to add that, or to switch to OT in the future.

For now, that's the last I have to say about OT.

About the Ripple
I'll keep contact with Ryan to see whether this concept fits inside the Ripple system, or whether this and the Ripple need to be separate projects.

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
becoin
Legendary
*
Offline Offline

Activity: 3431
Merit: 1233



View Profile
August 27, 2011, 06:26:43 AM
 #40

I would not use terms like fast bitcoin and slow bitcoin transactions, because this suggests overlapping parts of payment instruments, systems, block chains, or network protocols. THIS MUST BE AVOIDED AT ANY COST!

Is this an advice on how to name this system? In that case, thanks for the help. However, suggestions like "do something like this" are more useful than "don't do something like this".

No offense, but did you read that?

I need a name for my project
Does someone have a suggestion? With a name, I can create a website, make my design documents a bit clearer, and so on.
If it is about POS transactions the name of such a project can be poscoin.

If you like it I'm ready to contribute poscoin.com to this project. Just PM me and I'll gladly change DNS settings to point to your hosting account.
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250


View Profile
August 27, 2011, 08:21:45 AM
 #41

About Open Transactions
I think that Open Transactions is a much broader concept than my payment system. It seems to have more features, but having more features also has a disadvantage: if it also makes the software more complex, this makes it more difficult to have the source code reviewed by independent parties. I believe that having independent code reviews, and hence having clear, simple, publicly available source code are very important for building trust in software.

Maybe OT solves certain problems in a different way than the concept described by me. In that case: please point me to the disadvantages / flaws in my approach, and explain me how to do better.

Maybe OT can solve certain problems in the same way as I do. In other words: maybe my concepts can be implemented on top of OT. Even if that is the case, I will initially not use OT, for the sake of simplicity (see above reasoning). However, I will make the software layered in such a way that the top-level layer can easily be re-used on top of another bottom-layer. For instance, if an implementation on top of OT turns out to be a popular request from the community, I might decide to add that, or to switch to OT in the future.

FYI, I just posted a video walkthru of OT, which will probably help you a lot in understanding the concepts, and what it actually does.

Check it out here: http://vimeo.com/28141679

co-founder, Monetas
creator, Open-Transactions
cjp (OP)
Full Member
***
Offline Offline

Activity: 210
Merit: 124



View Profile WWW
August 27, 2011, 12:52:36 PM
 #42

I would not use terms like fast bitcoin and slow bitcoin transactions, because this suggests overlapping parts of payment instruments, systems, block chains, or network protocols. THIS MUST BE AVOIDED AT ANY COST!

Is this an advice on how to name this system? In that case, thanks for the help. However, suggestions like "do something like this" are more useful than "don't do something like this".

No offense, but did you read that?

I've read your entire post, but to be honest I did not understand it. The part I quoted is the only part I could interpret in such a way that it applies to the discussion in this thread.

Based on your response, I now believe I even misunderstood that part.

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
jtimon
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


View Profile WWW
August 27, 2011, 02:48:15 PM
 #43

FYI, I just posted a video walkthru of OT, which will probably help you a lot in understanding the concepts, and what it actually does.

Check it out here: http://vimeo.com/28141679

Thank you for the videos. I think I understand OT better now.
If the market could be extended to support "composite trades", ripple could be implemented within Open transactions.
This would be nice for bitcoin instant payments.
Please, let me know if you're interested in implementing ripple inside OT. I think that it would be relatively easy, given the functionalities that OT already has.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Pages: 1 2 3 [All]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!