Show HN: Bitcoin M-of-N Multisig P2SH Transaction Builder in Go | Hacker News Reader

Show HN: Bitcoin M-of-N Multisig P2SH Transaction Builder in Go

github.com

40 pointssoroushjp9 comments

How does this compare with https://github.com/conformal/btcwallet ?

@wslh go-bitcoin-multisig is not a full wallet -- it's only a multisig transanction builder, so given the requirements of a multisig transaction (m required keys, n public keys, destination etc.), you can construct a raw multisig transaction. An example where this is useful is for example, in implementing a Bitcoin micropayment channel (https://bitcoin.org/en/developer-guide#micropayment-channel) between a payer and payee -- for example as a server-client solution for micropayments buying content. This is what I'm working on next.

This would be good for api's like chain.com that let you publish a raw transaction. Using this you can generate a transaction and push it to an API to avoid having to keep a whole bitcoin node there.

That is incredibly dangerous behavior. You must be validating your own information before you sign any transactions, preferably with a full node or at a bare minimum SPV proofs. If you believe what information a random API gives you (incorrect or malicious, doesn't matter) you can instantly and irreparably lose all of your money.

0x83F1, I don't think deftnerd is talking about signing an arbitrary raw transaction. They're talking about constructing your own raw transaction using a tool like this (from any source of information, including your own funding wallets), and then using something like Chain to push the transaction on to the network, without connecting to nodes yourself. Chain couldn't really do anything too malicious -- at worst, change a couple of bytes to change the txid ie. transaction malleability.

Of course you're right, using a bad source of information for UTXO or any other part of the tx would give you an invalid transaction and it wouldn't get confirmed by the network.

See, that's the misconception most people have. What if an API tells you that you have an unspent output worth 0.01 BTC. and you spend it based on this information. If the API lied you could have just spent a 500 BTC output straight to fees with no recourse. If you just know the transaction hash and vout index you have no idea if the value is correct, many wallets reply on faulty information like this with potentially disastrous consequences.

Do you mean something like this http://blog.coinspect.co/copay-wallet-emptying-vulnerability

No. In a Bitcoin transaction the fees are implies by in minus out. There's no way of knowing without a proof the value of a particular output, so if you accidentally spend one far below it's actual value you can end up paying an insane fee. People have lost hundred of Bitcoin due to bugs like this, like off by one errors. A malicious or misbehaving API could misstate the value and cause you to unknowingly lose money in this way if you blindly trust them.

That's fair 0x83F1, that would be a valid attack. The economic incentive for that attack is pretty low (unless Chain is working with miners to boost their fees), but I see your point, you are definitely giving up some level of security and the trustless nature of Bitcoin by using an API for sure.

I do think as the Bitcoin ecosystem grows, it's going to be inevitable that some tradeoffs are made for usability, convenience and extensibility by mainstream users. I would be most worried about any tradeoff that was both a) open to a technical attack vector b) created economic incentives for parties to be malicious. Situations with only a) or b) but not both will likely be tolerated by users and only reinvented when major issues arise.

Reply on news.ycombinator.com