forked from cheng/wallet
misc
This commit is contained in:
parent
dbadd59e3c
commit
5f4642ddd2
@ -218,6 +218,9 @@ do not get all of it, they can calculate the signature.
|
||||
|
||||
# Threshold Signatures
|
||||
|
||||
FROST is an algorithm that produces a regular schnorr signature, and allows a quite large number of unequal shares.
|
||||
|
||||
|
||||
A threshold signature has the interesting feature that it is a randomness
|
||||
beacon. If there is one honest participant party to the signing it generates a
|
||||
random value unpredictable to all participants, This has obvious utility in
|
||||
@ -243,6 +246,10 @@ clean, simple, and easy to understand.
|
||||
[FROST algorithm for Schnorr distributed key generation and signing]:https://suredbits.com/schnorr-applications-frost/
|
||||
"Schnorr Applications: FROST"
|
||||
|
||||
[FROST with unequal shares]:https://github.com/Trust-Machines/frost
|
||||
|
||||
Source code for [FROST with unequal shares] is available on github, implemented for the bitcoin elliptic curve.
|
||||
|
||||
Each of the participants acts as the trusted dealer for his own share, hands
|
||||
out shares in it to everyone else, and the final key is the sum of everyone's
|
||||
share.
|
||||
|
@ -48,6 +48,14 @@ preserve distances within twenty five percent, in which case we need two
|
||||
hundred and fifty six dimensions. So a dimensionally reduced point is not
|
||||
necessarily reduced by a whole lot.
|
||||
|
||||
Two hundred and fifty six dimensions is still an impractically large
|
||||
dimensionality, albeit an improvement on what was likely a near infinite
|
||||
number of dimensions.
|
||||
|
||||
To reduce it to something actually useful, need principal component
|
||||
analysis. If non linear methods required, as likely they will be, neural
|
||||
network methods.
|
||||
|
||||
For spaces of dimension higher than fifteen or so, clever methods of
|
||||
nearest neighbour search generally fail, and people generally wind up with
|
||||
brute force search, comparing each point to each of the others, and then
|
||||
|
@ -92,13 +92,6 @@ the (possibly quite lengthy) merge message.
|
||||
Thus all changes should be made, explained, and approved by persons
|
||||
identified cryptographically, rather than through the domain name system.
|
||||
|
||||
It is preferable to simplify the history recorded in git by rebasing the
|
||||
changes in the branch that you want pulled to the most recent version
|
||||
signed by the puller of the branch that you want it pulled into. This
|
||||
produces an artificially linear history, which is likely to be more
|
||||
intelligible and informative than the actual history. In particular, more
|
||||
intelligible to the person who has been requested to pull.
|
||||
|
||||
# No race, sex, religion, nationality, or sexual preference
|
||||
|
||||
![On the internet nobody knows you are a dog](../images/nobody_know_you_are_a_dog.webp)
|
||||
@ -107,6 +100,10 @@ Everyone shall be white, male, heterosexual, and vaguely Christian, even
|
||||
if they quite obviously are not, but no one shall unnecessarily and
|
||||
irrelevantly reveal their actual race, sex, religion, or political orientation.
|
||||
|
||||
Unnecessarily informing people one is female or Jewish or nonwhite
|
||||
should get similar treatment to unnecessarily informing people one is a
|
||||
pure blooded Aryan.
|
||||
|
||||
All faiths shall be referred to respectfully. Even if they happen to be
|
||||
making war on us, this software may not be very relevant to that kind of
|
||||
warfare, in which case that discussion can be held elsewhere.
|
||||
|
@ -312,6 +312,8 @@ systems,with the same UUIDs to the same sata controller while powered
|
||||
down, big surprise is likely on powering up. Attaching one of them to
|
||||
virtio will evade this problem.
|
||||
|
||||
If you amend file system UUID's referenced in fstab and boot, have to amend `/etc/fstab` and `/boot/efi/EFI/debian/grub.cfg`, then rerun `update-grub`.
|
||||
|
||||
But a better solution is to change all the UUIDs, since every piece of software expects them to be unique, and edit `/etc/fstab` accordingly. Which will probably stop grub from booting your system, because in grub.cfg it is searching for the /boot or / by UUID.
|
||||
|
||||
However, sometimes one can add one additional virtual disk to a sata
|
||||
@ -3229,6 +3231,7 @@ not signing code, though that will be our first use of it, but to enable
|
||||
[sovereign corporations] to act through remote employees and safely use
|
||||
servers in the cloud. Information wants to be free, but programmers want
|
||||
to be paid.
|
||||
|
||||
### Phabricator
|
||||
|
||||
Server Size : 2GB Ram – 1 CPU Core – 50GB SSD
|
||||
@ -3455,11 +3458,34 @@ name](https://gitlab.com/gitlab-org/gitlab-ce/issues/13530).
|
||||
|
||||
## coupling to the desktop
|
||||
|
||||
[base directory specifications]:https://specifications.freedesktop.org/basedir-spec/latest/
|
||||
|
||||
[Linux desktop standard]:https://specifications.freedesktop.org/menu-spec/latest/
|
||||
|
||||
[Desktop Application Autostart Specification]:https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html
|
||||
|
||||
To couple to the desktop requires a pile of information and configuration,
|
||||
which most people ignore most of the time. To the extent that they provide it,
|
||||
they seem to write it for the Gnome based desktops, Cinnamon and Mate – more
|
||||
for Mate because it is older and has changed less.
|
||||
|
||||
An install program should use `desktop-file-install` which is presumably
|
||||
customized for each desktop,
|
||||
|
||||
The autostart directory `$XDG_CONFIG_HOME /autostart' is a part of the
|
||||
freedesktop.org/XDG [Desktop Application Autostart Specification].
|
||||
|
||||
`$XDG_CONFIG_HOME` is seldom set, in which case it is equal to `~/.config`, hence the autostart directory is nearly always `~/.config/autostart`
|
||||
|
||||
The desktop specification is chock full of references to `$XDG_foo_bar`,
|
||||
which is confusing because these are environment variables that no one
|
||||
ever sets, and which should never be set, which means that their default
|
||||
values *almost* always apply. Further, many of the directories are not
|
||||
default created, so the first program to write a file into them has to create them. Which is likely to be your program, because superuser is likely to
|
||||
create a user specially for your program.
|
||||
|
||||
This mysterious usage is explained, cryptically, in [base directory specifications]
|
||||
|
||||
Since wxWidgets is written for GDT in its linux version, it is written for Gnome.
|
||||
|
||||
Gnome3, the default Debian desktop, is broken, largely because they refuse to
|
||||
@ -3476,10 +3502,10 @@ Linux has its command line features polished and stable, but is still
|
||||
wandering around somewhat lost figuring out how desktops should work.
|
||||
|
||||
Under Mate and KDE Plasma, bitcoin implements run-on-login by generating a
|
||||
`bitcoin.desktop` file and writing it into `~/.config/autostart`
|
||||
`bitcoin.desktop` file and writing it into `~/.config/autostart` (`$XDG_CONFIG_HOME/autostart`).
|
||||
|
||||
It does not, however, place the `bitcoin.desktop` file in any of the
|
||||
expected other places. Should be in `/usr/share/applications`
|
||||
expected other places. Should be in `/usr/share/applications` (`$XDG_DATA_DIRS/applications`).
|
||||
|
||||
The following works
|
||||
|
||||
|
@ -139,7 +139,7 @@ apt install -qy wireguard wireguard-tools linux-headers-$(uname -r)
|
||||
On the server
|
||||
|
||||
```bash
|
||||
mkdir -p /etc/wireguard
|
||||
sudo mkdir -p /etc/wireguard
|
||||
wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key
|
||||
sudo chmod 600 /etc/wireguard/ -R
|
||||
```
|
||||
@ -147,7 +147,7 @@ sudo chmod 600 /etc/wireguard/ -R
|
||||
On the client
|
||||
|
||||
```bash
|
||||
mkdir -p /etc/wireguard
|
||||
sudo mkdir -p /etc/wireguard
|
||||
wg genkey | sudo tee /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key
|
||||
sudo chmod 600 /etc/wireguard/ -R
|
||||
```
|
||||
|
@ -371,7 +371,7 @@ power, and their failures rather too great consequences. But, following the
|
||||
way that git is designed and in practice used, we do not have to give them
|
||||
unlimited power, nor allow them to be a central point of failure.
|
||||
|
||||
### runningt in schism, with many approximately equal branches
|
||||
### running in schism, with many approximately equal branches
|
||||
|
||||
Centralized databases are a single point of failure. They are also extremely
|
||||
convenient, because they enable many humans to leverage the judgment of
|
||||
@ -385,7 +385,7 @@ Under attack, the system may well schism, with no one source that lists all
|
||||
or most Zooko identities that people are interested in contacting, but it
|
||||
should, like Git, be designed to schism, and work well enough while
|
||||
schismed. That is what makes Git centralization truly decentralized.
|
||||
Sometimes, often, there is no one authoritative branch, and things still work.
|
||||
Sometimes, often, there is no one authoritative branch, and things still work well enough.
|
||||
|
||||
The messages of the people you are following are likely to be in a
|
||||
relatively small number of repositories, even if the total number of
|
||||
@ -429,7 +429,6 @@ The metadata in the feed sharing reveals what network addresses are
|
||||
following a feed, but the keys are derived from user identity keys by a one
|
||||
way hash, so are not easily linked to who is posting in the feed.
|
||||
|
||||
|
||||
### Replacing Kademlia
|
||||
|
||||
[social distance metric]:recognizing_categories_and_instances.html#Kademlia
|
||||
|
Loading…
Reference in New Issue
Block a user