Shareable links as on-chain contracts

I have used the bitcoin.com wallet shareable link feature a lot during onboarding in past years

How could that be implemented to work on-chain wothout relying on any third party server?

2 Likes

You should try CashStamps. I have been using them lately to on-board people since Selene wallet added support. No centralized dependencies after creation of the stamp.

2 Likes

The cashscript.org beginner example contract covers this usecase of revocable gifts through contracts. The advantage of using smart contracts is that even the original gifter cannot take back the funds until some timelock.

However using on-chain contracts for revocable gifts has severe practical drawbacks. Let’s look at the contract first:

TransferWithTimeout

The TransferWithTimeout contract takes in 3 contract arguments and has 2 contract functions: transfer and timeout .

pragma cashscript ^0.10.0;

contract TransferWithTimeout(pubkey sender, pubkey recipient, int timeout) {
    // Allow the recipient to claim their received money
    function transfer(sig recipientSig) {
        require(checkSig(recipientSig, recipient));
    }

    // Allow the sender to reclaim their sent money after the timeout is reached
    function timeout(sig senderSig) {
        require(checkSig(senderSig, sender));
        require(tx.time >= timeout);
    }
}

Tradeoffs

Using on-chain contracts for revocable gifts has severe practical drawbacks:

  • you the recipient pubkey to create the contract which requires interaction between wallets
  • the receiving wallet won’t be able to find the funds on-chain by default, as the two other constructor arguments can be anything and so change the P2SH address
  • wallets don’t know how to spend from arbitrary contracts, you need something like a walletconnect web app for this.

My takeaway is that these are not good practical tradeoffs, it’s acceptable that the original gifter can reclaim the funds at any time, especially if it avoids interactivity and contract complexities.

CashStamps provides a much better solution to this problem by standardizing the wif: uri prefix, it also has the benefits of avoiding reliance on any one company to run the sharable link infrastructure. Instead any gifter can use their own URLs to encode sharable links.

2 Likes

Thank you both for that inspiration

I have to share some fact you might not be made aware of so far as you are not using Starlink in Colombia

They block access to the bitcoin.com domain…

So my primary concern is to have an absolutely censorship resistant solution

With censorship resistant I also mean that gifts can not be revoked (which could be executed by a censoring party or malicious actor sending out millions of gifts but reclaim them instantly just to mess with the product reputation as receivers would be disappointed thinking the product is not working)

Funds could go to some lottery wallet after x blocks passed, users could be subscribed automatically to that lottery or voluntarily on a specific date, maybe the anniversary of BCH based on gregorian calender or some specific interval derived from a function including the forks blocknumber 478558, so then users would be made aware of that historic date, another option could be to pay out the lottery based on the amount locked into it, that would incentivize users to keep on sending gifts and explaining that feature to others to hit that limit sooner

But that additional idea is just the whip cream on the ice cream, so major focus for me is censorship resistantance as I can already see Starlink being used to block access and I see non revokable contracts as an important part of a contract in general as much as it is necessary to shut out malicious fake users that just want to ruin tools and BCH reputation by sending out thousands of already revoked links

That shareable link feature has been a very important tool for me during past seven years on the streets

Its the major reason I have been using and promoting bitcoincom wallet despite it going closed source