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
Linu741 has quit []
dfmb_ has quit [Quit: Leaving]
proofofkeags has quit [Remote host closed the connection]
proofofkeags has joined #bitcoin-wizards
mdunnio has quit [Remote host closed the connection]
proofofkeags has quit [Remote host closed the connection]
proofofkeags has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
SchwarzeLocke has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
laptop has quit [Ping timeout: 256 seconds]
tromp has quit [Ping timeout: 260 seconds]
proofofkeags has quit [Remote host closed the connection]
mdunnio has joined #bitcoin-wizards
proofofkeags has joined #bitcoin-wizards
proofofkeags has quit [Ping timeout: 260 seconds]
mdunnio has quit [Remote host closed the connection]
proofofkeags has joined #bitcoin-wizards
proofofkeags has quit [Ping timeout: 256 seconds]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 272 seconds]
Belkaar has quit [Ping timeout: 246 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
proofofkeags has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp_ has joined #bitcoin-wizards
proofofkeags has quit [Ping timeout: 260 seconds]
tromp__ has joined #bitcoin-wizards
tromp has quit [Ping timeout: 272 seconds]
tromp_ has quit [Ping timeout: 272 seconds]
tromp__ has quit [Ping timeout: 272 seconds]
Emcy has quit [Remote host closed the connection]
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
shush has quit [Ping timeout: 240 seconds]
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 260 seconds]
queip has quit [Ping timeout: 246 seconds]
queip has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 260 seconds]
shush has quit [Remote host closed the connection]
proofofkeags has joined #bitcoin-wizards
surja795 has quit [Remote host closed the connection]
tromp has quit [Remote host closed the connection]
bpalmer1 has quit []
proofofkeags has joined #bitcoin-wizards
proofofkeags has quit [Ping timeout: 256 seconds]
michaelfolkson has joined #bitcoin-wizards
michaelfolkson has quit [Quit: Sleep mode]
michaelfolkson has joined #bitcoin-wizards
surja795 has joined #bitcoin-wizards
surja795 has quit [Ping timeout: 260 seconds]
stoner19_ is now known as stoner19
tromp has joined #bitcoin-wizards
kers has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
Guyver2 has quit [Ping timeout: 256 seconds]
proofofkeags has joined #bitcoin-wizards
michaelf_ has joined #bitcoin-wizards
michaelfolkson has quit [Ping timeout: 240 seconds]
<michaelf_>
Hey. Does allowing people to use improved light client protocols really drive the full node count down?
<michaelf_>
The alternative is to push mobiles into using trusted servers. It is not light client or full node. It is light client or trusted server.
<michaelf_>
Pushing them towards trusted server by preventing light clients seems to be antithetical to Bitcoin trust minimization and permissionlessness?
<theStack>
i think that depends on how "full node" is defined. would you consider a node not serving filters for light clients still to the full node count?
<sipa>
i consider a node that does not serve anything at all, and isn't even discoverable by others on the network to be a full node
<michaelf_>
I would... You don't need to be accepting incoming connections to be a full node. You wouldn't need to be serving filters to be a full node
<michaelf_>
But I don't understand what relevance that has to my initial question(s). Can you explain?
<michaelf_>
We don't say there are zero full nodes today because none of them are serving filters
<theStack>
well, generally speaking, i'd say to answer the question "does x drive y down?", it makes sense to exactly define y first :)
<michaelf_>
Ok sure, gotcha!
<sipa>
"full node count" is also the wrong metric; the real thing that matters is how many independent parties run and *use* a full node
<sipa>
unfortunately, the real thing is very hard to measure
<michaelf_>
Ok so we are concerned with x = independent parties running and using a full node
<michaelf_>
Does allowing people to use improved light client protocols really drive x down?
<theStack>
sipa: michaelf_: i would agree on your definition of full node count, but isn't it that people are having doubts about the decrease of _listening_ full nodes?
<theStack>
in the end a high full node count is worthless if no-one would accept incoming connections
<sipa>
theStack: i don't care at all about that
<sipa>
(i would if the numbers dropped to dangerous levels, but there is no evidence of that)
<sipa>
i think serving the network and providing validation services are ultimately orthogonal services, and there is no reason why they need to be correlated, or even provided by the same software in the long term
<michaelf_>
x = independent parties running and using a full node OR x = independent parties running and using a listening full node
<michaelf_>
Does allowing people to use improved light client protocols really drive x down?
<michaelf_>
Obviously it is not certain. But it appears to me at least plausible that increased usage of light client protocols drives x up.
shush has joined #bitcoin-wizards
<michaelf_>
Otherwise their use will be inherently limited. And people will be driven to alternatives anyway
<sipa>
i don't see why it would drive x up?
<michaelf_>
In a world where every mobile is a light client, there will have to be more full nodes to serve them all filters
<theStack>
sipa: that makes sense; but couldn't it be that this "numbers drop to dangerous levels" is exactly the people opposing bip 157 are worried about?
<theStack>
im not having a concrete opinion yet by the way, still trying to grasp the full picture
<michaelf_>
Me too
<michaelf_>
Is there an argument that at some point in the long term future mobiles could all be running a pruned full node?
<sipa>
wellyou should ask the people who have such opinions
<sipa>
i suspect different people have different concerns; there are all sorts of incentive questions around light client use
<michaelf_>
By incentives you mean people have different visions for where their projects fit into their long term view of Bitcoin's future?
<sipa>
1) incentive to serve data on the network at all
<sipa>
2) costs of running a full node with increased protocol requirementa
<theStack>
sipa: sure there are a bunch of different concerns here, but i was referring specifically to the "worried about decreasing node count" one
<sipa>
3) incentives for miners to produce valid blocks if fewer independent validations happen
<sipa>
theStack: to me personally, the term "full node" is unrelated to services offered to the network
Guyver2_ is now known as Guyver2
lederstrumpf has left #bitcoin-wizards ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
<sipa>
theStack: and i suspect - but don't know - that most of the concerns about "dropping full node count" are about the question whether miners will remain incentivized to produce valid blocks if most of the ecosystem depends on outsourced validation - but i don't know
<theStack>
sipa: hmm but in the case of bip 157 being a full node is a requirement for creating the service information, or did i miss something?
<michaelf_>
In a worst case where x did drop materially post merging of serving filters is it plausible that it could be disabled in a future release? I know ideally Core would prefer to avoid these types of flip flop scenarios.
<sipa>
i think the question is rather: what if it becomes available by default, and people start building services that rely on having cheap/easy access to filters... to the point where it becomes infeasible to turn it off again
jb55 has quit [Remote host closed the connection]
<sipa>
theStack: sure, but creating the filters and serving them isn't the same; the latter could be done by HTTP/cloud services/satellite feeds/... too
<theStack>
the origin of a filter information (which is deduced from full blocks) has to come from a full node, i don't see an alternative here
<sipa>
theStack: same is true for blocks, in a way - you only know what blocks to serve by validating them yourself... but serving them does not increase the cost of validation
<sipa>
it's providing dumb data
<michaelf_>
But as I understand the plan with PR #18877 is that they won't be available by default? The question is whether this is a stepping stone to them being turned on by default?
<sipa>
tbf, my idea is that they should be softforked in at some point im the future (increasing validation cost for all full nodes), and then made available by default to the network... just because people really shouldn't be using unverifiable data from untrusted peers in general
<sipa>
i suspect that is even more scary to people who feel all increased light-client support is a bad thing
<sipa>
i also suspect not many people think this way, and envision using filters from untrusted peers - i don't know
jb55 has joined #bitcoin-wizards
<sipa>
it's still an improvement over bip37
<michaelf_>
So is there an argument that serving filters shouldn't be merged now as it should be done properly as a soft fork (assuming consensus)?
<theStack>
sipa: for some reason i thought that the probability of a full node serving wrong filter information is lower than from arbitrary network nodes
<sipa>
theStack: probability is not the right metric
<theStack>
but i can't really justify
<sipa>
i like this analogy: in civil engineering you design building to withstand random events (earthquakes) and think about probabilities to analyse that
<sipa>
in military engineering yoj design buildings to withstand attackd, and think about how costly an attack is
nuncanada has joined #bitcoin-wizards
<sipa>
theStack: full nodes cannot be distinguished from arbitrary network nodes
<sipa>
that's the point - the fullness only matters to its operator
<sipa>
because don't trust, verify, yada yada
jonatack_ has quit [Quit: jonatack_]
jonatack has joined #bitcoin-wizards
michaelf_ has quit [Ping timeout: 240 seconds]
<theStack>
but if serving the network and providing validation services are orghogonal services, maybe bitcoin core is not the right place to put bip 157 in but rather start a separate software project focussed on just serving filters?
<sipa>
eh, i was talking more theoretically over the long term
<sipa>
in the sense that in theory serving the network could be done by other things
michaelfolkson has joined #bitcoin-wizards
proofofkeags has quit [Remote host closed the connection]
AaronvanW has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-wizards
proofofkeags has joined #bitcoin-wizards
kers has quit []
bitdex has quit [Ping timeout: 240 seconds]
tromp has quit [Remote host closed the connection]
rottensox has quit [Quit: Bye]
justanotheruser has joined #bitcoin-wizards
Dimlock has joined #bitcoin-wizards
michaelfolkson has quit [Ping timeout: 240 seconds]
michaelfolkson has quit [Ping timeout: 240 seconds]
michaelfolkson has joined #bitcoin-wizards
michaelf_ has quit [Ping timeout: 244 seconds]
mdunnio_ has joined #bitcoin-wizards
davispuh has quit [Ping timeout: 240 seconds]
mdunnio has quit [Ping timeout: 260 seconds]
<yanmaani>
sipa: Miners have incentives, right?
<yanmaani>
Miners want to get txn fees, so they want for people to send txns, so they want to incentivize SPV node stuff.
surja795 has joined #bitcoin-wizards
davispuh has joined #bitcoin-wizards
Dimlock has quit []
michaelfolkson has quit [Quit: Sleep mode]
bsm117532 has joined #bitcoin-wizards
nuncanada2 has joined #bitcoin-wizards
nuncanada has quit [Read error: Connection reset by peer]
nuncanada2 has quit [Ping timeout: 246 seconds]
nuncanada has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
tromp has quit [Remote host closed the connection]
mauz555 has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
RandIter has joined #bitcoin-wizards
RandIter is now known as Guest44912
tromp has quit [Ping timeout: 260 seconds]
tromp has joined #bitcoin-wizards
surja795 has quit [Remote host closed the connection]
surja795 has joined #bitcoin-wizards
rottensox has joined #bitcoin-wizards
surja795 has quit [Ping timeout: 256 seconds]
marcoagner has quit [Ping timeout: 272 seconds]
davispuh has quit [Remote host closed the connection]
davispuh has joined #bitcoin-wizards
mdunnio_ has quit [Remote host closed the connection]
<belcher>
yanmaani if most of the economy uses SPV then miners also have an incentive to print more bitcoins than is allowed by the controlled supply
<yanmaani>
if say 1% still use non-SPV then that shit won't fly
<belcher>
so you're right that probably it wont be too hard to find the resources to host all this stuff, but it may not lead to an outcome most people want
<sipa>
yanmaani: i don't see how miners could influence/incentivize SPV node functionality
<yanmaani>
belcher: I imagine some large sites would run full nodes too
<belcher>
if only 1% of the economy uses full nodes then probably what would happen is bitcoin would split into inflation-bitcoin and original-bitcoin, and since 99% use inflation-bitcoin then that coin would end up winning having a higher liquidity/value/adoption
<yanmaani>
sipa: By providing the required full nodes.
<yanmaani>
If full nodes were to become extremely expensive, miners would run them
<yanmaani>
as a loss-leader
<belcher>
you're misunderstanding how full nodes work, it doesnt matter to you if someone else has a node, the only thing that matters to you is your own node
<yanmaani>
belcher: SPV could do fraud proofs.
<belcher>
if someone figures out a way to make those work them im all ears
<yanmaani>
"block X is fraudulent, blacklist all nodes who send it, the proof is [...]"
<yanmaani>
it's not hard, just inelegant
<yanmaani>
creating coins ex nihilo is provable
<sipa>
not everything is efficiently provable (e.g. block weight limit, excess subsidy, ... basically require the entire block as proof)
<sipa>
there are softforkable solutions to that, but that still has the issue that the indexes required to be able to efficiently create those proofs are many times larger than what is needed to just validate
<yanmaani>
You can just send the entire block though.
<yanmaani>
It'd just happen once per attack.
<sipa>
that doesn't work for doublespending proofs
<sipa>
which either require an index on the prover side for all spent coins ever, or a utxo set on the verifier side (=essentially a full node)
<yanmaani>
Seems like UTXO commitments would fix it
DeanGuss has quit [Ping timeout: 240 seconds]
<sipa>
yes
<yanmaani>
Why don't we have them? "perfect is the enemy of good" and accumulators?
<sipa>
at a pretty high cost
<yanmaani>
not that high?
<sipa>
it's an order of magnitude increase in I/O overhead for block validation
<sipa>
because you'd need to update every merkle leaf above modified entries
<sipa>
a stateless design like utreexo doesn't have that problem
<yanmaani>
Would something like a log-structured merge tree work better?
surja795 has joined #bitcoin-wizards
<sipa>
it needs to be indexed by txid to enable efficient proofs
<yanmaani>
I'm thinking basically you have multiple UTXO sets
<yanmaani>
And keep every one as a perfect tree
<yanmaani>
And make a proof for each tree
<yanmaani>
so you have tree 1, and then tree 2 which is a delta for tree 1, and then t3 which is a delta for (t1+t2), ...
justanotheruser has quit [Ping timeout: 246 seconds]