Finally, a response to some of your own concepts:

I've read the threads you linked to about risk deposits. If I understand correctly, they work very similar to the "shared property" in my concept: I even hinted in my paper that, if one neighbor doesn't trust the other, he should make sure that the other keeps a significant fraction of the shared account, to make "hijacking"/"blackmailing" expensive. Using a 3rd party as escrow is a an interesting possibility; I didn't think of that yet. The difference with my concept is that, in your proposal, a failure somewhere in the middle of the chain can lead to blocked transactions, loss of reputation and possibly locked up risk deposits throughout the half of the chain, while in my concept the damage of misbehavior remains limited to the direct neighbor of the misbehaving node, and the misbehaving node itself.

Ah, I was actually planning to use a different routing method than you, to improve privacy. People typically don't want others to know who they are connected to. The downside of my routing method would be that the above "debugging" wouldn't be possible. But you are right: if routing is based on a publicly known network shape, and you can communicate directly with any node in the network, you have a good chance of identifying misbehaving defunct nodes.

Well, no.
Consider there are three parties:
Alice, Bob and Carol.
Alice spends 0.01 BTC to Bob and the same 0.01 BTC to Carol. Which transaction will be accepted?

I understand it better now, but still not get what "microtransaction channel" is? Is it special bitcoin transaction? Does it need to be opened long before microtransactions can be made? Is it pre-paid? Does it need to be recorded on blockchain and confirmed?

Thanks for explanation, I understand basic idea now.

Demo is available now:

https://github.com/aakselrod/libtxchain-java

It depends on BitcoinJ 0.10-SNAPSHOT from about a month ago (hopefully not too much in terms of API has changed since then).  It requires bitcoind running locally in regtest mode, with the snapshot from here:

https://github.com/aakselrod/bitcoin/tree/stdpreimage

The only change I've committed is permitting three new templates as standard transaction types (only one of them is used in this demo, though).

This demo is a proof of concept only - it has lots of bugs that need fixing, it doesn't support any kind of communication between nodes other than within the same process, it does no error checking or input validation whatsoever, etc.  It just sets up two payment channels (between an intermediary and two endpoints), and sends some payments between the endpoints by way of the intermediary.

I'm releasing this code into the public domain.  I've timestamped the file, info at the following URL:

https://www.proofofexistence.com/detail/44020f041501aea0d01ed3e0a7dd822732e5c9945dfedc9271d19890b4a3592d

(Although now that I look at it, it looks like they haven't actually sent any transactions to the blockchain in a while... hrm...)

Awesome, thanks for looking at it!  I'll update it to 0.10 when that's out.


I actually started working on this before 0.9 was published, so a lot of what you see is a mishmash of code based on 0.9-SNAPSHOT that was refactored (but not fully) to 0.10-SNAPSHOT.  I had already had a lot of it written (the bottleneck, aside from my limited time due to how busy my paid job and family make me, was testing on testnet before I realized you'd added regtest mode) prior to the BitcoinJ payment channel API.  As I was going to release it to the public domain, I figured I wouldn't spend much time looking at the payment channel code in BitcoinJ until I was ready to do so; that would avoid contaminating public domain code with Apache licensed code.

There are a couple of things that would be needed in the BItcoinJ payment channel code to be able to do this:

• The hash preimage part of the SriptPubKey/ScriptSig needs to be supported in order to send payments through chained channels atomically, and is what made the addition of the templates I wrote necessary in bitcoind
• Risk deposits are necessary for the chaining as well, and as far as I can tell, your code doesn't yet support them
• Reversing a payment channel is also useful, and I haven't yet looked to see if your code supports that, though it's probably not too difficult to add

It's definitely my intent to replace any polling with futures as appropriate, but there are lots of APIs I'm as yet unfamiliar with.  This was almost a braindump into code, and I'll clean this part up.


I intend to move away from using WalletAppKit and use discrete components instead, but this was good for a starting point.  I didn't see you add that method before I wrote the code that connects to the local regtest-mode bitcoind, or I would've used it, thanks!


I've already started using some of them (in particular, the multisig-related static methods, which I switched away from manually building those scripts opcode-by-opcode), but I'll look at it again and see what else I'm missing.  You've been working on ScriptBuilder as I've been working on this, so I probably haven't yet caught up with all the improvements.


You're right, concurrency is one of the things I haven't yet worked on in this context.  In using regtest, I was setting up an environment where this wouldn't matter much, but I need to fix this prior to the code being ready for pre-alpha.  The TODO list specifies this.  The reason I'm starting a new thread in this context is that when I wrote this code, BitcoinJ was still in 0.9-SNAPSHOT, and I wasn't thinking about thread safety yet.


I'm planning on moving away from that and using discrete components of BitcoinJ as I continue development.  There are lots of inconsitencies and things done wrong in my code... I've taken a note on a lot of them in the TODO file, but I have missed some, so thank you for looking over the code!  I hope to have time to improve on it in the near future and get it closer to a working model.


Now that I've published this, I'm planning on taking a closer look and seeing if I can use the standard payment channels API instead of what I wrote.  Thanks for providing such a great library to build on!

By reversing, I mean exactly what you mean:  reducing the value to the responder and increasing it to the initiator.

In the PaymentChannel.pay() method in my code, I keep track of a boolean called iSentLast.  If this boolean is false, I do the following things:

• Increase the fee by feeStep
• Decrease the locktime by locktimeStep
• Increment the contract input's sequence number by 1

This reduces the lifetime of the payment channel (I use blocks rather than time to count lifetime), and ensures that payments in the new direction become standard before payments in the old direction.  When transaction replacement is enabled, the increase in fee and sequence number will also help ensure that the new direction is prioritized over the old direction.

When a payment is sent in the same direction as the last payment, these steps don't need to be taken.  The recipient of the payment is the only party in possession of the fully-signed transaction for both payments, so the fact that the transaction for the latest payment contains the biggest take for the recipient should be enough motivation for the recipient to publish it.  My code doesn't yet handle the case where the recipient doesn't publish the latest transaction, but does handle the case where the recipient is offline and does not publish the transaction at all (in that case, the sender publishes the last fully-signed transaction s/he has when it becomes standard, stealing money from the recipient).

Unfortunately, peers need to be online in my scheme in order to process payments and tear down payment channels at the right time, and this highlights the locktimeStep-based trade-off between payment security and the need to tear down/rebuild channels.  I think in most cases, people will want to have a pair of channels and a large locktimeStep (at least 12 blocks probably), and only reverse them when they get fully used up, and I'll add methods to do that to the code when I get there.  For proof of concept purposes, this wasn't as important.

There is bug in the current code that prevents the fee from being incremented in at least one instance where it should (when making the first payment after the channel is established), but it's one of many bugs I know about and know how to fix, so I left it for a future update.

By the way, I meant to respond to your mention of IntelliJ - I am using Eclipse and it also has similar refactor functionality, though I've made very little use of it thus far.  I apologize in advance for my code being clunky/awkward, I'm still getting back up to speed on any sort of serious programming (and enjoying it immensely).

Your list of advantages is right, and I'm even more interested in the use of this technology to monetize other P2P services and meshnets without needing to create new currencies.

Unfortunately, I've been busy with paying work and family obligations. After the next one or two bubbles, I'm hoping to be able to quit my job and/or hire a freelancer to finish this, but I can't do that as things currently stand. I've written a prototype in case anyone with time feels like working on this in the meantime, and it's public domain and published on Github.

May I quote you on saying that this could be "the most important improvement since Bitcoin itself?" Maybe it would help me line up some resources to be able to work on this.


Because a node accepts money in one payment channel and sends it out another, I wouldn't bet on FinCEN not seeing the running of such a node as money transmission. I have no doubt this would quickly become impossible to police, but I'm not willing to stick my neck out personally to run such a node in production in the US. I have a family to care for. Still, running a node with connections only to people you trust not to rat you out is easy enough to do without giving away your activities.

Why would you want a third party in-between you and the person you are paying or being paid by?

Or is the main assumption here that middle-persons always go out of their way to revent people finding each other directly thus that most likely an given Alice would have little chance of happening upon a Bob without some Middleperson (Mallory?) regusing to introduce them but offering to get in between any thing they attempt to do together?

Presumably only these Mallory people - the middlepersons - would be money transmitters, since Alice and Bob are merely two people who happen to chose to transact with each other?

Maybe a desire to save the Mallories the expense of having to become moen transmitters, which expense they will doubtless try to pass on to as many Alices and Bobs as they can, with markups on it too, would be a good incentive to try to find ways to eliminate Mallories in general?

-MarkM-

markm: the point is to enable instantaneous payments with lower fees, but to multiple parties. This is just an expansion of Mike Hearn's micropayment scheme that permits payments.  It's friend to friend rather than fully peer to peer, but it's faster and more scalable than Bitcoin on its own because not everyone need to be aware of every payment. Everyone just knows about every payment channel that's established or torn down, as on chain transactions.

coinrevo: sorry, my signature contains a link to the code on GitHub. I'll update my posts.