Topic: Printable one-time coupons (to be used as "cash") (Read 478 times)

@aliashraf: Thank you for the explanation, again. domob's thread is interesting, I'll follow it. The crucial question seems to be if such a "chaining" is possible with the following two conditions:

1) when the entity who inscribes the TX to the blockchain has published the transaction to the mempool, nobody can change the receiving address and seize the funds, not even miners.
2) this entity can transfer the coins to any address.

domob's version seems to not need condition 1 because there are no "anyonecanspend" outputs involved (and both transactions have a fixed address where they pay their coins to), so it may be much easier to solve - in fact, the proposal at the Lightning dev list may be already the solution he needs.

For the "nesting" to work, the initiatior would have to specify a condition that only those in the "transparent computer" chain could met, and it cannot be a simple secret as already discussed ... (Edit: Maybe it's not so difficult, I think as you wrote in the other thread, it would be the other way around - the inscriber must be able to include a signed transaction into his own transaction if he's entitled to do so - which in "anoyonecanspend" is so by definition.)

@mixoftix: Thanks, I think I understand now what you mean. Later I'll look at the thread you linked, seems interesting.

of course we replace bank with blockchain here..

in fact a payment with crypto matches the "remittance money flow" in classic payment models which payer A "initiates" the flow by submitting the transfer order to bank A and bank A relays the order to bank B that sends an indication message to recipient B (in blockchain version, payer A submits her raw transaction to a node and after insertion into a block, the amount of confirmation that recipient B observes enrolls as indication message from bank B). and this model obviously causes DELAY in check-out step.

now look at the money flow in check-or-credit-like payment model. in these cases, the payer A submits her payment directly to recipient B. then recipient B sends the payment capture to bank B. then bank B invite bank A in a "settlement" process. this is why I basically suggest you follow the check-or-credit-like payment model, because I think payer A could submit her raw transaction to recipient B and let him to submit it to a node and let adding the transaction to the blockchain happen in a settlement like process. in this model you need to know your customer very well.

but the "debit order" model is totally a new field for research to fit in crypto world. in this model the recipient B is the initiator of payment and submits his debit order to bank B and bank A transfer in continue, but also sends an indication to payer A and listen to any protest from payer A. in a post that entitled "Dead man's switch" we had good comments/codes about reversible transactions in bitcoin:

https://bitcointalksearch.org/topic/dead-mans-switch-5069728

Sure "every party involved cannot copy the transaction" because they use transparent computers that provably follow the rules in spite of what the owner wishes. Note that the raw transaction is not available to any unfaithful entity before the inscription.

Back to the main protocol:
-To pay Charlie, Bob's machine, a PTC, doesn't need to generate a new txn if Bob wishes to pay the whole amount Alice initially sent, let's put it M,  it could simply pass  the txn A to Charlie's PTC, in encrypted format. Thereafter, Bob Machine won't double-spend txn A obviously.

-If Bob wishes to pay N > M, his machine may choose to generate a new txn B, just like Alice's txn, A with N-M as its amount and passing it to Charli'es machine along with txn A.

-If Bob wants to pay N < M  his machine can accept txn C from Charlie with M-N amount and pass A or  to publish A on the blockchain along with a conventional txn, paying charlie normally and claiming the reminder.

As you may have noticed it is completely analogous with how we use cash and paper money in real world, this time fully electronic and based on ip infrastructure. It sounds as fascinating as blockchain if not even more.

As I've described previously, current bitcoin core (and other bitcoin clones) doesn't support such a feature (deterministically chaining transactions) specially when it comes to anyone_cans_pend type as parent which is my favorite because miner can easily seize the funds when txn A is published. @domob has started a topic recently, putting forward a requirement  for another use case in which users need to make transaction that is to be claimed by another transaction and they don't wish to pay fees because they don't want their transactions to be processed unless the other party decides to accept the deal and pay fees by the child transaction which claims the output of the parent. It is known as Child pays For Parent or CPFP, @domob discusses this situation and says it doesn't work because when the two txns, parent and the child are inscribed parent may don't make it through minimum fee wall and child would be rejected without the parent being already included in mempool.
I've reminded him of this thread and discussed shortly about a new feature to support kinda nested transactions in bitcoin.

Thank you for your explanation. It's becoming a bit clearer now for me.

However, in your example - if I don't understand it wrong - there could be a double-spend problem as soon as the off-chain "transaction chain" becomes written to the blockchain:

- Alice transfers Anyonecanspend coins to Bob off-chain in a secret message containing transaction A.
- Bob uses the output to transfer coins, in the same way, to Charlie (transaction B). All three have "transparent computers", so they can convince themselves that inside the chain, everything is right.
- Now Charlie wants to inscribe his coins to the blockchain with transaction C. He must then publish transaction A and B, too.

An observant of the Bitcoin network could now execute a double-spend using the ANYONECANSPEND output of transaction A as input, as soon as transaction A is published.

In this configuration, nobody would want to inscribe the coins to the blockchain again. It's basically the same problem that emerges with the "paper coupons" I proposed in the OP. The advantage of the "transparent computer" approach, however, may be that the messages with the outputs cannot be simply copied by every party involved in the off-chain transaction chain (although I'm not sure here either).

opendime is a simple idea: charge bitcoin to a secure chip and pass the chip around just like a bill. Besides the cost other problems cause  low utility level: the need physical transportation, no back-up, fix value, ...

Aren't you just describing open dime ?

https://opendime.com/

Where it fails is the cost is at least 10 usd per unit

As I've stated before I understand/redefine this problem, paper-bitcoin, as an instance of a more general one: off-chain transaction processing. Suppose I send you an email containing an ANYBODY_CAN_SPEDND txn. Now you can keep this email secrete and use the txn's output as an input to your spending transaction, besides the obvious problem of hijacking in which miners would censor the second txn and seize the funds, we have double-spending problem too. It would be trivial to mitigate hijacking by means of introducing a new transaction format and/or opcode but double spending is another story.

Bitcoin and blockchain technology is a solution to double-spending in the first place and it would look crazy suggesting a solution to this problem off-chain and in the context of cryptocurrency but it is what I'm doing right now, such a crazy person I am.  

So, a hypothetical Transparent Private Computer is able to solve double-spending problem (and a lot of other problems), off-chain, how?

Suppose Alice and Bob  both have such devices, computers that can prove the software they are running with a specific level of security. This proof should be eventually provided by the device as a cryptographic signature but for devices belonging to same category it is possible to use a symmetric encryption scheme to convince each other about the abstraction level they provide to external environment i.e the protocols/algorithms they are running or simply, the specific  class of machine they are presenting.

Given both parties, Alice and Bob, own such a device that is provably running a fair bitcoin wallet and does not commit double-spending regardless of what the owner wishes or not, off-chain transferring of funds between the two instances of the device would be a trivial problem.

By proof I mean a cryptographic signature that is somehow secured in a quantitative manner up to a specific but high enough level to ensure safe off-chain transactions. Blockchain and cryptocurrency technology is able to provide security schemes for such applications one of the most interesting ones being curated lists.

Interesting concept, I also thought about a very simple "computer" to replace the "paper coupon", e.g. on a kind of smart card. But I still struggle with the problem that all hardware wallet designs I know need a key (private key or passphrase) to be stored on it. You can encrypt it, of course, but then the way do decrypt it is most of the time a password or PIN, and these are most likely to be relatively unsecure.

In theory you could design a wallet that is "empty" in the sense that the private key stored does not habilitate access to coins, and you will have to "activate" it with a transaction you could store on paper or elsewhere to "fund" it. But then, again, you'll have the problem that two transactions are needed for a payment (funding transaction and payment transaction).

Perhaps you could explain how your "Transparent Private Computer" could exactly help in that process? I'm really struggling to understand, maybe I'm simply too dumb

Might make sense, although there is not really a "bank" as a middleman.

Here I don't understand what you mean - a direct debit authorization generally is valid for a single merchant, and thus that would be relatively trivial to solve as the destination address can be known beforehand (as written in the OP). Can you elaborate?

That might be indeed interesting, but my knowledge about zero knowledge proofs is very limited - so I'll have to investigate further to give you an answer here ...

I could suggest 2 characteristics for such printable things:

- call it check (cheque in British) instead of coupons or cash
- consider the principles of direct debit [1] and forget any kinds of fast processing

and for having an advanced approach to the solution:

- include principles of zero-knowledge proof to the process [2]


[1] https://en.wikipedia.org/wiki/Direct_debit
[2] https://en.wikipedia.org/wiki/Zero-knowledge_proof

The basic concept behind this idea could be understood as off-chain transaction processing. One thing that I would propose here is secure smart hardware wallets that in spite of being in physical possession of the owner,  they are not programmable/hackable to do anything other than what  they've been primarily programmed for. Analogically speaking, a paper money/bank note, is a device that you own but you are not able to reprogram, because it is not forgeable, not supposed to be.

Securing a device to resist manipulation in spite of owner's physical access is definitely possible with current technology but  there are some high level issues like standardization and protocol design should be resolved. Personally I've been working on a more generalized idea: a Transparent Private Computer.

According to my model A TPC is a device that is privately owned by individuals and stores/secures private data on behalf of the owner but is transparent in the sense that any interested party would be trivially and provably convinced about the exact processing logic that the device follows. The secure smart hardware wallet i mentioned above could be one application for such a TPC device.

P.S.
It is the first time I publish anything regarding TPC and I did it just because the problem being put forward in this topic was the point from which I started thinking about it.

I guess that this kind of coupon probably would be a niche technology, as most people would simply use their smartphone for this kind of transaction. But there are reasons people use cash and could find this technology useful, for example, to be less exposed to data/identity theft in the case of the loss of the phone, to pay in regions without mobile internet (or with the wrong band), to pay in a dangerous neighborhood without having to carry the valuable phone, etc..

The difference is that you only transact on the blockchain (=pay transaction fees) if you really pay with the coupon.

For example, I have the following scenario in mind:

You go to a store and want to buy e.g. a bed. You don't know how much it will cost, but you don't want to spend more than 0.1 BTC, but probably more than 0.01 BTC.

Then you could print a paper sheet full of coupons/QR codes for 0.01, 0.02, 0.03 etc. up to 0.1 BTC - all spending the same UTXOs, so only one of them can be used simultaneously (so a thief seeing the paper could only steal you 0.1 BTC, the maximum amount you want to spend - equivalent of a "wallet with banknotes").

When you know the final price, you pay with the coupon with the amount most similar to the price of the bed. Only in this moment, the transactions are carried out.

(This is even a - very small - advantage compared to a low-amount smartphone wallet, because the smartphone wallet, like the paperwallet, must be funded before you enter the shop, and so you must always take care to have enough money on it.)

Then why use Bitcoins for it? (I don't see problems with LN).

I didn't saw any BIP that has a similar idea to make a "cash" version of any bitcoin transaction.
Probably because the very first reason we have a digital currency or even VISA is to be able to make cashless transactions.
This may be a step backward.

For me the old written/embedded Private key of a loaded address is still a good "cash-like " transactions.
Hand over the Paper/Coin to the merchant, he sweeps it, wait for confirmation.. and it's done.
The other two ideas also require transaction(s) to be able to complete the trade, what's the difference? But both are still inconvenient.

And as I'm always saying, to be able for the mainstream to use bitcoins in a standard transaction like coffees and meals, it will always requires a centralized body to accomplish it.

Gift cards normally are limited to a recipient (e.g. a store or franchise). You could call these coupons I have in mind "universal gift cards", as they could be redeemed by all bitcoin-accepting merchants.

A "normal" gift card is trivial to implement with Bitcoin, as you simply print out a signed transaction to an address (or payment code) of the store. It doesn't have the problem that a double transaction is needed (but the buyer also has to wait until the transaction has been confirmed).

@byteball: I don't know what exact project you mean, but it seems to be one with middlemen (a company storing the keys on a card) so it's not what I'm searching for.

@reingard: bitit.io seems to be a completely different concept (gift card for a fiat amount that gets redeemed into Bitcoin)

I remember seeing this somewhere. Looks like this website: https://bitit.io/redeem

Have you read about smart card ideas of a guy who participates in LTC?
They are interesting. Rather than store private key in tamper-resistant envelope, in addition to that he suggests
using smart card soft to hold the private key and to sign transactions and messages.

I do not have much idea about the technical side but the concept is explaining a gift card IMO.

If I want to gift some BTC to someone I like then I can follow the steps you just explained, if I need to spend it for myself then I have my app to pay directly from my wallet.

After reading some proposals for Bitcoin-based "cash" equivalents (like the original Casascius coins or "Bitcoin cards" containing a chip with a private key), I wonder if there is a way to pay in brick-and-mortar stores with Bitcoin with printable "coupons".

These coupons should be used roughly like cash: You should be able to use them at all stores, not only at these you know the address, and there should be no trust involved (nor for one of both parties, nor for a third party). The only difference: You wouldn't be able to re-use the coupons (once one person has paid with them, they cannot be used anymore).

Two ideas came up in a discussion about this topic in the German forum:
1) You create a fresh key-pair and then a transaction from your wallet to the resultant address, but do not broadcast it. You print the whole transaction and the private key of the receiving address to paper and pay with that "coupon". The store can check that transaction and private key are OK - he broadcasts the transaction and immediately transfers the amount to a wallet he owns.

2) You create a transaction from your wallet with an output that can be spent by an user knowing a secret S, providing the corresponding hash H(S). As in example 1, you don't broadcast the transaction but print it on paper, including the secret S. When you pay at a store, the recipient can check that the transaction is OK and the secret is correct, and transfer the coins to a wallet he owns.

(You could obviously also pay with a simple "funded paperwallet", but then you already inscribed the transaction to the blockchain, before the payment, and if you later decided to use the funds for another purpose, you would have lost the transaction fee.)

Both methods should work, but they have a drawback: For every payment, always two transactions are needed, because otherwise the customer can steal the funds as he also knows the secret/private key.

Then obviously the drawback of every brick-and-mortar payment: the merchant will want to wait until the payment is confirmed so you don't double-spend the funds.

I suppose such concepts have already been discussed, so it would be interesting to read if there are already more "mature" proposals, BIPs or applications for this kind of "printable coupon", either already working or at concept stage. It would be interesting, above all, if there are:

- ways to generate a coupon of this kind where only one transaction per payment is needed, but the coupon can be used at any store (it's trivial to create a coupon for a known store, e.g. a "gift card", as you simply would create a TX to a known address of the store)
- ways to generate a coupon of this kind which is compatible with the Lightning Network (this should be impossible or very difficult from all what I know, but maybe someone found a way ...?)