Topic: Multi-User transaction with Bitcoin. (Read 422 times)

Using PSBT is good option. But since PSBT can be represented with binary (as file) and Base64 string, this might cause small confusion since some wallet only expect one of the representations or user isn't aware there are 2 representations.


FYI, this is common SEO spam technique which used by spammer on this forum.

thumbs down for an irrelevant comment. not only that but the article itself is kind of pointless.

ok. you made your point. we'll leave it at that for now 

yeah, i mean you know more about this topic than i ever will i'm not arguing about it. the op should be thankful for your 2 feasible solutions to his problem. leave it at that.

A meaningless concession. There are millions of bitcoin on addresses with revealed public keys or locked by P2PK. Bob isn't going to spend decades trying to steal Alice's 0.1 BTC when if he was actually able to crack a public key he could steal millions of BTC instead.

There are plenty of projects which already use multi-party funded transactions in a trustless manner, such as Lightning and coinjoins. My suggestion for sharing unsigned/partially signed transaction directly between users was because other users were complaining the solutions given were too complicated. If you want a super simple solution like my Electrum one, then by necessity there will be some drawbacks. If you don't want these drawbacks, then use one of the more complicated solutions.

That's an entirely different question which has nothing to do with revealing public key and having that be abused by the party that you are in cooperation with for making a transaction!

There are a lot of other things that are "features" in Bitcoin that can be worse like if you send your coins to an OP_TRUE output script (anyone can spend it)! That doesn't mean they shouldn't exist. It is up to the user to learn how to use them correctly.

Technically, if Bob doesn't fulfill his end of the deal then he got Alice's public key for free. And she never actually did a transaction using it on the blockchain. He can sit on that public key for a long long time trying to crack it and waiting for her to use that public key again sometime. Again, this is all just symantics but it is probably worth pointing out in the hope for a more fair solution to "Alice".

But from that wiki page I linked, it says:


Address reuse refers to the use of the same address for multiple transactions. It is an unintended practice, abusing the privacy and security of the participants of the transactions as well as future holders of their value. It also only functions by accident, not by design, so cannot be depended on to work reliably.


if it only function that way by accident then it shouldn't probably be a "feature" of bitcoin in the first place. but i guess that's getting a bit off topic.

which imposes on her and she has to pay a transaction fee to get out of it. not the ideal situation for her vs bob. he doesn't have to do anything.

As @o_e_l_e_o points out, there is no need for multi-sig. You just create a single transaction with N (or more) inputs, each signed by one of the N participants.

BIP 174 (Partially Signed Bitcoin Transaction) is designed to handle this use case. I don't know which wallets support PSBT, but I wouldn't be surprised if there are some that do.

If what you want to do is more complicated than a single transaction, then the multi-user transaction could first send the bitcoins to a multi-sig address, with some sort of governance set up to spend them from there.

FYI, anonymous multi-user transactions are the basis of CoinJoin, though whether they use PSBT depends on the implementation.

Bob can only spend Alice's bitcoins in the transaction set up by Alice and Bob. The point is that Bob cannot hold Alice's bitcoins hostage.

So what you offer her is to wipeout her wallet faster than bob

As soon as the transaction is broadcast, Alice's public key becomes public anyway, so there is no additional information leaked to Bob that he would not have access to anyway in the scenario OP is describing.

Absolutely. But the provision was that both parties only spend their inputs if the other party also spends their input. If Bob refuses to broadcast the transaction, then Alice's input also remains unspent.

True enough, but as pooya87 points out, Bob can only do this if he commits his own funds to the transaction, which was the entire point of the transaction in the first place.

For the same reasons people use the same password for multiple accounts. Convenience, laziness, poor software which does it for them, it's what they always done and they can't be bothered to change, etc.

True, and easily avoided by Alice spending the UTXO in question to another address.

https://en.bitcoin.it/wiki/Address_reuse
Why would someone want to re-use an address when HD Wallets exist?
 

She might want them to reach there originally but circumstances could eventually change if bob waits too long - for whatever reason.

There can not be any kind of "ulterior motive" here simply because a public key is made to be public by design.

That's true but Bob still has to include his own UTXO and spend bitcoin to get that transaction to go through and reach the destination which we assume Alice wants the funds to reach to.

Is Alice leaking information about her public key to Bob though by doing this? I know it may not be a huge deal but if Bob is dishonest, then maybe he has ulterior motives.

That's what she hopes Bob will do. He doesn't have to. So if he doesn't do it then she will need to probably spend one of those utxos so that Bob at a later time can't come back on her at a point when she doesn't want the transaction to happen anymore.

If you think the options given above are too complicated, then here is an even easier solution which only requires a very basic knowledge of Electrum.

• Alice and Bob both want to pay 0.1 BTC to Charlie in the same transaction, and neither Alice nor Bob want the transaction to go ahead unless both Alice and Bob commit to it.
• Bob lets Alice know the input he will be using to make this transaction, by sharing an address with Alice and letting her know which UTXO on that address (if more than one exists) he wishes to spend.
• Alice then creates a new watch only wallet in Electrum, imports the address from Bob, and imports her own address she will be using to make this transaction.
• She then uses this watch only wallet to create an unsigned transaction sending 0.1 BTC from her own address, 0.1 BTC from Bob's address, and any change addresses as needed and agreed upon.
• She then imports this unsigned transaction to her full Electrum wallet and signs her input.
• She passes this partially signed transaction to Bob, who also imports it and signs his input, and then broadcasts it.

There is not need to look at a terrible shitcoin wallet, we already have the bitcoin wallet called Electrum that has multisig options that are very user friendly and easy to use. There is not really a learning curve needed either. If there is any demand for what OP proposes, it is trivial to create it on top of existing wallets like Electrum.

if you'd seen gui for a multisig wallet (best realized in stellar lumens lobster wallet) - it's already on the edge of learning curve for someone without those skills.

Sorry, but this is all wrong. Multiple decentralized, trustless methods have been suggested before and after your reply; with Bitcoin multisig, Leo's 2 little scripts, and MuSig.

I just want to clarify this for anyone reading this topic and getting confused by your reply. It's absolutely not required to put all the parties' keys into one wallet or using a centralized party.

That's also wrong; it is absolutely possible to implement one of the suggested methods in an easy-to-use, GUI-based application.
What is discussed here are the technicalities under the hood, that users never see. You wouldn't believe how many complicated things happen under the hood of the browser you're using to visit this forum. By your logic, 'nobody can access the web unless they are browser developers'.

it can't be done this way unless they're both blockchain programmers .

Why restrict to only these? You may use https://coinb.in/#newTransaction as well, of course offline after downloading it from Github. It is light weight & open source.

Both Sig Hash Type, i.e. ALL|ANYONECANPAY & SINGLE|ANYONECANPAY are available @ https://coinb.in/#sign

Brilliant idea!

Imagine if instead of using MuSig to aggregate signatures (since that doesn't work in M-of-N configurations), we make a transaction with a large number of outputs, but a comparatively smaller number of inputs from people who are signing with SIGHASH_ALL | SIGHASH_ANYONECANPAY.

Granted, tx size would still be a problem and this kind of signing wouldn't solve that, but imagine if there was a side network hat operated almost exactly like the Bitcoin network but it has more lax fee calculation for transactions with many outputs - so it becomes like a "discount".

In particular, if somebody broadcasts a L1 transaction that has a timelock, that will have priority over transactions which don't have such a time lock. And longer locks would have priority over shorter ones. Whereas on the side chain these transactions would be confirmed instantly, on the mainnet they are still listed with unconfirmed status, but they will confirm eventually.

Sure, that scheme would work by making an endless trail of unconfirmed transactions which are used on the side network, but the timelock prevents them from moving them back to L1 for a set period of time, so that there is always liquidity for the network to run with.

Which means:

A bunch of large, invalid (because outputs > inputs) transactions with SIGHASH ALL, ANYONECANPAY are broadcasted - this is an interactive process. The side network gets a list of all the outputs, and then constructs smaller raw transactions, that it requests those who are sending inputs to there right now to sign. Anyone who doesn't respond within an interval, is excluded. In this way, it guarantees that participating network users will always sign their transactions

To sign the transaction with inputs from both users you need those users private keys working on the same Core, and i feel this can be done if the core belongs to a third party.

Maybe creating a wallet service where users can make transactions together then they could be able to make this kind of 'team transactions'. But from my point of view without a third party it would be impossible.

And other option is to create a platform where users can manipulate their balance but not the private key, and leave the transactions to the server side, this would work like a mixing service.

This are just some ideas, i hope they helps.