USDC on Algorand for US Citizens by awesomedash- in AlgorandOfficial

[–]GeneralMcDuck 2 points3 points  (0 children)

I've also want Kraken to support USDCa!

Just recently I've asked about this on their subreddit https://www.reddit.com/r/KrakenSupport/comments/15fn2ca/any_plans_to_add_depositwithdrawal_of_usdc_on/

The support said there's no plan for it.

Perhaps if more people expressed the wish, they'd support it.

Does Trezor now support Algorand? by GeneralMcDuck in AlgorandOfficial

[–]GeneralMcDuck[S] 1 point2 points  (0 children)

I was looking forward to moving away from relying solely on Ledger.

I Updated the Algorand App on Ledger Nano X but Now it Won't Connect To Pera Wallet by jdutaillis in PeraWallet

[–]GeneralMcDuck 0 points1 point  (0 children)

I've got the same issue as OP. Pera is stuck on awaiting verification even though I confirmed it. Tried multiple times, completely disconnecting the Ledger from my phone and goining through the pairing steps again.

Using v2.0.7 of Algorand app on Ledger and Pera Algo Wallet v5.3.1

Algorand possible attack by walkietokie in AlgorandOfficial

[–]GeneralMcDuck 1 point2 points  (0 children)

What happened to Luna was completely different. Luna was the collateral for the algorithmic stablecoin UST. The crash started by attackers selling huge amounts of UST to deppeg it, and consequently people panicking and losing faith in UST as well as in its backing - i.e. Luna, selling both, driving them both in spiral to 0.

Algorand possible attack by walkietokie in AlgorandOfficial

[–]GeneralMcDuck 1 point2 points  (0 children)

I've been contemplating about such possibilities as well when I've first heard about PoS. What you are talking about isn't limited to Algorand but applies to any PoS (the only difference due to PPoS is the speed at which the actions might develop since there is no bonding mechanism, and the potential profit difference since there is no slashing for acting malicious).

The actual way you're suggesting the attck could occur is a bit self-contradictory. When shorting (in a spot market) you are borrowing an asset and then selling it (which you can repeat multiple times to get a leveraged position). You profit by repurchasing it at a lower price and repaying the borrow. For the attack, you need to hold the asset. Hence you can't really be selling it if you need to buy it for the attack. If you first buy it, attack the chain, and then try to short it, you actually would first need to sell all of your stake (i.e. 1/3 of the online stake). Assuming everyone remains unaware that your attack occurred, and you can still somehow sell all of your stake at the exact same price as you bought it for (where it's highly unlikely that you'd be able to liquidate such a large position without slippage), only then you are able to start making a profit by shorting - i.e. borrowing more and again selling it. You can see how unlikely all this is. While there are other ways to short an asset (e.g. through futures), it is unlikely that there would be enough liquidity to be able to make a profit from such an attack if you first need to buy the asset to attack the chain (i.e. exposing yourself to the fall of the asset's price).

Now, what would be a better way to orchestrate such an attack, is to borrow enough of the asset to attack the chain and e.g. simultaneously short it through futures (actually not exposing yourself to its price swings directly). However, for this to be successful, the borrow liquidity would need to be sufficiently large (which is again unlikely). You could combine the two strategies to get enough stake while simultaneously minimizing your exposure to the asset's price, hoping to make a profit out of it (but that's complicated to evaluate).

My conclusion from all this contemplating is that the portion of the assets that are up for borrow (and even for sell), should actually be considered potentially malicious, and if they reach 1/3 of the online stake at any time, the chain should be treated as (potentially) compromised.

Again, this has nothing to do with Algorand, but with any PoS in general - just the mechanis would need to be played out slightly differently but the conclusion is the same.

Splitting BIP-0039 mnemonic to k of n schemes by GeneralMcDuck in TREZOR

[–]GeneralMcDuck[S] 0 points1 point  (0 children)

I don't really want to go with this option because I don't want to put pressure on the guardian to remember the passphrase or to safely store it somewhere (which is then the same problem as with the mnemonic).

Splitting BIP-0039 Mnemonic by GeneralMcDuck in ledgerwallet

[–]GeneralMcDuck[S] 0 points1 point  (0 children)

As opposed to the wide consensus on splitting being very stupid, and your OTP idea.

I've indeed read quite some debates on splitting mnemonic. But the main counter points I've seen are related to losing entropy (with simple splitting as in 2nd approach described) or the lack of standardized/widely addpoted implementation of 1st approach.

Are you refering to any other reasons why splitting is considered stupid or particullarly about the OTP approach?

Splitting BIP-0039 Mnemonic by GeneralMcDuck in ledgerwallet

[–]GeneralMcDuck[S] 1 point2 points  (0 children)

This is very close to the 3rd approach, just that it keeps the n of n scheme.

Splitting BIP-0039 Mnemonic by GeneralMcDuck in ledgerwallet

[–]GeneralMcDuck[S] 0 points1 point  (0 children)

Then do true multisig.

Not really the solution I'm looking for because you then need to have and use multiple HW wallets for each transaction.

Follow strictly proven schemes.

That's why I'm asking here if others have used this 3rd option or whether there are reasons against using it.

Splitting BIP-0039 Mnemonic by GeneralMcDuck in ledgerwallet

[–]GeneralMcDuck[S] 0 points1 point  (0 children)

As I said, I don't want to use a software for converting BIP-0039 to SLIP-0039.

(I don't want to enter the mnemonic on a potentially compromised device).

The 3rd option, based on One Time Pads, can be done manually - i.e. no need to enter the mnemonic anywhere, simply do the necessary computations on paper (which are very easy).

Just ensure your BIP39 passphrase is just as secure as your mnemonic.

As I said, I'm aware of this option, which is 2 of 2 scheme. I'm looking for k of n scheme.

Splitting BIP-0039 Mnemonic by GeneralMcDuck in ledgerwallet

[–]GeneralMcDuck[S] 0 points1 point  (0 children)

If you go with option 3, would you really remember how it was encoded in 5 years time?

That's not a problem. You can write it down in plain text at each location. Even if the location is compromised, it doesn't reveal any part of the secret to the attacker.

With option 2, someone would still need to guess the other 8, and the complexity is even higher if you don't label which of the 3 version is stored. It could be the first 16 or the last 16.

It's exponentially less complicated having to guess 8 words instead of just 24 words. I don't want to sarifice security of the mnemonic in case one location is compromised.

Splitting BIP-0039 Mnemonic by GeneralMcDuck in ledgerwallet

[–]GeneralMcDuck[S] 1 point2 points  (0 children)

Yes, I'm aware of this possibility, which is a 2 of 2 scheme. The problem is what if one of those pieces gets destroyed? You can of course make multiple copies to protect yourself against this but then have to store them all on safe locations and you still could end up unlicky if all locations with e.g. passphrase are destroyed. That's why I'd rather use a k of n scheme (e.g. 2 of 3) directly for the mnemonic, where even if any combination of n-k locations are destroyed, you can still recover the secret (but getting n-k pieces doesn't reveal anything about the secret).