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
Chris_Stewart_5 has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
rmwb has quit [Remote host closed the connection]
rmwb has joined #bitcoin-wizards
danrobinson has quit [Quit: danrobinson]
rmwb has quit [Remote host closed the connection]
rmwb has joined #bitcoin-wizards
negatratoron has quit [Remote host closed the connection]
Ylbam has quit [Quit: Connection closed for inactivity]
Noldorin has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
jannes has quit [Quit: Leaving]
Murch has quit [Quit: Snoozing.]
rmwb has quit [Remote host closed the connection]
rmwb has joined #bitcoin-wizards
rmwb has quit [Remote host closed the connection]
rmwb has joined #bitcoin-wizards
dabura667 has joined #bitcoin-wizards
shangzhou has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
danrobinson has joined #bitcoin-wizards
danrobinson has quit [Client Quit]
danrobinson has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 255 seconds]
AaronvanW has joined #bitcoin-wizards
contrapumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
http_GK1wmSU has joined #bitcoin-wizards
http_GK1wmSU has left #bitcoin-wizards [#bitcoin-wizards]
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
dnaleor has quit [Quit: Leaving]
Noldorin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rmwb has quit [Remote host closed the connection]
pro has quit [Quit: Leaving]
chjj has quit [Ping timeout: 276 seconds]
Giszmo1 has joined #bitcoin-wizards
Giszmo has quit [Ping timeout: 255 seconds]
jtimon has quit [Remote host closed the connection]
shangzhou has quit [Quit: Connection closed for inactivity]
danrobinson has quit [Quit: danrobinson]
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
[7] has quit [Ping timeout: 276 seconds]
rmwb has joined #bitcoin-wizards
rmwb has quit [Remote host closed the connection]
TheSeven has joined #bitcoin-wizards
rmwb has joined #bitcoin-wizards
contrapumpkin has joined #bitcoin-wizards
contrapumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
priidu has quit [Remote host closed the connection]
chjj has joined #bitcoin-wizards
c0rw1n has quit [Ping timeout: 260 seconds]
c0rw1n has joined #bitcoin-wizards
DougieBot5000 has quit [Ping timeout: 240 seconds]
CubicEarth has quit []
jcluck has joined #bitcoin-wizards
cluckj has quit [Ping timeout: 260 seconds]
DougieBot5000 has joined #bitcoin-wizards
juscamarena_ has quit [Ping timeout: 240 seconds]
juscamarena_ has joined #bitcoin-wizards
BashCo has quit [Remote host closed the connection]
brutefruit has joined #bitcoin-wizards
rmwb has quit []
BashCo has joined #bitcoin-wizards
d_t has quit [Ping timeout: 276 seconds]
CheckDavid has joined #bitcoin-wizards
http_GK1wmSU has joined #bitcoin-wizards
http_GK1wmSU has left #bitcoin-wizards [#bitcoin-wizards]
JackH has joined #bitcoin-wizards
Giszmo1 has quit [Quit: Leaving.]
Giszmo has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
daszorz has joined #bitcoin-wizards
Lamby_ has joined #bitcoin-wizards
harrow has quit [Quit: Leaving]
ivan has quit [Quit: lp0 on fire]
ivan` has joined #bitcoin-wizards
harrow has joined #bitcoin-wizards
Aaronvan_ has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 246 seconds]
Aaronvan_ has quit [Client Quit]
daszorz has quit [Ping timeout: 255 seconds]
daszorz has joined #bitcoin-wizards
yRDIUTgn has quit [Ping timeout: 255 seconds]
AaronvanW has joined #bitcoin-wizards
PaulCapestany has quit [Quit: .]
PaulCapestany has joined #bitcoin-wizards
tucenaber has quit [Remote host closed the connection]
tucenaber has joined #bitcoin-wizards
onabreak has joined #bitcoin-wizards
brg444 has quit []
brg444 has joined #bitcoin-wizards
dnaleor has quit [Ping timeout: 260 seconds]
daszorz has quit [Read error: Connection reset by peer]
dnaleor has joined #bitcoin-wizards
daszorz has joined #bitcoin-wizards
Uglux has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
dnaleor has quit [Ping timeout: 276 seconds]
Giszmo has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
Guest31089 has quit [Read error: Connection reset by peer]
prime_ has joined #bitcoin-wizards
str4d has joined #bitcoin-wizards
pro has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
dnaleor has quit [Ping timeout: 240 seconds]
afk11 has quit [Remote host closed the connection]
afk11 has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
dnaleor has quit [Remote host closed the connection]
http_GK1wmSU has joined #bitcoin-wizards
http_GK1wmSU has left #bitcoin-wizards [#bitcoin-wizards]
Guyver2 has joined #bitcoin-wizards
Nightw0lf has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
Guyver2 has quit [Ping timeout: 260 seconds]
Guyver2_ is now known as Guyver2
laurentmt has quit [Quit: laurentmt]
Uglux has quit [Quit: Leaving]
dabura667 has quit [Remote host closed the connection]
deusexbeer has quit [Ping timeout: 276 seconds]
deusexbeer has joined #bitcoin-wizards
Noldorin has joined #bitcoin-wizards
str4d has quit [Ping timeout: 240 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
jannes has joined #bitcoin-wizards
brothchide has joined #bitcoin-wizards
<brothchide>
hi, why does every new node have to validate every transaction from the last 9 years in order to sync? if all they are doing is generating UTXO set, then there has to be a way to just deliver a trusted UTXO to the client instead of making them derive it all?
<andytoshi>
because bitcoin is trustless
<nsh>
well, that's a tiny bit glib. there's no a priori reason why historical transactions past a certain time can't be elided but it does require a more complexity
<nsh>
s/a more/more/
<brothchide>
why couldnt there be something IN the blocks that makes is you could somehow trustlessly get UTXO signature or something (im not very technical, pardon me).
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
str4d has joined #bitcoin-wizards
<andytoshi>
brothchide: that's a very hard research question. you might want to look into mimblewimble which improves on this situation at great cost in flexibility
<brothchide>
andytoshi is is true that moving in a direction towards UTXO reliance is bad for side chains and stuff?
<brothchide>
is it
<andytoshi>
basically because you need to prove that the UTXO set was obtained by a series of valid transactions, and proving that transactions are valid is cryptographically hard except by just providing the transaction and having people validate the whole thing
<brothchide>
could that be a reason why it hasnt much movement?
<andytoshi>
brothchide: no, that sounds confused, i'm not sure what it means even
harrymm has quit [Ping timeout: 240 seconds]
<brothchide>
"It is clear how UTXOs do not mesh well with stateful smart contracts: if there is a need to create a contract with multiple phases, eg. where multiple parties must provide some form of input, then after some period of time those parties must perform some additional operation, and then finally the "
<brothchide>
"2. UTXOs are stateless, and so are not well-suited to applications more complex than asset issuance and transfer that are generally stateful, such as various kinds of smart contracts.
<brothchide>
"
<andytoshi>
that sounds like confused ethereum talk, there is no need for contract state to ever interact with a blockchain except to be committed sometimes
<brothchide>
well i know blockstream was big about sidechains, you have to think they want smart contracts?
<andytoshi>
did i suggest otherwise?
<brothchide>
im just wondering if there is any other ulterior motive why we aren't syncing with UTXO better
<andytoshi>
lol no
<brothchide>
ok
<brothchide>
thanks bro
<andytoshi>
brothchide: i have a mimblewimble talk https://www.youtube.com/watch?v=aHTRlbCaUyM which describes a little bit why fast UTXO-validation is hard and what mimblewimble sacrifices to get around the difficulty
jcluck is now known as cluckj
<brothchide>
andytoshi thanks, you're probably a few levels over my head, like i said im not very technical. but i have a big imagination.
harrymm has joined #bitcoin-wizards
brothchide is now known as EarlyBroth
laurentmt has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
<stevenroose>
andytoshi: what is the reason holding back consensus enforced UTXO set commitments? like in coinbases?
<stevenroose>
it could be a very segwit-alike softfork I guess
ivan` has left #bitcoin-wizards [#bitcoin-wizards]
<andytoshi>
stevenroose: i -think- it's just that there isn't a consensus on the exact details or a BIP or anything. these commitments are potentially expensive to verify or update so you want to get the maximum value at minimum cost
Emcy_ has quit [Ping timeout: 260 seconds]
laurentmt has quit [Quit: laurentmt]
<gmaxwell>
stevenroose: the fact that they are phenominally expensive, and have narrow utility, and that there are several incompatible proposals.
<gmaxwell>
(and are an actively developing area of science)
<gmaxwell>
The naieve proposals like my original were DOA because increasing validation IO costs 10 fold or more is a non-starter. :)
laurentmt has joined #bitcoin-wizards
<gmaxwell>
And also because those schemes are incompatible with proposals which eliminate the need for any node to store a utxo set at all.
<EarlyBroth>
gmaxwell, defender of sidechains, to the resuce! morn bro.
<EarlyBroth>
*rescue.
<EarlyBroth>
*hugs* even if you dont agree.
<EarlyBroth>
*we
<stevenroose>
"proposals which eliminate the need for any node to store a utxo set at all" care to elaborate?
belcher has quit [Ping timeout: 255 seconds]
trippysalmon has joined #bitcoin-wizards
<stevenroose>
also, I'm amazed it's so expensive. I mean both Ripple and Ethereum have state trees all over the place.
<stevenroose>
I would think there has to be an efficient tree storage algorithm that could be used to store and update a UTXO set
<gmaxwell>
basically hundreds of times worse than bitcoin.
<EarlyBroth>
greg, movings towards some kind of UTXO thing would have no impact on your ability to do whatever you want with sidechains?
Emcy has quit [Remote host closed the connection]
<gmaxwell>
and ripple's scalablity is so poor that no one outside of ripple labs runs a node, so much so that when ripple's node had corruption they actually lost and cannot recover the early history of it.
<stevenroose>
well, ripple doesnt have reorgs or anything, so they don't need history. but that's a big mistake on its own ofc
<stevenroose>
and true, I heard numbers of what ripple was paying to keep their validator nodes online
<stevenroose>
it's insane
<gmaxwell>
(and anduck's graph has a sync with bitcoin core for conparison)
<stevenroose>
well, I did assume that the state tree system required more resources. didn't know it was this bad
<gmaxwell>
stevenroose: ethereum's problems are many layered.
<gmaxwell>
not just the fact that they commit to a zillion things, though that results in big slowdowns that are unfixable without major hardforks that change the protocol.
EarlyBroth has left #bitcoin-wizards [#bitcoin-wizards]
EarlyCrabs has joined #bitcoin-wizards
<stevenroose>
gmaxwell: the thing is that those commitment allow for a different security model. like looking only at the last X blocks and ignoring all the rest if there is enough work
belcher has joined #bitcoin-wizards
<gmaxwell>
You know I was the first person to propose these things, right?
<stevenroose>
not saying I like that though, I just think that's their idea, it's significantly different that bitcoin's though
<gmaxwell>
like you don't need to tell me what they are useful for.
<stevenroose>
I don't
<stevenroose>
I know you understand them, don't worry :) didn't know you proposed them
<stevenroose>
if you ask Gavin, he'd gladly steal your thunder :)
<stevenroose>
gmaxwell: did you take a look at parity's Bitcoin implementation?
<stevenroose>
They made it look like Gavin just wanted to proof that implementing Bitcoin is no biggy
<betawaffle>
of course gavin would steal credit ;)
<stevenroose>
When I briefly mentioned segwit, he immediately returned that "segwit is not part of the bitcoin protocol yet!"
<gmaxwell>
stevenroose: it was also obviously consensus incorrect, failing the first check I did. Ever try using it?
<stevenroose>
betawaffle: we all know that
<stevenroose>
gmaxwell: nope, I didn't
<stevenroose>
gmaxwell: what was the first check you did? you made me curious
<gmaxwell>
Not saying, then they'll fix it and I'll lose the easy test if it has had any competent review or not. :)
<gmaxwell>
(perhaps they subsiquently fixed it, haven't looked.)
<betawaffle>
is the fatal flaw included in that discussion?
<gmaxwell>
no, it's related to the earlier thread of discussion.
<betawaffle>
no, i mean the problem with your commitment proposal
<betawaffle>
(you said it was broken)
<gmaxwell>
no it doesn't talk about the limits, logs here from 2012ish are probably pretty good.
<gmaxwell>
The first set of flaws was that even rather clever fast ways of handling it are just rather slow. This wasn't obvious until people went and made optimized implementations.
<betawaffle>
oh i see
<gmaxwell>
The next set of flaws was that several of the things we thought they were needed for, like fraud proofs turned out to be better achievable other ways. (e.g. through source-offset witness data in transactions)
<betawaffle>
are fraud proofs eventually going to be possible?
<gmaxwell>
The next set of issues was that petertodd proposed schemes (and later other people too) to eliminate a node's need for a utxo set entirely, (with considerable tradeoffs) which are obviously incompatible with these proposals.
<stevenroose>
gmaxwell: "Since full nodes must already keep track of all open transactions for validation, maintaining such a tree would be relatively cheap (log2(n) for single updates, fewer per update if more than one txn changes at a time)." well, I might have made the same assumption :p
<gmaxwell>
betawaffle: not a technical question, tech issues are all solved for making htem possible; meaningful is another question since their utility is an open question.
<betawaffle>
wow, you can make fraud proofs for all kinds of fraud already?
<gmaxwell>
betawaffle: with softforks, yes.
<betawaffle>
i figured some would still be too expensive
<gmaxwell>
no we know how to have efficient proofs for every protocol rule.
<betawaffle>
kind of amazing
<gmaxwell>
but the open question about partitioning/censorship makes it value prop unclear.
<betawaffle>
ah, right
<gmaxwell>
There are proposed optimizations for some of these set commitment ideas that make them much more viable, but they each kill some of the gains.
<betawaffle>
to avoid those problems, you'd lose some of the benefits, right?
<gmaxwell>
For example you can delay and batch them, but that basically kills anything they liteclients would use them for, any use of them in fraud proofs, etc.
<gmaxwell>
And we have our rolling hash proposal, but again, kills many of the proposed applications. (but no IO overhead, hurray, but non-trivial CPU overhead, boo)
<betawaffle>
has a rolling hash been picked yet?
<betawaffle>
is the idea that it would be committed to in blocks?
JackH has quit [Quit: Leaving]
Emcy has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
Emcy has quit [Changing host]
EarlyCrabs has quit [Quit: BitchX: made with real honey.]
Aranjedeath has joined #bitcoin-wizards
<kanzure>
hmm there are no remaining consensus rules that have unsolved fraud proofs?
Emcy has quit [Quit: Leaving]
Emcy has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
Emcy has quit [Changing host]
Emcy has quit [Client Quit]
Nightw0lf has quit [Quit: Lost terminal]
Emcy has joined #bitcoin-wizards
Emcy has quit [Remote host closed the connection]
Emcy has joined #bitcoin-wizards
Murch has joined #bitcoin-wizards
contrapumpkin has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<gmaxwell>
there weren't in 2012.
<gmaxwell>
(IIRC)
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
<kanzure>
was block size the last holdout until luke-jr did that recently?
<kanzure>
(block weight, now.)
<gmaxwell>
luke's thing worked without extra commitments but it was always easy with extra commitments.
Murch has quit [Quit: Plugging out.]
q4 has joined #bitcoin-wizards
<gmaxwell>
add to the block a commitment to a running sum of size/weight whatever. if a block is too large, just show the last value. If the commitment is wrong, show the first point where it disagrees. (either two adj running sum values, or a two and a tranaction)
<gmaxwell>
any sum of whatever, sigops etc. can be done the same way.
<gmaxwell>
see also: 'sum tree' though you don't need to sum up a tree to get an efficient proof for the fraud proofs. Though a tree works too.
danrobinson has joined #bitcoin-wizards
<luke-jr>
what?
<luke-jr>
no amount of commitments can fix fraud proofs being broken
<luke-jr>
someone mining an invalid block can just fake any such commitment
<luke-jr>
the block size proof only works against a very specific case
<gmaxwell>
...
<gmaxwell>
luke-jr: you are simply wrong.
<luke-jr>
…
<gmaxwell>
unless you mean the censorship problem.
Guyver2 has joined #bitcoin-wizards
<gmaxwell>
where someone can just refuse to give anyone the whole block, so they can't tell that it's invalid.
<kanzure>
was your earlier statement exclusively about "since 2012 we have definitely known how to design commitments that could allow for fraud proofs of all the rules"?
<kanzure>
gmaxwell: i think that PoW verification should require the full transaction data. otherwise you're paying for possibly invalid data. this solves fraud proof censorship because you can't measure PoW strength claim without having all the data.
<kanzure>
(this would be solved by including the full transaction data next to the transaction merkle root)
<gmaxwell>
well then you don't need the fraud proof really, just verify it.
<gmaxwell>
if you're stuck always transfering it!
<kanzure>
say you add a block weight commitment to the header. it doesn't solve the problem of "just refuse to give anyone the whole block". so the fraud proof can't use the block weight commitment.
<betawaffle>
umm, doesn't refusing count as invalid?
<kanzure>
no, miners can mine literally anything.
<gmaxwell>
kanzure: I did propose how to solve that.
<betawaffle>
yeah, but how would that ever be considered valid if they don't give it out?
<gmaxwell>
But I don't think anyone else understands it.
<kanzure>
betawaffle: "you have a raspberry pi"
<gmaxwell>
betawaffle: imagine a world where almost everyone has lite clients.
<gmaxwell>
betawaffle: and they will give out spv proofs to them, but hide the naughty stuff until later.
<kanzure>
which proposal are you referencing?
<betawaffle>
well obviously that's not sufficient
<betawaffle>
is the goal to make light clients safer or to make full nodes cheaper?
<gmaxwell>
kanzure: using locally decodable codes. You make the protocol so the block is coded with an error correcting code that expands it. Then when a client wants to read part 5 for his spv proof he does so by picking some random subsets that when combined let him decode part 5. He will not accept the block unless he can get exactly the random segments he wants.
<gmaxwell>
The effect of the code is that if all the users do this, the sender cannot serve more than a finite number of clients, before the clients know enough to either be able to reconstruct the whole block, or prove that the sender was giving out inconsistent chunks.
<kanzure>
is there a minimum number of fragments to pick to make this work/not work?
<gmaxwell>
haven't done the engineering to find concrete parameters, it works asymtoptically at least.
<kanzure>
whole-reconstruction is the important property. you need the collusion around whole block transfer to include at least one defector that will opt to transfer the full contents to others.
<betawaffle>
is that a similar concept to fountain codes?
<gmaxwell>
but it has weird constraints, like a block would have to have a designated server list in its header which are guarenteed to have the whole block, or something like that.
<gmaxwell>
betawaffle: you would use something like a fountain code but with special constraints so that parts were decodable.
MaxSan has joined #bitcoin-wizards
<kanzure>
don't you run into the same "ha ha ha now 80% of the network shall be considered below even raspberry pis" problem? they will simply claim you cannot construct the full block due to your low bandwidth.
<kanzure>
i guess you have to stripe the random selection requests across a trusted set of peers (but each user can setup this set on their own) so that in aggregate among your trusted peers you know there has been a complete copy.....?
<kanzure>
as the total data size grows, you need to also grow your trusted peer set size, for striping requests across more available bandwidth..
BashCo has quit [Remote host closed the connection]
<gmaxwell>
well the idea is that each peer can select randomly... but they're sticky in their suggestion. You could also have a peer have a proxy request "hey bob, I wanted 1,2,4 from the last server but can't seem to get it, can you get it?" and if bob can't bob can start rejecting the block too.
<gmaxwell>
I don't know if this idea is _reasonable_ but it's not nothing.
<gmaxwell>
it has a lot of open problems in it.
BashCo has joined #bitcoin-wizards
<gmaxwell>
for one, it might turn out that efficient parameter sets only exist for uninteresting sizes.
<kanzure>
so one of the problems in the "undetected fraud" stuff is that if you do not detect fraud quickly, the network continues on and builds on top of the fraud, which makes the whole system worthless of course. so the validity needs to be absolutely knowable within ~minutes or less.
daszorz has quit [Read error: Connection reset by peer]
<kanzure>
if it turns out that way then i would argue just tack on the transaction data as part of verifying PoW strength. that way you can be sure you have al the data and can check it.
<betawaffle>
but...
<betawaffle>
that defeats the purpose entirely
<gmaxwell>
well one thing to help with that is you can seperate admisisson with consensus... which is what preconsensus techniques do... e.g. blocks commit to new transactions to add. but they're not really promising that they're all valid yet.. they also commit to an earlier point in history, which they promise is certantly valid honest to goodness.
<kanzure>
the benefit of transfering the proof with the PoW itself is that you can only verify the PoW if the data is small enough for it to actually transfer the data in the first place. you could imagine "super lite" clients that just accept any PoW claim but that's obviously stupid and nobody seems to do this. so....
<kanzure>
betawaffle: you're basically claiming that the current bitcoin protocol is self-defeating.
<gmaxwell>
I'm not all that convinced that pow that you can't verify at all without the data is actually possible, fwiw.
<betawaffle>
well, SPV by itself is
Chris_Stewart_5 has joined #bitcoin-wizards
<betawaffle>
(perhaps i'm confused about what the conversation is)
<kanzure>
oh that would be interesting. so like h=H(block data) but properties of h can be determined without the full block data ?
<gmaxwell>
something having a freeloading problem doesn't make it automatically self defeating.
<gmaxwell>
kanzure: yea, like if H is sha256, you can give a midstate and the end and still verify that you know <something><ends with this> with a given hash
<kanzure>
hmph well that's problematic. hmm.
BashCo has quit [Ping timeout: 260 seconds]
<gmaxwell>
also, even ignoring special cases like that, you run a generic ZK prover over your expensive verification to get a cheap one.
<betawaffle>
gmaxwell, perhaps this is slightly tangent, but if someone were to defraud an SPV client, would they be able to provide proof for all txs without revealing the fraud?
<kanzure>
wouldn't zk prover be slow and mining keep going anyway? this is the same thing as hiding fraud in distant past, if you can't check immediately then miners will just say "we're too far ahead on this branch already" or something.
tgorham84 has joined #bitcoin-wizards
<kanzure>
i think your block error correction code scheme is strictly no worse (and very possibly better) than the current ways that fraud can be hidden in untransmitted block contents. and as you have pointed out, my alternative (include transaction data as requirement to compute PoW) does not improve the situation.
<gmaxwell>
engineering complexity is not free.
<nsh>
+1
<kanzure>
with block error correction encoding scheme, global publication channel feature is sort of lost, right? and anti-replay is only lost to the extent that none of your peers are able to quickly report inconsistencies between (conflicting?) results received from miners or other full data 'relayers'.
petertodd has quit [Quit: Lost terminal]
Noldorin has quit [Ping timeout: 255 seconds]
BashCo has joined #bitcoin-wizards
abpa has joined #bitcoin-wizards
tiagotrs has joined #bitcoin-wizards
bildramer has quit [Quit: alway rember happy day]
str4d has quit [Ping timeout: 260 seconds]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
tgorham84 has quit [Remote host closed the connection]
tgorham84 has joined #bitcoin-wizards
d_t has joined #bitcoin-wizards
bildramer has joined #bitcoin-wizards
str4d has joined #bitcoin-wizards
luke-jr has quit [Excess Flood]
luke-jr has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
tiagotrs has quit [Ping timeout: 240 seconds]
tgorham84 has quit [Quit: pizza]
Chris_Stewart_5 has joined #bitcoin-wizards
Noldorin has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
Murch has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
nanotube has quit [Ping timeout: 240 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
tgorham84 has joined #bitcoin-wizards
nanotube has joined #bitcoin-wizards
str4d_ has joined #bitcoin-wizards
str4d__ has joined #bitcoin-wizards
str4d has quit [Ping timeout: 276 seconds]
str4d_ has quit [Ping timeout: 240 seconds]
tiagotrs has joined #bitcoin-wizards
tiagotrs has quit [Changing host]
tiagotrs has joined #bitcoin-wizards
<sipa>
betawaffle: there are some benefits to them being committed, but not so much... in a first step i wouldn't argue for a consensus rule
<betawaffle>
k
<betawaffle>
can they be used to reduce the trust necessary in using a utxo set snapshot?
<sipa>
eh, under what assumptions?
<sipa>
if you have a trusted UTXO set hash, you can always verify a UTXO snapshot you're getting
<sipa>
all rolling hashes do is make it much cheaper to always have a hash
<betawaffle>
like, imagine you can download the UTXO set (and hash) from one node, then ask other nodes too
<sipa>
lol, don't do that
<betawaffle>
but only because of the sybil risk, right?
<sipa>
you shouldn't assume that a majority of your peers are honest
<betawaffle>
correct
<tgorham84>
but why would you have have to get the hash for the UTXO from the node instead of the blockchain?
Ylbam has joined #bitcoin-wizards
<betawaffle>
tgorham84: if it isn't committed
<sipa>
tgorham84: perhaps from an earlier run (if you're reindexing), or from another system you're operating
<sipa>
or perhaps it can be shipped with software
<tgorham84>
i see
<betawaffle>
is there a way to fetch the UTXO set from other nodes currently?
<sipa>
no
<sipa>
if it is committed, you allow a new security level where you trust the majority of hashrate up to some point in the future, and then fully sync from there
<sipa>
rolling utxo hashes imho also have more engineering-related advantages... you can use them as a simple local checksum
<sipa>
(compute one from chain history, and one from the utxo set... they should be identical)
<betawaffle>
is it based on a window of history?
<sipa>
no
<sipa>
you can't compute a hash of the utxo set by only looking at a part of history :)
<betawaffle>
darn
<sipa>
?
<betawaffle>
well, some rolling hashes will match up as long as you know where to start
<sipa>
heh?
<tgorham84>
wow that guy earlybroth started a convo about UTXO and then got banned now everyone talking all day :)
<betawaffle>
not cryptographic ones ;)
<sipa>
this is a cryptographic hash, it won't accidentally match with anything everything
<sipa>
*ever
<sipa>
betawaffle: to be clear, the idea is that a node would continuously update its cached rolling utxo hash of the last block
<betawaffle>
so what makes this one easy to recompute?
<sipa>
not recompute - update
<betawaffle>
right...
<sipa>
you can start from the previous hash, "subtract" the spent utxo's from it, "add" the created utxo's to it, and have the new hash of the set
<betawaffle>
ohhhh. ok so what do those operations look like then?
<sipa>
either elliptic curve addition/subtraction
<sipa>
or finite field multiplication/division
<betawaffle>
got it!
<sipa>
the finite field one is probably easiest to understand
<sipa>
your hash is just a big number (3000ish bits), and for every utxo you add - you hash the utxo, and multiply it into the hash
<sipa>
for every utxo you spend, you divide the hash by it
<sipa>
clearly, a create and a spend will cancel out, in whatever order they occur, regardless of what other operations happened in between
<betawaffle>
and what data do you hash about the tx? same as the tx id?
<sipa>
the txid, the output position in the txid, the amount, the scriptPubKey, the height, whether it's a coinbase or not
<sipa>
(= exactly the data maintained in the utxo set)
<betawaffle>
so, what use-cases do you already have for this?
<sipa>
read the last 15 minutes in this channel :p
Chris_Stewart_5 has quit [Ping timeout: 276 seconds]
danrobinson has quit [Quit: danrobinson]
<irc_bot>
<nicola> that’s amazing ^
str4d__ has quit [Ping timeout: 260 seconds]
priidu has quit [Ping timeout: 276 seconds]
xulf has joined #bitcoin-wizards
<xulf>
a broadcast medium makes sense as a way to distribute blocks
<xulf>
wireless or satellite
dnaleor has quit [Quit: Leaving]
dnaleor has joined #bitcoin-wizards
<xulf>
but is there a trust problem with many users receiving from the same source for blocks?
belcher has quit [Ping timeout: 276 seconds]
<sipa>
xulf: if they rely on that source being available, yes
<sipa>
as an addition means to prevent partition, no
<sipa>
*additional
danrobinson has joined #bitcoin-wizards
chjj has quit [Ping timeout: 276 seconds]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
belcher has joined #bitcoin-wizards
Murch has quit [Quit: Snoozing.]
dnaleor has quit [Quit: Leaving]
petertodd has joined #bitcoin-wizards
yoleaux has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
<xulf>
https://www.youtube.com/watch?v=H0DKRl8XIcU human inaudible sound transmission example, if you can pay a satellite radio station to broadcast at 23 khz for example it wouldn't affect people listening to the station
<xulf>
that are also listening to music
Belkaar has quit [Ping timeout: 246 seconds]
d_t has quit [Ping timeout: 240 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
dnaleor has quit [Quit: Leaving]
d_t has joined #bitcoin-wizards
d_t has quit [Read error: Connection reset by peer]
Dizzle has joined #bitcoin-wizards
Murch has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]