new file: docs/libraries/time.md
new file: docs/manifesto/SWIFT.md
This commit is contained in:
parent
7674b879eb
commit
9c5a393a93
75
docs/libraries/time.md
Normal file
75
docs/libraries/time.md
Normal file
@ -0,0 +1,75 @@
|
||||
---
|
||||
title: time
|
||||
sidebar: true
|
||||
notmine: false
|
||||
...
|
||||
|
||||
We plan to have a network with all parties agreeing on the consensus network time,
|
||||
which accommodates leap seconds by being rubbery,
|
||||
passing at 1001 milliseconds per second, or 999 milliseconds per second, or so,
|
||||
when a leap second happens.
|
||||
|
||||
the C++ library chrono reports the steady time, guaranteed not to jump,
|
||||
and guaranteed to pass at very very close to one second per actual second,
|
||||
but not guaranteed to have any particular relationship with any other machine,
|
||||
and also the global official time, with no guarantees
|
||||
that it is not wildly wrong, and which once in a while jumps by a second.
|
||||
|
||||
To check the global posix time on linux, *and uncertainty in that time* on linux
|
||||
|
||||
``` c
|
||||
#include <stdio.h>
|
||||
#include <sys/timex.h>
|
||||
|
||||
int main()
|
||||
{
|
||||
struct timex timex_info = {};
|
||||
timex_info.modes = 0; /* explicitly don't adjust any time parameters */
|
||||
|
||||
int ntp_result = ntp_adjtime(&timex_info);
|
||||
|
||||
printf("Max error: %9ld (us)\n", timex_info.maxerror);
|
||||
printf("Estimated error: %9ld (us)\n", timex_info.esterror);
|
||||
printf("Clock precision: %9ld (us)\n", timex_info.precision);
|
||||
printf("Jitter: %9ld (%s)\n", timex_info.jitter,
|
||||
(timex_info.status & STA_NANO) ? "ns" : "us");
|
||||
printf("Synchronized: %9s\n",
|
||||
(ntp_result >= 0 && ntp_result != TIME_ERROR) ? "yes" : "no");
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
Those machines that do not have an accurate global time will try to be
|
||||
at the median of all the machines that they have direct connection with
|
||||
while biasing the consensus towards the passage of one second per second,
|
||||
plus or minus a couple of milliseconds, by being a little bit off the median,
|
||||
should the consensus time seem to be moving too fast or too slow -- which is
|
||||
to say if the new consensus seems to have drifted from the old,
|
||||
they will stubbornly drag their heels in moving to the new consensus.
|
||||
|
||||
Those that do have an accurate global time will try to be nearer to the
|
||||
global time, while remaining inside two thirds of the distribution.
|
||||
If the network
|
||||
time differs by so from the authoritative time, they will be as
|
||||
close as they can be to the authoritative time, while remaining inside
|
||||
the majority consensus, thus causing the consensus to drift towards
|
||||
the authoritative time.
|
||||
|
||||
This describes an ad hoc mechanism for keeping consensus.
|
||||
|
||||
[gamma distribution]:../estimating_frequencies_from_small_samples.html#beta-distribution
|
||||
{target="_blank"}
|
||||
|
||||
[delta distribution]:../estimating_frequencies_from_small_samples.html#beta-distribution
|
||||
{target="_blank"}
|
||||
|
||||
We could be really clever and represent the consensus by a
|
||||
[gamma distribution], which for a continuous quantity such as
|
||||
time means a two dimensional $α$ and a two dimensional $β$,
|
||||
hyper parameters, but the mathematics of conjugate distributions
|
||||
gets rather scary.
|
||||
|
||||
Or cleverer still and accommodate leap seconds by consensus
|
||||
on both the time and the rate of passage of consensus time relative
|
||||
to steady time by a [delta distribution], in which case we have
|
||||
a three dimensional $α$ and $β$
|
612
docs/manifesto/SWIFT.md
Normal file
612
docs/manifesto/SWIFT.md
Normal file
@ -0,0 +1,612 @@
|
||||
---
|
||||
# katex
|
||||
title: >-
|
||||
Lets eat SWIFT's lunch.
|
||||
sidebar: true
|
||||
notmine: false
|
||||
abstract: >-
|
||||
SWIFT transactions are slow, expensive, and unreliable. And there are a lot of them,
|
||||
a mountain of money to be made. SWIFT is being weaponized and shooting itself in the feet.
|
||||
Everyone wants to move into the vacuum that has opened up,
|
||||
but what moves into the vacuum will be Bitcoin,
|
||||
*if* we can handle the scaling problem.
|
||||
|
||||
SWIFT merely provides an infrastructure for exchanging messages.
|
||||
Double spends are resolved by databases of the entities receiving the messages.
|
||||
The grotesque profits are made by the banks that use it.
|
||||
And the profits for its crypto currency replacement are going to be made
|
||||
by the cexs, dexes daos and wallets that use it.
|
||||
With a lions share of the profits made by first dao of the first dex,
|
||||
because of first mover advantage.
|
||||
|
||||
A replacement of SWIFT will not make money.
|
||||
It will be a neutral environment in which people can make money.
|
||||
So the replacement needs to be funded by software bounties.
|
||||
---
|
||||
|
||||
# Opportunity.
|
||||
|
||||
People are spending an enormous amount of money on SWIFT transfers.
|
||||
How much is hard to know, because the profits are made by the participant banks,
|
||||
not by SWIFT, which is a neutral platform and neutral protocol,
|
||||
that does not in itself transfer any money, but enables transfers,
|
||||
but something in the ballpark of a billion dollars a day.
|
||||
If people who create the infrastructure that repaces SWIFT can
|
||||
capture a tiny sliver of that, they all get very rich.
|
||||
|
||||
Incoming international wire transfer fees may range from $10–$30,
|
||||
while outgoing fees can be up to $50 or more.
|
||||
SWIFT reported an average of 42 million payments and securities transactions per day in 2022,
|
||||
indicating a about a billion dollars a day in fees.
|
||||
|
||||
The World Bank estimates that the average cost of an international bank transfer
|
||||
is around 6% of the amount transferred,
|
||||
which also indicates about a billion dollars a day in fees.
|
||||
|
||||
It is difficult for Bitcoin to replace gold as a store of value because of Metcalfe's law.
|
||||
Central banks keep gold and do not keep bitcoin,
|
||||
because all the other central banks keep gold and do not keep bitcoin.
|
||||
If Bitcoin level two replaces SWIFT, then the central banks will need bitcoin,
|
||||
and soon enough bitcoin will replace gold.
|
||||
This will raise the market cap of Bitcoin to something like ten times its current value,
|
||||
but that is small potatoes compared to capturing a tiny sliver of SWIFT fees.
|
||||
|
||||
# Outline of what needs to exist.
|
||||
|
||||
SWIFT is a messaging system that handles about five hundred standardized structured messages per second
|
||||
(many messages of many types) between a few hundred banks, with certain special security guarantees,
|
||||
in particular reliable and provable delivery. To eat SWIFT's lunch,
|
||||
need a sharded reliable broadcast channel with open entry, without centralization.
|
||||
|
||||
I am using “reliable broadcast channel” in the cryptographic sense.
|
||||
It will not be reliable in the ordinary sense, since you may attempt to put a message on it,
|
||||
and the message may not get on it, and you have to try again.
|
||||
It will not be broadcast in the ordinary sense,
|
||||
since most messages are end to end encrypted so that only the two parties can read them.
|
||||
What makes it a reliable broadcast channel in the cryptographic sense,
|
||||
is that if Bob sends a message to Carol over it,
|
||||
as part of a protocol where Bob has to send a message,
|
||||
and Carol has to send a reply, then if the protocol fails because of Bob, Carol can prove it,
|
||||
and if the protocol fails because of Carol, Bob can prove it.
|
||||
And both can prove what messages they received,
|
||||
and what messages they sent that the counterparty should have received.
|
||||
|
||||
Being sharded, can handle unlimited volume.
|
||||
And once that exists as a neutral protocol with open entry and no central control,
|
||||
can put dexes on it, Daos on it,
|
||||
uncensored social media on it, web 3.0 on it, and coins on it.
|
||||
|
||||
And the first thing that should go on it is a dex that can exchange
|
||||
Bitcoin, Liquid Bitcoin, Liquid Tether, Lightning, and Liquid Lightning.
|
||||
And the next thing that should go on is the Aqua wallet.
|
||||
But it needs to be a neutral open protocol, not owned by anyone,
|
||||
and especially not owned by Blockstream.
|
||||
Because Blockstream will gain value by being able to send or receive
|
||||
a money bearing message to anyone.
|
||||
|
||||
At present each dex has its own messaging platform that does not talk to any of the others.
|
||||
Bisq has a custom platform that runs on Tor, while Particl uses a fork of Bitmessage.
|
||||
And each platform lacks some of the features a dex needs,
|
||||
for which the dao of each dex has ad-hoc workarounds requiring frequent human intervention,
|
||||
such as Bisq's painfully slow and unreliable mediation and arbitration system, which most
|
||||
of the time winds up resolving issues that computers can and should solve automatically.
|
||||
|
||||
If one party goes down and stays down in the middle of a Bisq transaction, it gets
|
||||
resolved by humans to the disadvantage of the unresponsive party, a simple rule
|
||||
that machines should execute automatically.
|
||||
|
||||
Such a channel needs a distributed consensus as to what messages went on it.
|
||||
Consensus is a hard problem, that gets a whole lot harder when you have sharding.
|
||||
But a whole lot easier when the platform does not have to resolve double spends,
|
||||
but merely provide a total order that enables other systems to
|
||||
communicate about their resolution.
|
||||
|
||||
In existing dex communication platforms messages have value because of their relationship to other blockchains,
|
||||
and it is those other blockchains that resolve double spends.
|
||||
This is the equivalent of the way SWIFT does it.
|
||||
|
||||
And Bob can prove it even if his message is supposed to appear on one shard,
|
||||
and Carol’s response on a different shard
|
||||
|
||||
Because SWIFT does not carry money, sharding its cryptocurrency equivalent
|
||||
is a much easier problem than sharding a blockchain.
|
||||
If two incompatible messages are sent over Swift,
|
||||
the equivalent of a double spend on Bitcoin, the conflict is resolved outside of Swift,
|
||||
and then messages resolving the conflict are sent within Swift.
|
||||
|
||||
# Scaling
|
||||
|
||||
Bitcoin hit its scaling limit in 2016-2017. Lightning still has capacity,
|
||||
but high level one fees have ended growth in the number of lightning channels,
|
||||
so it is going to hit its scaling limit soon.
|
||||
And we are very soon going to be facing vastly increased demand for transactions.
|
||||
|
||||
Blockstream’s plan is to use the layer two bitcoin blockchain,
|
||||
Liquid, to take over from SWIFT. Liquid can handle a lot of transactions per second,
|
||||
but to really take over from Swift, we are going to be taking Visa’s role in international transaction,
|
||||
and that will need Liquid Lightning, a layer three.
|
||||
Which theoretically exists, but has no useful consumer wallet and has no useful Liquid lightning network,
|
||||
because its command line wallet is only barely usable by a linux guru
|
||||
who is running exactly the right version of linux.
|
||||
Which is OK, if you have half a dozen linux systems running on
|
||||
your private network and several shelves full of computers
|
||||
with no keyboards or video screens running in your basement,
|
||||
which you interact with over ssh and xrdp.
|
||||
|
||||
The collapse of SWIFT is happening now, and Blockstream’s replacement for it is happening now.
|
||||
The internal collapse of the US$ is a few years off,
|
||||
and we need to have crypto currency ready to replace it.
|
||||
And I don’t think that even liquid lightning Bitcoin can handle that.
|
||||
Going to need recursive snarks with snark based sharding.
|
||||
BitcoinOS are addressing that. When last I looked their solution was far from ready,
|
||||
but it does not yet urgently need to be ready.
|
||||
|
||||
To take over from SWIFT, lightning is unlikely to suffice.
|
||||
Going to need Liquid. Since Liquid uses polynomail commits, it
|
||||
might be possible to shard it, but the path to that is unclear,
|
||||
in which case replacing SWIFT is going to need to need Liquid Lightning.
|
||||
|
||||
For Liquid Lightning to be any use, going to need more than Boltz
|
||||
for exchange between lightning and liquid lightning.
|
||||
Third parties will not want to build on a network wholly owned by a single party,
|
||||
for fear that once that party gets Metcalfe law network lockin,
|
||||
it will, like SWIFT, enshitify the network, as so many beneficiaries of Metcalfe's law have done.
|
||||
To replace SWIFT will need liquid lightning, and liquid lightning
|
||||
will need to be exchangeable on a dex,
|
||||
a dex on which Boltz may well be the largest single liquidity provider,
|
||||
but only one liquidity provider of many.
|
||||
|
||||
To take over from Visa in international transactions,
|
||||
Lightning and Liquid are unlikely to suffice, due to scaling limits,
|
||||
going need Liquid Lightning, which theoretically exists, but not really.
|
||||
|
||||
To take over in internal transactions when the US$ collapses,
|
||||
Liquid Lightning is unlikely to suffice. Going to need recursive snarks,
|
||||
which allow a sharded blockchain. Bitsnark's plan is
|
||||
[Grail](https://assets-global.website-files.com/661e3b1622f7c56970b07a4c/662a7a89ce097389c876db57_BitSNARK__Grail.pdf),
|
||||
a bridge between level one Bitcoin and a shardable level two bitcoin based on recursive snarks.
|
||||
|
||||
# Existing messaging systems
|
||||
|
||||
Every interchange blockchain bridge and every dex has its own ad hoc,
|
||||
incomplete, and unsatisfactory messaging system,
|
||||
and the design for this swift killer was primarily motivated by
|
||||
the messaging systems of Particl and Bisq, and in particular by
|
||||
Particl's adoption of Bitmessage for its purpose.
|
||||
If there was something much better, and more scalable, than Bitmessage, everyone could use it.
|
||||
So the first step is to create a better, and more blockchain friendly, Bitmessage.
|
||||
|
||||
We need something like Particl to enable a dex that exchanges
|
||||
bitcoin, lightning, liquid bitcoin, liquid tether, liquid lightning bitcoin,
|
||||
and liquid lightning tether,
|
||||
for SWIFT is a nexus of third parties and third parties are not going to build on a cex.
|
||||
A major reason that Particl is not very satisfactory is that Bitmessage is not very satisfactory.
|
||||
|
||||
# misc unorganized fragments
|
||||
|
||||
## consensus
|
||||
|
||||
> why do you hate POW? Because of resource waste? I thought it was the
|
||||
> reason for success of BTC. With proof of share, or proof of stake,
|
||||
> there will be always discussions of pre-mine, centralization etc.
|
||||
> Would it be the case?
|
||||
|
||||
Hate the resource waste. It offends me. Plus a system that does
|
||||
not directly handle money, that is a a messaging system between
|
||||
systems that do handle money, cannot incentivise the
|
||||
necessary resource waste.
|
||||
|
||||
It could bill people for messaging, and the payments could go to the block winner, but then
|
||||
it would be a dao or yet another crypto currency, and not a neutral platform that other daos
|
||||
and crypto currencies could use.
|
||||
|
||||
Suppose we have a filecoin style proof of spacetime .
|
||||
Which also wastes resources, but identifies those
|
||||
peers that are contributing to the network by storing
|
||||
information and are capable of passing it around,
|
||||
and have lots of connections to other peers.
|
||||
All peers that pass the proof of space test become
|
||||
authorized consensus makers for
|
||||
a certain number of blocks, say 8192 blocks.
|
||||
The test is not too hard. Most peers are authorized.
|
||||
|
||||
We harvest randomness, possibly from the fact that parties
|
||||
do not know each other's secret keys, possibly from the
|
||||
proof of space time test, so that each round, or each group of rounds,
|
||||
a peer gets a random weight, such that the inverse of the weight is uniformly
|
||||
distributed between one and two to the fifty sixth
|
||||
|
||||
Which means the weight is non uniformly distributed, with a very few peers
|
||||
having most of the weight.
|
||||
|
||||
Each peer goes with the consensus block that has the highest chain of weights that it knows of.
|
||||
|
||||
Actually that algorithm has pathologies that could lead to suprising chain re-organisations
|
||||
-- a slightly more complex algorithm is needed.
|
||||
|
||||
Every time a proposed block consensus is shared, it now has addiitional support.\
|
||||
The weights of the two peers that have that consensus
|
||||
and have the highest weight of all peers having that consensus is propagated
|
||||
among all the peers that have that consensus, and the weight of the consensus is the weight of
|
||||
the lesser of the two peers, plus the weight of the lesser of the two peers of the block it
|
||||
was built upon that were known to the peer that built upon it at the time he built upon it,
|
||||
plus the weight of the block that block was built upon, and so on and so forth.
|
||||
|
||||
Thus the most well known chain is propagated, becoming more well known. The more
|
||||
peers that know of a block, the greater the weight of the block.
|
||||
|
||||
It is a better algorithm, but a whole lot more work to implement than RandomX POW.
|
||||
|
||||
## plan
|
||||
|
||||
|
||||
> > But there is a perfectly respectable case for a social net that
|
||||
> > allows end to end encrypted conversations and allows
|
||||
> > pseudonymous identitities to conceal their network address, since if
|
||||
> > one is doing trades of blockchain currencies on
|
||||
> > a dex, one has make public offers without revealing the network
|
||||
> > address of a computer that could be stolen, or
|
||||
> > a person who could be subjected to rubber hose cryptography, and
|
||||
> > engage in securely private conversations
|
||||
> > about the resulting transactions, also without revealing one's
|
||||
> > network address.
|
||||
> >
|
||||
> > For liquid lightning to work, needs an exchange between level one
|
||||
> > lightning, liquid lightning,
|
||||
> > tether lightning, bitcoin, liquid bitcoin, and tether.
|
||||
> >
|
||||
> > And the early adopters are not going to get aboard if the wallet is
|
||||
> > locked to a cex, locked to Boltz, fearing
|
||||
> > that once Boltz gets Metcalfe's law on its side, it is going to
|
||||
> > enshitify the network.
|
||||
> >
|
||||
> > Early adopters will want a dex, on which Blockz happens to be the
|
||||
> > major, but entirely replaceable, supplier
|
||||
> > of liquidity, so that if it turns evil, as corporations that have a
|
||||
> > Metcalfe's law lockin tend to do, the
|
||||
> > dex will become dominated by less evil alternatives.
|
||||
> >
|
||||
> > And a dex, a dex that exists for the perfectly respectable purpose
|
||||
> > of exchanging level one bitcoin
|
||||
> > for level two (lightning and liquid) bitcoin, tether, and level
|
||||
> > three (liquid lightning) bitcoin needs a
|
||||
> > privacy social net.
|
||||
|
||||
> It makes sense.
|
||||
|
||||
> > If they decide they want a liquid lightning network to exist, they
|
||||
> > need a dex, and they need a privacy social net for it
|
||||
> > (Though I need a name less likely to give corporate officers the
|
||||
> > hebee jeebies than privacy social net.
|
||||
|
||||
> Special social net. :)
|
||||
|
||||
Maybe I will just long windedly call it a social net designed to support
|
||||
humanand and machine communications in a way suitable for cryptographic currency
|
||||
purposes and especially a dex, that is a superset of the capabilities of Particl and
|
||||
Bisq human to human communication protocol, particl's system being Bitmessage,
|
||||
and Bitmessage being out of support.
|
||||
|
||||
> > My plan is to tell them they need a liquid lightning network to
|
||||
> > exist, for it to exist there has to be
|
||||
> > a liquid lightning dex, and it needs a mechanism for communicating
|
||||
> > publicly and privately
|
||||
> > without revealing one's network address.
|
||||
> >
|
||||
> > Therefore, fund a privacy protocol that is an update to bitmessage,
|
||||
> > with additional capability of
|
||||
> > zooko names and reliable broadcast, reliable in the cryptographic
|
||||
> > sense.
|
||||
> >
|
||||
> > Reliable broadcast in the cryptographic sense being that if one has
|
||||
> > a transaction protocol in which Bob is supposed
|
||||
> > to send a message to Carol, and Carol supposed to send a
|
||||
> > corresponding response to Bob, the blockchain
|
||||
> > can prove who dropped the ball -- so one can have contracts on the
|
||||
> > blockchain that have one outcome if Bob failed to
|
||||
> > send the message, and a different outcome if Carol failed to reply.
|
||||
> >
|
||||
> > This makes possible a whole lot of useful dex capabilities, which do
|
||||
> > not yet exist on any dex, but could.
|
||||
> > I need to write them up as part of a totally bland proposal for a
|
||||
> > totally bland privacy social net that
|
||||
> > enables arbitrary dexes and daos, among them a totally bland dex
|
||||
> > that enables exchange of things near and dear to
|
||||
> > Blockstream's heart.
|
||||
|
||||
> Ok, if you want me to pass your proposal, I'm ready to do it. I'm
|
||||
> sure I can contact Adam, and at least get a response. I'm not sure
|
||||
> how it should be proposed though. "Someone I messaged on BitMessage
|
||||
> sharing this proposal, I'm sure you'll like it." :) But I think we
|
||||
> can work it out.
|
||||
|
||||
I want to read what Adam has been writing, before I prepare the proposal.
|
||||
|
||||
I think he has been on some you tube channels, or something like that --
|
||||
some kind of conference.
|
||||
|
||||
The proposal is going to be long and technical -- a white paper explaining what
|
||||
Bitmessage is, that it is being used in the Particl dex, and explaining what
|
||||
additional capabilities a dex needs, that Bisq and Particl lack.
|
||||
|
||||
## Python rant
|
||||
|
||||
Wouldn't it be an start to use existing code to experiment some p2p
|
||||
> payments using bitmessage protocol?
|
||||
|
||||
Python is the best language in the world for code you intend will only be used by yourself,
|
||||
used only a few times, then thrown away. It also works great for small trivial programs,
|
||||
because these are apt to remain reasonably portable.
|
||||
|
||||
But the bigger it gets, the more it traps you into code that is only going to run
|
||||
correctly on your one particular development system and that no one else is
|
||||
going to be able to modify and add to, so investing in python
|
||||
in anything you intend to be widely used is a trap. Open source
|
||||
python is also a trap, because no one else is going to be able
|
||||
to modify and add to it.
|
||||
|
||||
If I try to start modifying Bitmessage, I will surely fail. It is a bigger python
|
||||
program than anyone except the original developer can maintain and modify.
|
||||
|
||||
In this sense, no large open source python program is truly open source. PHP
|
||||
has the same problem, though to lesser degree. Javascript likewise. Has
|
||||
improved considerably, but still sucks. But typescript which is compiled to javascript is OK.
|
||||
so all big projects with many developers use typescript rather than javascript.
|
||||
Or they die before they get big.
|
||||
|
||||
## mixer plan
|
||||
|
||||
(Which I am sure blockstream does not want)
|
||||
|
||||
> > Get early adopters to use it. One obvious use case is bitcoin
|
||||
> > mixing. We have mixers, but the social environments that made them
|
||||
> > usable have all been shut down.
|
||||
|
||||
> Or maybe integratate Samourai wallet into current BitMessage client?
|
||||
|
||||
Samourai wallet migrated to centralisation, which directly led to them getting
|
||||
busted. That codebase is poisoned with communications that the FBI
|
||||
has flagged as actionable. And integrating anything into current
|
||||
Bitmessage is impossible except for the original developer. No
|
||||
big Python program is truly open source.
|
||||
|
||||
The correct design for a mixer is as follows. One has a social net,
|
||||
on which anyone can offer to coordinate a single mixing transaction.
|
||||
for a mix that will produce mixed coins (utxos )of a particular
|
||||
round number, 10mBTC, 20mBTC, 50mBTC, or 100mBTC,
|
||||
plus unmixed changed coins.
|
||||
|
||||
All the mixed coins are of equal value, for example all 100mBTC.
|
||||
|
||||
Not some funny value highly identifiable value like 99.9872384mBTC
|
||||
|
||||
People offer to contribute utxos to this mix transaction - revealing
|
||||
to the coordinater the public keys, the address, of the utxos,and
|
||||
revealing to the coordinator that these utxos have a common owner.
|
||||
|
||||
They also give him the blinded addresses of coins they want to
|
||||
receive. He blindsigns those addresses. They then reveal the unblinded
|
||||
addresses, and his unblinded signature, which proves he signed those
|
||||
addresses, but does not reveal to him which of the addresses he blindsigned it
|
||||
is -- he does not learn the relation between the utxos that will be contributed
|
||||
to the mix transaction, and the mixed or the change utxos that it will replace
|
||||
them. (Though he and anyone doing blockchain analysis can trace the
|
||||
change coins by the sudoko attack. But the sudoko attack is irrelevant to
|
||||
coins that are all the same round number of bitcoin, such as 10mBTC)
|
||||
|
||||
He then creates the transaction, and everyone signs it. If not everyone
|
||||
signs, everyone can see what the missing utxos were, the ones that
|
||||
were promised, and not delivered, and blacklist them,
|
||||
then try again.
|
||||
|
||||
People contributing already mixed utxos do not have to pay transaction fees
|
||||
so get back exactly what they contributed.
|
||||
|
||||
People contributing as yet unmixed bitcoin have to pay a portion of the transaction
|
||||
fee proportional to the number of utxos contributed and received. This is good for
|
||||
them because the free of charge remixed utxos are enlarging their anonymity pool.
|
||||
making each mixing transaction part of one enormous anonymity pool instead of many
|
||||
tiny anonymity pools.
|
||||
|
||||
If mixing does not work like this, then someone has fucked it up in order to profit from
|
||||
it, their users will be traced, and *they* will be traced, then arrested.
|
||||
|
||||
> > The core of my plan has always been Web 3.0, a privacy social net,
|
||||
> > and everything else is just monetization, because software never
|
||||
> > gets done properly or properly maintained without someone making
|
||||
> > money off it.
|
||||
|
||||
> I got what you mean now. Once you reach a point that's indeed a good
|
||||
> strategy to reinforce value of the network. You offer those
|
||||
> integrate your service to beat metcalfe's law, your network becomes
|
||||
> much more stronger. Facebook and some other social networks all
|
||||
> followed this path via. 'applications' within them.
|
||||
|
||||
> > I have been trying to do that, but it is hard to get to the front of
|
||||
> > the line of all the people who want to tell blockstream why
|
||||
> > blockstream should fund them and their projects.
|
||||
|
||||
> Have you really tried? Adam must have had some fidelity to
|
||||
> cypherpunks.
|
||||
|
||||
I have not tried, but I have been looking for entry points, and
|
||||
have come up empty. One has to have an in, and one has
|
||||
to listen before one speaks.
|
||||
|
||||
## the big problem
|
||||
|
||||
The urgent important problem that crypto currency has to solve is privacy and scaliing.
|
||||
|
||||
But cannot solve it just by creating a currency that is private and scales,
|
||||
because scaling is not a competitive advantage over ten thousand scamcoins,
|
||||
five thousand shitcoins, and two dozen altcoins,
|
||||
until you reach a market capitalization of thirty billion dollars,
|
||||
which is when scaling started to bite bitcoin in 2016-2017
|
||||
|
||||
Further, all the recursive snark libraries are rough around the edges.
|
||||
Polygon's Poly2 is OK, but though theoretically open source,
|
||||
it is not exactly open source, there are complications and gotchas.
|
||||
|
||||
So, the path is to create a privacy social net tool first.
|
||||
A tool where you can securely have public and private conversations
|
||||
without your IP being discoverable. Bitmessage done right.
|
||||
|
||||
A Dao that facilitates stuff done wth crypto currency,
|
||||
such as Bisq and Particl, needs such a social tool,
|
||||
and what they have is rather broken.
|
||||
|
||||
A Dao can organize over such a tool in ways that flagrantly fail the Howey test.
|
||||
Which is to say, it can openly organise in a way that is
|
||||
efficient and transparent to investors, a sovereign corporation,
|
||||
while existing daos are dancing around the Howey test,
|
||||
and so are opaque and disorderly.
|
||||
|
||||
So, create, not a crypto currency, but an environment for such Daos.
|
||||
Among them daos for trading crypto currency.
|
||||
A Dao that facilitates crypto currency transactions needs a trade currency
|
||||
and dao ownership currency (substitute for shares).
|
||||
These are apt to be one and the same, to obfuscate the Howey test,
|
||||
but they need not be and probably should not be.
|
||||
|
||||
There are a whole lot of capabilities that a crypto coin needs
|
||||
-- and we see that even in things that are well funded by many large corporations,
|
||||
these things are geneally missing.
|
||||
|
||||
Blockstream does not have a satisfactory lightning wallet,
|
||||
and their business plan depends on the existence of a satisfactory lightning wallet.
|
||||
Litecoin has demonstrated atomic exchange between
|
||||
Bitcoin, bitcoin lightning, Litecoin, and litecoin lightning,
|
||||
but does not have a dao in which to do it. Particl is not quite working,
|
||||
and Bisq lacks important things and still, after all these years,
|
||||
has known major bugs which can cause the loss of lots of money.
|
||||
|
||||
Blockstream's aqua is sort of a lightning wallet, and sort of not.
|
||||
It is not quite what they need, and lack. And very few people are using it.
|
||||
It is not really a proper connection to the lightning network.
|
||||
It is what they could come up with in a hurry.
|
||||
|
||||
This stuff is hard and takes a long time to write.
|
||||
|
||||
My initial business plan was: Plan A: Issue a private and scalable currency --> ????? --> profit
|
||||
|
||||
Revised business plan. Plan B: Issue a privacy social net that conceals IP addresses.
|
||||
Bitmessage does this OK, but it is abandonware and mighty rough around the edges,
|
||||
and being written in python, really cannot be fixed.
|
||||
Large python projects accumulate such technical debt that only the original programmer
|
||||
can fix them, and become ever more fragile to minor,
|
||||
obscure, and seemingly irrelevant changes in their environment.
|
||||
|
||||
Get early adopters to use it. One obvious use case is bitcoin mixing.
|
||||
We have mixers, but the social environments that made them usable have all been shut down.
|
||||
|
||||
An important use case for bitmessage was selling services for crypto currency
|
||||
to people who did not want to reveal their IP address.
|
||||
This use case becomes a lot more conveniient if we can lift crypto transactions on existing privacy currencies
|
||||
(Litecoin and Monero) and semi secure currencies (lightning) into the communication channel,
|
||||
as Nostr does a sort of mostly OK job of lifting lightning
|
||||
into the communication channel.
|
||||
First such use, following the footsteps of nostr tips.
|
||||
|
||||
Get existing Daos to use it
|
||||
|
||||
Get new Daos to use it. A Dao that wants to openly organise in an efficient manner transparent
|
||||
to investors is going to want a very private privacy blockchain on which to issue its shares.
|
||||
|
||||
And now, it is back to plan A. (almost) A privacy blockchain
|
||||
on which anyone can issue a Daocoin. Or a shitcoin or scamcoin.
|
||||
|
||||
But the privacy blockchain does not need to be fully scalable.
|
||||
It does, however need to be future compatible with the technologies
|
||||
that make full scalability possible. But we delay in the hope that by currency time,
|
||||
recursive snarks libraries do not have quite so many rough edges
|
||||
|
||||
> > The size of this project is illustrated by how many other big
|
||||
> > projects need some key element of this project, and do not have it.
|
||||
|
||||
> I'm not sure if I understood that to be honest.
|
||||
|
||||
The core of my plan has always been Web 3.0, a privacy social net,
|
||||
and everything else is just monetization,
|
||||
because software never gets done properly
|
||||
or properly maintained without someone making money off it.
|
||||
|
||||
And I look at all these people doing Web 3.0 stuff,
|
||||
or doing projects like particl that really require Web 3.0,
|
||||
and they are not done.
|
||||
|
||||
> Can you double check Keet/Pear.. Holepunch thing? I belive a good
|
||||
> part of Blockstream funding is coming from Tether. And Tether (and
|
||||
> their CEO) loves Keet (like his brainchild). Problem is they don't
|
||||
> have any good use case. I believe a project somehow leveraging would
|
||||
> easily get funding from Blockstream hence Tether.
|
||||
|
||||
I have been trying to do that, but it is hard to get to the front of
|
||||
the line of all the people who want to tell blockstream why
|
||||
blockstream should fund them and their projects.
|
||||
|
||||
Also, I need to find the keywords needed to get the proposal
|
||||
past the layer of idiot no men whose job is to protect them
|
||||
from all those people with bright ideas as to why blockstream should fund them.
|
||||
|
||||
What words are they internally using for stuff that really needs to be done?
|
||||
|
||||
But some of the stuff I want done, they really need done.
|
||||
>
|
||||
> Also excuse me but how it would work if you stays anonymous and pay
|
||||
> devs to work on it. How can they fund, doesn't it require
|
||||
> psedenomous organization? Or do you think some can work in psedonmy
|
||||
> but some can be non-anonymous while working on it?
|
||||
|
||||
I think they should promise an L-BTC bounty or lightning Bitcoin bounty
|
||||
for someone who accomplishes certain goals.
|
||||
Other people have used this funding model, albeit lightning Bitcoin.
|
||||
|
||||
> Even if you have the funding, it is not easy to bring talent on the
|
||||
> table. What's your plan to find to hire the talent even if you can
|
||||
> pay them?
|
||||
|
||||
Litecoin bounties for contributions that get included in the repository.
|
||||
(Litecoin being arguably the best existing privacy currency -- at least when you use mweb addresses.
|
||||
|
||||
> > And so, all the larger moving parts that have to be part of the
|
||||
> > ultimate coin, have to be part of something that has more immediate
|
||||
> > utility, and is part of a business plan that will bring the project
|
||||
> > closer to completion, and product of that completion closer to
|
||||
> > getting past the cold start problem
|
||||
> 100%
|
||||
>
|
||||
|
||||
## collapse and cryptocurrency
|
||||
|
||||
>
|
||||
> Or, do you think it will replace the Gold, nobody would need or want
|
||||
> to use it.
|
||||
>
|
||||
> Today, if you ask me to accept Gold vs. Bitcoin, leaving aside the
|
||||
> speculative part, I'd go 100% for gold. I'm not sure that would
|
||||
> change in the future. But also maybe that's because I think I'm
|
||||
> emotional about it. I always thought Gold is a godly thing, a "gift"
|
||||
> of god to us punish or reward. No question fiat is a scam, or even
|
||||
> in a good intent it is an opiod of an ecomy, however I'm really not
|
||||
> convinced about Gold.
|
||||
|
||||
Obviously over the past few years, Bitcoin has risen enormously more than gold.
|
||||
|
||||
When it looked like full scale war might break out, bitcoin fell a little,
|
||||
and gold rose considerably.
|
||||
|
||||
If the crisis is nuclear war, Gold, 22 LR rifle ammo, whiskey, tobacco,
|
||||
and coffee are likely to be considerably more valuable investments than bitcoin.
|
||||
|
||||
If, on the other hand, the crisis is state internal collapse and red terror
|
||||
against whites, straight males, and Christians, bitcoin because you can carry it through an airport,
|
||||
while gold will be fairly useless
|
||||
|
||||
If the crisis is that you are likely to get conscripted to die in Eastern Europe or the middle east or Taiwan,
|
||||
or all of them simultaneously, bitcoin will be useful, and gold fairly useless.
|
||||
|
||||
If the crisis is hyperinflation and collapse of the US dollar,
|
||||
Gold and Bitcoin both work, but Bitcoin is better because
|
||||
the primary problem will be transactions over distance.
|
||||
|
||||
If the problem is all of the above, simultaneously or in rapid succession, Bitcoin.
|
Loading…
Reference in New Issue
Block a user