When we think about privacy, it's usually in the context of an individual being able to hide something, usually from the government, but also from lots of other entities. It's a security issue in the greater discourse because there are bad people that can and will use information about you to reveal embarrassing information, blackmail, or even steal from you.
This is not just true of criminals, but also of companies and even governments. They can and do use information about you to propagandize you or demand taxes from you. These are, of course, understandable concerns and good reasons to want privacy.
Status Games
But there's another aspect of privacy which is just as important, perhaps more important than these and it's the social dynamic at play.
Privacy, you see, is a necessary buffer between people to keep order. This is because people are, in the end social creatures and in every social group, there is a constant jockeying about for position, what I would call status games being played.
The problem with status games is that they are by nature zero-sum. Whoever is at the top is usually both admired and envied, while whoever is at the bottom is generally pitied. This is especially true when the participants can change their position, whether through achievement, violence or politics.
Envy and Resentment
Too much clarity on the status of individuals in the group causes strife in the form of envy. This is not just for people at the bottom, whose envy of everyone above them is understandable, but also for those near the top, who likewise will envy people above them. A big enough group of disaffected people in a status game will cause some form of revolution. In other words, strictly ordered status games are not stable.
Thus, too much information sharing is bound to cause bitterness and resentment which in turn causes unstable organizations because humans are very status-aware. Marxism tries to solve this by making everyone equal, but of course, this doesn't work because the entity which controls this equality ends up being higher status than everyone else. You cannot have full transparency and social order. There will be too many dissatisfied people.
This is where privacy is important because it gives groups ambiguity about where each individuals stand. For example, most social groups in the US have as a default, social standing that corresponds with their level of wealth. The richer you are, the higher on the status ladder you are and the poorer, the lower. A very strict pecking order where everyone knew exactly how many assets everyone had would breed a significant amount of envy and resentment. Any group where this level of transparency was required would be unpleasant to be in strictly for that reason. We need a level of ambiguity to socially interact in a reasonable way.
Decentralized Status Games
That's not to say that everything is completely obscured. Most people that have money signal in various ways, with their clothing, car, topics of conversation and so on. They signal with various levels of loudness and reveal status information to the people that they're targeted at. One of the features of "old money" people is that they're very good at identifying other "old money" people while simultaneously hiding their wealth from people that are not as rich as they are. In a sense, this is a survival mechanism because envy, bitterness and resentment are not pleasant to deal with and oftentimes dangerous.
Privacy is the ability to disclose information at our discretion, not someone else's and that's exactly what happens in groups to keep the peace. Privacy has deep social value because it gives individuals the discretion to reveal where they are relatively in status. That protects not just them from attack, but also protects the group from upheaval. The less envy, bitterness and resentment there is, the more cohesive the group can be.
Conclusion
Privacy is a necessary part of civilization because cooperation is hard and nothing destroys cooperation like bitterness and envy. And those two in turn are caused by too much clarity on status. Privacy is what adds ambiguity and empowers individuals to calibrate group dynamics.
Privacy: it's not just for cypherpunks anymore.
https://m.stacker.news/26250
Quit my well compensated job at the Federal Reserve and become unemployed. It's been tough but as a "Bitcoin maxi", did I have any other choice??? It could cost me everything.
Key sorting
Any wallet that supports BIP48 inherently supports deterministic key sorting as per BIP67 so that all possible multi-signature addresses/scripts are derived from deterministically sorted public keys.
Path levels
We define the following 6 levels in BIP32 path:
m / purpose' / coin_type' / account' / script_type' / change / address_indexhor'in the path indicates that BIP32 hardened derivation is used.Each level has a special meaning, described in the chapters below.
Purpose
Purpose is a constant set to 48' following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification.
Hardened derivation is used at this level.
Coin type
One master node (seed) can be used for multiple Bitcoin networks. Sharing the same space for various networks has some disadvantages.
Avoiding reusing addresses across networks and improving privacy issues.
Coin type
0for mainnet and1for testnet.Hardened derivation is used at this level.
Account
This level splits the key space into independent user identities, following the BIP44 pattern, so the wallet never mixes the coins across different accounts.
Users can use these accounts to organize the funds in the same fashion as bank accounts; for donation purposes (where all addresses are considered public), for saving purposes, for common expenses etc.
Accounts are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.
Hardened derivation is used at this level.
Script
This level splits the key space into two separate
script_type(s). To provide forward compatibility for future script types this specification can be easily extended.Currently the only script types covered by this BIP are Native Segwit (p2wsh) and Nested Segwit (p2sh-p2wsh).
The following path represents Nested Segwit (p2sh-p2wsh) mainnet, account 0:
1': Nested Segwit (p2sh-p2wsh)m/48'/0'/0'/1'</br>The following path represents Native Segwit (p2wsh) mainnet, account 0:
2': Native Segwit (p2wsh)m/48'/0'/0'/2'</br>The recommended default for wallets is pay to witness script hash
m/48'/0'/0'/2'.To add new script types submit a PR to this specification and include it in the list above:
X': Future script typem/48'/0'/0'/X'</br>Change
Constant 0 is used for external chain and constant 1 for internal chain (also known as change addresses). External chain is used for addresses that are meant to be visible outside of the wallet (e.g. for receiving payments). Internal chain is used for addresses which are not meant to be visible outside of the wallet and is used for return transaction change.
Public derivation is used at this level.
Index
Addresses are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.
Public derivation is used at this level.
Examples
network account script chain address path
mainnet first p2wsh external first m / 48' / 0' / 0' / 2' / 0 / 0
mainnet first p2wsh external second m / 48' / 0' / 0' / 2' / 0 / 1
mainnet first p2wsh change first m / 48' / 0' / 0' / 2' / 1 / 0
mainnet first p2wsh change second m / 48' / 0' / 0' / 2' / 1 / 1
mainnet second p2wsh external first m / 48' / 0' / 1' / 2' / 0 / 0
mainnet second p2wsh external second m / 48' / 0' / 1' / 2' / 0 / 1
testnet first p2sh-p2wsh external first m / 48' / 1' / 0' / 1' / 0 / 0
testnet first p2wsh external second m / 48' / 1' / 0' / 2' / 0 / 1
testnet first p2wsh change first m / 48' / 1' / 0' / 2' / 1 / 0
testnet first p2wsh change second m / 48' / 1' / 0' / 2' / 1 / 1
testnet second p2wsh external first m / 48' / 1' / 1' / 2' / 0 / 0
testnet second p2wsh external second m / 48' / 1' / 1' / 2' / 0 / 1
testnet second p2wsh change first m / 48' / 1' / 1' / 2' / 1 / 0
testnet second p2wsh change second m / 48' / 1' / 1' / 2' / 1 / 1
We're really sorry about this and working to fix the issues.
Currently there are two main issues that cause force closes in mutiny.
Paying to a zeus lightning address almost always causes a force closure because it uses hodl invoices so the user need to come online between the time the zeus user claims the payment and before the htlcs time out, this can be a few hour window and often no user will hit it. Ldk is doing some work to help prevent this to give us more leeway in when the user can come back online but this will still be a problem, frankly zeus lightning addresses are just a nonsensical way to use lightning. https://github.com/lightningdevkit/rust-lightning/issues/2698
The second being multiple instances of mutiny running for the same seed. We have a bunch of checks to try to prevent this but it is difficult. We've exhausted so many options we're beginning to suspect some browsers (mainly safari) just clears some of our state which can cause the error. In our latest release we've started using a fork of ldk so instead of force closing it'll fail to start up instead, just to add more protection.
After all this, if you do everything right but still get a force close, you needed to come back online within 24 hours of the force close to sweep your money. This is just the nature of lightning with its high availability requirements. Our latest release extended this to two days but the best solution would be to add watch tower support so it can be swept without the user. Ldk does have experimental support for this but not something we've built out yet.
We do work closely with the LSP and if the user's funds are swept we are always able to get the money back.
These always really pain me because everyone on the team uses the wallet everyday and haven't ran into any loss of funds issues, so it's really hard to try and reproduce what exactly is causing all the problems. Fixing these is our top priority but a lot of it is just trying something and putting it out into the wild and seeing if our number of channel closures go up or down. Posting any logs when you get an issue is always extremely helpful.