Building on ICP: gifting Bitcoin to people who have never had a wallet. Feedback requested

[Lorimer]

@marc0olo

blackholing is certainly sth. that some adopters would like to see, but it also means you cannot further update the canister code.

I think there’s a middle ground where the blackholed canister can be assigned sole control over itself, and if it detects that it is no longer functioning correctly it can un-blackhole itself by assigning control to a DAO (though that should be a never scenario that just gives peace of mind that the plausible worst case scenario is temporary custody assigned to a DAO). That significantly limits incentives for governance capture over that DAO while, imo, meeting the bar for ‘non-custodial’.

That’s the path Jupiter Faucet is taking for the core value moving canisters.

[marc0olo]

@homebisquit

It would be great if the II shared email worked to securely deliver that gift. And yes, the current plan would be that the sender would provide both the email and phone number of the recipient and we would use 2FA, this way nobody could intercept the email and therefore the gift, but hopefully II email is a better solution. I just haven’t educated myself on it enough yet and need some direction and to do more homework.

I think it should be secure enough via the II shared email. II is verifying the ownership, so I think you should be able to fully rely on that. (given that you require the user to sign-in via II where he granted your app access to the shared email before he is able to claim the gift)

@homebisquit

I will take a look at the links provided for the similar project. Thanks for sharing.

just a sidenote here → the developer didn’t use II here for authentication and implemented his own dedicated solution for email verification.

@Lorimer

I think there’s a middle ground where the blackholed canister can be assigned sole control over itself, and if it detects that it is no longer functioning correctly it can un-blackhole itself by assigning control to a DAO (though that should be a never scenario that just gives peace of mind that the plausible worst case scenario is temporary custody assigned to a DAO). That significantly limits incentives for governance capture over that DAO while, imo, meeting the bar for ‘non-custodial’.

that sounds great, assuming it would always work. I am not sure if that can always be guaranteed though how would a canister automatically detect that it is no longer functioning correctly?

[Lorimer]

If the canister depends on an external API (e.g. a system canister such as NNS governance or the ICP ledger/index canisters) the canister can catch arbitrary errors attempting to use that API. Depending on the canister, it could either increment an error counter or log the timestamp of the last successful call. If the counter exceeds a certain theshold (consecutive failures in a row) or a specified period of time has gone by without a successful call, the canister can assign control of itself to a pre-specified recovery principal (a ‘lifeline’ canister in Jupiter Faucet terms, and the lifeline is intended as a DAO-controlled canister).

Basically the canister should catch any unexpected errors and use that information to decide if it needs to unblackhole itself.

The only reason this wouldn’t work is if an error isn’t caught (but it’s fairly easy to write/verify code that has a catch all). If the call to the management canister somehow fails to reassign control, that would be due to a breaking change to the management canister API which should never be allowed to happend, and if it did the NNS would revert that change (it would be crazy not to).

[kizzafredrichkibalam]

i’ll be open and ready to support my brother here, But definately if you are looking for a huge market Africa is Open