Topic: Is it possible to sign/create a transaction without specifying inputs? (Read 392 times)

Ah OK. My bad.  Now I understand better what you meant with the "honey pot address". That's indeed a pretty good strategy to prevent robberies.

Perhaps then it is indeed a better strategy to simply use an HD wallet without Internet connection for "private and secure shopping at brick-and-mortar stores". I'm not familiar enough with this wallet concept to see if it could cover all use cases a paper-based "Bitcoin gift card" could. Maybe something like an "open source smartcard" (with extremely low-cost hardware) could be developed, combined with a point-of-sale system.

By HD wallet I meant Hierachical Deterministic wallet : https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

I'm aware that for most cases a mobile wallet - or alternative a hardware wallet - with an encrypted private key (which you could unlock with a non-stored password or PIN) would be ok for most use cases. However, I can imagine situations - like if you have to go to an awkward neighborhood - where you wouldn't like to take your phone with you. Or people which simply don't like to be tracked and prefer to be "offline" sometimes.

But you can think of my "problem" also as a thought experiment: It's perhaps unlikely that this kind of gift card will be ever implemented, but I'm simply interested in "non-standard" things and transactions that are possible with Bitcoin and the Script language.

That's interesting, thanks for the explanation. I never owned a dedicated hardware wallet.

She doesn't have to take her whole bitcoin with her. But as you stated
let's say she takes her whole bitcoin. It is a lot of money just for shopping.

Firstly, if the key is BIP38 encrypted she does not have to worry about her phone being stolen. She must have a backup at home and the robber does not have the time to decrypt the private key until she gets home and transfers the bitcoin to a new address.

Secondly, the case where she can effectively been stolen her bitcoin would be if she is threatened : with any mean of payment but Bitcoin you cannot do much. But with a HD wallet you can have kind of a "honey pot" address (I don't know the english expression) with not all your bitcoins you can give under threat. Since the attacker cannot check every address, it reduces the risks of having your whole bitcoin stolen.

Finally, all the issues you detailed which are consequences of not having a wallet are not encountered.

Exactly ... only that I wanted to specify a condition in the first transaction (let's call it "transaction A") to avoid that someone simply changed the outputs, as you wrote.

I see maybe I am formulating my goal a bit complicated, so I try to write it in "Alice & Bob" manner. The goal is an "universal gift card without centralized management":

- Alice owns 1 Bitcoin.
- Alice wants to go shopping. However, she doesn't want to take her private key with her on a device (or paper) because if it's stolen she loses the whole BTC. But she wants to be able to spend up to 1 BTC, so creating a wallet with a smaller balance is not an option. So she wants to create "coupons" to be spent in the shop(s).
- Additionally, she wants to re-use these "coupons", if she spends money in several shops. This is why she doesn't want to specify the input to be spent in the coupon.
- Bob is the shop owner where she ends buying, but Alice doesn't know in advance where she will buy something (so she cannot simply pre-sign transactions to his address, that would be regular "Bitcoin gift cards" like we already know).

The original idea is almost the same one @Coding Enthusiast described: Alice creates a transaction with a special output (transaction A) which authorizes anyone fulfilling a certain condition (knowing a secret) to spend the 1 BTC. This transaction is broadcasted and confirmed before she begins shopping. When she pays Bob, she shares the secret with him, and Bob is thus authorized to spend a part of the transaction (transaction B).

Now Bob in theory could spend the whole Bitcoin once he knows the secret. That's why my idea was that Alice, instead of providing him an "arbitrary" secret, could specify an slightly different condition:
1) She creates a list of values of the BTC she may want to spend (e.g. 0.1, 0.2, 0.3 ... BTC), and signs each item of the list without specifying the output, with the rest returning to her change address. Each of these items would be, essentially, a "signed transaction without specified input and with incomplete output". She prints them on paper.
2) In transaction A, she specifies that only the value that is signed with her private key can be spent by the shop owner. (This is what may not be possible with current opcodes, if I understand both your posts correctly).

Bob then broadcast transaction B to his own address, providing both Alice's "pre-signed incomplete transaction" as secret, and spending Alice's special output of Transaction A.

However this setup would be equally unsafe than the one with the simple secret, because when Bob shares Alice's pre-signed "incomplete transaction" , then anyone listening to the Bitcoin network could try to double-spend that transaction with another output.

Maybe, however, there is a way for Alice to provide an additional condition: In the pre-signed transaction she handles to Bob, a hash of an additional secret could be specified which must be known by Bob to spend the output of transaction B in a new transaction (transaction C). In this case, if someone double-spends the output of transaction A, (creating transaction B* to his own address), he won't be able to spend the output of transaction B*.

I hope my goal is clearer now ...

OK, sounds logical. However, I think in my setup the output of transaction A checks only transaction B and Alice's public key (to know that's she who is signing the "incomplete transaction"), and transaction B the output of transaction C, or not?

I'm not sure I understand what you want to do.

Are you trying to have a presigned transaction where the outputs are unknown. Then you can add outputs afterwards without having to sign again?

If so, that is not possible and is unsafe. If this were possible, anyone could just change the output to whatever they want, so anyone can change the outputs to give them money and not the person you wanted to pay. Furthermore, you cannot use opcodes to restrict the recipients because opcodes cannot inspect other inputs and outputs of the transaction they are in.

@achow101: Interesting. However, I think it's not what I'm searching for: If I wanted to pay with this kind of transaction, I would have to specify the outputs myself after pre-signing it. That could be done afterwards (e.g. when returning home to my PC with the Bitcoin wallet), but as the transaction cannot be broadcasted in the "pre-signed" state and the merchant doesn't know if I own any valid BTC, no merchant would accept it. I guess I'll have to look into the opcodes myself to see what's possible.

@CodingEnthusiast: Of course it would not be worth to add two opcodes. I was hoping that something like my little pseudocode-snippet was already possible with the current ones, but it doesn't seem so ...  In this case, I could try it to be added to some small altcoin desperately needing an USP ...

Anyway, if really anybody could spend the output, then it would not be what I wanted and it would be useless, as you say. The idea of the second snippet was to specify a condition where I could only spend the specified amount to another address if I prove that I own the private key. But I see I made a logical failure here ... if I have to take the private key with me when I sign the destination address+amount (to release the funds in the "prepared" output), then I can also sign a complete transaction, so this concept would be worthless, too.

Have to think again about the concept I had in mind ... but I'm already losing hope that what I search for is possible ...

The problem is that we don't have any operations for these, so they have to be implemented. Imagine a calculator that has +, -, * operations but doesn't have log, so you have to define log operation first before you can use it.

For example you should propose a fork that adds a new OP code with NOP4 and NOP5.
OP_CheckAmountEqualVerify can for example check the amount field in the spending tx and run OP_Equal and OP_Verify.
OP_CheckTxInEqualVerify can check the Tx_In run OP_Equal and OP_Verify.

But you can't just waste 2 OP code for something like this!

Let's not overlook the fact that you are technically creating an Anyone-Can-Spend Output here with a different kind of conditions. So unless you add additional restrictions/conditions, these outputs will be spent by anyone.

There's nothing preventing you from creating a raw transaction with no inputs but has outputs. Such a transaction wouldn't be able to be broadcast to the Bitcoin network as they are invalid since there are no inputs. But you could make them and whoever you give the transaction to can add their own inputs.

Furthermore, those who sign the transaction can use SIGHASH_ANYONECANPAY where they only sign the outputs of the transaction and just their input. So other inputs can be added afterwards too.

Thanks for your answer. A similar solution was also my first try with "coupons". My model basically consisted in outputs which are spendable by anyone knowing a secret (point 2 in this post).

These coupons, however, are not re-usable. In theory, I could provide various outputs specifying the same "secret", But once I use one of them, the secret and the connection hash/secret becomes known to all observers on the blockchain, and thus all outputs could be spent by anyone who saw it.

For one-time coupons, however, that works relatively well. You can even specify various alternative transactions without broadcasting them, so you could print out a sheet containing transactions of 1, 2, 3, 4, 5 ... and so on BTC (or mBTC or Satoshi). Once you pay with that sheet, only one of them is included in the blockchain. A drawback is that you need two transactions per payment, because the merchant has to "secure" his coins with a new transaction. As we're exposed to a theft risk until the transaction is confirmed (because of the problem you mention below), that coupons would only work for small amounts.

However, what I wanted to achieve are "reusable" coupons. The goal: You should be able to print out a sheet with different transaction values and be able to transact every single item as many times as you wish - until the balance on your address(es) becomes zero.

For that to happen you would need a transaction without specifying an output.

Yes, that problem is what led me to think it's maybe better to sign something with one of your private keys than simply to prove you know a secret. Thinking again, I think the payer must sign the destination address, because otherwise the problem appears again ...

So it would be easier if - instead of what I wrote - the pseudocode were:
In this case, as the destination address is signed, there is no way to fraudulently spend the transaction by another party.

That approach would need a mathematical operation when you pay (signing the destination and change address), but that could be achieved with a device without connection to the Internet or the Bitcoin network.

Why create/sign a transaction? Why not create an output that needs to satisfy a condition?

I think what can work for "coupons" is some non-standard output script which doesn't require a private key to spend. For instance it can be a script like this (note that I am new to scripts):
The 32 byte data can be double SHA256 of some password that you give away on a website. Like this:
ScriptPub:

In order to spend it, I need to know the password and use it as my signature script:
scriptsig:

Note that the problem with this script is that as soon as you broadcast it, anyone who is looking can take the transaction's signature out and create a new one with a different destination address and steal the funds.

Coupon is a second layer solution at the top of the fiat. A coupon centralizes and restricts the options you have to spend money. For a store, it would only be convenient to provide coupons that are tokens or that a use restriction is possible.

But I think it would be interesting to have a way to pass coins without having to access the wallet. The opendime seems to work something like this. Although it is a physical object, you can pass several times without opening the wallet. But you still have a company behind, you need to have some confidence in that company.

I think trying to create a bearer's check would be a simpler way of thinking about this problem rather than coupons. A code that you could type a single time on any computer or smartphone that has a simple Bitcoin wallet. The transaction would be transmitted. This would allow you to use the code on unsafe computers without any risk to your wallet.

I wonder if it was possible using the Bitcoin protocol to create a "generic" transaction where I only specify the amount and the recipient, but not the inputs I want to use for this transaction. (This could have advantages in some situations, like when creating bitcoin-based "paper coupons".)

I guess - from all I've read about transactions - that it should not be possible to create a standard transaction from scratch without specifying the input(s), as these must be part of the signed transaction.

But what could be possible is to previously create a transaction with an output containing a contract of the following (pseudo-pseudocode ) form:


The goal being that I don't have to connect to my Bitcoin client nor to my private key to effectively transact the Bitcoins. So I would be able to pre-create transactions that always transact a specified amount, but I can choose the recipients.

I'm pretty sure it would be possible with Ethereum and other "account-based currencies". But my contract knowledge is too limited to know if this is possible with Bitcoin's UTXO-based transaction protocol.

Edit: Clarified/edited the "pseudocode" - the goal is that it should not be necessary to sign the representation of the public key of the recipient.