Quote from: retep on March 15, 2013, 04:36:55 PM

Cool! Also I'm seconding jgarzik's demand to see a demo.

If cjp decides not to include this method in his project, I will try to write a demo this summer after some major obligations are finished up in early June.

Quote from: jgarzik on March 15, 2013, 05:30:45 PM

FWIW, I've been talking on IRC about a decentralized network of bots (numbering 3, 5, or 7, not large numbers) that would facilitate off-chain transactions, escrow, auctions, etc.

With the network you mentioned on IRC (I did read the logs) or even a decentralized node with intermediaries which forward funds, I think that would mean the intermediary nodes would need to register under the clarified FinCEN rules in the US. Since I live in the US, that would preclude me from being able to run a node such as this anywhere but on testnet. However, as I understand it, this wouldn't prevent US residents from using such a network through intermediary nodes based in another jurisdiction.

Quote from: Mike Hearn on March 15, 2013, 05:53:37 PM

This is great work. I think a network of nodes with channels between them has been proposed before, or at least I remember talking about it, but nobody has gone into as much depth as you have. The 2-phase commit is a neat extension.

Yes, it was proposed before by cjp here and by Meni Rosenfeld here.

Quote from: Mike Hearn on March 15, 2013, 05:53:37 PM

I was a bit confused by your description of channels as "uni-directional". You realize that the amount of value transferred from Alice to Bob can go down as well as up, right? I don't see why you need to create them in pairs.

You're correct; I corrected myself in a previous post in this thread after a comment by cjp. It's still more efficient to treat them as reversible rather than bidirectional, IMO, due to my preferred tx versioning method including bringing nLockTime closer (see farther down in my reply).

Quote from: Mike Hearn on March 15, 2013, 05:53:37 PM

The main issue I see is the need to constantly have some coins allocated to the intermediaries - regular Bitcoin payments require no such pre-commitments. Of course this is an issue with the entire concept of payment channels (they are not necessarily micropayment sized), but for most micropayment applications the amount of money you lock up isn't that big and the channel can close fairly quickly. Deciding how much to allocate could be rather tricky. For routing of micropayments around it wouldn't matter so much and that may be the most optimal application.

I would agree that, at least to start, this should be a micropayment application. I'm personally interested in using Bitcoin as a means of allocating resources in a peer-to-peer computation network (so instead of mining, people can put their GPUs and FPGAs to work folding proteins for profit, for example, and a researcher can just pay peers in the network when they happen upon a solution with an energy level that's a certain amount lower than a previous solution rather than building his own compute cluster or relying on volunteers running Folding@Home). In addition, I wouldn't trust large amounts of money to a node on such a network until the software has proven itself in micropayments. Also, if the price continues to go up, the micropayment network can become a retail payment network without increasing the amount of money in the payment channels between nodes as denominated in bitcoins.

Quote from: Mike Hearn on March 15, 2013, 05:53:37 PM

I wouldn't bother trying to come up with ways to work around the networks current limitations. We know what we need to do to reactivate transaction replacement and make non-final transactions standard again. If you don't want to do that, you can (and should) always prototype on the testnet where I think IsStandard is disabled and tx replacement is enabled.

Even with a full re-enabling of non-final transactions as standard and transaction replacement, you can't force any of these changes on miners. The discussion in the previously-mentioned thread Meni started had a mention of decreasing nLockTime starting here. Decreasing nLockTime can be combined with increasing fees, if necessary, but also with incremental transaction version numbers so that the mechanism works no matter how transaction replacement is implemented.

Quote from: Mike Hearn on March 15, 2013, 05:53:37 PM

You would need to consider how peers can discover each other. Even if routing data can be extracted from the block chain, the protocol requires direct communication between all parties (ie, TCP connections). IP addresses change. One possibility is to require all participants to use Tor and then embed your hidden service key in a transaction. That way you get authentication, encryption and privacy for free. This boils down to using (abusing?) the Tor HSDir servers as a secure rendezvous mechanism. The short key hash (onion address) can be added to the channel transactions using OP_DROP. Note that whilst the Tor protocol is very slow/heavy for connecting, there is a proposed optimization for the case where participants don't actually care about being hidden:

https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-encrypted-services.txt

In many cases these intermediaries wouldn't care about being hidden, so that can make things faster.

Yes, this was outside the scope of what I was trying to write. My initial demo would probably have whitelisted keys and manual connections and go for node discovery from there. I would probably do node discovery in a broadcast network or even a DHT. To advertise its presence, a node would sign a statement with its key that contains the several last seen block hashes, the number of blocks for which the statement is valid, and the IP address(es)/eepsites/Tor hidden services at which the node can be contacted. The node would then either broadcast it through the P2P broadcast network or write it to the DHT, associated with a hash of its key. Other nodes trying to contact the signing node would be able to compare the age and validity of signed statements.

Quote from: cjp on March 16, 2013, 02:06:41 PM

Is this a correct summary of your proposal?:

Code:

m is initially only known by final payee
hash(m) is sent together with promise
...

Yes, except the part I pasted above. m can be known only by the payer, instead, and used for escrow.

Quote from: cjp on March 16, 2013, 02:06:41 PM

New idea 1: if a transaction stays undecided for too long, any node can put a bounty on publication of m, by making an (in-blockchain) Bitcoin transaction that can be spent with m; I think the scriptPubKey will be something like this:

Code:

SHA256 Hashm EQUALVERIFY

True, and neat! However, the incentives may not line up: the intermediary node wouldn't want to spend more than it would gain from m's publication, and the only person who knows m wouldn't want to publish m without getting at least the amount she stands to lose by the publication in return.

Quote from: cjp on March 16, 2013, 02:06:41 PM

New idea 2: you don't have to put all bitcoins of a link at stake when performing a transaction. You can also make a "promise T2" with outputs like this:

Code:

1. 89.99 BTC to: PubkeyAlice CHECKSIGVERIFY
2. 00.01 BTC to: SHA256 Hashm EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
3. 10.00 BTC to: PubkeyCarol CHECKSIGVERIFY

This can be generalized to allow multiple transactions happening simultaneously on the same channel, even in opposite directions.

I'm not sure I understand what you're proposing. If you have time and are still interested in developing this new idea further, I'd love it if you could explain it in more detail.

Quote from: cjp on March 16, 2013, 02:06:41 PM

Possible problem: What happens when nLockTime is reached on a channel that is in "undecided" state?
Scenario:

T2_old = (1BTC to payer, 0BTC to payee)
T2_promise = (0BTC to (payer,m), 1BTC to (payee,m), nLockTime = T2_old.nLockTime - 1 week)
m is not published
T2_promise.nLockTime is reached
payee broadcasts T2_promise
T2_promise is included into block chain

Result: link remains "undecided" forever, unless m is published
Disincentive: never let payee have 0BTC (so he would risk losing his own BTC by doing this)

This is the risk deposit concept mentioned earlier.

Quote from: cjp on March 16, 2013, 02:06:41 PM

Question to think about: What happens when nLockTime is different for different channels in a payment? What will be the incentive for different participants when it comes to commit/rollback/keep things undecided until nLockTime?

I don't believe this would be a problem as long as there's enough risk deposit from both side of each channel and channels are finalized well before the closest nLockTime hits. It would be in each node's interest to do this to avoid exactly the scenario where nLockTime hits an undecided transaction. Having a risk deposit that's a large multiple of the maximum payment size allowed through a channel prevents any party from wanting to lock up the coins in a payment because it costs them a much bigger risk deposit.