<p>Not necessarily interoperable. </p>

<p>Firstly, libraries have to agree on what kind of parameters to exchange and how they are exchanged. There's no guarantee that the parameters required by <code>bitcoinj</code> and <code>libbitcoin</code> are the same. </p>

<p>Secondly, it is now considered standard practice to create P2SH transactions regardless of what kind of transaction you're setting up, unless it is P2PKH. In the case of P2SH transactions, you then have to assert that the payment channel protocol would also be able to parse/recognise/understand the redeem script provided by service provider of the payment channel (assuming that you're talking about a single-direction payment channel). </p>

CC BY-SA 3.0
2016-07-12T19:43:03.257Z
Thx for this answer. With regard to your bit on the parameters required by each library...: is it correct to say that there is a standard in terms of the transaction protocol itself (viz. what on bitcoin.org) but not for its implementation into APIs by libraries? Isn't it a significant issue for a p2p network like Bitcoin where nodes cannot be expected to use the same clients?
hartmut
CC BY-SA 3.0
2016-07-12T21:56:01.897Z
To my knowledge, I am not aware of a standard for payment channels. I do recall however seeing an attempt in the bitcoin-dev email to formalise a standard for payment channels, but I've yet see it written in the form of a BIP yet. On top of that, Payment Channels is more of an application layer protocol on top of Bitcoin, therefore it is not consensus critical.
rny
CC BY-SA 3.0
2016-07-11T23:46:06.233Z
2016-07-12T11:33:05.610Z
2016-07-12T11:33:05.610Z
rny
<p>I just read bitcoinJ's <a href="https://bitcoinj.github.io/working-with-contracts" rel="nofollow noreferrer">working with contracts</a> tutorial and I am puzzled as:</p>

<ol>
<li><p>it seems to me that n-m addresses are implemented in Bitcoinj using plain multisig (as defined in <a href="https://bitcoin.org/en/developer-guide#multisig" rel="nofollow noreferrer">this bit</a> of the developer's guide, and discussed <a href="https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions">here</a>) </p></li>
<li><p>I looked for implementations of addresses controlled by more than one private key with pybitcointools (tutorial on that <a href="https://bitcoinmagazine.com/articles/pybitcointools-multisig-tutorial-1394686325" rel="nofollow noreferrer">here</a>) and on libbitcoin's <a href="https://github.com/libbitcoin/libbitcoin-explorer/wiki/How-to-Spend-From-a-Multisig-Address" rel="nofollow noreferrer">wiki</a>. It seems to me that these two libraries use P2SH.</p></li>
</ol>

<p>Most libraries seem to use P2SH, but bitcoinJ chose the other way it seems (or is it?)...</p>

<p><strong>In an implementation of micropayment channel with bitcoinJ on one side and, say, libbitcoin on the other ; will the two sides be able to interoperate?</strong></p>

<p>(edit: I m talking here only about <em>unidirectional</em> payment channels)</p>

<p>Thanks</p>

<bitcoinj><python><library><micropayments><micropaymentchannels>
micropayment channels, n-m addresses, interoperability
hartmut
# micropayment channels, n-m addresses, interoperability

(Asked by: username_0 on 2016-07-09)

I just read bitcoinJ's [working with contracts](https://bitcoinj.github.io/working-with-contracts) tutorial and I am puzzled as:

1. it seems to me that n-m addresses are implemented in Bitcoinj using plain multisig (as defined in [this bit](https://bitcoin.org/en/developer-guide#multisig) of the developer's guide, and discussed [here](https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions))
2. I looked for implementations of addresses controlled by more than one private key with pybitcointools (tutorial on that [here](https://bitcoinmagazine.com/articles/pybitcointools-multisig-tutorial-1394686325)) and on libbitcoin's [wiki](https://github.com/libbitcoin/libbitcoin-explorer/wiki/How-to-Spend-From-a-Multisig-Address). It seems to me that these two libraries use P2SH.

Most libraries seem to use P2SH, but bitcoinJ chose the other way it seems (or is it?)...

**In an implementation of micropayment channel with bitcoinJ on one side and, say, libbitcoin on the other ; will the two sides be able to interoperate?**

(edit: I m talking here only about *unidirectional* payment channels)

Thanks

**Tags:** bitcoinj, python, library, micropayments, micropaymentchannels


---

## 1 answers

### Answer by username_1 on 2016-07-11. Score: 1 | Accepted answer

Not necessarily interoperable.

Firstly, libraries have to agree on what kind of parameters to exchange and how they are exchanged. There's no guarantee that the parameters required by `bitcoinj` and `libbitcoin` are the same.

Secondly, it is now considered standard practice to create P2SH transactions regardless of what kind of transaction you're setting up, unless it is P2PKH. In the case of P2SH transactions, you then have to assert that the payment channel protocol would also be able to parse/recognise/understand the redeem script provided by service provider of the payment channel (assuming that you're talking about a single-direction payment channel).

> **Comments:**
> **username_0**: Thx for this answer. With regard to your bit on the parameters required by each library...: is it correct to say that there is a standard in terms of the transaction protocol itself (viz. what on bitcoin.org) but not for its implementation into APIs by libraries? Isn't it a significant issue for a p2p network like Bitcoin where nodes cannot be expected to use the same clients?  
> **username_1**: To my knowledge, I am not aware of a standard for payment channels. I do recall however seeing an attempt in the bitcoin-dev email to formalise a standard for payment channels, but I've yet see it written in the form of a BIP yet. On top of that, Payment Channels is more of an application layer protocol on top of Bitcoin, therefore it is not consensus critical.  

---

