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
frankenmint has quit [Remote host closed the connection]
JHistone has quit [Quit: Leaving]
dnaleor has quit [Quit: Leaving]
dnaleor has joined #bitcoin-wizards
buZz has quit [Read error: Connection reset by peer]
buZz has joined #bitcoin-wizards
buZz is now known as Guest96086
Guest96086 has quit [Read error: Connection reset by peer]
buZz_ has joined #bitcoin-wizards
buZz_ is now known as buZz
rdponticelli has quit [Ping timeout: 258 seconds]
AEM- is now known as aem
frankenmint has joined #bitcoin-wizards
dEBRUYNE has quit [Quit: Leaving]
toffoo has joined #bitcoin-wizards
Noldorin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
toffoo has quit []
terrapin has joined #bitcoin-wizards
bsm1175321 has quit [Remote host closed the connection]
bsm1175321 has joined #bitcoin-wizards
digitalmagus8 has joined #bitcoin-wizards
blackwraith has quit [Read error: Connection reset by peer]
blackwraith has joined #bitcoin-wizards
chjj has quit [Ping timeout: 258 seconds]
Ylbam has quit [Quit: Connection closed for inactivity]
edvorg has quit [Ping timeout: 258 seconds]
blackwraith has quit [Ping timeout: 260 seconds]
Emcy has quit [Ping timeout: 276 seconds]
Aranjedeath has quit [Quit: Three sheets to the wind]
chjj has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
<bramc>
Hey everybody
<bramc>
The discussion in list is productive, but unfortunately it's cut into my coding time :-/
<bramc>
It's been worth it just to find out that blake2 is 5 times as fast as sha256 though. Anybody know what the block and padding sizes for blake2 are?
ClockCat has quit [Quit: Leaving]
pro has quit [Quit: Leaving]
<nicolag>
has it been proven that byzantine fault tolerant protocols must have 3 phases? (/cc amiller)
<amiller>
it might depend on the setting, especially synchronous, asyncronous, or osmeting else, and what tolerance
<amiller>
and whether you mean in the worst case or in an optimistic case
PERSIAN has quit [Quit: PERSIAN]
<amiller>
nicolag,
<amiller>
i'm curious if you had something specific in mind!
<amiller>
also: hi nicola!
<nicolag>
hello amiller, I am on my way reading your honey badger paper
<nicolag>
and I took a step back re-reading the pbft
<nicolag>
and I have been watching Barbara Liskov presenting in 2001
<zooko>
BLAKE2b has 128-byte blocks, BLAKE2s has 64-byte blocks
<zooko>
padding is "minimal", i.e. optimized out when possible
<zooko>
What mailing list discussion?
<nicolag>
also amiller I have a set of questions that I will ask once I am done
<nicolag>
(i might answer them and ask you if my thinking is correct)
<bramc>
zooko: on bitcoin-dev
<amiller>
nicolag, sure
Giszmo has quit [Quit: Leaving.]
<zooko>
bramc: are the things you want to hash small things like the outputs from lower-level hashes in a tree, or large things like kilobytes worth of data? Or both?
<bramc>
I don't really need to look at benchmarks to know I should switch to blake2. It beats sha256 in a blowout.
<zooko>
Right.
<bramc>
What is the significance of blake2b and blake2s?
<zooko>
b is the 64-bit-optimized version, with 128-byte blocks, and s is the 32-bit-optimized version, with 64-byte blocks.
<bramc>
My API should probably stick with sha256 for the things passed in, because it accepts them either hashed or unhashed and the external hashing function is much more likely to be sha256
<bramc>
Ah. My understanding is that 32-bit machines are dying out.
<zooko>
Yeah, I was surprised to see 64-bit quickly spread in cell phones
<zooko>
32-bit is probably continuing to be super-important in embedded (IoT) and so on.
<zooko>
But if your inputs can fit into 64-bytes then BLAKE2s might be a little more efficient even on 64-bit CPUs.
<zooko>
Or maybe not. Probably ought to try both and measure.
<bramc>
I doubt there are going to be many 32-bit machines running this so I'm going to optimize for the common case and do blake2.
<bramc>
Also I don't expect to see many 128-bit machines ever.
* zooko
nods
<zooko>
BLAKE2b is a fine choice.
<gmaxwell>
the other fun though is that sha2 looks like it will be considerably faster once silicon support for it ships.
<gmaxwell>
So you end up with the aes vs chacha support, where aes is much faster/more power efficient with hardware support, and much worse without.
<bramc>
gmaxwell: grumble grumble. blake2b is probably down in 'cache misses are just as much of a problem' territory, so the boost from hardware acceleration might not matter all that much.
<bramc>
I like how we went through all that time and effort to select sha3 and now we're debating sha256 vs. blake.
<zooko>
;-)
<zooko>
SHA3 could also be super-fast someday, if added into hardware.
<bramc>
Everything is fast if you accelerate it in hardware.
<zooko>
The SHA3 contest was a great success. It produced not only SHA3, but also produced the realization that making secure hash functions is relatively easy nowadays, and in fact SHA256 apparently already was one.
CrazyTruthYakDDS has quit [Quit: Connection closed for inactivity]
<Taek>
blake2 also doesn't suffer from length extension attacks
<zooko>
True.
<zooko>
My observation in choosing between SHA256 and BLAKE2 in Zcash is that dumb engineering bits that like make a big difference.
<gmaxwell>
bramc: fwiw, sha2 is siginificant in profiles of bitcoin core, enough that there is work underway to use sse4 sha256, and use parallel sha256 in the tree hashing.
<gmaxwell>
it wasn't until we made everything else fast, however.
<bramc>
gmaxwell: Adding utxo commitments would quite a bit of hashing overhead
<bramc>
would add I mean
<gmaxwell>
(in particular the impact on block connection is non-trivial... as signatures are cached and such)
AusteritySucks has quit [Ping timeout: 252 seconds]
AusteritySucks has joined #bitcoin-wizards
roman_ has joined #bitcoin-wizards
digitalmagus8 has quit [Read error: Connection reset by peer]
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
digitalmagus2 has joined #bitcoin-wizards
nonaTure has joined #bitcoin-wizards
Jeremy_Rand_2 has joined #bitcoin-wizards
Jeremy_Rand_2 has quit [Client Quit]
bramc has quit [Quit: Page closed]
ThomasV has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 250 seconds]
nonaTure has quit [Ping timeout: 240 seconds]
nonaTure has joined #bitcoin-wizards
hashtag_ has quit [Ping timeout: 244 seconds]
slackircbridge1 has quit [Remote host closed the connection]
slackircbridge has joined #bitcoin-wizards
Ylbam has joined #bitcoin-wizards
skang404 has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
Tiraspol has quit [Ping timeout: 252 seconds]
Tiraspol has joined #bitcoin-wizards
Tiraspol has quit [Ping timeout: 252 seconds]
Tiraspol has joined #bitcoin-wizards
Guyver2 has quit [Quit: :)]
Emcy has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
ManfredMacx has joined #bitcoin-wizards
frankenmint has quit [Remote host closed the connection]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
frankenmint has joined #bitcoin-wizards
frankenmint has quit [Ping timeout: 276 seconds]
e4xit_ has joined #bitcoin-wizards
e4xit has quit [Ping timeout: 244 seconds]
e4xit_ is now known as e4xit
ThomasV has quit [Ping timeout: 246 seconds]
Ylbam has quit [Quit: Connection closed for inactivity]
Davasny has joined #bitcoin-wizards
pro has joined #bitcoin-wizards
Tiraspol has quit [Ping timeout: 250 seconds]
Tiraspol has joined #bitcoin-wizards
Tiraspol has quit [Changing host]
Tiraspol has joined #bitcoin-wizards
nubbins` has joined #bitcoin-wizards
nubbins` has quit [Quit: .]
ThomasV has joined #bitcoin-wizards
blackwraith has joined #bitcoin-wizards
priidu has quit [Ping timeout: 260 seconds]
dnaleor has quit [Quit: Leaving]
dnaleor has joined #bitcoin-wizards
Noldorin has joined #bitcoin-wizards
Ylbam has joined #bitcoin-wizards
arubi has quit [Read error: Connection reset by peer]
skang404 has quit [Remote host closed the connection]
arubi has joined #bitcoin-wizards
gielbier has quit [Changing host]
gielbier has joined #bitcoin-wizards
SyncYourDogmas has quit [Quit: Leaving]
jl2012 has quit []
jl2012 has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
frankenmint has quit [Remote host closed the connection]
Guest10680 is now known as [Derek]
[Derek] has quit [Changing host]
[Derek] has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
blackwraith has quit [Ping timeout: 260 seconds]
ThomasV has quit [Ping timeout: 246 seconds]
MaxSan_1 has joined #bitcoin-wizards
MaxSan_ has quit [Ping timeout: 276 seconds]
droark has quit [Quit: Later.]
nonaTure has quit [Ping timeout: 250 seconds]
Noldorin has quit [Ping timeout: 258 seconds]
jannes has joined #bitcoin-wizards
NewLiberty_ has joined #bitcoin-wizards
NewLiberty_ is now known as NewLiberty
<bsm1175321>
@bramc I was explaining to my CEO yesterday your UTXO set commitment plans, and why speed was so critical. It comes down to the fact that a UTXO commitment is created/verified in the *critical*path*. (At block validation time)
<bsm1175321>
The fact of the matter is that NO speed is going to be "fast enough".
<bsm1175321>
The Satoshi construction has a race condition (or equivalently assumes zero latency -- including block verification time), that needs to be removed from the critical path.
<bsm1175321>
That's exactly what braids do -- since blocks can have multiple parents, the verification is removed from the critical path. Miners should mine on the previous block until they're finished verifying an incoming block, and then they should name them BOTH as parents.
<bsm1175321>
This removes the race condition, and cuts off SPV mining and selfish mining at its knees.
ThomasV has joined #bitcoin-wizards
wizkid057 has quit [Ping timeout: 276 seconds]
dnaleor has quit [Ping timeout: 276 seconds]
wizkid057 has joined #bitcoin-wizards
c0rw1n_ has joined #bitcoin-wizards
c0rw1n_ has quit [Remote host closed the connection]
frankenmint has quit [Remote host closed the connection]
nabu has joined #bitcoin-wizards
nabu has quit [Ping timeout: 250 seconds]
nabu has joined #bitcoin-wizards
alpalp has joined #bitcoin-wizards
<maaku>
bsm1175321: simple solution: commit to last block's utxoset
frankenmint has joined #bitcoin-wizards
N0S4A2 has joined #bitcoin-wizards
RoboTeddy has quit [Remote host closed the connection]
belcher has joined #bitcoin-wizards
JackH has quit [Ping timeout: 244 seconds]
<kanzure>
maaku: besides an overview of efforts re: formal verification of bitcoin script, libconsensus and 'smart signatures', what else is missing or what efforts are underway
frankenmint has quit [Remote host closed the connection]
PaulCape_ has quit [Quit: .]
PaulCapestany has joined #bitcoin-wizards
rasengan has quit [Quit: WeeChat 0.4.2]
<bsm1175321>
maaku: That implies that I've verified the last block's UTXO set. There is a time lag in the verification, which is exactly the race condition I'm talking about.
<bsm1175321>
I might have created a new block while verifiying the last block's UTXO set. That's the problem.
<bsm1175321>
No one should commit, cryptographically, to something they haven't verified.
bramc has joined #bitcoin-wizards
bitcoin-wizards1 has joined #bitcoin-wizards
<bramc>
bsm117532: I understand that braids do in principle get rid of this problem, but I'm still not sure exactly what their tradeoffs are, and they're a bit of a pipe dream for Bitcoin today, where utxo commitments are something which can be added immediately
<maaku>
braids are magic pixie dust and on my /ignore list until bsm1175321 writes them up in detail
<bramc>
maaku: I got far enough into understanding them at one point that I realized that you can't go halfway - siblings-only for example is worse than the way bitcoin works today
<bramc>
Although that's all swapped out of my brain right now.
<bramc>
The other nice thing about merkle sets is that they're a useful toy for all kinds of stuff, not just Bitcoin
<gmaxwell>
still haven't seen how any of these off tip techniques don't greatly magnify selfish mining.
bitcoin-wizards1 has quit [Ping timeout: 250 seconds]
<bsm1175321>
bramc: *delayed* utxo set commitments can be added. Or prompt UTXO set commitments, worsening the selfish mining problem.
<bsm1175321>
gmaxwell: The larger the delta-t in verifying a block, the larger the incentive to SPV mine or selfish mine.
<bramc>
bsm1175321: If the big utxo set is delayed a few blocks and each block contains roots of just the things added and removed in that block, then proofs of inclusion and exclusion are possible and the latency problem isn't made any worse.
<gmaxwell>
bsm1175321: verifying can be removed entirely out of the critical path.
<bsm1175321>
maaku: see my talk this coming Friday at the On Chain Scaling conference. Still not sure how to get this into Bitcoin. But it solves the underlying problem.
<gmaxwell>
this is what weak blocks do.
<bramc>
weak blocks are also a good idea, but different approaches to them have different tradeoffs
<katu_>
bsm1175321: btw, have you formalized the chain rules state machine yet?
<maaku>
bsm1175321: will it be recorded?
<bsm1175321>
gmaxwell: How do weak blocks remove verification from the critical path? How do I know I'm not mining on an invalid parent?
<katu_>
on back of envelope, plain bitcoin is about 5 branches, braids is at least 20.
<katu_>
so would like to see it
<bsm1175321>
katu_: Yes, consensus rules will be stated. Will be happy to state them now if desired, though the context will make it more comprehensible, and work to be done in the next few days...
<bramc>
There can always be blocks which don't use a weak block. Unless you require weak blocks, which creates more selfish mining problems.
<bsm1175321>
katu_: 20? Can you elaborate?
<bsm1175321>
maaku: Yes it will be recorded.
<katu_>
bsm1175321: i'm basically counting all the branches a code has to make. its really difficult to reason about it completely
<katu_>
as it is simply too many variables for me
<bsm1175321>
"a code has to make" -- what does that mean?
<gmaxwell>
bsm1175321: because with weak blocks, the whole consensus state is announced and verified long before the winning solution.
<bramc>
katu_: Not sure what you mean about code branches. But then I write all my stuff extremely idempotently which tends to mask that information.
<gmaxwell>
bsm1175321: the only thing finding a block does in weak blocks is announce a winning nonce (and coinbase txn) for an already announced state change.
<gmaxwell>
so when the solution shows up you've already validated the state its tied to.
<bsm1175321>
gmaxwell: My understanding is that weak blocks is "headers first" -- and ignores the block contents. Data corruption is real, and a block might be orphaned anyway despite having a valid PoW, no?
<bramc>
gmaxwell: But then someone can selfishly keep a weak block for themselves, unless you give them incentive to announce it... at which point you're reinventing braids
<gmaxwell>
bsm1175321: no thats incorrect.
<gmaxwell>
(I dunno who is presenting this misinformation but they should be stabbed really hard with and exploding knife)
<katu_>
bsm1175321, bramch - the number of various edge cases i can come up with. bitcoin is quite intuitive in that regard, but even that took me a while how get oriented myself in reorg code.
<gmaxwell>
bramc: thats now how it works either. ugh
<bsm1175321>
There are so many iterations of weak blocks...I can't keep track of them all, please elaborate gmaxwell.
<bramc>
gmaxwell: Oh wait you're right, as long as weak blocks aren't required then there isn't any selfish benefit to withholding weak blocks because you're hurting yourself as much as everybody else.
<bramc>
In my head 'weak blocks' is a constellation of different closely related ideas, not sure which of them have gained traction.
<gmaxwell>
bramc: yes, but it's not mining without validating!
<gmaxwell>
Even that is too much detail. Participants voluntarily announce sub difficuty shares (subject to a propagation rule) that attempt to solve blocks which also commit to a superset block that they'd rather be solving. The 'block' isn't transmitted at that time (it's irrelveant, as it failed to win) but the superset they'd rather mine ( using efficient block transmission).
<gmaxwell>
once that superset is widely propagated (and validated), miners switch their actual mining attempts to be exactly that. (or one of several such proposed tips, by themselves or others).
<bsm1175321>
If there exists any asymmetry in how miners get rewarded, it will be exploited. Clearly orphan blocks are an asymmetry. Uncles in Ethereum are an asymmetry. Weak blocks also preserve an asymmetry. Someone loses, and it will be exploited.
<bramc>
There is of course nothing wrong with both making things as fast as possible without weak blocks and then adding weak blocks later.
<gmaxwell>
There is no asymmetry here.
* bsm1175321
ponders...
<gmaxwell>
bsm1175321: please don't speak like that about ideas you just showed you completely misunderstand.
<gmaxwell>
bramc: sure, and thats also been our effort in bitcoin, to optimize the existing system first.
<bsm1175321>
gmaxwell: Doesn't this asymmetry exist, 11 blocks back?
<bramc>
gmaxwell: In your specific proposal is there any change to blocks at all? In its weakest form weak blocks is simply a form of compression
<gmaxwell>
bsm1175321: no, any miner can attmept to mine any weakblock they know about. So even if their own prefered weak blocks are not (yet) well propagated, they simply attempt to mine someone elses.
<bramc>
More stuff I need to read. I'm a little too tired today to parse through all of this, especially because I need to read through the MMR stuff. I still don't understand how proofs of unspent status are supposed to work there.
<gmaxwell>
This means that large miners would enjoy a small boost in voting power, but not income; to there is no feedback loop there.
<bsm1175321>
gmaxwell: Isn't that just a rearrangement of asymmetry? f(asymmetry) != symmetry.
<gmaxwell>
(the small boost because they have lots of hashpower and many spend an inconseqeuntial more time mining on their own weakblock suggestions, but this doesn't increase their income over their fair share.)
<gmaxwell>
bsm1175321: You might as well be saying it has weeblax for all that means; you can point to any difference you want and say there is asymetry, the centeralization pressure comes from disproportional increases in income.
<gmaxwell>
Which weak blocks eliminate, by taking verification out of the critical path, and making it so that income is not increased for the 'most quickly verified party'.
<bsm1175321>
gmaxwell: I agree. The only solution is to symmetrize, to prevent centralization pressure.
<bramc>
gmaxwell: There are two different regimes weak blocks need to think about: (1) mempools are mostly empty, blocks mostly drain in out, and (2) the mempool is always completely full, blocks pull out the highest value transactions
<bsm1175321>
Miners should not know or care.
<gmaxwell>
I don't think (1) rationally exists. Why wouldn't someone just run a script to backup their computer into the chain if there was 'free' capacity?
<bsm1175321>
gmaxwell: I look forward to debating weak blocks vs. braids in the coming weeks. I suspect we will converge on the same solution.
<bramc>
(1) is not far from what we have today, with people freaking out when blocks actually get full
Noldorin has joined #bitcoin-wizards
<bramc>
Although yes, (2) is the way things 'should' be, and which I've been a strong advocate for.
<gmaxwell>
bramc: nah, don't believe lies that get sent to the press.
<gmaxwell>
Current mempool status in bitcoins is 150mb of transaction data, and has been constantly that almost constantly since the limits were introduced.
<bsm1175321>
Let's separate economic expenditure (hash value) vs. validation. It's not the same thing.
<gmaxwell>
bsm1175321: the whole incentives argument in bitcoin (esp for allowing SPV clients) depends on them being tightly linked.
<bsm1175321>
We can entirely divorce the two. You present me a hash value that satisfies a PoW condition, I can accept it regardless of my database's consensus requirements.
<gmaxwell>
only if we don't want to exist non-validating nodes which depend on the economic rationality of the people doing mining work for their security.
<bsm1175321>
I can build a PBFT (h/t Honey Badger amiller) that contains PoW hashes, and transactions against them.
<gmaxwell>
some advocate that, but these systems are far less scalable without that capability.
<bsm1175321>
gmaxwell: Agreed it's less scalable.
<gmaxwell>
... yes you can introduce identity and N^2 communications consensus systems if you really want to make sure all the virtuious properties of bitcoin are dead. :)
<bsm1175321>
I'm attempting to divorce the economic piece from the consistency piece.
<bsm1175321>
Anyhoo, thought to consider... I'm thinking about a hypothetical a PoW coin that accepts PoW as "value creation" below its consensus target. It would be an interesting excercise, and easy to prevent from becoming centralized.
<bsm1175321>
(FWIW, not going to be making any altcoins anytime soon -- I'd rather bring ideas to Bitcoin)
<bsm1175321>
Imagine a "value creation" transaction which takes the last block's Merkle root and satisfies a PoW condition -- and you get coins allocated proportional to your PoW target. And if you're lucky enough to satisfy the network's PoW target, you get a block, and possible more coins as a consequence.
King_Rex has quit [Remote host closed the connection]
alpalp has quit [Ping timeout: 249 seconds]
<bramc>
bsm1175321: Greg understands what braids is trying to do at a high level but is very skeptical that it doesn't make selfish mining attacks worse. That's what you have to convince him off
<bramc>
Well that and an argumement that it could be deployed in a soft fork
<bsm1175321>
Yeah I have nothing to convince him of a soft fork...
<bramc>
And that playing games with how conflicts are handled in braids couldn't let people undo transactions after a lot of time has passed
<bsm1175321>
How could it possibly making selfish mining attacks worse? Selfish mining works because of the asymmetry between not profiting from a block, and profiting from a block. If *both* parents of a block profit, there is no asymmetry, and selfish mining is dead.
<bsm1175321>
bramc: It's always possible to undo transactions with >51%. The burden of proof is that you can't do it with less. You can with bitcoin, at present.
nonaTure has quit [Ping timeout: 240 seconds]
<bsm1175321>
Sounds like you two are talking in person. Great!!! I want UTXO set commitments!!! SPV sucks!!!
<bramc>
bsm1175321: The sort of selfish mining attack in question is one where a miner intentionally doesn't propagate a block they've found for their own future gain. A 1/3 miner in Bitcoin can gain advantage over time this way.
alpalp has joined #bitcoin-wizards
<bsm1175321>
bramc: The algorithm I will present on Friday considers such a miner a "minority participant" -- and as such any conflicts will be decided against him. It's easy to evaluate that his hashpower is less than the hashpower between his parent and his youngest child.
<bsm1175321>
bramc: The longer a miner doesn't propegate his block, the more "minority" he becomes. The notion of "minority" is decided by a blocks *children*.
MaxSan_ has joined #bitcoin-wizards
<bramc>
bsm1175321: I'm not the one you need to convince, and the details are sufficiently technical that trying to hash them out over irc is probably a fool's errand, you need to have a convincing presentation which people can go over at their leisure.
<bsm1175321>
bramc: Any conflicting transactions in a long-delayed block will always be decided in the favor of the majority chain, in concordance with the 51% rule.
Guyver2 has quit [Quit: :)]
<bsm1175321>
bramc Agreed. I have experience in this.
<bsm1175321>
Still not sure how to get this into Bitcoin. But eliminating the race condition has been my goal.
<Taek>
<gmaxwell> still haven't seen how any of these off tip techniques don't greatly magnify selfish mining.
<Taek>
I'm pretty convinced that my Jute stuff does not suffer from selfish mining attacks
<bsm1175321>
FWIW I think I just described how it kills it.
<Taek>
The merge mechanism for pulling orphaned blocks into the chain and rewarded them means that a miner with 40% hashrate can't compete with 60 1% miners
<Taek>
Because, the 1% miners can continue to merge eachother's blocks, and can merge the blocks from the 40% miner as they get released
<Taek>
The 40% miner can create a chain that would be ahead by a constant amount of time, say 30 seconds or something
<bsm1175321>
asymmetry kills. Define asymmetry, you've defined selfish mining.
<Taek>
but the cliff for including blocks is a lot longer than 30 seconds, which means the 40% miner is not going to be able to isolate the small miner's blocks without being victim to losing, as it's fighting against 60% hashrate
<Taek>
I feel like I can explain this a lot better on a whiteboard
<Taek>
maaku: I spent some time considering your concerns over SPV. Though SPV is not that important to me, I do think that you can pretty easily repair SPV within Jute
belcher has quit [Quit: Leaving]
<Taek>
You introduce utxo commitments that lag by a few minutes
<Taek>
similar to how utxo commitments today would probably point to the previous block instead of the current block
alpalp has quit [Ping timeout: 250 seconds]
<bsm1175321>
Taek: you. me. whiteboard. soon.
<Taek>
wouldn't mind making a video of that
<bsm1175321>
heheehee ;-)
<bsm1175321>
Please see my on chain scaling on-line talk next Friday. I'd like to figure out what is the best solution WRT weak blocks/graphs/braids.
<bramc>
Taek: Yes I just explained the delayed utxo commitments thing in the bitcoin-dev mailing list
laurentmt has joined #bitcoin-wizards
<Taek>
bsm: will definitely watch the video
laurentmt has quit [Client Quit]
<Taek>
weak blocks are nice because it's a relatively clean change to the code
<Taek>
any braid stuff is going to be more brutal, and probably a hardfork or outright an altcoin
* bsm1175321
doesn't like delays. It means I'm wrong a certain percentage of the time, and I don't like being wrong.
<Taek>
it doesn't mean you are wrong, it just means you need to wait an extra block to tell if your transaction got mined
<bsm1175321>
Braids are a hard fork. At best we can checkpoint back to a 1MB block, but it's "brutal" to do, as Taek says...
<instagibbs>
bsm1175321, presentation and solid paper or bust ;)
nabu has joined #bitcoin-wizards
<bsm1175321>
instagibbs: sold.
roman_ has quit [Read error: Connection reset by peer]
<bsm1175321>
bramc: I think you just discovered crypto-currency?
<bramc>
This is even better than covenants!
MoALTz has quit [Quit: Leaving]
Davasny has quit [Read error: Connection reset by peer]
dEBRUYNE has joined #bitcoin-wizards
r0ach has quit [Ping timeout: 244 seconds]
nonaTure has quit [Ping timeout: 250 seconds]
<kanzure>
status of libsecp256k1 paper? has a draft or pile of notes happened yet?
<nicolag>
why does fault-tolerance requires neutralizing deciding messages in a consensus protocol? (I was watching the beginning of Mazieres' talk at google)