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
KindOne1 has quit []
slivera has quit [Quit: Leaving]
shush has quit [Remote host closed the connection]
justanotheruser has quit [Ping timeout: 248 seconds]
shush has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
ensky has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
nirved has quit [Read error: Connection reset by peer]
Noldorin has joined #bitcoin-wizards
Noldorin has quit [Client Quit]
marcoagner has quit [Ping timeout: 268 seconds]
yanmaani has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 258 seconds]
grubles_ is now known as dingus
shush has quit [Remote host closed the connection]
nirved has joined #bitcoin-wizards
superkuh has quit [Read error: Connection reset by peer]
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
tromp has quit [Remote host closed the connection]
<asukan>
On-chain data availability is based on the assumption that miners will broadcast new blocks as fast as they can and there're always some ondes keep a full history imo
superkuh has joined #bitcoin-wizards
surja795 has quit [Quit: Connection closed for inactivity]
Dean_Guss has joined #bitcoin-wizards
justanotheruser has quit [Read error: Connection reset by peer]
nick_freeman has quit [Remote host closed the connection]
<jeremyrubin>
asukan: you may want to catch up on the context of the conversation. It's about if on-chain availability is an important property over off-chain availability
<jeremyrubin>
Off chain availability can be more available than on chain
<jeremyrubin>
So on chain availability isn't a fantastic solution (e.g., if you rely on on-chain availability from random nodes you really want to lose your txns in a reorg?)
Belkaar has quit [Ping timeout: 258 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
justanotheruser has quit [Read error: Connection reset by peer]
jimmysong has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
<asukan>
I was referring to "all nodes can prune old blocks" and make sense of using layer 1 as a data availability layer
<asukan>
Re-org is not an issue if you only consider data on-chain after X blocks
ensky has quit []
<asukan>
I agree that ZK rollup doesn't reduce on-chain state
bayashi has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 260 seconds]
pinheadmz has quit [Quit: pinheadmz]
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 272 seconds]
pinheadmz has joined #bitcoin-wizards
pinheadmz has quit [Quit: pinheadmz]
<jeremyrubin>
All nodes can prune old blocks. It's a problem for bootstrapping, but assumeutxo helps with that
<jeremyrubin>
I.e., if someone tricked you on the last year of blocks, they could probably trick you on the prior years.
<jeremyrubin>
The only data you would *need* to check from old blocks to validate assumeutxo would be the unspent outputs (can ignore/filter the spent ones)
<jeremyrubin>
And if you get into a txoutproof world (e.g, utreexo), then nodes won't even store your outputs, you'd have to store them to spend
<jeremyrubin>
Both of the above aren't even soft forks, they are p2p changes
<jeremyrubin>
Further, if you accept ZKPs into your assumption set, you could also go the route of just ZKP'ing that this chain has this much work, this UTXO set hash, and is valid
<jeremyrubin>
So there would be zero data availability to catch up
<jeremyrubin>
So when I claim that there's not really such a thing as on chain data availability, I'm pretty sure we shouldn't be encouraging people to expect that some other blockchain user will forward them this info.
tromp has joined #bitcoin-wizards
<jeremyrubin>
If you want data availability, you need to have your own redundant solution.
tromp_ has joined #bitcoin-wizards
<jeremyrubin>
This is also largely true for Ethereum -- but it's harder on bandwidth given the EVM's design to pull this off
<jeremyrubin>
But still, there are certainly contracts which use merkle trees on ethereum for compact lookups. And any such contract has a data availability issue
tromp has quit [Ping timeout: 272 seconds]
tromp_ has quit [Ping timeout: 272 seconds]
pinheadmz has joined #bitcoin-wizards
<asukan>
I see what you mean, thanks for the explaination.
<asukan>
If you introduce ZKP to compress the history then there's no DA on layer 1 anymore. Without the ZKP assumption, layer 1 still provides a meaningful data availability window even if all users prune old blocks > X days, and that window is enough for protocols like ZK rollup.
<jeremyrubin>
That's fair. I'm interested in knowing what the window of availability required is and if something outside consensus is sufficient
<jeremyrubin>
Data consistency isn't required, right? Just *availability*
<jeremyrubin>
E.g., would it be available enough to just use AWS S3 if you're just worried about a day of availability?
<jeremyrubin>
Or if there's some sort of issue with using a provider, what about issuing a transaction into the Bitcoin mempool with expected acceptance of the time period (e.g., bid the median fee).
<jeremyrubin>
Theoretically, the mempool is ~more available than older confirmed blocks, but less consistent.
<jeremyrubin>
If you observe the transaction being low to the bottom of the mempool, you can reissue one paying higher fee
<jeremyrubin>
This is cheaper than actually getting confirmed as you only pay if you get confirmed before your next state update txn
<jeremyrubin>
Although IIRC RBF requires higher absolute fee and higher feerate,
<luke-jr>
for ZK bootstrap to work, it also needs to be mandatory
<luke-jr>
otherwise miners could make a chain and ZK proofs for it, but never provide the full blocks to non-ZK nodes
<jeremyrubin>
that's kind of my point
<jeremyrubin>
It *can* be mandatory
<jeremyrubin>
so you can't rely on avail of old blocks
AaronvanW has joined #bitcoin-wizards
<asukan>
To withdraw a user needs to provide a merkle proof of his account balance, which can be re-constructed from on-chain data. A longer window would allow users to get online more infrequently, so it's more of a usability thing.
<asukan>
I think consensus is needed because rebuilding the state requires a consistent view of transaction order.
tromp has joined #bitcoin-wizards
<jeremyrubin>
consensus != consistency
<jeremyrubin>
if a UTXO exists, and I have a preimage i must know to spend it, and I ask Alice and she says X and I ask Bob and he says Y, I just see which one was correct
AaronvanW has quit [Ping timeout: 258 seconds]
<jeremyrubin>
X could be saying "H(x), x is preimage"
<jeremyrubin>
Y could be "Don't know H(X)'s preimage"
bayashi has quit []
tromp has quit [Ping timeout: 272 seconds]
<jeremyrubin>
But just that I got some correct answer means consistency
<jeremyrubin>
* availability
<jeremyrubin>
Bitcoin itself is kind of like this
<jeremyrubin>
Your peer could say that they don't have any blocks past a certain date
<jeremyrubin>
Or claim the difficulty went down and here's a low-work chain
<jeremyrubin>
But you *eventually* get a decent answer, which you can check
<jeremyrubin>
But there's no point in making the way you get an answer in Bitcoin consensus the same for getting spending conditions for your txn
<jeremyrubin>
In fact there are privacy reasons not to do that
NilsHitze has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
tromp has quit [Ping timeout: 272 seconds]
pinheadmz has quit [Quit: pinheadmz]
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
francisco___ has quit [Quit: Connection closed for inactivity]
shush has quit [Remote host closed the connection]
jungly has joined #bitcoin-wizards
jimmysong has quit [Ping timeout: 255 seconds]
rh0nj has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
CryptoDavid has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 240 seconds]
someone235 has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
NilsHitze has quit []
marcoagner has joined #bitcoin-wizards
francisco___ has joined #bitcoin-wizards
gorthx has joined #bitcoin-wizards
yanmaani has joined #bitcoin-wizards
jungly has quit [Read error: Connection reset by peer]
jungly_ has joined #bitcoin-wizards
jungly has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
jungly_ has quit [Ping timeout: 258 seconds]
nick_freeman has joined #bitcoin-wizards
son0p has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
jungly_ has joined #bitcoin-wizards
jungly has quit [Ping timeout: 255 seconds]
CryptoDavid has quit [Quit: Connection closed for inactivity]
someone235 has quit [Quit: Connection closed for inactivity]
someone235 has joined #bitcoin-wizards
jungly_ has quit [Remote host closed the connection]
rusty has quit [Quit: Leaving.]
AaronvanW has joined #bitcoin-wizards
gorthx has quit []
Qui_Sum1 has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
son0p has quit [Remote host closed the connection]
<tromp>
jeremyrubin: not all nodes can delete old blocks; network needs archive nodes to seed new full nodes
AaronvanW has quit [Remote host closed the connection]
pinheadmz has joined #bitcoin-wizards
pinheadmz has quit [Quit: pinheadmz]
Chris_Stewart_5 has joined #bitcoin-wizards
someone235 has quit [Quit: Connection closed for inactivity]
pinheadmz has joined #bitcoin-wizards
luke-jr has quit [Ping timeout: 255 seconds]
jungly has joined #bitcoin-wizards
jungly has quit [Read error: Connection reset by peer]
jungly has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
TheoStorm has quit [Remote host closed the connection]
jungly_ has joined #bitcoin-wizards
jungly has quit [Ping timeout: 255 seconds]
bitdex has quit [Ping timeout: 240 seconds]
luke-jr has joined #bitcoin-wizards
bitdex has joined #bitcoin-wizards
jungly has joined #bitcoin-wizards
jungly_ has quit [Ping timeout: 255 seconds]
Qui_Sum1 has quit []
CryptoDavid has joined #bitcoin-wizards
jungly has quit [Remote host closed the connection]
<nsh>
Do you have insightful and exciting work sitting in a drawer somewhere because it never quite panned out? Are you willing to share your failed approaches so that others can learn from them without having to re-travel the same road? Are you tired of reading papers that pretend the incremental result they happened to achieve was well-motivated and was their goal all along?
<nsh>
<nsh>
We are! That’s why we need a conference for papers that describe instructive failures or not-yet-successes, as they may prefer to be called.
<nsh>
<nsh>
The second Conference for Failed Approaches and Insightful Losses (CFAIL 2020) is seeking original papers in the field of cryptology that detail currently unsuccessful but insightful attempts to:
<nsh>
<nsh>
Prove a conjecture,
<nsh>
Disprove a conjecture,
<nsh>
Design a cryptographic algorithm or reduction,
<nsh>
Simplify a cryptographic algorithm or concept,
<nsh>
Cryptanalyze a cryptosystem,
<nsh>
Implement a cryptosystem,
<nsh>
Formulate a new security definition,
<nsh>
Systemize a collection of ad-hoc attacks,
<nsh>
Or any other task that is part of the practice of theoretical or applied cryptology, broadly construed.
<nsh>
--
tromp has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
smk has quit [Ping timeout: 260 seconds]
Chris_Stewart_5 has quit [Ping timeout: 255 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
davterra has joined #bitcoin-wizards
shesek has quit [Read error: Connection reset by peer]
shesek has joined #bitcoin-wizards
shesek has joined #bitcoin-wizards
shesek has quit [Changing host]
rh0nj has joined #bitcoin-wizards
rh0nj has quit [Remote host closed the connection]
Guyver2 has joined #bitcoin-wizards
rh0nj has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
davterra has quit [Ping timeout: 240 seconds]
davterra has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
nick_fre_ has joined #bitcoin-wizards
nick_freeman has quit [Ping timeout: 272 seconds]
jungly has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
jungly has quit [Ping timeout: 258 seconds]
shush has joined #bitcoin-wizards
nick_fre_ has quit [Remote host closed the connection]
shush has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
Chris_Stewart_5 has quit [Ping timeout: 255 seconds]
<yanmaani>
man that is a cool idea
<yanmaani>
I don't have a dog in this fight but that is a very cool idea
nick_freeman has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
CryptoDavid has quit [Quit: Connection closed for inactivity]
shush has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
Ceriand has quit []
TheoStorm has quit [Client Quit]
shush has quit [Remote host closed the connection]
yanmaani has quit [Remote host closed the connection]
yanmaani has joined #bitcoin-wizards
rottensox has joined #bitcoin-wizards
forcer1 has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
nick_freeman has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
jungly has joined #bitcoin-wizards
nick_freeman has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
brianhoffman_ has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
shush has quit [Remote host closed the connection]
brianhoffman has quit [Ping timeout: 265 seconds]
brianhoffman_ is now known as brianhoffman
nick_freeman has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
jungly has quit [Remote host closed the connection]
<jeremyrubin>
tromp: that's not strictly true. As implemented today, yes. But in the far-flung future, you can't guarantee the blocks are available as the state required for validation of all prior blocks can be compressed into something O(1) (most work chain proof, UTXO set accumulator, UTXO spend accumulator, transaction validity proof, etc)
<jeremyrubin>
I agree it would be nice if someone would serve old block data, I just don't think it's strictly speaking neccessary
<jeremyrubin>
And it's important to keep this top of mind since if we ever go to txo proofs (which is the first step in this direction) users will be responsible for keeping their own txo data
jungly has joined #bitcoin-wizards
jungly_ has joined #bitcoin-wizards
jungly has quit [Read error: Connection reset by peer]
jungly has joined #bitcoin-wizards
jungly__ has joined #bitcoin-wizards
jungly has quit [Read error: Connection reset by peer]
jungly___ has joined #bitcoin-wizards
rjected has joined #bitcoin-wizards
jungly__ has quit [Read error: Connection reset by peer]
jungly_ has quit [Ping timeout: 260 seconds]
jungly___ has quit [Remote host closed the connection]
<tromp>
i think it's not just nice, it's essential to maintain bitcoin's security model, which is based on full nodes being able to trustlessly verify what is the most worked chain
<jeremyrubin>
^ not if ZKP?
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
forcer1 has quit []
shush has quit [Remote host closed the connection]
<tromp>
ZKP even if based on just ECDLP, don't offer quite the same guarantees in practice due to bigger scope for bugs in either theory or impl
shush has joined #bitcoin-wizards
<tromp>
this far flung future would have to be one in which the vast economic majority has as much faith in ZKPs as we now have in the fully transparent history verification
IGHOR has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
<jeremyrubin>
I'm just saying that there's a cost tradeoff
<jeremyrubin>
ZKPs v.s. archiving and storing all this data
<jeremyrubin>
people aren't going to want to store all this crap
<jeremyrubin>
ZKP trust is better than expecting archival nodes to exist IMO
<jeremyrubin>
One is more centalized inherently
rjected has quit [Quit: WeeChat 2.7]
<tromp>
i think the crap should be kept sufficiently in check that archival node prevalence is all but guaranteed
<jeremyrubin>
crap?
<tromp>
just quoting you back:-)
<tromp>
"store all this crap"
<jeremyrubin>
I don't get how you are keeping it in check
<tromp>
limiting block size growth and developing second layer solutions help
<jeremyrubin>
I think it will be highly unlikely in the long future that people will be getting archival nodes broadcasting. Maybe you'll go to a university library and check out a "memory crystal" to get a decade of backup data
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<jeremyrubin>
tromp: disagree.
<jeremyrubin>
L2 is going to increase the utilization of L1
<jeremyrubin>
And I don't think anyone except luke-jr is advocating a block size reduction
<jeremyrubin>
(also what do you think of segwit pruning??? -- this is a proposed thing that archival nodes won't serve signatures)
<tromp>
first time i hear of segwit pruning; need to read up on that
<jeremyrubin>
I think it's highly probable that if you're running an assumevalid node you don't download signatures at some point
<tromp>
as adoption increases, the percentage of full nodes will drop of course, but the hope is that in absolute numbers it won't
<jeremyrubin>
doubt it
<jeremyrubin>
In absolute numbers it may drop simply due to hardware failures/running out of space
<jeremyrubin>
or bandwidth
<jeremyrubin>
if the number of nodes grows, and only a const number of archivals
<jeremyrubin>
those archivals become more and more expensive to run
<tromp>
storage and bw costs tend to drop exponentially over time
pntbr has joined #bitcoin-wizards
<tromp>
while chain growth is almost linear, so that should sort itself out
<jeremyrubin>
unclear
<jeremyrubin>
I'd take the bet on P(ZKPs getting better) > P(exponential bw/storage increase)
<jeremyrubin>
Also I think if bw and storage do legitimately increase, we'll do more block size increases a la segwit
<tromp>
i prefer bets with well-defined criteria:-)
<jeremyrubin>
Well the bet is that a ZKP system would be sophisticated enough to prove chain history without data availability
<jeremyrubin>
And be reasonably reviewed enough that nodes no longer serve blocks to new nodes catching up
<tromp>
yes, that's the promise of recursive schemes like Halo
<jeremyrubin>
Even if you *are* worried about a cryptographic break, you still wouldn't want to pay the bandwidth costs
<jeremyrubin>
So you wouldn't make the data available unless there were a break in the scheme
<tromp>
i expect there will be full nodes and lesser full nodes that verify a ZKP proof of most work history
<tromp>
but the latter will complement rather than replace the former
<jeremyrubin>
I guess that's a will see
<jeremyrubin>
But it's all to say we shouldn't design around expecting immediate access to historical chain data you yourself did not store when you could have
<jeremyrubin>
I should concretize my segregated inputs proposal at some point...
<tromp>
the chain analysis companies will always keep copies:-)
<jeremyrubin>
And wouldn't serve them to their potential competitors ;)
<tromp>
they'll sell it to whomever is paying the price:)
<jeremyrubin>
But also a reason to, if ZKPs get fast enough, propagate blocks without the data underneath
<tromp>
that's break in consensus model that will never happen
<jeremyrubin>
No not consensus
<jeremyrubin>
In p2p/networking
<tromp>
oh, to give miners a head start? sure
<jeremyrubin>
seg inputs: Basically if you make a new segwit style commitment to the inputs being spent in a txn, you don't need to spend them in the actual TX so you can discount all the inputs being spent in addition to the witnesses. The only issue with this is you need to move the value back on chain somehow. You can do that easily if you do this at the same time as CT.
<jeremyrubin>
tromp: no; you don't need to have block data to maintain consensus with the network. You need a *proof* that the tip you're mining on and utxo set are valid, and the prior tips to be able to reorg to.
<jeremyrubin>
The block is just that proof
<tromp>
yes, miners will take any reasoable proof that some tip is valid in order to mine on top
<jeremyrubin>
But, if you could provide an alternative proof the merkle root obeyed the consensus rules, that would be fine
<jeremyrubin>
tromp: yes, of course.
<jeremyrubin>
But if you have a reasonable proof, you don't need *more* neccessarily
<jeremyrubin>
Why would you care to get the extra bandwidth?
<jeremyrubin>
What benefit is it doing for you having it?
<jeremyrubin>
It hurts privacy
<jeremyrubin>
So you wouldn't share it
<jeremyrubin>
worse privacy --> decreases value of your Bitcoin investment
jungly has joined #bitcoin-wizards
<tromp>
if you seriously care about privacy then maybe bitcoin is not for you:-)
<tromp>
with that, let me thank you for sharing your thoughts and bowe out of this discussion
<jeremyrubin>
Hah, I was typing the same
<jeremyrubin>
People do sincerely care about privacy 'round these parts
<jeremyrubin>
But it's incremental progress for sure (btw the only serve ZKproof blocks is pretty close to what grin tries to do)
jungly has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
CryptoDavid has joined #bitcoin-wizards
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-wizards
ghost43 has quit [Remote host closed the connection]
rusty has joined #bitcoin-wizards
ghost43 has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
rusty has joined #bitcoin-wizards
rusty has quit [Client Quit]
bitdex has quit [Ping timeout: 240 seconds]
bitdex has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]