Das Problem bei reinen Paperwallets ist ja das Double-Spending-Risiko für den Merchant, und weitergeben kann man die Paperwallets auch nicht (da jeder, der den PrivateKey kennt, die Paperwallet jederzeit leeren kann), deshalb wären es auch nur Einweg-Gutscheine. Allerdings ist das, wenn der Merchant die ~10 Minuten Zeit hat, zu warten, tatsächlich einfach lösbar: Der Merchant selbst tätigt eine TX von deinem Paperwallet auf die eigene Wallet und wartet auf die Confirmation. Geht die TX durch, ist alles in Butter.

Ich sehe gerade, dass genau dasselbe Problem auch bei dem "Transaktionen-als-Bargeld"-Konzept besteht, das ich kurz angesprochen hatte. Allerdings hat das von mir genannte Konzept einen Vorteil: Es ist eine Transaktion weniger notwendig, also weniger TX-Gebühren. (Und: Wenn ich die Einweggutscheine am Ende doch nicht nutze, brauche ich keine Transaktionen zu broadcasten.) (Editiert, hab vorhin was falsches geschrieben )

Praxistauglich (mit Blick auf das Scaling-Problem) wäre das ganze natürlich nur, wenn es gelänge, es mit LN-Transaktionen zu realisieren (es sei denn, man nutzt Sidechains oder Ähnliches). Allerdings scheinen mir da auf dem ersten Blick unlösbare Probleme bei der Benutzerfreundlichkeit zu bestehen. Ich muss ja bei jeder LN-Operation den selben Channel modifizieren. Wenn ich also LN-Transaktionen ausdrucke und damit zahlen will, sind die "Geldscheine" quasi abhängig voneinander und nicht austauschbar (Beispiel: Ich drucke mir 3 "0.001-BTC-Scheine" aus. Dann muss ich penibel drauf achten, dass ich Schein 1 zuerst ausgebe, dann erst Schein 2 und dann Schein 3 - gebe ich zuerst Schein 3 aus, dann gebe ich ja 0.003 BTC aus, da ich ja damit den Channel um 3 "Schritte" modifiziere. Dazu kommt, dass die Gegenpartei zwischendrin die Transaktionen ebenfalls signen muss. Hach, was 'n Knoten im Kopf, hehe.).