Topic: Purpose of anyone can pay transaction (Read 412 times)

It is better if you start a new topic, but for now you should know that SIGHASH_NONE should not be used in any transaction spending a single-sig output (like P2PKH) simply because it is saying "my money can go anywhere", or in more technical terms the signature spending that output can be used in any other transaction (specially with ANYONECANPAY) to send the money to anyone else's address.

So in this case when the crowd-funding tx is waiting in the mempool to be confirmed, anyone can take any inputs from that tx that uses (NONE | ANYONECANPAY) and steal those coins.

The only way I see we can make this work is if the receiver asks everyone to make "pledges" on a centralized platform (like a website) with their change output, when the total amount was reached they release all the outputs like this:
0. total_amount_of_funds_to_be_raised + fund_raising_address
1. change_amount_participant_1 + change_address_participant_1
2. change_amount_participant_2 + change_address_participant_2
....
Then everyone signs this tx by adding their own input and signing the tx with (ALL | ANYONECANPAY) and publishing the signature.
This way nobody can steal the coins, and the issue with change is solved (it can't with NONE), the tx fee is also pre-defined.
The problem is that if one participant refuses to sign, all the previous steps has to be repeated to create a new tx.

Unfortunately, you are out of luck.

ethicnology hasn't been around since July 2020. He wasn't very active even before that.
darosior is a more frequent poster, but he hasn't logged in since August either. You might have some more luck getting hold of him over Twitter. He is tweeting more frequently there. Alternatively, he also uses GitGub.

https://twitter.com/darosior
https://github.com/darosior

Best of luck!

Hello ethicnology/darosoir -

I have been learning about Bitcoin programming and now on this topic of SigHash. While I was researching about it, came across this thread. Out of the two options you mentioned, which one did you use, looks like the latter (Receiver create first then Donor donate)? If this is crowdfunding, how does the Receiver communicate the info to Donors? Do the Donors just sign the raw transaction and give it to the Receiver without publishing it on the chain as otherwise miners can spend them? Do you have a working platform for crowdfunding using this strategy.

You are welcome.  

To handle your friend's use case, I'm proposing a new opcode SIGHASH_INPUT which locks an input to another input (its SIGHASH part), once used this opcode requires the input (being signed properly) to be part of a transaction that includes another input with specified SIGHASH for the wallet it unlocks and with this way inputs can be nested and secure against stealing because only the person who can spend a specific wallet address is eligible to spend such inputs. So, this would be the new scenario:

1- Your friend, ALice, gives her wallet address W_A to Bob or simply publishes it in his site.

2- Bob the donor, decides about the amount he wishes to donate and selects/makes an address with same balance.

3- Either Bob was forced to make a transaction or has already such a wallet address, he generates a SIGHASH_INPUT|ANYONECANPAY txn immediately with W_A as its locked key hash and sends it to Aice.

4- Collecting all such donations and querying the blockchain Alice decides to claim them at some point and does so by making a transaction with Bob's (and other donors') received transactions which are locked to W_A as explained, adding an input which spends a utxo that is locked to W_A. So, the final txn includes one or more SIGHASH_INPUT|ANYONECANPAY inputs, one SIGHASH_ALL|ANYONECANPAY special input that unlocks a utxo with W_A sighash.

5-Alice may reuse W_A as one output (with very low balance) of the transaction in case there is a chance of receiving more donations to same address.

The only problem with such a feature would be what i've been struggling with in STEP #2: Bob should donate all of the balance of one of his received transactions (not the wallet tho). But I think this happens anyway when you don't lock outputs and if there is an option for such thing in bitcoin, there should be a use-case.

Another challenge would be current orientation in bitcoin core community that is more focused on high volume transactions and  has lost hopes on supporting day-to-day/micro payments, to be honest.

Though this proposal is not just about micropayments. A smart reader might noted that it would be part of an infrastructure (not the whole tho) for off-chain p2p transactions, I can imagine scenarios in which such 'notes of payments' are circulating around more than once like cash by employing complementary techniques.

Another range of applications would be fee-on-receiver use-cases in which the receiver both determines and pays for the transaction fee and is very important both for LN and decentralized exchanges.

To have a  better picture of other applications, you may follow the discussions I've contributed to here: https://bitcointalksearch.org/topic/m.49610575

Thank you for your explanations.
Could you please give more details about the mechanism you exposed above ? Are there cons to the implementation of such a mechanism ?

Hello "the friend", Unfortunately, neither of the two scenarios are secure (actually they are the same), sorry.

Once the receiver broadcasts the txn donations will be exposed to public and subject to robbery.
Currently, bitcoin doesn't support the mechanism I've proposed above.  I do believe it is a very good and important use case and I might try championing for a BIP regarding it. You need to wait a few months I suppose optimistically speaking. 

Hi guys, I'm the "friend".
Thanks all for answers!

Sorry for my shitty english

I'm working on my own project "CoinFunding" the purpose is to use Bitcoin "smart-contract" to make a crowdfunding.
When i heard about AnyOneCanPay argument in Bitcoin Mastering chapter 6, i started to investigate.
I really want to manage AnyOneCanPay transactions to build a good User Experience around Crowdfunding on Bitcoin.

I want to promote Bitcoin with a free crowdfunding software without taxes (except fees) or government pressure.


So:

1 - Donors build rawTx and sign it with the amount they want to give and "NONE | ANYONECANPAY"
2 - Receiver collect all inputs from donors and build his own rawTx with "ALL | ANYONECANPAY"
If all inputs stay valid Receiver can broadcast his Tx?
Donors has to precise the good address?

OR

1 - Receiver create a rawTx and sign it with the amount that he want and the "ALL | ANYONECANPAY"
2 - Donors create their rawTx with the same address and amount they sign it with "NONE | ANYONECANPAY"
3 - Once amount is reach Receiver can Broadcast his Tx

A SIGHASH_SINGLE signature aside from some complexities and inflexibilities involved, causes more costs:

1- The donation/funding txns  would become longer as the donor now should include output scripts as well.
2- To spend the funds, the receiver needs to spend multiple UTXOs and pay fees as the result of much longer transactions.

Above conditions make it almost infeasible to accept micropayments/tips from customers/donors because of fees. In my proposed scenario your friend could pay less fee for receiving funds to just one single output address of his choice and spend it with a 200 Bytes txn. It would help both users and bitcoin blockchain to save costs.

P.S.
Please note that this feature is not supported by bitcoin for now.

Thank you for your answer.

Can't the donors use a SIGHASH_SINGLE signature ? Why do we need to use such a feature, I mean why don't we (just) create a transaction with inputs from all the donors that they sign afterwards ?

Edit : I'll point my friend to this thread so that he can describe what he did, and what he tries to achieve

OP,
Using ANYONE_CAN_PAY flag as a mechanism for crowdfunding would be good idea if it was safe but for now, it is not:


1- Your friend provides simple utility/script for his investors/donors through his web site to sign SIGHASH_NONE inputs and privately sending them to him.

2- he picks a number of such received inputs, adds one input from his side and generates a SIGHASH_ALL | SIGHASH_ANYONECANPAY input that locks as many outputs as he wishes and merges selected inputs to the transaction.

Now he has to publish the txn but it will put the signed SIGHASH_NONE  inputs exposed to full-nodes in the transaction relay network and eventually to miners, giving them an opportunity to steal the funds by applying the second phase with their own outputs just like your friend and relaying theirs instead of his.

This is one example of what I've been discussing earlier about the necessity of implementing  nested transactions in bitcoin. To have such a feature SIGHASH_NONE inputs should be allowed to be bound to another key hash (a bitcoin address) not as a conventional output but as a necessary part of one of the inputs of the transaction that tries to spend them and is SIGHASH_ALL | SIGHASH_ANYONECANPAY type hence locks all the outputs.  

Only such a feature would allow  use cases such as yours or many other fantastic ones spending with zero fee (ffe on receiver) and most importantly off-chain/delayed payments.

Check this article https://medium.com/@bitaps.com/exploring-bitcoin-signature-hash-types-15427766f0a9  it may be useful for you.

Hi,

I was helping a friend of mine today which is working on creating a crowfunding system with anyonecanpay transactions.
I have some difficulties to understand the purpose of such a transaction, and the use of the differents SIGHASH types (SINGLE, NONE, ALL) (link) for it.
I have read about anyonecanpay transactions in "Mastering Bitcoin" by Andreas Antonopoulos, but haven't heard about it since and, as my friend pointed out, it is quite difficult to find some implementations/details about.

Has anyone more informations about it please ?


EDIT (Nov 2020)
Signing a transaction with the ANYONECANPAY | ALL sighash flag (a modifier for the signature) allows you to only sign the input you are actually signing. Not the entire set of inputs, this way one can attach new inputs without invalidating the signature.
This can be used for donations mechanisms or fee-bumping for example.

Contrary to what aliashraf is saying below, it *is* safe to use.