Topic: lost, unspendable UXTOs, FUD or no? relevant to Armory? (Read 189 times)

totally understand

thank you for everything you do!

BIP32 is in there. My main concern atm is migrating away from SWIG to cppyy (for py3 and eventually qt5 support). Then I need to get the new features in the GUI, and only then can I look at HW wallet integration. However I'm not doing that stuff alone, there are people offering to help and/or currently helping with the process. I have given up on ETAs a long time ago, I never hold them. I'm really hopeful to deliver a lot of stuff this year, the universe willing.

Excellent,

Thank you so much for taking the time to ease my mind guys.  The recent price action has me doing node maintenance (migrated to a larger hard drive, updated core) and thinking about the mechanics of actually touching the old keys, something I get pretty nervous about.  I have the paper with the 4 lines of 4 character groups, so I think I can continue using change addresses from that wallet.

Goatpig, while I have a sliver of your attention, I have seen you mention hardware wallet support as a dev priority.  Can you guess at a timeline on implementation of that?  While I will always use Armory for my deep stash, I have been thinking one of those fancy HW wallets would be pretty handy.

There are no unspendable address types in the context of SegWit, quite the opposite actually: SegWit scripts are anyone-can-spend prior to fork activation. This is irrelevant on the Bitcoin chain, but on BCH (and whatever fork that does not have SW), mistakenly sending coins to a SegWit script will lose you the money (to a miner most likely).

The most realistic way to blackhole coins is to send them to a script hash that has no known preimage. You could also construct scripts that can't be spent from at all (always interpret to false), but in both cases this is not related to SegWit and is rather an issue of bad wallet implementation.

I guess there could be a semi easy way for a wallet dev to bork SegWit script generation in code, but he'd catch it right away on the testnet.

Another potential way to mess up is to swap script types around. A buggy wallet could grab the public key hash from a P2WPKH payment address and construct a P2PKH output script instead, which may result in the receiving wallet to never see the payment. The coins are still redeemable, but in this case the recipient will most likely fail to see it on chain, since he isn't looking for that script type in the first place.

None of these potential snafus are stuff you can achieve through a wallet GUI. Basically, the only way to mess up this bad is to craft your own tx manually.

this has to be wrong

Address types:

• P2PK (since 2009) Bitcoin Core still supports them. Wallets (of any software) won't create these as new addresses, but miners (who run Bitcoin Core) will mine spends from them. Significant funds remain at these addresses
• P2PKH (since 2010) Everything still supports both compressed and uncompressed types. Most won't create uncompressed keys, except Armory (this may change in a future version of course)
• P2SH (since 2012) Everything supports these
• P2WPKH/P2WSH (since 2017) Majority of wallets support these

The Bitcoin devs went out of their way to maintain backwards compatibility of the addresses, it's important for BTC's money properties (and so also to the price, can't have people losing confidence in their ability to spend old BTC outputs)

P2SH is a special case here: it includes multisig, wrapped segwit, wrapped compressed (which only Armory does AFAIK), timelocked, timelocked contracts (so lightning channels iow), basically anything with something other than the basic opcodes is a P2SH/P2WSH. And that doesn't matter in compatibility terms, sufficient numbers of miners are up to date with the scripting softforks that it's guaranteed someone will mine a P2SH scripted output that uses the valid and available ops, nothing new has been introduced since Segwit, and 99-100% are mining even those.

tl;dr FUD

Based solely on what you've said it sounds like a mix of FUD and the issue I mentioned, but I don't know enough about the lower layers to be some sort of authority on it.
I know things can get a bit dicey when using Armory's P2SH-P2PK if you needed to export and use those keys. Other clients don't support this exact format, so you'd have to craft a transaction yourself.
P2PKH works fine in everything, of course.
P2SH-P2WPKH support is getting quite widespread too.

If these are Armory paper backups (lines of "words") you should be fine. That Armory backup can generate all the private keys you'll ever use.
If using old paper wallets that are a single address you'd hit the same issue with change addresses if you only relied on that paper backup. So definitely avoid that pitfall, but that issue has existed from the start right up until HD wallets came about.

You'd sacrifice privacy but you can instruct Armory to pay any change back to the same or an existing address. Unnecessary unless you're using imported keys, but the option is there.

Corrections welcomed.

Thanks for the reply PF.

Unfortunately, I don't recall the exact posts.  I just read a couple things back in the 3K doldrums and made a mental note to look into it.

I am pretty frigging paranoid about messing with the old paper wallets...want to make sure I understand any modern pitfalls.


I am thinking that as long as I stick to P2PKH outputs, or sweep entire addresses I will be OK.

Some context as to where you've heard this would help, as well as what the horror stories are?

The only thing I can think of is back before HD wallets existed, and old backups wouldn't know about any addresses generated after the backup, which lead to people being unable to get to the change.

So what is this I hear about horror stories of people making a test transaction out of a large old wallet only to fat finger the unspent change into an incompatible, unspendable address type??

Is this anti-segwit FUD or is it a real thing? 

Is this something I need to be aware of and guard against as an Armory user?