9c5a393a93
new file: docs/manifesto/SWIFT.md
613 lines
29 KiB
Markdown
613 lines
29 KiB
Markdown
---
|
||
# 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.
|