Bitcoin Forum
September 17, 2019, 11:52:32 AM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Purpose of anyone can pay transaction  (Read 196 times)
darosior
Full Member
***
Offline Offline

Activity: 184
Merit: 209



View Profile WWW
February 10, 2019, 04:55:44 PM
Merited by ETFbitcoin (1)
 #1

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 ?

1568721152
Hero Member
*
Offline Offline

Posts: 1568721152

View Profile Personal Message (Offline)

Ignore
1568721152
Reply with quote  #2

1568721152
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1568721152
Hero Member
*
Offline Offline

Posts: 1568721152

View Profile Personal Message (Offline)

Ignore
1568721152
Reply with quote  #2

1568721152
Report to moderator
1568721152
Hero Member
*
Offline Offline

Posts: 1568721152

View Profile Personal Message (Offline)

Ignore
1568721152
Reply with quote  #2

1568721152
Report to moderator
1568721152
Hero Member
*
Offline Offline

Posts: 1568721152

View Profile Personal Message (Offline)

Ignore
1568721152
Reply with quote  #2

1568721152
Report to moderator
bitaps
Member
**
Offline Offline

Activity: 111
Merit: 20

https://bitaps.com/


View Profile WWW
February 10, 2019, 05:50:53 PM
Merited by darosior (2), khaled0111 (1)
 #2

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

aliashraf
Hero Member
*****
Offline Offline

Activity: 896
Merit: 656


View Profile
February 10, 2019, 11:41:31 PM
Merited by darosior (2), ETFbitcoin (1)
 #3

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.
darosior
Full Member
***
Offline Offline

Activity: 184
Merit: 209



View Profile WWW
February 10, 2019, 11:49:09 PM
 #4

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 it 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.
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

aliashraf
Hero Member
*****
Offline Offline

Activity: 896
Merit: 656


View Profile
February 11, 2019, 12:19:57 AM
Merited by darosior (1)
 #5

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
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.
ethicnology
Newbie
*
Offline Offline

Activity: 3
Merit: 10


View Profile
February 11, 2019, 07:40:15 PM
Last edit: March 21, 2019, 06:45:25 PM by ethicnology
Merited by MagicByt3 (2), darosior (1)
 #6

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
aliashraf
Hero Member
*****
Offline Offline

Activity: 896
Merit: 656


View Profile
February 11, 2019, 08:08:15 PM
 #7

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.  Wink
darosior
Full Member
***
Offline Offline

Activity: 184
Merit: 209



View Profile WWW
February 11, 2019, 08:23:24 PM
 #8

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 ?

aliashraf
Hero Member
*****
Offline Offline

Activity: 896
Merit: 656


View Profile
February 12, 2019, 08:38:19 AM
Last edit: February 12, 2019, 10:01:49 AM by aliashraf
Merited by vapourminer (1), MagicByt3 (1)
 #9

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 ?
You are welcome.  Smiley

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 WA 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 WA 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 WA as explained, adding an input which spends a utxo that is locked to WA. So, the final txn includes one or more SIGHASH_INPUT|ANYONECANPAY inputs, one SIGHASH_ALL|ANYONECANPAY special input that unlocks a utxo with WA sighash.

5-Alice may reuse WA 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://bitcointalk.org/index.php?topic=5106762.msg49610575#msg49610575

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!