sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
Steini- has quit []
slivera has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
_whitelogger has joined #bitcoin-wizards
veox has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
freewil has joined #bitcoin-wizards
freewil has quit [Quit: Leaving.]
shush has quit [Remote host closed the connection]
Belkaar has quit [Ping timeout: 260 seconds]
Belkaar_ has joined #bitcoin-wizards
veox has quit []
superkuh has quit [Remote host closed the connection]
bitdex has joined #bitcoin-wizards
lassulus1 has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
superkuh has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 258 seconds]
justanotheruser has joined #bitcoin-wizards
rottensox has quit [Ping timeout: 260 seconds]
rottensox has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 258 seconds]
justanotheruser has joined #bitcoin-wizards
captjakk has joined #bitcoin-wizards
pinheadmz has quit [Read error: Connection reset by peer]
pinheadmz has joined #bitcoin-wizards
captjakk has quit [Remote host closed the connection]
captjakk has joined #bitcoin-wizards
captjakk has quit [Remote host closed the connection]
captjakk has joined #bitcoin-wizards
captjakk has quit [Remote host closed the connection]
captjakk has joined #bitcoin-wizards
captjakk has quit [Remote host closed the connection]
captjakk has joined #bitcoin-wizards
captjakk has quit [Read error: Connection reset by peer]
captjakk has joined #bitcoin-wizards
captjakk has quit [Remote host closed the connection]
lassulus1 has quit []
weez17 has quit [Ping timeout: 240 seconds]
toresbe1 has joined #bitcoin-wizards
weez17 has joined #bitcoin-wizards
meshcollider has joined #bitcoin-wizards
Logicwax has quit [Ping timeout: 265 seconds]
pinheadmz has quit [Quit: pinheadmz]
pinheadmz has joined #bitcoin-wizards
jonatack has joined #bitcoin-wizards
Kiminuo has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 258 seconds]
Logicwax has joined #bitcoin-wizards
paultroon has joined #bitcoin-wizards
paultroon has quit [Ping timeout: 260 seconds]
ddustin has joined #bitcoin-wizards
Kiminuo has quit [Ping timeout: 265 seconds]
toresbe1 has quit []
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 260 seconds]
Guyver2 has joined #bitcoin-wizards
Logicwax has quit [Ping timeout: 268 seconds]
Logicwax has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 245 seconds]
captjakk has joined #bitcoin-wizards
paultroon has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
paultroon has quit [Ping timeout: 268 seconds]
slivera has quit [Remote host closed the connection]
paultroon has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
DrGuschtel has joined #bitcoin-wizards
bitdex has quit [Ping timeout: 240 seconds]
luke-jr has quit [Remote host closed the connection]
AbramAdelmo has joined #bitcoin-wizards
AbramAdelmo_ has joined #bitcoin-wizards
AbramAdelmo has quit [Ping timeout: 265 seconds]
_whitelogger has joined #bitcoin-wizards
paultroon has quit [Remote host closed the connection]
TheoStorm has quit [Quit: Leaving]
AbramAdelmo_ has quit [Remote host closed the connection]
AbramAdelmo has joined #bitcoin-wizards
AbramAdelmo_ has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
AbramAdelmo_ has quit [Remote host closed the connection]
AbramAdelmo has quit [Ping timeout: 268 seconds]
paultroon has joined #bitcoin-wizards
AbramAdelmo has joined #bitcoin-wizards
AbramAdelmo_ has joined #bitcoin-wizards
AbramAdelmo_ has quit [Remote host closed the connection]
AbramAdelmo has quit [Ping timeout: 258 seconds]
AbramAdelmo has joined #bitcoin-wizards
AbramAdelmo_ has joined #bitcoin-wizards
AbramAdelmo has quit [Ping timeout: 265 seconds]
AaronvanW has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
Dean_Guss has joined #bitcoin-wizards
DeanGuss has quit [Remote host closed the connection]
luke-jr has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
Guyver2 has quit [Ping timeout: 264 seconds]
AbramAdelmo_ has quit [Remote host closed the connection]
AbramAdelmo has joined #bitcoin-wizards
Guyver2__ has joined #bitcoin-wizards
AbramAdelmo_ has joined #bitcoin-wizards
DrGuschtel has quit []
Livestradamus has quit [Ping timeout: 268 seconds]
Guyver2_ has quit [Ping timeout: 264 seconds]
shush has joined #bitcoin-wizards
AbramAdelmo has quit [Ping timeout: 265 seconds]
shush has quit [Ping timeout: 248 seconds]
Livestradamus has joined #bitcoin-wizards
pinheadmz has quit [Read error: Connection reset by peer]
pinheadmz has joined #bitcoin-wizards
captjakk has quit [Ping timeout: 240 seconds]
paultroon has quit [Remote host closed the connection]
AbramAdelmo_ has quit [Remote host closed the connection]
Chris_Stewart_5 has joined #bitcoin-wizards
davispuh has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
<waxwing>
haven't really read it yet but could be relevant to some people's interests: "FastSwap: Concretely Efficient Contingent Payments for Complex Predicates" https://eprint.iacr.org/2019/1296
davispuh has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 268 seconds]
<gmaxwell>
waxwing: I believe that one is "I tell you I have the solution to a puzzle, and the hash of a hashtree transcript of a determinstic algorithim verifying that its a solution is X." I say, okay great and pay you. If I'm unhappy, I initate a challenge, which forces you to publish to the chain your solution. If I say that its verification trace doesn't pass, I challenge you to show it does.
<gmaxwell>
We've talked in here before about bonded challenge response protocols that use log() queries into an execution trace... but I think in past discussions they ran into problems where one side couldn't easily challenge if the transcript has was just uniform random value. This avoids that issue by making the inputs all public during dispute.
<gmaxwell>
(if my litterally 10 second look at the paper isn't confused)
paultroon has joined #bitcoin-wizards
<gmaxwell>
in any case, if my understanding is correct this has the substantial advantage of not requiring a heavyweight ZKP system, but the substantial disavantages of being interactive, non-private (in the dispute case), and requiring publishing the exchanged data on the blockchain.
Chris_Stewart_5 has joined #bitcoin-wizards
<gmaxwell>
(or at least parts of it)
AbramAdelmo_ has quit [Remote host closed the connection]
paultroon has quit [Ping timeout: 268 seconds]
AbramAdelmo has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
<M7918070_[m]>
I was reading about compact blocks, and it seems like mempool sync is a problem.
<M7918070_[m]>
How come? Couldn't a simple UDP network be used? Whenever a valid transaction is received, send it to all known nodes. That would cause transactions to propagate rapidly, which would in turn make it possible to send ~200 byte blocks.
<gmaxwell>
M7918070_[m]: why do you think mempool 'sync' is a problem?
<M7918070_[m]>
Each node has a list of peers it has seen online. A peer is removed from the list if it hasn't been seen in 24 hours. Whenever a transaction is received, it first checks with its local Bitcoin instance if it qualifies for inclusion in the mempool, and if so loops over the list and sends it out.
<M7918070_[m]>
Well, because you need it for compact blocks. They're 9kb at present, and that's for 1mb blocks.
<M7918070_[m]>
If all mempools were synchronized, you could get it down to almost only the header+coinbase.
<gmaxwell>
M7918070_[m]: "send transaction to all nodes" has extremely poor scaling, as it would use traffic quadtraic in the number of nodes. Unless you assume only the originator is responsible for propagating, in which case he could easily selectively slow block propagation by leaving people out.
<M7918070_[m]>
It's quadratic to the number of nodes, but each node doesn't need to know all nodes.
<gmaxwell>
M7918070_[m]: then what you're describing is already just bitcoin's transaction propagation (with the addition of UDP which doesn't particularly buy much)
<M7918070_[m]>
Besides, if a transaction averages 200 b, and you have 10000 nodes, with 3 tps, that's just 48 mbit.
<M7918070_[m]>
So how come it takes so long time?
<gmaxwell>
M7918070_[m]: how come what takes so long?
<M7918070_[m]>
Transaction and block propagation
<gmaxwell>
M7918070_[m]: The size of a compact block doesn't come from missing transactions, it comes from the computationally inexpensive method used to code the selection of transactions in a block.
<gmaxwell>
block propagation is extremely fast.
<M7918070_[m]>
It takes several seconds at the least, from what I understand. Shouldn't it be doable in <500 ms?
<gmaxwell>
It takes well under 500ms the vast majority of the time to reach the vast majority of nodes.
<M7918070_[m]>
Why does it need to be coded? Can't a single order be decided on?
<M7918070_[m]>
From what I understand, transactions are already sorted in topological order, and within that fee in sat/byte. Isn't it enough that a relay network relays the "typical" blocks fast?
<M7918070_[m]>
ah
<M7918070_[m]>
do you have stats?
<gmaxwell>
and even that exaggerates the time, because it's considering random nodes... which includes slow stuff on slow links, rather than just considering miners.
<gmaxwell>
The observed orphan rate on the network last I checked implies a hashrate weighed propagation time <200ms.
<gmaxwell>
M7918070_[m]: the sort for blocks currently is much more complicated. It is a determinstic algorithim if local prioritization is not used.
<gmaxwell>
M7918070_[m]: one thing you might not realize-- we didn't when we first started implementing faster propagation-- is that its fairly easy to end up limited by the latency of computation.
<M7918070_[m]>
How come? What more factors into the sorting algorithm, assuming no local prioritization?
<M7918070_[m]>
Of signatures or of blocks?
<gmaxwell>
M7918070_[m]: considering that the internet circumference of the earth is about that, 280 sounds fairly good. Orphaning implied latency is the hashrate weird latency between miners, while stuff like bitnodes is presumably measuring 'all' nodes.
<gmaxwell>
M7918070_[m]: Child pays for parent. The income maxizing block isn't just the one that takes the highest feerate txn, because sometimes there is a low fee parent transaction with a high fee child.
<gmaxwell>
M7918070_[m]: so the selection process uses a solver to find an approximately income maximizing.
<gmaxwell>
The current order in blocks is the order that comes out of that process.
<gmaxwell>
It's approximately topological then sorted by the feerate of the txn and all its parents, excluding all the parents which were already included. Then including a child forces including its parents right above it.
<M7918070_[m]>
And that takes a few seconds to compute?
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
<gmaxwell>
No, though some tens of milliseconds isn't uncommon.
<gmaxwell>
And depending on various assumptions that means using it is not necessarily a win.
<gmaxwell>
Say you reduce serialization delays by 2ms but increase processing by 10ms-- you lost.
<M7918070_[m]>
that's not too bad then
<M7918070_[m]>
And it can't be optimized?
<gmaxwell>
lemme take a step back. There are two main mechenisms right now used to distribute blocks in Bitcoin. Compact Blocks and Fibre. Compact blocks primary object is to minimize node bandwidth usage, secondary objective reduce propagation latency. Primary design constraint is that it needed to be simple to implement and review to avoid introducing issues.
<gmaxwell>
Fibre's objective is to minimize total propagation latency, especially across real international internet links (high RTT, 1-3% packet loss), even at the expense of implementation complexity.
<M7918070_[m]>
And both already do their job well enough, with the exception of Fibre being quasi-centralized?
<gmaxwell>
(oh also fibre has a design objective of being _consistently_ fast, even if blocks are adversarially generated)
<gmaxwell>
oh god. no.
<M7918070_[m]>
what's the problem? The propagation times are good, no?
<gmaxwell>
Fibre is not centeralized in any way shape or form. You're confusing it with matt's relay network, which is a high profile user of fiber (also the author of the implementation)
<gmaxwell>
Fibre is just a block propagation protocol like compact blocks, optimized for different objectives.
<gmaxwell>
Perhaps someday all nodes will speak fibre (or some simplified version of it) too.
<M7918070_[m]>
But they do the job well enough?
<gmaxwell>
Sure.
<M7918070_[m]>
ah
tromp_ has joined #bitcoin-wizards
<M7918070_[m]>
So then there is not any problem, at least not for 1mb blocks?
<gmaxwell>
In any case, fibre ends up doing the lions share of the long distant hauling in bitcoin... because bitcoin propagation is "fastest first" -- so whatever method is fastest will do most of the work.
<M7918070_[m]>
of course
<gmaxwell>
M7918070_[m]: you mean 2mb blocks or whatever. :) but no, there doesn't currently appear to be a problem (sadly). Orphaning rate is so low now its difficult to measure.
<M7918070_[m]>
1.7mb?
<M7918070_[m]>
>sadly not a problem
<M7918070_[m]>
haha
<gmaxwell>
Open areas for improvement though are better robustness against adversarially constructed blocks.
<gmaxwell>
Perhaps better speed over tor and satellite would also be interesting.
<gmaxwell>
M7918070_[m]: sadly because it's an interesting research area! :)
<M7918070_[m]>
Say you'd use a UDP network though, where you just send everything to all your "friends", and listen to everything that comes in regardless of source. You decide a fixed number of nodes, and then drop the slowest ones. So for all blocks or TXNs that you got from "all" your nodes, you determine when you got them and sort them.
tromp has quit [Ping timeout: 246 seconds]
<M7918070_[m]>
So you get a ranking - the first one gets 0ns latency, and then decreasing.
<gmaxwell>
Also getting something fibre-like onto all nodes, so it doesn't have an issue of needing seperate maintance efforts would be nice.
<M7918070_[m]>
So the way you get added is to simply be among the top N fastest nodes.
<M7918070_[m]>
Would this be a workable solution?
<gmaxwell>
M7918070_[m]: that kind of thing automatically geo-partitions. (or at least automatically forms networks with an extremely low min-cut, not robust)
<M7918070_[m]>
gmaxwell: So what's the speed like over Tor? If it takes N ms for "all" nodes to get the latest txns, can't it just connect to a random node and get it in N+(tor latency) ms?
<gmaxwell>
there are all sorts of things you can do that are non-robust. E.g. learn the topolgy then compute a minimum spanning tree (with latency+bw*blocksize as the cost) rooted from each miner. :P great speed, terrible robustness.
<M7918070_[m]>
gmaxwell: No it doesn't. If you're sending TXNs out the USA, then a direct link to an American node is likely to be faster than a link to another Chinese node to another Chinese to another ... to a Californian node
shush has joined #bitcoin-wizards
<M7918070_[m]>
or am I wrong? It would prioritize long-haul links I would think and end up with a hub-and-spoke topology. No need for a global knowledge though.
<gmaxwell>
M7918070_[m]: Tor has slow bandwidth too. So for example, right now exploiting predictable block ordering and using a smaller block representation is either a net loss or a close to a net loss in latency. Over tor, it's probably a win.
<M7918070_[m]>
Ah, so you'd want to have some sort of sliding scale, where on one hand you have 10 Gbit server run by big mining farm which gives zero shits about BW use, and the other one being 2007 Dell desktop in Africa, on 50 kbit internet with 1000 ms ping
<gmaxwell>
M7918070_[m]: if you connect to the fastest thing, you'll end up connected to just geographically close things, except with a tiny amount of links to further away places. If those links go down (or get DOSed) the network is partitioned (or at least a TON slower) until it heals. In any case, don't let me confuse you, there can be value to doing things like that.
<gmaxwell>
M7918070_[m]: for exaple, do you know how HighBandwidth mode for compact blocks works in Bitcoin Core?
<M7918070_[m]>
No, not the lowest latency, the lowest latency to the source.
<M7918070_[m]>
So it'll be weighted by the source.
<M7918070_[m]>
If it's 40% coming out the USA, 30% out of Germany, and 30% China, my node list will look appx like that.
<M7918070_[m]>
>do you know how HighBandwidth mode for compact blocks works in Bitcoin Core
<M7918070_[m]>
It just sends whatever it thinks could potentially be useful without asking, right?
<gmaxwell>
M7918070_[m]: Yes, sort of. Block propagation is significantlly round trip bound, so one improvement CB made over what comes before is that it can send blocks unsolicited. But this would waste a lot of bandwidth if you did it all the time (and that would also ultimately hurt latency, though keep in mind CB's primary goal is bandwidth reduction). So instead of doing it all the time,
<gmaxwell>
Bitcoin Core askes the three distict peers who most recently sent you a block you accepted to send eagerly. The rest send only a header and wait for you to ask for the block.
<gmaxwell>
So I think thats in a similar spirit to what you're discussing.
<gmaxwell>
to be clear 'most recently that you accepted' means they were the first to get the block to you.
shush has quit [Ping timeout: 245 seconds]
<M7918070_[m]>
That doesn't do anything to optimize topology, but it's in the same spirit.
<gmaxwell>
It doesn't however, change the overall network topology because we're extremely concerned with partition resistance, since the security of the network depends very strongly on being not partitioned... eeking out the last few milliseconds of latency isn't worth creating a lot of risk there.
shush has joined #bitcoin-wizards
<M7918070_[m]>
What is the risk? Won't it result in the opposite?
<gmaxwell>
People have discussed in the past adding a few extra connections which are more latency optimized... so even if they're bad for partitioning they make things no worse.
<M7918070_[m]>
If a long-haul link is faster than many short local connections, then it works better, no?
davispuh has quit [Quit: No Ping reply in 180 seconds.]
justMaD has joined #bitcoin-wizards
<M7918070_[m]>
as in, is stable and not fragile
davispuh has joined #bitcoin-wizards
<M7918070_[m]>
And since long-haul is just dumb pipe, while many short connections has the receive-deserialize-verify-send overhead, that should be the case.
<gmaxwell>
M7918070_[m]: the existing network has an extremely high min-cut. It's difficult to partition by turning off nodes or networks or DOS attacking things. If you make the topology optimized for latency, you'll end up with lots of links through the fastest places, few links elsewhere. The fastest places go down or get dos attacked-- and the network is more likely to end up partitioned.
<gmaxwell>
M7918070_[m]: oh also you've a couple times make a statement which isn't entirely correct.
<M7918070_[m]>
What is the fastest place though? It's a matter of latency, not bandwidth, so any VPS close to a major IX should cut it.
<gmaxwell>
M7918070_[m]: a path with lots of medium haul hops can be faster than a single long haul hop, even when they span the same total distance.
<M7918070_[m]>
How come? I mean sure it can, but wouldn't the direct connection in the general case be faster?
shush has quit [Remote host closed the connection]
<gmaxwell>
the reason for this is retransmissions. international long haul links have a couple percent packet loss, you'll wait a RTT (at least) for a retransmission. a path with a bunch of short hops can do retransmissions much faster.
shush has joined #bitcoin-wizards
<M7918070_[m]>
But that's assuming you don't do the massive replication thing.
<M7918070_[m]>
If you have 5% packet loss and 100 nodes that eagerly send the packet, the long-haul links should win out.
TheoStorm has joined #bitcoin-wizards
TheoStorm has quit [Remote host closed the connection]
<gmaxwell>
M7918070_[m]: [aside, as far as VPSes go, actually a lot of them have pretty poor latency, due to contention on the hardware. At some point matt moved his relay network onto dedicateds because it was a big latency improvement.]
<M7918070_[m]>
that's true
<M7918070_[m]>
but you can get dedicated servers for not too much money
<gmaxwell>
M7918070_[m]: if you're sending 100x overhead, you're going to lose for latency too. when you're talking about miliseconds the bandwidth matters too.
<M7918070_[m]>
so, cheap dedis then
<M7918070_[m]>
would you? If you have gigabit internet?
<gmaxwell>
Do you know how fibre works? I feel kinda like you're eventually going to reinvent it. :P
<M7918070_[m]>
Fibre works by having some designated servers who trust one another and having them send among one another, and then send out to "subscribers"
<gmaxwell>
NO
<gmaxwell>
fuck god I hate life
<M7918070_[m]>
oh
<M7918070_[m]>
I should read up more on it
<gmaxwell>
sorry, just the disinformation on this stuff is so extremely bad it hurts.
<M7918070_[m]>
I am probably just poorly informed. So how does it work?
<gmaxwell>
Yep. :)
<gmaxwell>
Block comes in, and the node uses an error correcting code to start generating 'correction' packets for the block and round robbing them to their fibre speaking peers via UDP at a rate configured for each peer. Never sends the same packet twice. Once any peer has enough data, it recovers the block.
<gmaxwell>
'Enough data' = if the peer knows no transactions at all, it just needs to get a total amount of packets equal to the size of the block.
<M7918070_[m]>
Ah, that's a smart move. But that only works for a trusted relay network, yes?
<gmaxwell>
Nothing about this is trusted.
<M7918070_[m]>
Aren't the servers "inside" the relay network trusted?
<gmaxwell>
No. Hold up. I'm not done.
<M7918070_[m]>
like, not "you don't need any signature verification" trusted, but "I won't DoS you" trusted
<gmaxwell>
Part of what it sends looks like a compact block (also with erasure coding), so it can use its mempool to fill in... so usually, it only needs data equal to the size of the CB plus the size of whatever transactions weren't known to the reciever. (though the sender doesn't know in advance which ones won't be known).
<M7918070_[m]>
OK - latency on Tor is a bit bad, so there might be a problem with the ordering of the messages.
<gmaxwell>
M7918070_[m]: nothing I described so far usuaes any kind of trust at all. If someone sends you bad blocks you can just ban them, like any other peer.
<gmaxwell>
s/usuaes/uses/.
<M7918070_[m]>
I mean the 6 FIBRE nodes. They trust each other, right?
<gmaxwell>
there arent "the 6 fibre nodes", you're confusing matt's public realy network with the fibre protocol.
<M7918070_[m]>
Yeah, but doesn't every FIBRE relay network need such trusted nodes?
<gmaxwell>
There are hundreds of nodes running fibre, at least.
<gmaxwell>
No. Go look at the protocol I described so far-- what about it involves any kind of trust?
<M7918070_[m]>
How do you verify the ECC data isn't just random garbage?
<M7918070_[m]>
Before broadcasting it further on
<M7918070_[m]>
or I suppose you wait until you ahve the full block, but that's not ideal either
<M7918070_[m]>
s/ahve/have/
<gmaxwell>
M7918070_[m]: you don't, but eventually you recieve enough, and if the block doesn't decode you ban the peer. Just like "how do you know a compact block a peer sent you isn't garbage".
<gmaxwell>
BINGO!
<gmaxwell>
SO, matt's implelementation has a setting, which you can set on a per peer basis, that will forward on before reconstructing and also combine packets from multiple sources. and _that_ optimization is DOS vulnerable.
<gmaxwell>
but it's also not responsible for much speedup if you were already assuming that you're just directly broadcasting to everyone. :)
<M7918070_[m]>
right, that makes sense, but if you don't get it from multiple peers, it's indeed safe
<M7918070_[m]>
thank you for the explanation
<gmaxwell>
But the big optimization in fibre is the zero round trip, no vulnerablity to packet loss, get only as much data as you're missing part.
<gmaxwell>
The transitive realy is nice too, but only works safely between your own hosts. One could imagine some kind of reputation thing where you'll conditionally be willing to grant status like that to your best peers or something and take it away if they start misbehaving.
<M7918070_[m]>
Isn't eagerly sending compact blocks also zero round trip?
<gmaxwell>
M7918070_[m]: only if there is zero missing data, fibre is unconditionally zero round trip it even works across one-way links (like satellite broadcast). So step back and think about why we care about minimizing block propagation latency:
<gmaxwell>
We care about getting latency as low as possible because latency breaks the progress freeness of bitcoin mining: latency makes larger miners get disproportionally large rewards at the expense of smaller ones, creating a centeralization pressure.
wullon has joined #bitcoin-wizards
<M7918070_[m]>
Can't it be fixed by first sending a header, like "there are this many ECC blocks, these are the hashes"
davispuh has joined #bitcoin-wizards
<M7918070_[m]>
If you get multiple copies, eagerly sending is safe for packet loss. Say for instance, each node has a number N, as in "send eagerly to me with p 1/N and otherwise just a inv vector". N can be chosen so p_zeroroundtrip for a given packet loss and node count is, say, 0.95.
<gmaxwell>
Which means that if a large miner could make their blocks slower to propagate, it would be in their interest to do so. So fibre minimizes latency even if miners aren't playing nice. (technically the objective of a miner is to get their block to 30% of the hashrate as fast as possible)
<M7918070_[m]>
Well, selfish mining doesn't happen too often, although it's in their best interest.
<M7918070_[m]>
Unfortunately, I must leave. It's been an interesting chat and I should look into the matter more.
<gmaxwell>
M7918070_[m]: selfish mining has a very complicated pay out. it delays your income for weeks/months. which can be a loss if you assume hashrate will increase in the future (which it mostly have). very risky at a minimum. Latency resulting in mining centeralization is a real thing which we observed at massive scale, and before relay network was deployed resulted in >50% hashpower ending up on a
<gmaxwell>
single pool.
<gmaxwell>
in any case, if you don't care about mining incenties there is little reason to care about blocks taking 200ms to propagate vs 2 seconds.
<gmaxwell>
incentives*
<gmaxwell>
M7918070_[m]: unfortunately, forward error correction for "long messages" that can handle corrupted parts is extremely cpu expensive. This gets in the way of combining multiple untrusted sources.
<gmaxwell>
First sending a message with all the packet hashes would be pretty bad for latency. You could instead have each source sign each packet... allowing you to blacklist bad sources.
<gmaxwell>
or you could have a hashtree over the packets, and each packet provides its membership proof, allowing you to combine sources that agree on the hash.
<gmaxwell>
downside of this is that it would require constructing all packets in advance and not incrementally.
<gmaxwell>
The FEC used in Fibre is also a fountain code. There is (theoretically) an unlimited number of packets.
<gmaxwell>
At a minimum you do want there to be many more packets than there are in the block, so you can achieve non-duplication.
<gmaxwell>
E.g. say I send packet X to Alice, I never want to send that same packet to anyone else, because alice is capable of forwarding it on... and if someone gets two copies of X they just wasted their bandwidth.
<gmaxwell>
So I send X to alice, Y to bob. Then each send each other these packets. And if two packets were required for reconstruction, we're done.
<gmaxwell>
What the fibre protocol does, more concretely is that it streams a stream of unique packets to each peer, and stops when the peer sends a message that says enough (or when a hardcoded sanity limit is reached, so it doesn't send forever to a peer thats offline or on a one way link).
<gmaxwell>
in any case, the fact that the packets are non-duplicative is extremely useful if the peers will be relaying incomplete data (and combining reconstruction from multiple sources).
<gmaxwell>
but that gets in the way of "send a hash of the packets first".
<gmaxwell>
Not impossible to work around, but I'm less confident that it's possible to work around without adding so much cpu time that you might as well just skip the whole "relay before you're finished", since that optimization doesn't save _that_ much.
<gmaxwell>
like if your network diameter is three hops (to reach miners, pretty realistic)... and reconstructing before forwarding at each hop adds an extra 10ms. ... then if precoputing and hashing the correction data (and sending the hashes) costs more than 30ms it'll be a loss.
<gmaxwell>
Another, I think simpler alternative, would be to do just don't bother with the relay-before reconstructing, but do combine data from multiple sources. And if you have a reconstruction failure, stop combining sources, figure out the bad source, and ban them.
davispuh has joined #bitcoin-wizards
<gmaxwell>
_usually_ in bitcoin the whole thing gets reconstructed after just a couple packets. So relay-before reconstructing hardly saves there. Though in the worst cast (when the txn in the block are mostly unknown) its quite helpful.
<gmaxwell>
M7918070_[m]: thanks for the chat.
<gmaxwell>
Some relevant things to check out: https://en.bitcoin.it/w/index.php?title=User:Gmaxwell/block_network_coding this is a number of ideas related to faster block propagation from 2013/early 2014 mostly. When we tried to implement the ideas from it, we learned that in practice no scheme that takes a lot of CPU time can be a winner for latency reduction purposes... because the latency that can be
<gmaxwell>
saved by complex schemes over fairly simple ones with low cpu costs isn't that gigantic.
<gmaxwell>
are high level design writeups which ultimately inspired fibre and compact blocks (respectively), from Dec 2015.
<gmaxwell>
they're not the best sources for fibre or compact blocks themselves... since there are differences in the real protocols (including some nice improvements), but BOTH have appendexes with suggested "next steps" which you might find interesting.
<gmaxwell>
in particular, re, hashes of correction packets:
<gmaxwell>
(4) if the miner generates the FEC coded data for the block
<gmaxwell>
and includes a hash tree commitment, then the coded data could
<gmaxwell>
data to decode it is received). This would avoid serializing
<gmaxwell>
the receipt and decode across multiple nodes, so the whole
<gmaxwell>
be passed through before being decoded (or even before enough
<gmaxwell>
network could decode in roughly the time it took to get the
<gmaxwell>
first couple peers.
<gmaxwell>
--
<gmaxwell>
Or if crazyier ideas that are less likely to pan out in practice, along the lines of that en.bitcoin.it link, strike your fancy, https://people.xiph.org/~greg/cuckoo_transaction_order.txt is a more recent (year old) one in that spirit.
<gmaxwell>
(though it's more centerered on minimum bandwidth instead of minimum latency)
<gmaxwell>
I have a prototype implementation of efficient.block.xfer.txt appendix (2) that achieves an average of about 800 bytes a block in bitcoin (or, well, did a year ago when I tried it), using minisketch and sending a edit list for the block order vs a locally generated one. But its cpu-speed is also too slow to make it interesting for latency reduction, it would probably only be interesting for
<gmaxwell>
radio/sat transmission of blocks.
<gmaxwell>
(er, actually, to be clear it achieves an average of 800 bytes a block for the ~99% or whatever of blocks that had no missing txn)
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
marcoagner has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 265 seconds]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
ddustin has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 258 seconds]
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 245 seconds]
justMaD has quit []
<M7918070_[m]>
I still don't understand why adversarial miners are a problem though. If they want for their blocks to relay slower, can't they just wait N seconds?
<gmaxwell>
M7918070_[m]: they want it to be slower but not for everyone. They want to reach ~1/3rd of the hashrate as fast as possible, and everyone else as slow as possible.
<M7918070_[m]>
I don't see the difference between adversarially constructing a block that doesn't relay well, and just waiting 10 seconds before you relay it.
<M7918070_[m]>
Well, won't adversarially consructed blocks have trouble reaching them too?
<gmaxwell>
no, -- for example, if the block is just big, it'll propagate relatively quickly to hosts near you with low rtt high bandwidth links, and slower further away.
<gmaxwell>
main motivator in fibre's design is mitigating that effect.
<M7918070_[m]>
And is this 33% thing a different attack from selfish mining? I remember it vaguely. What was the solution they proposed again? Was it the one where they said you should need the private key for PoW?
<gmaxwell>
it's motivated for similar reasons, but no it's not the same as selfish mining.
<gmaxwell>
Their paper's 'fix' was just utterly broken, it recommended changing tie breaking to pick later blocks if they had lower hashes.
<M7918070_[m]>
I don't see how that helps
<gmaxwell>
which actually makes selfish mining phenominally more reliable though it caps the benefit, it also opens other attacks.
<M7918070_[m]>
You'll just get lots of reorgs
<gmaxwell>
M7918070_[m]: the idea is that the selfish miner delays their block as long as possible, and only announces it the instant they see someone else starting to announce. by randomizing you make it so their ability to win that race is capped.
<M7918070_[m]>
Randomizing what? Which block wins?
<gmaxwell>
which block you follow in the event of a tie.
<gmaxwell>
(tie being multiple blocks at the same height)
<M7918070_[m]>
that doesn't seem very robust, does it?
<gmaxwell>
no, it's stupid. (in particular, it creates an enormous selfish mining incentive.. if your block hash is unusually low you should always delay your block announcement)
<gmaxwell>
it's only a worthwhile suggestion against the very narrow attack pattern considered in that paper.
<M7918070_[m]>
Don't you already have some big selfish mining incentives? I was thinking about this the other day
subdriven1 has joined #bitcoin-wizards
<M7918070_[m]>
Say you mine a block, but it gets orphaned. Isn't it in your best interests to double down, and optionally recruit extra hashpower via e.g. nicehash?
<gmaxwell>
No, not really. The selfish mining style attack pattern has really bad payoff properties.
<gmaxwell>
M7918070_[m]: nicehash is like 1% of the network hashrate or something, not really a concern. :P
<gmaxwell>
but yes, there are bad incentives if you can get enough hashrate to conspire.
<M7918070_[m]>
Well, not nicehash. But in general.
<gmaxwell>
particularly with low subsidy and if there isn't a backlog of transaction fees.
<M7918070_[m]>
How come there isn't more nicehash-style mining pools anyway? Altruism?
<M7918070_[m]>
If the fees are low enough, it seems like it would be strictly more profitable, which is crucial in a low-margin business.
<gmaxwell>
More like real world economics. Lets say you setup a thing like that, do you (1) behave honestly and get nitpicked down to the lowest possible fees by the set of miners that are trying to maximize income, or (2) pretend to be very low fees but randomly defraud your customers, after all your service has really little reason to exist except enabling various kinds of fraud in any case.
<gmaxwell>
(2) is pretty attractive. As a miner you can't distinguish (1) and (2). So do you want to risk larger losses for the sake of maybe making 0.5% more or whatever? waste of time. :)
<Alanius>
These bad incentives (i.e., by engaging in selfish mining, you can earn in expectation more than your proportion of hash power) ... why are they bad?
<M7918070_[m]>
How can't you distinguish 2?
<M7918070_[m]>
If the pool signs receipt of shares, then you immediately know something's wrong if you don't get the signature.
<gmaxwell>
Alanius: because they are centeralization pressures, also most of them result in network instability so if used users can't count on a few confirmations to mean much.
<M7918070_[m]>
And if you have signatures, fraud proofs seem trivial.
<Alanius>
got it, thanks
<M7918070_[m]>
Like, how could a NH-style system screw someone over, if they're running a simple PPS pay-in-advance system?
<gmaxwell>
M7918070_[m]: "sorry, we didn't find any blocks this week, bad luck" In theory you could imagine some enormously complex auditing mechenism that could avoid some issues, but all is realy hard. For example, one way a pool can defraud miners is to just discard real solutions, in order to increase the profitability of their mining outside of the pool.
<M7918070_[m]>
No, not like that. You make an account, put in bitcoins, buy hashing futures, then point it to your pool.
<M7918070_[m]>
You pay the miners per submitted share
<gmaxwell>
M7918070_[m]: PPS either has very high fees or goes bankrupt, it's hard for anything to use PPS to incentivize penny chasing miners.
<gmaxwell>
Variance is a bitch.
<gmaxwell>
go plug in the math for how big your bankroll need to be for mining to have a 1% fee pps pool. It's enormous.
<M7918070_[m]>
That's the end user's problem. They pay money per share. If they want to mount an attack, they'll need a big share of the hashrate anyway.
<M7918070_[m]>
If they're just buying hashrate to fund their pool, they can pay their miners on a PPS basis and point it to a pool which pays by some other scheme.
<gmaxwell>
historically most PPS things have just robbed users in one way or another. (for example, being 101% PPS but pocketing all txn fees, during times when tx fees were 25% of the income.)
<M7918070_[m]>
That's not a problem here.
<M7918070_[m]>
Miners know in advance how much they're getting paid per share
<gmaxwell>
No, they know what they're being told they'll be paid. And even that isn't useful unless they spend a lot of effort creating non-existing auditing infrastructure.
<gmaxwell>
In practice, historically speaking, miners that do stuff like that get ripped off and go out of business.
ddustin has joined #bitcoin-wizards
<M7918070_[m]>
The coordinator could provide open-source software to do the auditing.
<gmaxwell>
'Cloudhashing' provided a thing to do that. My understanding was that no customers noticed when it stopped working.
<M7918070_[m]>
It's quite trivial: when you submit a share, you get a response, "we owe you X BTC for this share and intend to pay it to this address: 1xxxxxx with this txn: asdjhasdjasdasd"
<M7918070_[m]>
No response within 1 second? Disconnect pool. Transaction not on blockchain? Disconnect pool and broadcast fraud proof.
<gmaxwell>
Essentially the problem you have is that any _legitimate_ PPS is going to be 90% EV or worse. So by definition anything you do like this that pays an attractive rate means you are doing business with a fraudster or a moron, ... which isn't a good idea, esp if its just to make 1% more.
<gmaxwell>
And of course if they say they're going to pay 10% more or whatever that just means they are an even bigger fraudster or a bigger moron. :P
<M7918070_[m]>
Not necessarily. If you run a pool that pays on a more stable scheme but that isn't PPS, and buy PPS hashing power and point it there, won't that work?
<M7918070_[m]>
From what I understand, doing business with fraudsters is A-OK as long as it's in their rational self interest
<gmaxwell>
I agree these kinds of games are interesting to consider in theory, -- my point is just in practice frictions like dishonesty and imperfect information and indifference to small differences due to cost-of-attention mostly make them not happen.
<gmaxwell>
M7918070_[m]: the point is that if you do business with a fraudster they'll also constantly try to defraud *you*, so there is a significant operating cost. Like they give you an open source audit tool. Great, how do you know they didn't slip a bugdoor in it? Public review has pretty significant limitations.
<M7918070_[m]>
Oh, no
<M7918070_[m]>
They're not fraudsters. The people you're selling to are.
<gmaxwell>
13:32:33 < M7918070_[m]> Not necessarily. If you run a pool that pays on a more stable scheme but that isn't PPS, and buy PPS hashing power and point it there, won't
<gmaxwell>
that work?
<M7918070_[m]>
You have a nicehash-style intermediary that doesn't (necessarily) buy the hashes themselves, just sells them to other pools/miners/evil people. You trust them.
shush has joined #bitcoin-wizards
<M7918070_[m]>
You don't trust who is on the other end of that business relationship, but the middleman takes care of that.
<gmaxwell>
that was essentially piratepool's business. of course, he robbed everyone he could. (I think he's still in jail for his other ponzi scheme?)
<gmaxwell>
M7918070_[m]: thats also what nicehash is, its just a broker.
<M7918070_[m]>
Yes, NiceHash but with lower fees.
<M7918070_[m]>
5% is disastrous, but if you'd charge say 0.2% a lot of people would probably be willing to use it
<M7918070_[m]>
What's the payout like for the various types of unethical mining again?
<gmaxwell>
they used to be low, and it's been done with 'zero fee'.
<M7918070_[m]>
and it wasn't profitable?
ddustin has quit [Remote host closed the connection]
TheoStorm has joined #bitcoin-wizards
<gmaxwell>
No, because fraud and drama.
ddustin has joined #bitcoin-wizards
TheoStorm has quit [Remote host closed the connection]
<gmaxwell>
If you cheat and earn (say) 5% more, but take on bigger fraud risks that require a bunch of investment in anti-fraud (auditing, etc) then it's not necessarily a win.
<gmaxwell>
And you could instead spend your limited attention on negoiating for lower power prices or improving cooling or whatnot for better risk adjusted returns.
shush has quit [Ping timeout: 260 seconds]
<gmaxwell>
to prevent a bad incentive race to the bottom it's not neceesary to eliminate the bad incentive, only reduce it to the point where it's swamped by other frictions.
<M7918070_[m]>
It seems like a sensible broker would make the needed auditing software and then pay someone from the outside a large but not too large sum of money to audit it.
<gmaxwell>
some kinds of fraud are extraordinarly hard to audit for.
<M7918070_[m]>
Assuming it's a 5% increase, then it seems like direct selling to pools would be smarter. Find a pool, tell them to mine for you instead, they pocket the 5% increase and nobody notices.
<gmaxwell>
no attack that does anything interesting is unnoticable! :)
<M7918070_[m]>
Are the miners going to care though?
<M7918070_[m]>
As long as they get paid, there is no problem for them. They're not going to sift through the logs of which specific blocks they did, right?
<gmaxwell>
M7918070_[m]: you might have missed earlier, "or example, one way a pool can defraud miners is to just discard real solutions, in order to increase the profitability of their mining outside of the pool."
<M7918070_[m]>
With PPS that isn't a problem.
<gmaxwell>
M7918070_[m]: the cost to the mining pool is that the bad actor destroys the reputation of their pool and causes them to lose a nice revenue stream.
<gmaxwell>
M7918070_[m]: with PPS you will go bankrupt rapidly unless you're only paying a low amount 90% EV.
justanotheruser has quit [Ping timeout: 260 seconds]
<M7918070_[m]>
Are they going to care though? If they share some of the revenue, are miners going to switch out of altruism?
<gmaxwell>
I never said anything about altruism.
<M7918070_[m]>
Doesn't it depend on the scale? If you're doing a big attack, you need big hash power, and then it ought to even out.
<M7918070_[m]>
You said reputation.
<gmaxwell>
people tend to not do business with parties that rip them off.
<gmaxwell>
If you assume PPS you have to imagine some enormous highly disruptive attack that could overcome the PPS variance. OK. now your problem is that the attack would be exceptionally disruptive.
<M7918070_[m]>
Anyway, the broker could use another payout scheme as well, since it sees all the shares. It could validate whether a certain customer has "found a block" no problem.
<gmaxwell>
And it would not be rational to risk your investment in mining hardware destroying the value of the thing you're mining.
<M7918070_[m]>
Right, their implicit long positions are some factor. How come it's not more common for them to sell futures contracts?
<gmaxwell>
M7918070_[m]: why do you think it isn't?
<M7918070_[m]>
Like, "you pay me X BTC now and you'll get so-and-so many hashes the next year"
<M7918070_[m]>
If so they're not exposed to it anymore, no?
<M7918070_[m]>
or, USD more like.
<M7918070_[m]>
If so, BTC would already have gone to zero, and it would be a complete non-issue if the "value of the hardware" disappeared into thin air.
<gmaxwell>
M7918070_[m]: well several answers: (1) people do make that contract, it's called a mining hardware vendor. You give them money now and they give you a box that makes hashes. :)
<gmaxwell>
(2) general hash for money contracts are not particularly attractive to take because of the income uncertanty due to difficulty.
<M7918070_[m]>
Yeah but for the actual mining. You give them lump sum X of money, they give vendor lump sum X-epsilon of money where epsilon = opex+profit
<gmaxwell>
(3) miners do derisk their explicit (in the form of immature blocks) and implicit (in the form of hardware) long postsions, using futures markets, though I think that most aren't interested in much more than fairly short term contracts.
<gmaxwell>
bitcoin variance is very high, implied volitility on futures markets ranges between mid 60% and 120%, so futures for bitcoin are expensive.
<M7918070_[m]>
So if they are derisked, why is it a concern if BTC plummets because of their unethical hashing?
<gmaxwell>
M7918070_[m]: they derisk somewhat-- like against daily/weekly volitility or e.g. buying puts cover their power cost against future mining at low prices, it's very expensive to derisk longer term.
<M7918070_[m]>
hmm
<M7918070_[m]>
in other words, you could force miners into caring about the long-term health of the ecosystem by setting the coin maturation time to something ludicrously high via softfork?
<M7918070_[m]>
turning the system into a weird mix of proof-of-work and proof-of-stake?
<M7918070_[m]>
(I'm not suggesting you do it, but as a thought experiment)
<gmaxwell>
I don't think so, I think too long maturation just gets turned into options sales.
<M7918070_[m]>
If they get their coins after a year, for instance
<gmaxwell>
I mean, it would have an effect but you get diminishing returns.
<gmaxwell>
M7918070_[m]: certantly increasing maturity time has seemed attractive in discussions before.
<M7918070_[m]>
uh, BitMEX futures are in contango
<M7918070_[m]>
for XBTM20 (June 26), 2% premium
<gmaxwell>
I don't think much of bitmex futures prices, as bitmex is a bucket shop-- trade on huge margin without the underlying. :)
<gmaxwell>
if you go look at long dated OTM calls on ledgerx, you can see they have a premium, clearly people think there is a risk that the price will increase substantially post halving.
<M7918070_[m]>
bitmex is the most liquid market
<M7918070_[m]>
and also most trusted
<M7918070_[m]>
and oldest
<gmaxwell>
it's easy to be 'liquid' when they don't have the underlying.
<M7918070_[m]>
BitMEX has a good supply of BTC, which is the underlying
<gmaxwell>
Their contracts aren't backed by equal value of the underlying but only by a small percent of it.
<M7918070_[m]>
calls are a different thing entirely
<M7918070_[m]>
Well, sure, but they get liquidated if it falls below. It's a solid system.
<M7918070_[m]>
And the avg margin is not that bad
<gmaxwell>
it's essentially the same system as bitcoinica...
<gmaxwell>
calls are a different thing entirely-- no, not so. a long future position is a long call short put at an identical price. (ignoring american-style-ness effects)
<M7918070_[m]>
as you can see, median leverage is only about 13x
<M7918070_[m]>
well, is it? Bitcoinica was CFD, so an actual bucketshop I would think
<M7918070_[m]>
or do I miss something?
<M7918070_[m]>
no options are generally weird. A LEPO option is the only thing you could possibly want to compare, where the strike price is zero
<M7918070_[m]>
for derisking, options are not very useful. You pay a premium to lose the downside, whereas with futures you lose all volatility and get paid in advance. It's clearly a much better deal with contango.
<gmaxwell>
0_o
<M7918070_[m]>
That is, if you sell a BTC futures contract now, you get about 2% more than if you sell BTC now.
<M7918070_[m]>
If you have BTC, it's more profitable to sell a futures contract and let it sit there doing NOTHING until it goes to settlement
<gmaxwell>
yes, but do nothing isn't your alternative.. having the ability to sell at an even higher price is. :)
<M7918070_[m]>
sure, but it implies an utterly out-of-whack market
<M7918070_[m]>
it implies people are willing to pay more for bitcoins in half a year than they are now
<M7918070_[m]>
That said, BitMEX is a bit odd
<M7918070_[m]>
because it doesn't handle fiat
<M7918070_[m]>
so it has a desperate need for USD and is willing to pay a premium for them
<gmaxwell>
14:04:49 < gmaxwell> I don't think much of bitmex futures prices,
<M7918070_[m]>
you can get like 10% APR lending USD to them
<gmaxwell>
also wrt the premium prices on futures out 6+ months from now, I believe it's due to the halving.
<gmaxwell>
as that showed up in long dated calls on ledgerx for post halving dates.
kenshi84_ has quit [Ping timeout: 245 seconds]
<M7918070_[m]>
Deribit has the same though
<M7918070_[m]>
yeah but how can it be expected to rise in the halving? Shouldn't all that be priced in
<M7918070_[m]>
I refuse to believe the market could be inefficient
<gmaxwell>
as far as the 10% APR: what you're getting 10% APR for is exposing yourself to losing everything if the site goes down or is hacked.
<gmaxwell>
M7918070_[m]: dunno, belief matters too? In a total vacuum without considering people's opinions the price of bitcoin cannot be defined.
<M7918070_[m]>
I'd trust BitMEX more than 90% of exchanges. No history of scams, everything in cold storage, probably not illegal, no kyc, etc etc
<M7918070_[m]>
yeah but the belief should already be priced in. "market thinks btc will go up after halving" -> market buys btc after halving and sells after -> price rises now
<gmaxwell>
you don't need to explain that to me. :) I'm aware-- thus the dunno. There are a lot of frictions though that prevent real markets from becoming efficient.
<gmaxwell>
I've certantly avoided plenty of trades because of counterparty risks, for example.
<M7918070_[m]>
it's odd, since there should be a lot less frictions for btc than for say stocks
<M7918070_[m]>
no kyc or such
<M7918070_[m]>
What about stablecoins traded on DEXes? Or are all the stablecoins and DEXes so incompetently designed it's no good?
<gmaxwell>
For example, S2X futures on bitfinex were at one point selling for ~0.3 BTC. Basically 1/3rd bitcoin for free, you just had to be willing to expose your funds to bitfinex.
<gmaxwell>
M7918070_[m]: I've never heard a design of one of those that really had a fighting chance of not going insolvent at just the wrong time ... a real concern when faced with assets that hit >>100% annualized volatility.
<M7918070_[m]>
cross-chain atomic swaps?
<M7918070_[m]>
or for stablecoins?
<gmaxwell>
a real stable coin has counterparty risk. cross chain swaps are defeated by the assets being really highly correlated so there isn't much of a trade to make
<M7918070_[m]>
Not necessarily. Surely you could make a stablecoin without counterparty risk?
<gmaxwell>
These are all frictions that make it harder for a market to reach equlibrium.
Guyver2__ has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<gmaxwell>
M7918070_[m]: if you're a centeral bank, perhaps. :) but otherwise, thats not clear.
<gmaxwell>
tether's funds were seized by governments. (this is not to say that I believe it was competently managed, but even if was they probably would have ended up with their funds seized regardless)
<M7918070_[m]>
No, trustless. As long as you solve the oracle problem, it should be trivial. Just imitate BitMex' perp contracts with an on-chain order book.
* gmaxwell
eyeroll
<gmaxwell>
I think you've been smoking too much blockchain.
<M7918070_[m]>
No, say you have a cryptocurrency. You have some kind of token which is fixed in supply and fluctuates wildly. You use this as margin for perpetual contracts, just like BitMEX.
<gmaxwell>
Say the cryptocurrency price drops to $1. How do you pay off the zillion dollars in fakeUSD? At some point, the assets just aren't there for it. If you require super capitalization then you have to assume people are willing to just sit on huge locked up coin exposures, ... which is not a very compatible assumption with assuming people are going to want a lot of the fakeusd tokens long term.
<M7918070_[m]>
You do it slowly. If you cap the funding rate to 1% per day and allow for no leverage, it should be stable enough.
<M7918070_[m]>
That's like asking, what would BitMEX do if the cryptocurrency price dropped to $1.
<gmaxwell>
They'd go insolvent and eat all their depositors funds.
<gmaxwell>
Which is exactly why people are getting 10% depositing funds for nothing.
<M7918070_[m]>
No, I don't think that's how it works.
<M7918070_[m]>
If you deposit $100 bitcoins and immediately short it, you should stand to receive a zillion bitcoins if that happened. So what happens is the longs go insolvent.
<M7918070_[m]>
Like, they get margin called but there's not sufficient bitcoins to find anywhere to fill their position
<gmaxwell>
It's absolutely how it works. Their margin calls only save them from losses if they can execute in a timely manner. If the market is too disjoint and imbalanced they'll implode.
<M7918070_[m]>
As in, they owe a zillion bitcoins, but there are only 21 million of them
<gmaxwell>
or only 40,000 in their actual possession...
<M7918070_[m]>
Right, but on the part of the margin callees
<M7918070_[m]>
If it crashes further, then the shorts will be ADL'd
<M7918070_[m]>
for excess profit
<M7918070_[m]>
ah, so that's how it works
<gmaxwell>
earlier you suggested you believed markets should be efficient, so you should be taking bitmexes 10% deposit interest rates as a first approximation of the public's estimate that they'll gobble the funds all up. :)
<M7918070_[m]>
right, the shorts can't make infinity profit because there isn't enough supply for the longs to actually pay their margin calls. So unless they want to double down and fund it, the shorts will just drain all the margin from the open interest, and then get ADL'd
<gmaxwell>
(or at least the difference between 10% and overnight bank interest rates, :P )
<M7918070_[m]>
risk-free rate is 2%, so that means the general public puts the risk of them collapsing at 8%?
<gmaxwell>
I'm sure that people's beliefs have some weird distribution over time that make it hard to just convert it to an odds number.
<gmaxwell>
good luck getting 2% risk free on an investment which is perfectly liquid and had no interest rate risk! :P
<gmaxwell>
actually ignore that, 2% is only a little high.
<M7918070_[m]>
No, 8% collapse within the year
<gmaxwell>
right now money market funds are floating at about 1.6% at the moment, I'm used to looking at post-tax numbers.
<gmaxwell>
M7918070_[m]: I was squibbling over your risk free rate, I withdrew my squibble. :P
<M7918070_[m]>
SOFR is at 2.1% or so
<M7918070_[m]>
I don't think BitMEX users pay tax
kenshi84 has joined #bitcoin-wizards
<gmaxwell>
perhaps not, but most bitmex users don't have access to SOFR either. :P
Kiminuo has quit [Ping timeout: 260 seconds]
<M7918070_[m]>
I'm no expert here, but if the funding goes up and down constantly, then that's like leveraged gambling: if you reported each funding to the tax authorities, you'd end up deep in the hole
<M7918070_[m]>
like people who daytrade cryptos and come out with a "20%" return, but end up owing several million to the IRS
<M7918070_[m]>
1.6% interest just makes it worse. Then that means it's at 8.4% collapse within the coming year
<gmaxwell>
those people are either actually losing money overall and fooling themselves or are not correctly acconting for their losses.
ddustin has quit [Remote host closed the connection]
<M7918070_[m]>
well, or getting lucky
ddustin has joined #bitcoin-wizards
<gmaxwell>
ure but if they got lucky they can pay the IRS their 28% pound of flesh. :P
<M7918070_[m]>
not necessarily
<gmaxwell>
there are ways to screw yourself, like turning a huge win into a paper win with another position and taking a huge loss and not realizing it until the next year.
<M7918070_[m]>
what happens is something like this: they put in $100, buy shitcoin A, it goes up to $5000, they sell it and buy shitcoin B, it goes down to $100, they cut losses. They made a $4000 profit, on which they have to pay $1250 tax, and then invested $4000 at 145% leverage and made a 98% loss
<M7918070_[m]>
yes, but that's just mental accounting gone wrong. Here they end up doing extremely high-risk investing by investing money they owe the IRS
kenshi84_ has joined #bitcoin-wizards
<gmaxwell>
M7918070_[m]: assuming they don't split tax years, that loss will offset their profits.
kenshi84 has quit [Ping timeout: 248 seconds]
<M7918070_[m]>
*they put in $5k at 180% leverage
ddustin has quit [Ping timeout: 265 seconds]
<M7918070_[m]>
yes, but often they do. Like, the canonical case I suppose is that you buy bitcoin, then a shitcoin, and never declare anything. If the losses are in different years, you're screwed
<gmaxwell>
Yep. Indeed thats a thing, really just trading with money you owe for taxes is stupid.
<gmaxwell>
I stick the funds I own for taxes in some boring money market fund and don't worry about it after that point.
<M7918070_[m]>
That might be one thing, but if you're just trading on some random exchange that doesn't even do KYC? It's easy to see why you can end up quite deep in the hole
<gmaxwell>
fun fact: you can pay US income tax with a cash back credit card... the processor charges 1.87%, but you can get a 3% card...
<M7918070_[m]>
NSTAAFL
<gmaxwell>
no, it's true. but sometimes someone else is buying the lunch.
<gmaxwell>
besides hasn't our entire conversation been about picking up pennies in front of a steamroller? :P
<M7918070_[m]>
sure
TheoStorm has joined #bitcoin-wizards
<phantomcircuit>
gmaxwell, 2% is quite high, there's various online "banks" offering more but they're generally not as risk free as they imply
pinheadmz has quit [Quit: pinheadmz]
<M7918070_[m]>
no, that's the SOFR
<M7918070_[m]>
it replaces the LIBOR, and is usually used in derivatives contracts etc
<M7918070_[m]>
What I'm curious about is what's the most robust stablecoin that could conceivably be created. You could create one that's safe if the underlying doesn't fall more then 90%, for instance, by requiring longs to have ludicrous amounts of margin while still making shorts pleasant and safe.