With all of the debate around the block size, I have been looking at alternatives to how Bitcoin will scale without simply increasing that limit. What constantly comes up is the Lightning Network which generalizes payment channels into a form that can be operated over a network of hubs. So naturally I’m wondering how and if Counterparty transactions can be carried out over a payment channel to start and eventually over a Lightning-type network.
For a Bitcoin payment channel, some funds are committed by the payer to a multisig address which can be spent the payer after some period of time. This is so the payer can get back their money if the recipient disappears. Then individual payments are made by the payer sending a transaction to the recipient that divvies up the funds more and more toward the recipient over time to pay for a service. Those payments are only submitted to the Bitcoin network when the channel needs to be closed by one of the parties.
So to implement a payment channel in Counterparty, we need a multisig support and nLocktime. I understand Counterparty has multisig but I don’t think it has nlocktime though I can imagine a Bitcoin transaction with an nlocktime that allows a payer to get their funds (assets, etc.) back might be possible to be coordinated. The question then becomes, can those smaller payments be done. They require that the sender creates a transaction that spends the funds held in multisig in part to the recipient and in part to themselves.
So my understanding is that a payment channel is possible with Counterparty assets. Can anyone confirm this?
I would like to know ultimately if Lightning can be done but will only go into that if we can nail down payment channels first.
The chief scientist should probably weigh in here, but most of the functionality from bitcoin applies directly to counterparty already, without much need for support on our end. Certainly nLockTime already works, though I don’t think anyone is working with it currently in production. Here’s a quick ruby nLockTime example, if you’re curious:
require 'counterparty_ruby'
Counterparty.production!
unsigned_tx = Counterparty::Send.new source: '186sRhi5Ux1eKGzx5vRdq1ueGGB5NKLKRr', destination: '1Co1dcFX6u1wQ8cW8mnj1DEgW7xQMEaChD', asset: 'YACHTMONEY', quantity: 100
tx = Bitcoin::P::Tx.new [unsigned_tx.to_raw_tx].pack('H*')
tx.lock_time = current_block_height + 6*24 # A day from now
# TODO: Sign tx, and send it around!
I don’t think Lightning Network will work quite as seamlessly as nLockTime given the current counterpartyd codebase, but it’s highly probably that the code required to support it won’t be a large project.
The problem is that you can’t escrow counterparty tokens in a nLockTime bitcoin transaction.
So, say I have balance of 100 TOKENLY in my account. I create a bitcoin transaction with an embedded send of 80 TOKENLY from me to you with an nLockTime of 2 days from now. You might think you have a guarantee of those 80 TOKENLY as long as no one double-spends the UTXOs in that transaction. But you don’t. Here’s why.
While you are waiting 2 days, I create another transaction from my same address and send all 100 TOKENLY somewhere else using different UTXOs than the ones wrapped up in the nLockTime transaction.
So what happens in 2 days when the nLockTime transaction gets mined? Well, you get the BTC dust. But the counterparty daemon will check my account balance and see that there are 0 TOKENLY there. So, the counterparty transaction will be resolved as a send of 0 TOKENLY from me to you.
Is it possible to modify counterparty server to be aware of nLockTime transactions and hold funds in escrow when it sees a broadcasted nLockTime transaction? Possibly. My instincts tell it me it is trickier than it sounds.
I think smart contracts are also a viable solution to this problem. A smart contract could (theoretically) hold the TOKENLY in escrow and then send them along when the original transaction gets pushed to the blockchain, or refund them if it does not.
Thanks for this. We need an nLocktime in Counterparty itself because the Bitcoin one doesn’t work like it should in this case. Perhaps this is something that can be added to the Counterparty protocol and while we’re at it, add something like the relative locktime that Lightning needs.
I would definitely help write one but I feel it’s something that should commented on by one of the devs before doing all that. I mainly want to know that becoming Lightning-compatible is in line with the general roadmap of the protocol as they’ve been developing it.
I think we need to take it one more step before we present this idea to the founders.
The first step is putting together a high-level overview of what exactly we want to accomplish and what the technical implications are.
It might be possible to enable payment channels for assets, but there are some unanswered technical questions. Can assets be securely held in escrow with some modifications to the Counterparty code? If so, how?
If we can lay out a technical plan of how this might work, then we can go to the founders and present our plan.
Ultimately Counterparty should be a community project and not just a project owned entirely by the 3 founders. And I believe the founders are open to that. If we can present a good technical argument for adding the feature that will help our case with the founders.
also since its open sourced, they cannot really stop anyone if they want to create it themselves. If its possibly to do and the need is there, someone will just do it
I’d be interested to see a Counterparty Improvement Proposal for adding micropayment support to Counterparty itself. (@deweller is correct: you can’t use the Bitcoin one out of the box.)
I’ve been thinking about this more. I’m reasonably sure all we need to do is add support P2SH addresses in Counterparty to support payment channels.
Adding P2SH support means you could confidently lock Counterparty tokens in a multisig address after a few confirmations. You could then exchange an nLockTime encumbered refund transaction that refunds all the Counterparty tokens. And the payment channel communication would proceed with the same flow as a bitcoin payment channel exchange. The only difference is that each updated payment channel transaction also includes the valid counterparty send data.
So, really this is a question as to what it will take to add support for P2SH addresses in Counterparty? I know this has been discussed previously and I know this is more than a trivial change. But I don’t have a sense as to how much effort this will require.
I will give an