modifying bitcoinj micro payment channels

[samnet]

Hello,

can you re-explain your motivations for modifying the bitcoinJ part on payment channels please? I m v. interested in setting a MPC with bitcoinJ on one side and some other library on the other (perhaps pybitcointools) and I worry about interoperability.
If interoperability was a significant difficulty, would not it have been easier to set-up MPC facilities over TCP from scratch (e.g., using pybitcointools on both sides and communicating via JSON over TCP) (It's my first year studying CS)

Regards,

[adonley]

At the time (I no longer know if this is the case) there wasn't a standard for micropayment channels established. bitcoinJ was basically the only functioning implementation that was around. We wanted to use a javascript library and websockets to communicate with browser clients to achieve full duplex which required some changes bitcoinJ and bitcore. Also, it's worth noting BIP65 wasn't around either. @snakecharmer1024 was the real power behind the micropayment channels - he might be able to speak to your question better than I.

[illuzen]

Hey @samnet, thanks for your interest in Bitmesh!

Interoperability was precisely the reason we chose to modify them. Bitmesh has a javascript frontend, which uses bitcore. Bitcore at the time had a mostly functioning implementation of MPC that used P2SH and bitcoinj used raw multisig. These are not compatible, so I made bitcoinj's MPC into a P2SH version and modified bitcore's conversation structure to make them compatible.

In retrospect MPC may have been a solution looking for a problem. You can't do javascript MPCs on a mobile device because the javascript won't run while you have another tab open. It's a cool technology, but it's not really necessary to Bitmesh and makes it a lot more complicated.

Does that answer your question?