tcrypt has quit [Remote host closed the connection]
tcrypt has joined #bitcoin-wizards
tcrypt has quit [Ping timeout: 244 seconds]
amincd has quit [Quit: Page closed]
<gmaxwell>
nsh: the paper is dense IIRC; but the whole idea reduces to a kind of trivial idea (if I remember it correctly).
Tiraspol has quit [Ping timeout: 272 seconds]
<gmaxwell>
Basically say you have a block box that produces false proofs for a system; you want to use this to show that some underlying hard problem is not really hard (e.g. by using the black box to solve the hard problem). This is the normal black box reduction approach.
<gmaxwell>
They show that a succinct ZKP can be totally busted, and you can have an efficient attacker in a black box; and yet may still not be able to show any particular underlying hard function is insecure; because the black box may only produce false proofs for NP statements so complex that no one could possibly verify them; so you can't actually tell if the false proofs are false proofs.
<gmaxwell>
And so you cannot get an unconditional reduction where access to a blackbox false proof maker is guararenteed to tell you anything useful at all.
<gmaxwell>
Or at least that was my understanding of it.
skullum has quit [Quit: Leaving.]
<gmaxwell>
There is of course much more to formalize and complete the argument. I also think it had a limit that it doesn't hold if basically P==NP or if all cryptographic assumptions are actually false. :)
HostFat has quit [Ping timeout: 264 seconds]
Tiraspol has joined #bitcoin-wizards
Tiraspol has quit [Ping timeout: 240 seconds]
Relos has quit [Ping timeout: 272 seconds]
kaykurokawa has joined #bitcoin-wizards
bebijlia has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
jeremyrubin has quit [Remote host closed the connection]
elastoma has quit [Ping timeout: 255 seconds]
elastoma has joined #bitcoin-wizards
kaykurokawa has quit [Ping timeout: 276 seconds]
Quanttek has quit [Ping timeout: 264 seconds]
jeremyrubin has joined #bitcoin-wizards
mpmcsweeney has joined #bitcoin-wizards
jeremyrubin has quit [Ping timeout: 244 seconds]
NewLiberty_ has joined #bitcoin-wizards
llllllllll has quit []
<kanzure>
"The problem with this implementation is you can still drive the block size up easily and in not that much time. So block congestion is still a tool for the resource rich. A self-scaling method will require the block size to be able to go both ways. We basically need a formula that helps incentivize miners to keep the block size as small as possible while still allowing it to increase. Or put another way, one that punishes miners for ...
<kanzure>
... submitting larger blocks relative to the current max by reducing the next valid block size by some proportion of max / current block size (probably not a linear one). As TX fees become a larger percentage of miner revenue, miners will value scarcity in the block anyway, so ultimately we need a way to punish the network for more transactions. We know that miners still indirectly value more transactions because more transactions ...
<kanzure>
... implies more adoption, which implies more demand for BTC, which implies a better exchange rate. There's a way to balance these things, we just have to figure it out."
SubCreative has quit [Remote host closed the connection]
GGuyZ has joined #bitcoin-wizards
amincd has quit [Ping timeout: 246 seconds]
amincd_ has quit [Quit: Page closed]
erasmospunk has joined #bitcoin-wizards
hashtag has joined #bitcoin-wizards
iyrsx has joined #bitcoin-wizards
p15 has quit [Max SendQ exceeded]
p15 has joined #bitcoin-wizards
shesek has quit [Ping timeout: 265 seconds]
erasmospunk has quit [Remote host closed the connection]
priidu has joined #bitcoin-wizards
spinza has quit [Ping timeout: 256 seconds]
HostFat has joined #bitcoin-wizards
shesek has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
gill3s has joined #bitcoin-wizards
NkWsy has joined #bitcoin-wizards
wallet42 has quit [Ping timeout: 272 seconds]
NkWsy has quit [Ping timeout: 256 seconds]
b_lumenkraft has joined #bitcoin-wizards
NkWsy has joined #bitcoin-wizards
dEBRUYNE_ has joined #bitcoin-wizards
p15x_ has joined #bitcoin-wizards
p15_ has joined #bitcoin-wizards
p15 has quit [Ping timeout: 244 seconds]
p15x has quit [Ping timeout: 264 seconds]
Logicwax has quit [Ping timeout: 240 seconds]
hktud0 has quit [Read error: Connection reset by peer]
hktud0 has joined #bitcoin-wizards
dEBRUYNE_ has quit [Ping timeout: 255 seconds]
orperelman has joined #bitcoin-wizards
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
antanst has joined #bitcoin-wizards
kmels has joined #bitcoin-wizards
hearn has joined #bitcoin-wizards
gill3s has joined #bitcoin-wizards
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dEBRUYNE_ has joined #bitcoin-wizards
orperelman has quit [Ping timeout: 276 seconds]
s3gfault has joined #bitcoin-wizards
orperelman has joined #bitcoin-wizards
rusty has quit [Ping timeout: 256 seconds]
iyrsx has quit [Quit: Leaving]
uydxhc has joined #bitcoin-wizards
uydxhc has quit [Read error: Connection reset by peer]
p15_ has quit [Max SendQ exceeded]
p15 has joined #bitcoin-wizards
lclc has joined #bitcoin-wizards
Mably has joined #bitcoin-wizards
Logicwax has joined #bitcoin-wizards
andy-logbot has quit [Remote host closed the connection]
andy-logbot has joined #bitcoin-wizards
* andy-logbot
is logging
p15x_ has quit [Max SendQ exceeded]
p15x has joined #bitcoin-wizards
s3gfault has quit [Ping timeout: 240 seconds]
spinza has joined #bitcoin-wizards
SubCreative has joined #bitcoin-wizards
SubCreative has joined #bitcoin-wizards
NkWsy has quit [Remote host closed the connection]
priidu has quit [Ping timeout: 240 seconds]
sparetire has quit [Quit: sparetire]
NkWsy has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 252 seconds]
cpacia has quit [Quit: Leaving.]
NkWsy has quit [Remote host closed the connection]
lclc has quit [Ping timeout: 264 seconds]
sickpig has joined #bitcoin-wizards
NkWsy has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
sickpig has quit [Ping timeout: 256 seconds]
hashtagg has quit [Read error: Connection reset by peer]
hashtagg has joined #bitcoin-wizards
p15x_ has joined #bitcoin-wizards
orperelman has quit [Ping timeout: 256 seconds]
p15 has quit [Ping timeout: 240 seconds]
p15x has quit [Ping timeout: 264 seconds]
ThomasV has quit [Ping timeout: 244 seconds]
Relos has joined #bitcoin-wizards
p15x_ has quit [Max SendQ exceeded]
p15x has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
damethos has joined #bitcoin-wizards
hashtag_ has joined #bitcoin-wizards
lclc has joined #bitcoin-wizards
hashtag has quit [Ping timeout: 240 seconds]
p15 has joined #bitcoin-wizards
shesek has quit [Ping timeout: 245 seconds]
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Jaamg>
amincd_: my take on the subject (copy paste from the reddit thread): we should have as big of a blockchain as is technologically possible. After we have that, we let the market decide which transactions happen where. If as big of a blockchain as is technologically possible is not enough for all blockchain-preferred transactions, then Mike Hearn's Crash Landing is what happens.
<Jaamg>
but I'm just a random lurker
<gmaxwell>
The arguments on that page don't match our expirence with full blocks at the end of 2012/ beginning of 2013; not really make much sense to me no matter what the supply is that has no relation to the demand; blocks could be 200MB (ignoring the viability of that in general) but then someone could offer 201MB of load; just like in 2012 a single really inefficient service pushed the network against i
<gmaxwell>
ts limits.
<gmaxwell>
So that page really seems to be arging that blocks need to be unboundadly large because things will fail if they're full; but failure isn't what we observed previously.
<Jaamg>
I'm not saying that complete failure happens if the blocks are full. What happens is that not all blockchain-preferred transactions can not happen in blockchain.
shesek has joined #bitcoin-wizards
<Jaamg>
Maybe they happen somewhere else or maybe they don't happen at all.
<Jaamg>
s/can not/can
<gmaxwell>
yea, thats fair; it's also just a consequence of resource allocation; there is a actual true limit in the supply of well decenteralized network capacity... so not all potential users may be able to get to it.
<Jaamg>
yes, I agree
<Jaamg>
So it's kind of a trade off wheter the potential user is left out from the blockchain because of too tough tech requirements for running a node or too little capacity in the blockchain
<Jaamg>
maybe I'm just being captain obvious in this
<gmaxwell>
sipa says, if the size is too large the system is moot because no one can verify so the lack of security makes it worthless, if the size is too small it's secure but thats irrelevant because you can't get access. Equlibrium is someplace in-between.
NkWsy has quit [Remote host closed the connection]
NkWsy has joined #bitcoin-wizards
NkWsy has quit [Ping timeout: 264 seconds]
<Jaamg>
yes, I agree that too large blocks lead into a situation where only few "professionals" can upkeep a node. And few professionals are easier target for Jack-booted thugs. I guess what was missing from my original argument was what I meant by "as big as technologically possible"
amincd has joined #bitcoin-wizards
<gmaxwell>
yea, I think I actually understood you there. if I thought you meant possible at all.. well thats a ton; if you want to e.g. admit a full rack of equipment. :)
<Jaamg>
It's of course a hard question. I think that tech requirements should not be more than what is possible with "standard home computer / net" ...or maybe even "highish end home computer / net"
gill3s has joined #bitcoin-wizards
<Jaamg>
yea, I know you understood. But also noticed that my original argument was a little bit vague in that sense
<gmaxwell>
Jaamg: well I think more like 'using a small enough fraction of reasonably performant hardware/connectivity that its not a nussance'
<gmaxwell>
which also means it can run on somewhat less performant setups (but using most of its resources).
<gmaxwell>
e.g. ignoring the bad bufferbloat interaction, bitcoin core on a multimegabit cable connection and a modern i7 quad core with 16gb ram is basically unnoticable right now. But it still runs on the slowest DSL you're likely to find plus a rasberrypi; though using all the resources and behaving obviously slowly.
<gmaxwell>
This is important to because not all the world is the most developed parts of the world.
p15 has quit [Max SendQ exceeded]
<amincd>
the argument that past a certain average size of block, Bitcoin is simply not secure/useful, makes sense to me. However, what I see as the open question is: would the larger economy associated with more legitimate (non-spam) transaction data attract more users willing to run full nodes, thus compensating for the loss of full nodes from higher node operating costs
p15 has joined #bitcoin-wizards
<gmaxwell>
amincd: "number of nodes" is not a concern, it's not a capacity issue. If there was a capacity shortage; I'd plunk a credit card into ec2 and add a lot of capacity personally.
<Jaamg>
yes, it's important "what is behind a node"
<gmaxwell>
Node usage is a security issue; the criteria is how hard it is to violate the network's security properties due to users protecting themselves by not just trusting others.
<Jaamg>
what kind of services/users/etc
<amincd>
gmaxwell, number of independent parties running full nodes?
<gmaxwell>
someone that just starts up a bunch of ec2 nodes isn't really helping on this... it may add some somewhat useful capacity; but capacity can be added in many ways. outright capacity doesn't strictly need much decenteralization.
<gmaxwell>
amincd: and amount of economic activity indivigually protected by their own nodes.
<fluffypony>
node centralisation is far more concerning than miner centralisation
<fluffypony>
with miner centralisation they can certainly be selfish, but they can't change the rules without the vast array of non-mining nodes rejecting their blocks
<amincd>
SPV users trust others, yes, but it's not trust of the same manner that underpins a classic bank-customer relationship. It's only trusting that >50% of mining power is not trying to defraud them, and trusting that they are not isolated from the network and connected exclusively to cancer nodes
<fluffypony>
with node centralisation the small handful of node operators can change the rules at their discretion
<Jaamg>
i think node centralisation only becomes a problem when it becomes possible to coerce node-runners
<gmaxwell>
node decenteralization is what keeps miners on good-ish behavior even if miners are too centeralized; not that the latter isn't a serious concern too (e.g. due to the potential for censoring transactions)
Crowley2k has joined #bitcoin-wizards
<gmaxwell>
amincd: right the combination of mining centeralization (which we have pretty terribly right now) and node centeralization is not good however.
p15 has quit [Max SendQ exceeded]
<amincd>
what kind of selfish attacks are miners going to do because to low a percentage of Bitcoin users runs full nodes?
<fluffypony>
Jaamg: you don't even need to coerce them, they'll eventually just come together and say "you know, we're operating the 10 nodes around the world, and we don't get paid for it. Let's institute a small, 2%-of-value fee that gets paid to us for our trouble."
<gmaxwell>
amincd: lets be clear when you say "that >50% of mining power is not trying to defraud them" you mean "so long as a group of largely anonymous self selecting dozen or so parts (and maybe as few as 4 or 5) are not trying to defraud them".
<amincd>
*too low
<gmaxwell>
s/parts/parties/
p15 has joined #bitcoin-wizards
p15x_ has joined #bitcoin-wizards
<gmaxwell>
fluffypony: or screwing people in other ways like monitoring transactions and selling the data.
<fluffypony>
yup
<Jaamg>
fluffypony: i think we really can't avoid that, we already have the nodes that have that power
<amincd>
gmaxwell so would hashing power being split amongst a larger number full node running miners address the main security threat that emerges from high node operating costs?
<gmaxwell>
Jaamg: depends on how cemented it is; in todays world mining is at least fundimentally open access; anyone who wants to pay the energy costs can do it.
<Jaamg>
gmaxwell: but i meant nodes like coinbase, xapo, bitpay etc...
<gmaxwell>
Jaamg: even there; their behavior is backstopped by the very real threat of customer flight.
<fluffypony>
Jaamg: they can't change the rules without forking themselves off the network
p15x has quit [Ping timeout: 264 seconds]
<fluffypony>
I mean, I run in excess of 10 nodes, and none of them can be coerced into changing the rules or selling the data
<gmaxwell>
amincd: the direct one would be improved; there are indirect ones; e.g. higher validation costs is a pressure (in several respects) for miners (and other nodes) to centeralize.
<fluffypony>
so if CoinBase decides to do its own thing it won't make the smallest iota of difference to me
<Jaamg>
fluffypony: where dfo you think users go if coinbase, bitpay, xapo and circle decide to fork their own network, to their network or the one where you have 10 no-coerced nodes running?
<gmaxwell>
My point was more like if someone shows up and starts saying "Coinbase, you need to block all transactins that we haven't approved of..." coinbase would naturally push back hard because such a move would put them out of business.
RoboTeddy has joined #bitcoin-wizards
<amincd>
gmaxwell doesn't this become moot if something like GBT gets adopted? in that scenario, hash power contributors can rely on any full node for tx data
<gmaxwell>
Jaamg: depends on what they were doing? e.g. to compete with bitcoin? or to act as a private clearing system between each other? The latter sounds completely reasonable to me.
<fluffypony>
Jaamg: there are enough alternatives for merchants and users that it would be self-decimating for them to do so
<davout>
Jaamg: also nobody cares about 1mn users with a couple of pennies each
<gmaxwell>
amincd: random nodes don't expose GBT, its a fairly expensive rpc call. and gbt has bandwidth usage linear in the block size; even at 1MB blocks that is a major reason many have refused to use it for remote pools.
Crowley4k has joined #bitcoin-wizards
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Jaamg>
fluffypony: exactly
<amincd>
gmaxwell thank you for the information
<Jaamg>
davout: i don't see your point
<davout>
Jaamg: the point is what you see as 'big' entities are not that relevant
<Jaamg>
not that relevant compared to what?
<davout>
compared to what is actually needed to push the network one side or the other of a potential hard-fork
<Jaamg>
nobody knows what is actually needed. my point is that coinbase's node is more significant than the one that say, I, would be running
<fluffypony>
more significant to its users, sure
<fluffypony>
not significant to the network as a whole
<Jaamg>
but this all is now kind of a sidtrack from what I was discussing with gmaxwell earlier
<amincd>
if mining revenue were to increase proportionally to block size, wouldn't the share of revenues that a pool pays for full node operation remain constant?
<Jaamg>
fluffypony: exactly
<amincd>
->assuming it has the same share of total network hashrate
<gmaxwell>
amincd: assuming the costs were all linear? then proportionally, but then say you are spending $$$$ now on those costs and by combining with 4 other miners, you can turn that into $.. more profit, hurray.
<gmaxwell>
so you could centeralize now and cut your validation related costs by the amount of centeralization; but if those costs are small in absolute numbers... why bother.
RoboTeddy has quit [Remote host closed the connection]
<amincd>
gmaxwell perhaps pools perceive everything relatively. For a pool making $1 mill a month, a $100 validation expense is just as significant as a $1000 validation expense for a pool earning $10 mill a month
hashtag_ has quit [Ping timeout: 272 seconds]
<amincd>
Jaamg I saw your response in the thread. my question is: what is the largest blockchain technologically possible? Is it the maximum size at which a typical user can run a full node. or a top 20% user? what determines the right size and why?
<Jaamg>
amincd: yea, sorry, the argument is a bit vague in that sense. We discussed it a bit earlier here.
<Jaamg>
I have no answer to what or who should determine it, and I can only vaguely say something like "the limit should be as high as possible but not higher than what makes running a full node with home computer / net impossible"
Burrito has joined #bitcoin-wizards
<Jaamg>
i think 1MB is definitely below that limit, and I also think that 20MB is below that limit
<Jaamg>
but maybe the limit still shouldn't be more than 20MB at this point
hashtag has joined #bitcoin-wizards
hashtag has quit [Ping timeout: 240 seconds]
<gmaxwell>
Jaamg: what evidence draws you to the conclusion that 1MB is below that limit?
<gmaxwell>
Trends in node deployment now at the 0.4MB average block size level appear to be evidence that 1MB may be too high. :( (not that I'd seriously suggest reducing it further right now)
<davout>
Jaamg: i think 1mb is actually too big wrt the UTXO size
<davout>
even gavinandresen says so, if i understand correctly, the upper bound on UTXO growth per year is sthg like 50gb with a 1mb max block size
<gmaxwell>
actually somewhat more I think, because in the worst case the utxo growth I think can be somewhat bigger than the block.
<gmaxwell>
but close enough.
lclc has quit [Ping timeout: 240 seconds]
<gmaxwell>
it's hard to say there are a lot of low hanging things we've been fixing; huge speedups. It may be with all of them deployed the negative trends will reverse.
<gmaxwell>
and it'll become clear that 1MB is indeed below that level.
<gmaxwell>
davout: I had suggested several times in these blocksize discussions that if there is any change the new limit should incorporate UTXO size impact. ... but a fundimental problem is that people pushing hard for uppled limits (1) want no limit at all, and (2) don't see any/many risks problems; and so there is no incentive to even discuss things more complex than remove/increase the limit.
<Jaamg>
davout: yes, I'm looking this more from systemic/incentives perspective. I should not be the one who decides what is "as high as is technologically possible", I just said what is my understanding
<gmaxwell>
e.g. to incorporate the UTXO impact you get rid of the "size" limit and make it a cost limit, and assign costs to size, utxo increase, and negative cost to utxo decrease...
<gmaxwell>
likewise the curently pretty braindamaged sigops limit can be turned into cost.
<Jaamg>
davout: I can't argue against what you just said. if you are correct than I must assume that we are simply closer to Mike Hearn's Crash Landing
<Jaamg>
*then
<Jaamg>
i was hoping more was technologically possible
<davout>
Jaamg: sure, onchain changetip will crash, bitcoin can still be the backbone
amincd has quit [Ping timeout: 246 seconds]
* gmaxwell
continues to protest the "crash" comparison; as that wasn't what we saw before; it seems insane to conjecture it now. We can't ever be sure things will be okay... but assuming it will crash is basically an assumption that it can _never_ work, since it can always be overloaded to arbritary levels.
<Jaamg>
current blockchain can't be the backbone if, say, 5,000,000 new users suddenly want to make a single paper wallet, which i see as a potential crash landing scenario
<gmaxwell>
5,000,000 it'll take 8-10 days to claear; similar to not great luck on an international wire transfer.
kmels has quit [Remote host closed the connection]
oleganza has joined #bitcoin-wizards
<gmaxwell>
doesn't sound like a "crash" to me, esp when you're paying to a piece of paper in a box; which won't tend to mind when the payment takes a while!
<Jaamg>
it might be rather dissappointing from "future payment system"
<gmaxwell>
Jaamg: the fact that you don't get instant soft irreversability is a much more immeidate "dissapointment" from a "future payment system"
<Jaamg>
i agree that crash landing was a bit exaggerated term, in the blog Hearn still described something similar what davout just said
GGuyZ has joined #bitcoin-wizards
<gmaxwell>
Bitcoin is a currency and a payment system; the demands of being a secure decenteralized currency make it not very impressive as a payment system by conventional metrics; fortuantely it's powerful enough to securely overlay better payment systems on top (and has other features like smart contracts).
<gmaxwell>
well on-chain-changetip isn't a think AFAIK; they clear all that stuff offchain on a centeralized system (which is probably reasonable enough for the value levels involved)
<Jaamg>
yes, but point is that 'crash landing' should not be understood as a total destruction. It just means huge disappointments to many
<Jaamg>
life goes on but "bitcoin wasn't the future currency/payment system after all"
<gavinandresen>
gmaxwell: what time zone are you in?
<gmaxwell>
pacific but wrapping over night and getting only 4 hours of sleep; which I'm overdue for. :(
<Jaamg>
i guess after that line might be a good point to say big thanks to all you devs for the great work you're doing
<gavinandresen>
gmaxwell: I took some melatonin last night, FINALLY got 8 hours….
<gmaxwell>
yea, thats actually too effective for me, I need like a 0.5 mg dose or I feel like I got hit with a bus the next day... on top of the general bitcoin activity pieter and rusty are in town right now. I'm actually sleeping okay, just due to staying up until I'm exhausted; but having to get up a couple hours later is not so great. :)
<kanzure>
don't let a timezone stop you
sickpig has joined #bitcoin-wizards
<gavinandresen>
in college I think I found my natural sleep cycle is something like 10 hours asleep, 18 hours awake….
<lmatteis>
lol
<gavinandresen>
I was spending a lot of time in a dank basement on a big greenscreen terminal
<gielbier>
i miss those green/black screens.
<kanzure>
gavinandresen: when you said (in email) you wont reply to issues raised on irc, what did you mean?
<kanzure>
or rather, your actual statement was something like, "it must be in the form of a pull request" (but that doesn't make sense-- pull requests don't seem like a good option for log delivery)
<gavinandresen>
kanzure: I don’t know… I probably meant I can’t respond to every issue raised on IRC because I am not on IRC 24/7
<lmatteis>
what's your favorite color?
<fluffypony>
blue
<kanzure>
gavinandresen: i am curious if you feel the same way about email
williamdunne has joined #bitcoin-wizards
<gavinandresen>
kanzure: if it is an issue with Bitcoin Core, then it should be an issue on github.
<gavinandresen>
kanzure: if it is an issue with something I wrote on a blog post, then email is fine, but I get a flood of email so don’t expect 100% response
<kanzure>
do you read all email anyway?
<lmatteis>
i get 0 email :(
<gavinandresen>
kanzure: yes, I read all email. I don’t have time to respond to it all
<gavinandresen>
kanzure: … and I have a pretty aggressive spam filter....
<kanzure>
sounds like we should dump all emails from bitcoin-development straight into github issues, then
<lmatteis>
kanzure: why do you care so much?
Quanttek has joined #bitcoin-wizards
<gavinandresen>
kanzure: if you don’t like the process, then please, suggest a better way. I do also read every message to bitcoin-development mailing list, you can bring things up there.
<kanzure>
lmatteis: he's basically saying that he can't respond to all possible issues unless they are in the issue tracker
<gavinandresen>
For general questions, the bitcoin stackexchange is the right place.
<kanzure>
gavinandresen: er, does that mean you don't think the email2issue idea was good?
<gavinandresen>
kanzure: I’m not sure what you mean by “issue”
<lmatteis>
kanzure: what's your point?
oleganza has quit [Quit: oleganza]
<kanzure>
lmatteis: i was answering your question
<gavinandresen>
kanzure: … and this is off-topic for bitcoin-wizards, anyway
<kanzure>
fair enough
<lmatteis>
yup, we only discuss about magic here
<fluffypony>
and favourite colours
erasmospunk has joined #bitcoin-wizards
<lmatteis>
is anybody experienced in DHTs here? i'm trying to find a simple solution of broadcasting messages in a DHT network by having peers listen on a specific key
erasmosp_ has joined #bitcoin-wizards
<lmatteis>
however, i'm afraid that has implications with regards to having too much data stored near the decided key
sickpig has quit [Ping timeout: 246 seconds]
erasmospunk has quit [Ping timeout: 250 seconds]
belcher has joined #bitcoin-wizards
bsm117532 has joined #bitcoin-wizards
oleganza has joined #bitcoin-wizards
jhogan42 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
GGuyZ has quit [Quit: GGuyZ]
Crowley4k has quit [Quit: Connection closed for inactivity]
b_lumenkraft has quit [Quit: b_lumenkraft]
GGuyZ has joined #bitcoin-wizards
erasmosp_ has quit [Ping timeout: 264 seconds]
<nsh>
gmaxwell, sorry i dozed off before seeing your synopsis of the argument against falsifiable assumptions in succinct ZK argument systems
sparetire_ has quit [Ping timeout: 272 seconds]
<nsh>
i does make intuitive sense after a little thought. it's eventually a counting argument so you can gloss the formalism a little without danger
<nsh>
*it
shesek has quit [Ping timeout: 255 seconds]
b_lumenkraft has joined #bitcoin-wizards
<nsh>
can we have a sufficiently high degree of confidence in probabilistically-checkable proofs within zero-knowledge
<nsh>
argument systems, if there is a restriction in the complexity of the asserted statements in terms of circuit depth?
<nsh>
for bitcoin-y type applications, we are tending to want to prove relatively simple statements, aren't we?
<nsh>
static-soundness suffices for zerocoin-likes, i think
grandmaster has joined #bitcoin-wizards
shesek has joined #bitcoin-wizards
b_lumenkraft has quit [Read error: Connection reset by peer]
b_lumenkraft_ has joined #bitcoin-wizards
uydxhc has joined #bitcoin-wizards
grandmaster has quit [Ping timeout: 244 seconds]
c0rw1n is now known as c0rw|away
priidu has joined #bitcoin-wizards
hashtag has joined #bitcoin-wizards
Crowley2k has quit [Quit: Leaving]
Crowley4k has joined #bitcoin-wizards
sadoshi has quit [Remote host closed the connection]
sadoshi has joined #bitcoin-wizards
belcher has quit [Quit: Leaving]
grandmaster has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
droark has joined #bitcoin-wizards
hashtag_ has joined #bitcoin-wizards
bsm117532 has quit [Quit: Leaving.]
hashtagg has quit [Ping timeout: 272 seconds]
gill3s has joined #bitcoin-wizards
oleganza has quit [Quit: oleganza]
zooko has joined #bitcoin-wizards
sparetire has joined #bitcoin-wizards
oleganza has joined #bitcoin-wizards
damethos has quit [Remote host closed the connection]
damethos has joined #bitcoin-wizards
p15x_ has quit [Max SendQ exceeded]
p15x has joined #bitcoin-wizards
Mably_ has joined #bitcoin-wizards
shesek has quit [Ping timeout: 240 seconds]
Mably__ has joined #bitcoin-wizards
nuke1989 has joined #bitcoin-wizards
Mably has quit [Ping timeout: 244 seconds]
Mably__ is now known as Mably
Mably_ has quit [Ping timeout: 272 seconds]
NkWsy has joined #bitcoin-wizards
metamarc has quit [Ping timeout: 240 seconds]
Tiraspol has joined #bitcoin-wizards
Tiraspol has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
shesek has joined #bitcoin-wizards
roconnor has joined #bitcoin-wizards
williamdunne has quit [Ping timeout: 265 seconds]
NkWsy has quit [Remote host closed the connection]
shesek has quit [Ping timeout: 240 seconds]
wallet42 has joined #bitcoin-wizards
zooko has quit [Remote host closed the connection]
jeremyrubin has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
temujin has joined #bitcoin-wizards
shesek has joined #bitcoin-wizards
NkWsy has joined #bitcoin-wizards
amincd has joined #bitcoin-wizards
<amincd>
As far as I can tell, with all factors being held equal, as long as mining revenue and scale of economic activity (including number of users) scales linearly with block size, the number of full nodes, and most importantly, the number of full node running miners that are contributing to the network hashrate, should stay constant.
ThomasV has joined #bitcoin-wizards
<Jaamg>
are there any technical reasons why certain number of nodes is needed?
<amincd>
if 1 billion people want to use Bitcoin, we can either have a hard limit that forces most of them to move BTC on the chain through intermediaries, but allows most of them to still audit the chain themselves, or the converse of allowing most of them to move BTC with their own private keys, but makes most of them dependent on others for auditing
<Jaamg>
i'm thinking something like will slow propagation / latency become an issue
<amincd>
Jaamg the main assumption is that Bitcoin security requires every user to be able to run their own full node. But I would argue that there's a case to be made that as long value density of tx data remains constant, systemic security shouldn't suffer. Propagation
antanst has quit [Quit: Leaving.]
<davout>
that doesn't make much sense, either you can check the full transaction history independently, or you don't
<amincd>
I don't see any theoretical limits to bandwidth, that would prevent propagation of lot of tx data
skeebop has joined #bitcoin-wizards
<amincd>
davout if you can't audit the chain yourself, your own security suffers, but necessarily systemic security
<davout>
you mean 'not necessarily', right?
<Jaamg>
amincd: i agree that it's crucial that "anybody" can become a Bitcoin node at will. It will not be Bitcoin anymore if this property is taken away
<davout>
either way, 'systemic security' is quite nebulous
<davout>
and therefore irrelevant
<Jaamg>
but i was thinking of situations where perhaps nodes around the globe are too sparse which could cause problems. I don't know if this is possible, that's what i was asking
<kanzure>
heh an amusing problem for all of the proof-of-publication stuff: "Does a 60 year old archive of a block-chain that "lived" for 15 years of any value? It could probably be "faked" with a cluster of machines and some time?" (the answer is yes)
jtimon has quit [Ping timeout: 240 seconds]
<amincd>
Jaamg, but even if 'anybody' can become a Bitcoin node, they anybody can't directly 'use' Bitcoin, by moving BTC on the chain with their own private keys. So one way or another, 'full access' to Bitcoin under a scenario with 1 billion users is limited to the rich
oleganza has quit [Quit: oleganza]
<amincd>
Better that the masses can move BTC with their own private keys, and trust the full nodes doing mining, then have no way to move BTC on the chain themselves, and have to trust bank like entities
<amincd>
End user claims have to be stored on off-chain ledgers, controlled by TTPs, with a block size that doesn't meet global demand, meaning auditing the chain yourself is pointless for the average user who can't afford to move BTC on the chain with their own private keys
<amincd>
the issue is one of systemic risk IMO, and that hasn't been convincingly shown to suffer as block sizes increase in proportion to mining-revenue/scale-of-economic-activity
<amincd>
favour yes I meant 'not necessarily'
<Jaamg>
the systemic risk i see with too big blocks is if running a full node becoming too expensive or otherwise impossible
<amincd>
autocorrect. favour = davout
<Jaamg>
i don't think we are anywhere near that point, but say, if there wasn't any limit then this could happen if blockchain transactions become very popular
<amincd>
Jaamg, going back to my earlier point: As far as I can tell, with all factors being held equal, as long as mining revenue and scale of economic activity (including number of users) scales linearly with block size, the number of full nodes, and most importantly, the number of full node running miners that are contributing to the network hashrate, should stay constant.
<skeebop>
honestly if we build the infrastructure right 7 tps might just be fine
PRab_ has joined #bitcoin-wizards
<skeebop>
suppose we only needed bitcoin for things on par with SWIFT settlements. SWIFT does something like 200 tps. with payment channels, we can probably bring that down quite a bit. there should be very little reason ever to publish to a blockchain unless you're opening a channel or closing due to conflict
<Jaamg>
amincd: i don't see why we should care about the number of full nodes as long as it's possible for anybody to launch a node
<amincd>
I don't think the fundamental security properties of Bitcoin degrade as long as the average value density of transaction data
<Jaamg>
and unless there are any technical reasons (maybe issues with too slow propagation etc)
<amincd>
remains constant.
PRab has quit [Ping timeout: 256 seconds]
PRab_ is now known as PRab
<amincd>
Jaamg I don't see why we should care about 'anybody can launch a full node' more than 'anybody can move BTC on the blockchain with their own private keys'
<Jaamg>
amincd: i think that's the same thing expressed in two different ways
PRab has quit [Client Quit]
<skeebop>
its not quite. long term it can become too expensive for the average fella to transact on chain. but it ought NEVER be too expensive to validate the chain on commodity hardware
PRab has joined #bitcoin-wizards
<amincd>
Jaamg not following you. You can move BTC on the blockchain with your own private keys without running a full node, by using SPV. Better to trust the mining collective than a bitbank
gill3s has joined #bitcoin-wizards
<Jaamg>
amincd: oh yeah, now i see
<Jaamg>
wait a sexc
<amincd>
skeebop why is the former less important than the latter?
<Jaamg>
sec :)
metamarc has joined #bitcoin-wizards
<skeebop>
because micropayment channels will suffice
<skeebop>
and realistically we will not be able to keep tx fees down given PoW drawbacks and the inflation taper
<Luke-Jr>
amincd: what good are your own private keys, if you're trusting someone else to tell you what money you have/control with them? ;)
<skeebop>
so as long as anyone can validate, its fine to trust third parties for setting up channels and so on because you can check up on them
<Jaamg>
amincd: what Luke-Jr said
<amincd>
skeebop, at some adoption levels, they do not. If the Lightning Network was globally adopted, most people would have to use bit banks, with current block sizs
<skeebop>
slash what Luke-Jr said lol
<skeebop>
and thats fine, because they can validate/monitor the bitbanks
<Luke-Jr>
amincd: Lightning makes it easier to *not* use banks
<skeebop>
and anyone can start one
<skeebop>
well but you still need funding txs. and if its too expensive the bitbanks will help you set those up
<amincd>
Luke-Jr Lightning Network requires 130 MB blocks for every person on Earth to use. therefore everyone won't be able to use if we don't raise the block size
<skeebop>
lol what?!
<Luke-Jr>
amincd: uh, compare apples to oranges?
<skeebop>
you mean if everyone opens their channel all at once ....
<Luke-Jr>
130 MB is far better than 1 TB (non-Lightning)
<skeebop>
I'm still pushing for 1MB
<Luke-Jr>
skeebop: "for every person on Earth"
<Luke-Jr>
if we bump up against 1 MB with Lightning, I'm all for raising it..
<amincd>
Luke-Jr what good is auditing the chain when your claim to BTC is held on a TTP ledger and only as good as ability of the TTP to honour it
<skeebop>
ok so for every person on earth to open a payment channel on bitcoin with 7 tps will take 4.5 years
<skeebop>
totally legit :)
<Luke-Jr>
amincd: TTP?
<amincd>
Trusted Third Party, e.g. a bitbank
<skeebop>
who said anything about their ledger?
<Luke-Jr>
amincd: I don't advocate that.
<Luke-Jr>
amincd: Lightning is not TTPs
<Luke-Jr>
it uses UNtrusted third parties
priidu has quit [Ping timeout: 276 seconds]
<amincd>
skeebop, everyone on Earth can't use the Lightning Network with the current block size. most people would need to access it through intermediaries, meaning they would have their claim to BTC stored off-chain on the ledger of TTPs
<skeebop>
sure they can! itll just take 4.5 years to open a channel for each one ...
<skeebop>
1000000000/7./60/60/24/365
<amincd>
Luke-Jr everyone on Earth can't use the Lightning Network if we assume the block size has to be small enough to allow everyone to run a full node
<skeebop>
oh shit theres 7billion not 1. ok so 30 years. maybe not as great
jeremyrubin has quit [Remote host closed the connection]
<Luke-Jr>
amincd: this is not true
<Luke-Jr>
130 MB blocks will be reasonable long before everyone on Earth has technology
<amincd>
130 MB..
<skeebop>
ya I'll give you max 2MB
<skeebop>
:D
<amincd>
Luke-Jr if everyone on Earth decides they want to use Bitcoin tomorrow, they would have to use bitbanks, whether the LN is in place or not, if we assume that the only acceptable scenario is one where the average user has to be able to run a full node
<Luke-Jr>
everyone on Earth WON'T decide they want to use Bitcoin tomorrow
<amincd>
it's not a sound principle IMO
<skeebop>
fortunately for us, every one on earth will not want to use bitcoin tmrw. lets start opening payment channels for those who do asap
ThomasV has quit [Ping timeout: 264 seconds]
<amincd>
the fact that it doesn't work in theory shows the principle underlying it is unsound. the principle should work under any adoption level
wallet42 has joined #bitcoin-wizards
<skeebop>
mmm no it shouldnt. this is practical engineering not theoretical
GGuyZ has quit [Quit: GGuyZ]
<amincd>
skeebop the insistence on limiting tx data so that the average person can run a full node is not justified by practical engineering IMO
<skeebop>
ah fair point. but thats one of the design criteria'
<skeebop>
the client demands, at all costs, that the average person can run a full node
<skeebop>
now go be a practical engineer around that ;)
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<amincd>
skeebop and I'm arguing that it's quite possibly an unsound design criteria
<skeebop>
unsound meaning what?
<amincd>
meaning that it doesn't maximise utility for the world
<skeebop>
impossible? untenable? dumb? not necessary?
gill3s has joined #bitcoin-wizards
<amincd>
better to allow more txs to be generated as demand for txs increases
<skeebop>
well i think its arguable. theres no really nice way to quantify the tradeoff
<amincd>
as long as txs meet the value/fee requirements
<skeebop>
i think it would do us well (and maybe even maximize utility) to be as creative as possible within these constraints before releiving them
<amincd>
skeebop thought experiments like 'everyone on Earth wants to use Bitcoin, what do we do' help inform whether the trade-offs are right
<skeebop>
undeniably. but the answer shouldn't be "sacrifice key design criteria"
<amincd>
the design criteria should make the optimal tradeoffs. It shouldn't be defended blindly.
<skeebop>
the challenge is to make the optimal tradeoffs given the design criteria
<amincd>
we need the right design criteria.. the current one is very possibly not right IMO
kmels has joined #bitcoin-wizards
<skeebop>
bitcoin is like science. we want people to be able to use it and independently validate it. explosion in the former has crippled the latter, arguably to our detriment
<skeebop>
thinking especially in biomedical sciences
<amincd>
well, that assumption doesn't seem right to me, for reasons I explained earlier
<skeebop>
ok i dont want to get carried away on the analogy cuz itll break down soon. but you really suppose sacrificing the "anyone can verify" property is worth it?
<amincd>
skeebop yes absolutely. Verifying it is useless if you can't store your tx on it
<skeebop>
personally i'd rather see it done with atomic-swaps to alt-chains + payment channels rather than bumping the block size too soon
<skeebop>
so maybe slow and steady growth in blocksize is warranted. but this protocol is so damned precarious I can't help feel itll crumble over itself
priidu has joined #bitcoin-wizards
<amincd>
the idea that tx data should be limited to ensure everyone can verify, when the same limit ensures everyone can't store, is unsound, regardless of efficiency improvers like the LN and sidechains
<skeebop>
everyone can store, we just need to be more creative ;)
<amincd>
skeebop any reason for your belief that'll crumble with more tx data (higher operating node costs) ?
<Jaamg>
amincd: it's not about 'everyone can verify' it's about not needing to trust other party if you want to broadcast
<amincd>
Jaamg, but with limits on tx data, everyone can't broadcast txs anyway
<skeebop>
ya so higher node costs but thats separate, i mean unpredictable side effects from a seemingly innocuous change
<skeebop>
software bugs are hard :'(
<amincd>
Jaamg better to be able to create your own txs and trust miners and the sample of full nodes you poll, then not be able to broadcast your own txs period
<skeebop>
but the fees are going to be so high that you'd be crazy to do that anyways ...
<skeebop>
you know, unless we move to proof of stake, but I hear you can get shot for speaking such blasphemy around here
<amincd>
skeebop tx fees don't need to increase for total mining revenue to scale linearly with block size. As for PoS, it can't establish secure distributed consensus
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Jaamg>
amincd: we have limit now and everyone can broadcast
<skeebop>
so fees right now are a couple orders of magnitude below inflation so not sure how you expect revenue to scale without jacking fees. and PoS can, please don't cite the Polestra paper, let's not get into it now ;)
droark has quit [Quit: ZZZzzz…]
<amincd>
Jaamg, under the design goal of one person = one node, this breaks down at some adoption levels.
frankenmint has joined #bitcoin-wizards
<Jaamg>
amincd: yes, i think we should have as big max block size as possible while still keeping the property 'anybody can become a node'
<Jaamg>
if transactions hit that limit some day we have a positive problem
<amincd>
Jaamg I don't think one person = one node makes sense, for reasons I provided. I guess we can go in circles forever on this
<Jaamg>
or ehm, maybe not positive but more positive than "should we increase the 1MB limit"
<Jaamg>
amincd: it doesn't need to be one person = one node, the point is that the possibility must be there
<amincd>
Jaamg Yeah I understand that. I disagree that this is the optimal design goal, for ressons I provided
<Jaamg>
amincd: it doesn't need to be 1 person = 1 newspaper, but there must be the possibility for anybody to start a newspaper
<amincd>
everyone being able to create and store a tx on the Bitcoin blockchain, if it does not create systemic risks, and I don't see any compelling arguments that it does
<amincd>
.. is essential
skeebop has quit [Ping timeout: 252 seconds]
gill3s has joined #bitcoin-wizards
<jgarzik>
amincd, OK. So - we need a network that supports... 1B mobile phones?
<jgarzik>
Must quantify, not wave hands in the air.
<jgarzik>
Paypal rate is 130 tps. VISA is 2000 tps.
<jgarzik>
In the bitcoin system, a single computer needs to be able to process 100% of the worldwide traffic.
arubi_ is now known as arubi
<amincd>
jgarzik, if it doesn't introduce systemic risk, I don't think there should be any limit to what the network supports. If the world demands 1 million tps, and is willing to pay fees for them, the network should support it, if it's not found to be systemically unsound
Quanttek has quit [Ping timeout: 272 seconds]
<amincd>
jgarzik why does a single a computer need to be able to validate global traffic?
<jgarzik>
amincd, Because that is how bitcoin is designed
<amincd>
not according to Satoshi's original description
<jgarzik>
It's nice to be able to wave a hand and say "it should do X" but that is not how reality works.
<jgarzik>
amincd, Yes, according to Satoshi's description
metamarc has quit [Ping timeout: 240 seconds]
<jgarzik>
amincd, Every bitcoin node validates 100% of the blockchain traffic, because it does not trust other nodes.
<jgarzik>
amincd, In your system, that means every computer must handle 1 million tps all by itself, as well as copying 1 million tps to several other nodes, as well as serving data to 1 billion mobile phones
<amincd>
jgarzik every computer being able to validate global traffic wasn't an origins design goal of Bitcoin
<amincd>
*original
antanst has joined #bitcoin-wizards
<jgarzik>
amincd, full nodes being able to validate 100% of global traffic was and is design goal of bitcoin
<jgarzik>
amincd, lightweight clients are in a separate category, referred to in this conversation as mobile phones - non validating nodes which are more populous
<amincd>
jgarzik the quote by Satoshi that I linked to directly contradicts your claim
<jgarzik>
amincd, no it doesn't. I just explained the context.
<amincd>
The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.
<jgarzik>
re-read what I just wrote
<amincd>
jgarzik I did and, with all due respect, it's not an accurate description of Satoshi's statement.
<jgarzik>
amincd, sigh, You need to learn more about bitcoin
<amincd>
"The more burden it is to run a node, the fewer nodes there will be."
<amincd>
it doesn't get any plainer than that
<jgarzik>
Each node in that last sentence is a full node, each of which independently processes 100% of the worldwide traffic.
<amincd>
no it isn't. Satoshi meant SPV by "client nodes"
<jgarzik>
"The more burden it is to run a node, the fewer nodes there will be." <<-- refers to full nodes
<jgarzik>
" The rest will be client nodes" <<-- refers to SPV nodes, non validating
<amincd>
jgarzik yes exactly
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<jgarzik>
A system of 1 million tps requires that each and every full node independent process 1 million tps, and then relay 1 million times X to other nodes.
<jgarzik>
*independently
<amincd>
jgarzik, yes
<jgarzik>
That narrows the ability to run a full node down to.... 1 or 2 in the world.
<jgarzik>
Which is even more centralized than VISA
<jgarzik>
Easily controlled by big instituations, even more so than the US Dollar
<jgarzik>
You have reinvented centralization, at which point a client-server model would be cheaper and more efficient.
<jgarzik>
The exact opposite of egalitarian access
skeebop has joined #bitcoin-wizards
gill3s has joined #bitcoin-wizards
roconnor has quit [Quit: Konversation terminated!]
HostFat has quit [Ping timeout: 256 seconds]
Mably_ has joined #bitcoin-wizards
Mably__ has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
Mably has quit [Ping timeout: 250 seconds]
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Mably_ has quit [Ping timeout: 272 seconds]
Mably has joined #bitcoin-wizards
Mably__ has quit [Ping timeout: 245 seconds]
gill3s has joined #bitcoin-wizards
gill3s has quit [Client Quit]
Yoghurt114 has joined #bitcoin-wizards
gill3s has joined #bitcoin-wizards
sickpig has joined #bitcoin-wizards
<amincd>
jgarzik 1 million tps is 3 would be probably entail global adoption, and an economy that i
<amincd>
1 million tps is 31 trillion txs per year
<amincd>
currently there are 3 trillion tpy
Crowley4k has quit [Quit: Connection closed for inactivity]
<amincd>
so in this scenario, when Bitcoin has a market 10 times bigger than the entire current world economy, there would be many more big players that could run full nodes
<amincd>
there's no reason to assume full nodes will decline as tx volumes will increase, as long as tx volumes scale linearly with scale of economic activity on the Bitcoin network, and mining revenue
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Jaamg>
why should anything be assumed one way or the other regarding the number of full nodes?
amincd has quit [Quit: Page closed]
metamarc has joined #bitcoin-wizards
frankenmint has quit [Read error: Connection reset by peer]
<amincd_>
jaamg the idea that it must be possible for an average computer to validate 100% of global Bitcoin traffic rests on the idea that the number of independent parties running full nodes declines with tx volume. jgarzik suggests that at 1 million tps, there'd only be one or two full nodes. I'm disputing that there is any compelling reason to believe that would be the case
temujin has quit [Quit: Page closed]
gill3s has quit [Ping timeout: 256 seconds]
<amincd_>
1 million tps is 1-2 GB/s. Not necessarily out of reach for hundreds of thousands of parties in the event that Bitcoin usage outsizes all current means of transacting by a factor of 10. This would be a scenario where Bitcoin is orders of magnitude more important than the major financial institutions like Goldman Sachs, so dedicated fiber for full nodes is conceivable
metamarc has quit [Ping timeout: 256 seconds]
<amincd_>
To put another way, at 1 million tps, Bitcoin would be 10X more important than the entirety of the current global financial and monetary system, central banks and treasuries included. This would create significant demand for running these super nodes. There'd be more than one or two.
<sipa>
i do not think this is relevant
<sipa>
the number of full nodes is a distraction
<Jaamg>
i'm thinking the exact same thing
<sipa>
it is interesting as a means to detect how easy it is to run one
<sipa>
but the relevant metric is who you give access to validation
<sipa>
not how many people actually do
<amincd_>
an average computer being to run one is an arbitrary design requirement. Why not the average mobile phone.
<sipa>
yes, it is arbitrary
<sipa>
but it is the most important question we need to answer
<sipa>
it is a compromise between validation scalability and access scalability
skeebop has quit [Ping timeout: 256 seconds]
<sipa>
thrre is no optimal vslue for this
<sipa>
but it is a choice
<amincd_>
sipa: it is indeed the most important question, but IMO, it hasn't been discussed enough. I don't even see a compelling reason to ensure that those without access, are able to validate
<sipa>
i think there is
<amincd_>
sipa: there is an optimum for net utility. We just have no way to know for certain what it is
<amincd_>
if you don't have access, your txs are stored in off-chain ledgers, that are only as good as the willingness and ability of the TTPs to honor them. You can validate the main chain, but you can't validate the TTP's ledger
<sipa>
even if for some reason only big banks were able to transact, i think the only benefit bitcoin could offer is the ability for outsiders to vdlidate they are not cheating
<sipa>
and cheating is the wrong word
<sipa>
simply the fact that one needs to cinvince the population of full node using users, is the dtrongest reason why the rules they demand of the system remain maintained
<gavinandresen>
gmaxwell : I’m thinking of creating a spreadsheet with your proposed dynamic fee algorithm, so I can get a feel for how subsidy, hash rate, price, fees, etc work. You haven’t already done that, have you?
<amincd_>
whether a Bitcoin network only directly accessible by big banks is validated by just the big banks, or every person in the world, makes very little practical difference in my opinion. A few thousand super nodes validating that the other super nodes are acting honestly is going to be effective. Everyone else can reliably find out if the banks are acting within the rules of the protocol.
<sipa>
amincd_: i agree the value is higher for people participating
<sipa>
especially those actually receiving transactions
<amincd_>
so then, my reasoning goes, access, and systemic security (a large enough number of independent parties running full nodes), should be the priority, not universal validatability.
Quanttek has joined #bitcoin-wizards
trippysalmon has joined #bitcoin-wizards
skeebop has joined #bitcoin-wizards
<Jaamg>
i think universal validatability is a distraction
<Jaamg>
it's about freedom to participate
<Jaamg>
we talked about this earlier
<gmaxwell>
gavinandresen: no-- (I did simulate some older one at one point; but not the current one). It certantly does need to be done; the formula might need some constant factors twiddled to get sane behavior.
GGuyZ has joined #bitcoin-wizards
<amincd_>
Jaamg "freedm to participate" is vague. The world cannot participate in creating main txs if the block size is limited to allow a typical computer to run a full node
<amincd_>
*main chain
<Jaamg>
amincd_: it is currently limited and we currently have freedom to participate
skeebop has quit [Ping timeout: 244 seconds]
<amincd_>
Jaamg: we had this exchange before. The current design principle fails to allow full participation in generating txs at higher adoption levels.
<amincd_>
It's not future proofed
<Jaamg>
if we hit the max block size regularly, users get disappointed (eg. "crash landing scenario") and go do other things
<Jaamg>
then there is room in the blockchain again
<Jaamg>
to avoid this scenario i suggest that we keep the max block size as big as possible
<amincd_>
Jaamg: that's true
<Jaamg>
that's why i like gavinandresens proposal to increase max block size
<sipa>
define "as possible"
<sipa>
i don't believe in the existance of such a number
frankenmint has quit [Remote host closed the connection]
<sipa>
there is a max block size above which things just stop working
<sipa>
but the number above which the chain becomes insecure or uninteresting is a question of tradeoffs
<Jaamg>
sipa: i think it can only be expressed vaguely like that. i think it shouldn't be bigger than what makes running a node with regular home pc impossible
<sipa>
that's a meaningful choice, but it is a choice
<gavinandresen>
gmaxwell: I especially want to do some calculations around the subsidy halving, because having it suddenly become much more or less attractive to build bigger blocks is undesireable. That’s what made me start to think that adjusting the upper limit at the subsidy halving might make sense….
<amincd_>
sipa: the most compelling argument I can see for a small block size is that resistant to government censorship might not scale with economic power, so a network with 5,000 super nodes, handling $1 trillion in economic activity, wouldn't be as resistant to censorship as a network with 5,000 consumer-grade nodes handling $10 billion in economic activity. However, this is merely speculation.
<amincd_>
*resistance to
<sipa>
agree
<sipa>
amincd_: i have to agree that the most important question is validatability by the participants
<sipa>
amincd_: but i believe the participants should also have the right to avoid evolution towards them becoming unable to participate
<sipa>
in both ways (access and validation)
<gmaxwell>
gavinandresen: Good thing to think about-- the motivation for the original scheme had actually been "in the limit" with no subsidy; e.g. it's really supposted to be something where picking some size gives you an optimal fee income; and the optimal size is less than infinity (but larger than average if there is a backlog of good fees). Mark and I spent some time talking about omitting the subsid
<gmaxwell>
y from the effect (e.g. by increasing the subsidy when you make a higher diff block) but thats complex and hard to make people confident of; we realized that leaving it in is no big deal, it's just a bit of extra pressure against bigger blocks that goes away over time.
<gmaxwell>
gavinandresen: but a sudden change may be weird.
<gavinandresen>
gmaxwell: so you imagine some fixed upper limit that never changes? Like 11 gigabytes ?
<amincd_>
sipa: I think 'Bitcoin's global traffic must be validatable by a typical computer' makes a decision that participation is less important than validatability
<sipa>
amincd_: agree
<amincd_>
so maybe we should re-examine that, and consider evolution toward super nodes as one possible future
s3gfault has joined #bitcoin-wizards
droark has joined #bitcoin-wizards
<Jaamg>
what i meant by 'freedom to participate' was that running a node should be possible to 'anybody'. Maybe this actually is what you ment by validatability earlier.
<Jaamg>
i probably misunderstood, sorry
ThomasV has joined #bitcoin-wizards
sparetire_ has joined #bitcoin-wizards
amincd_ has quit [Ping timeout: 246 seconds]
<sipa>
running a node by someone who doesn't actually rely on the result of the validation it provides is not very useful
<sipa>
those nodes can be forked ofd without being noticed
jmcn has joined #bitcoin-wizards
jmcn_ has quit [Ping timeout: 264 seconds]
sickpig has quit [Ping timeout: 240 seconds]
<kanzure>
sipa: i have noticed you mentioning that lately. i wonder if there is a good physical quantification or measurement of whether a node is being used in a meaningful way?
hulkhogan_ has quit [Quit: leaving]
Transisto has joined #bitcoin-wizards
Transisto is now known as testtt
hulkhogan_ has joined #bitcoin-wizards
testtt is now known as Transisto2
ThomasV has quit [Ping timeout: 272 seconds]
NkWsy has quit [Remote host closed the connection]
s3gfault_ has joined #bitcoin-wizards
NkWsy has joined #bitcoin-wizards
s3gfault has quit [Ping timeout: 265 seconds]
frankenmint has joined #bitcoin-wizards
hulkhogan_ has quit [Remote host closed the connection]
hulkhogan_ has joined #bitcoin-wizards
hulkhogan_ has quit [Changing host]
hulkhogan_ has joined #bitcoin-wizards
NkWsy has quit [Ping timeout: 240 seconds]
hulkhogan_ has quit [Ping timeout: 244 seconds]
NkWsy has joined #bitcoin-wizards
hulkhogan_ has joined #bitcoin-wizards
hulkhogan_ has quit [Changing host]
hulkhogan_ has joined #bitcoin-wizards
hulkhogan_ has quit [Changing host]
hulkhogan_ has joined #bitcoin-wizards
wallet42 has quit [Ping timeout: 250 seconds]
wallet42 has joined #bitcoin-wizards
dEBRUYNE_ has quit [Ping timeout: 244 seconds]
belcher has joined #bitcoin-wizards
Crowley4k has joined #bitcoin-wizards
b_lumenkraft_ has quit [Quit: b_lumenkraft_]
NkWsy has quit [Remote host closed the connection]
zooko has joined #bitcoin-wizards
rusty has left #bitcoin-wizards [#bitcoin-wizards]
williamdunne has joined #bitcoin-wizards
NkWsy has joined #bitcoin-wizards
zooko has quit [Remote host closed the connection]
hashtag has quit [Ping timeout: 244 seconds]
hashtag has joined #bitcoin-wizards
Yoghurt114 has quit [Ping timeout: 246 seconds]
uydxhc has quit [Ping timeout: 240 seconds]
c-cex-yuriy has joined #bitcoin-wizards
antanst has quit [Quit: Leaving.]
jmcn_ has joined #bitcoin-wizards
jeremyrubin has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 272 seconds]
kmels has quit [Ping timeout: 246 seconds]
Guyver2 has quit [Remote host closed the connection]
s3gfault_ has quit [Ping timeout: 272 seconds]
s3gfault has joined #bitcoin-wizards
NkWsy has quit [Remote host closed the connection]
Crowley4k has quit [Quit: Connection closed for inactivity]
fanquake has quit [Read error: Connection reset by peer]
fanquake has joined #bitcoin-wizards
skeebop has joined #bitcoin-wizards
kmels has quit [Remote host closed the connection]
<dgenr8>
not very useful, yes. and if the world's 100000 tps were all denominated in bitcoin, but were consolidated down to 7 tps in the blockchain, none of the consolidated traffic would be meaningful to any average validator
<phantomcircuit>
kanzure, there's no way to tell
<phantomcircuit>
dgenr8, actually it would be meaningful for everybody then
<dgenr8>
it's a bunch of huge settlement trades between big banks
<kanzure>
phantomcircuit: i don't mean remotely
<kanzure>
i mean local
<phantomcircuit>
kanzure, not really since you can interface with a trusted node over the p2p protocol
dEBRUYNE_ has quit [Ping timeout: 272 seconds]
<phantomcircuit>
dgenr8, im not sure settlement is the right word there though (or banks either)
<kanzure>
the word "settlement" is overloaded in finance to mean many many things
<phantomcircuit>
kanzure, yeah that's part of why i dont think it's the proper term to use
<phantomcircuit>
it's confusing as to what you mean exactly
<phantomcircuit>
dgenr8, take for example lightning hubs when the micropayment channel expires
<phantomcircuit>
those transactions can be validated as correct by the participants
<phantomcircuit>
thousands of participants could potentially now be interested in that one transaction
<dgenr8>
i was thinking "trades" is the most off ... transfers is better. settlement is accurate -- it's a net +- amount summarizing and finalizing off-chain activity. for banks, whatever .. "entities"