This also implies that we are probably going to get payment channel specific op_codes in the future.
It would for example be interesting to have an opcode that allows for pulling funds, but only applicable to the secondary layer. Would allow us to make credit card type of payments available.
Topic: op_codes usability in payment channels? (Read 1036 times)
I assumed that funding a channel via op_cltv and op_csv were required only to setup the channel
I have experimented with implementing payment channels using python-bitcoinlib and unless I'm mistaken timelocked transactions are not used during channel setup. The setup is just a regular payment to a multisig address. However, a timelocked refund (which is not broadcast if the payment channel is otherwise closed) is used to prevent funds from being taken hostage.
Watch the lightning guys explain it (skip to six minutes for payment channel stuff):
https://www.youtube.com/watch?v=8zVzw912wPo
If you are referring to lightning network payment channels, they still use bitcoin transactions. The way that lightning works is that the channel is really just a transaction that is never broadcasted and replaced over and over as transactions in the channel happen. When the channel is closed, that transaction is broadcast to the network.
Because that transaction is a bitcoin transaction but I'd not broadcast until later, it still must use OP codes.
Because that transaction is a bitcoin transaction but I'd not broadcast until later, it still must use OP codes.
Rusty said similarly on IRC, and I understand that. But here is something that I dont understand.
If I make a transaction on a payment channel, following all the Script rules, then how does channel funding play a role?
I assumed that funding a channel via op_cltv and op_csv were required only to setup the channel, and thus whatever transaction took place would be "outside" the scope of Script and rely on different rulesets.
If Script is still in use, it implies that all transactions are subsequently recorded in mempool as they are Bitcoin transaction, but with the only exception of that they wont get mined (due to op_cltv/op_csv settings). This sounds, wrong, so I am sure I missed something in terms of the transaction abstraction on secondary layers.
If I make a transaction on a payment channel, following all the Script rules, then how does channel funding play a role?
I assumed that funding a channel via op_cltv and op_csv were required only to setup the channel, and thus whatever transaction took place would be "outside" the scope of Script and rely on different rulesets.
If Script is still in use, it implies that all transactions are subsequently recorded in mempool as they are Bitcoin transaction, but with the only exception of that they wont get mined (due to op_cltv/op_csv settings). This sounds, wrong, so I am sure I missed something in terms of the transaction abstraction on secondary layers.
Not sure I understand your question.
Transactions in payment channels are all valid Bitcoin transactions, so they must use the same set op_codes as the main Bitcoin network. In a payment channel, OP_CHECKSIG, OP_CHECKMULTISIG, OP_HASH160, HASH256, OP_CSV, OP_CLTV are probably enough for all functions.
Transactions in payment channels are all valid Bitcoin transactions, so they must use the same set op_codes as the main Bitcoin network. In a payment channel, OP_CHECKSIG, OP_CHECKMULTISIG, OP_HASH160, HASH256, OP_CSV, OP_CLTV are probably enough for all functions.
With improvements in the Script language such as P2SH and OP_CSV, how are they going to be in used on payment channels? Since payment channels most likely write their own logic layer, wont the entirety of the script be negligible, as we can assume settlement on chain will be costly?
Or are payment channels going to utilize the Script language in Bitcoin at the secondary layer as well? I have been unable to find anything on both Lightning implementations as well as the Thunder implementation.
From all I can see, there are no scripting rules. But wont this kill the need for more op_codes as we move ahead with abstraction layers?
Or are payment channels going to utilize the Script language in Bitcoin at the secondary layer as well? I have been unable to find anything on both Lightning implementations as well as the Thunder implementation.
From all I can see, there are no scripting rules. But wont this kill the need for more op_codes as we move ahead with abstraction layers?
Jump to: