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?
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?
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.
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:
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);
}
}
Using on-chain contracts for revocable gifts has severe practical drawbacks:
recipient pubkey
to create the contract which requires interaction between walletsconstructor arguments
can be anything and so change the P2SH addressMy 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.
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