<Taek>
I'm not sure that officials always think through that far
belcher has quit [Client Quit]
belcher has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
<gmaxwell>
depends on who you're talking about; obviously there is a layer of people who just say "but I want in!" without thinking at all.
<zooko>
Yeah, it's not safe to assume internal consistency.
dEBRUYNE has quit [Ping timeout: 272 seconds]
<Taek>
I remember an officer 'shuddering to think' how many people would have gotten away if phone encryption was standard
zmachine has quit [Ping timeout: 264 seconds]
<Taek>
but these people had video evidence of their crimes *on their own phones*
<zooko>
I think the safest bet is that each person is doing something that they think will improve their own social and/or economic standing.
<zooko>
Beyond that it gets pretty hazy to me. :-)
jmcn_ has joined #bitcoin-wizards
zmachine has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 276 seconds]
<Taek>
A lot of regulation seems to crop up from people not understanding how easily it can be avoided
<Taek>
And some of this might come from a taboo upon looking for ways to bypass laws
<Taek>
if the average person was a lot better at knowing how to avoid laws/regualtion, I wonder if our laws wouldn't be more effective as a consequence
kmels has quit [Ping timeout: 256 seconds]
<BlueMatt>
zooko: keep in mind most of us are insane, so its hard to tell what people are thinking :p
<zooko>
BlueMatt: :-)
d1ggy_ has joined #bitcoin-wizards
* rusty
resists urge to completely rewrite protobuf-c...
<nsh>
is it bad?
<zooko>
Taek: well, that pattern fits in really well with my model, which is that the people proposing the regulation don't *actually* care, in an effective sense about the *consequences*, only about the nominal intent.
<zooko>
If you pass a law banning murder of puppies, you improve your social and/or economic standing. Whether this results in more or fewer puppy murders is irrelevant.
* zooko
notices that he isn't in the politics chatroom.
* nsh
smiles
<rusty>
nsh: It's... well-meaning.
<nsh>
economic regulation is a little less vulnerable to political incentive issues, as it's usually compartmented such that the people doing the regulating are heavily vested some notional sense of the efficient functionality of the system
<nsh>
as long as it favours their privileged position
<zooko>
An important detail to what I said is "in an effective sense". I mean that those people
<zooko>
may well *feel* strong feelings about saving puppies, and may completely
d1ggy has quit [Ping timeout: 272 seconds]
<zooko>
honestly *believe* that their actions will save puppies, but I think the system
<zooko>
selects for people who convincingly appear that way, including people who
<zooko>
sincerely are that way, not for people that actually reduce the rate of puppy murders.
<zooko>
See what I mean?
<zooko>
I'm not accusing them of dishonesty, but of irrelevance.
<nsh>
right, but the fed reserve board of governors is less concerned with voterfeels than projections, and economic policy, thankfully, is not written by politicians
<nsh>
it's harder to be cynical than bored reading their minutes. one is inclined to believe in grand conspiracies because the real agenda of the most powerful in society is tragically mediocre and predictable for the most part
<zooko>
Everything I wrote above applies to other incentives than voterfeels!
* nsh
may have missed some context; just reconnected to bouncer after lappy freeze
* nsh
looks at logs
<zooko>
I did use the example of passing a law that voters like.
<zooko>
But the general principle applies to, e.g. defending the honor of your intellectual tradition, getting a juicy consulting job after you retire, etc.
* nsh
nods
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
roconnor has joined #bitcoin-wizards
nickler has quit [Ping timeout: 244 seconds]
wallet42 has quit [Quit: Leaving.]
<nsh>
i thought of a question i couldn't easily answer earlier that some of you will probably know: could you speed up WPA2-PSK cracking significantly by collecting lots of handshakes, rather than just trying to match a single one?
Cory has joined #bitcoin-wizards
nickler has joined #bitcoin-wizards
<nsh>
it's a more complex protocol than i'd imagined
wallet42 has joined #bitcoin-wizards
felipelalli has quit [Ping timeout: 244 seconds]
<nsh>
i guess the trivial [active] answer is: yes, there are nonces involved and router uptime can be made arbitrarily low.
<nsh>
but i've never seen any talk of using more than one handshake, so perhaps it wouldn't be worth it? not clear to me how to boil down the schematic protocol representation into a complexity analysis in terms of repeated handshakes
kgk has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
PRab has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.1/20150513174244]]
GGuyZ has joined #bitcoin-wizards
* nsh
muses about this in ##crypto instead
<nsh>
oh, there is a weakness to the groupwise shared key, but it's somewhat mitigated by the fact that you have to have been associated in the past: http://www.airtightnetworks.com/WPA2-Hole196
<nsh>
i did suspect there would be an issue there
kgk has joined #bitcoin-wizards
nuke1989 has quit [Remote host closed the connection]
nessence has joined #bitcoin-wizards
frankenmint has quit [Remote host closed the connection]
kgk has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Dr-G has quit [Disconnected by services]
Dr-G2 has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
kgk has joined #bitcoin-wizards
zooko` has joined #bitcoin-wizards
zooko has quit [Ping timeout: 258 seconds]
zooko`` has joined #bitcoin-wizards
zooko` has quit [Ping timeout: 265 seconds]
zooko``` has joined #bitcoin-wizards
zooko`` has quit [Ping timeout: 256 seconds]
belcher has quit [Quit: Leaving]
nessence has quit [Remote host closed the connection]
frankenmint has quit [Remote host closed the connection]
tdryja has quit [Remote host closed the connection]
frankenmint has joined #bitcoin-wizards
zooko```` has joined #bitcoin-wizards
zooko``` has quit [Ping timeout: 240 seconds]
PRab has joined #bitcoin-wizards
DrWat has quit [Quit: Actually, she wasn't really my girlfriend, she just lived next door and never closed her curtains.]
frankenmint has quit [Remote host closed the connection]
wallet42 has quit [Quit: Leaving.]
wallet42 has joined #bitcoin-wizards
wallet42 has quit [Ping timeout: 258 seconds]
frankenmint has joined #bitcoin-wizards
TheSeven has quit [Ping timeout: 265 seconds]
TheSeven has joined #bitcoin-wizards
kmels has joined #bitcoin-wizards
akrmn has quit [Ping timeout: 256 seconds]
jae has joined #bitcoin-wizards
jae is now known as Guest45171
frankenmint has quit [Remote host closed the connection]
mpmcsweeney has joined #bitcoin-wizards
<maaku>
if nLockTime were compared against something else other than the height/timestamp of the block, what would that be? GetMedianTimePast()?
dgenr8 has quit [Quit: Leaving]
dgenr8 has joined #bitcoin-wizards
dgenr8 has quit [Client Quit]
dgenr8 has joined #bitcoin-wizards
fanquake1 has joined #bitcoin-wizards
fanquake1 is now known as fanquake
fanquake has quit [Changing host]
fanquake has joined #bitcoin-wizards
<dgenr8>
maaku: that seems an odd question. what is the goal?
<maaku>
well petertodd mentioned on a pull request the possibility of soft-forking nLockTime to be GetMedianTimePast() instead of the block timestamp
<maaku>
which decreases some timestamp forgery incentives as far as I can tell, maybe has some other benefit too
<maaku>
i'm not aware of the discussion surrounding that
<maaku>
but while switching nLockTime to be based on GetMedianTimePast would be a soft-fork change, doing the same for a hypothetical relative locktime would be a hard-fork change
<maaku>
so, kinda important to get it right...
<dgenr8>
oh he tweeted about exploiting clock-nLocktime to induced propagation inconsistency
fanquake1 has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
<dgenr8>
my thought was why not let it into the mempool a bit early
fanquake has quit [Ping timeout: 256 seconds]
NewLiberty has joined #bitcoin-wizards
zooko```` has quit [Ping timeout: 258 seconds]
fanquake1 has quit [Read error: Connection reset by peer]
fanquake has joined #bitcoin-wizards
fanquake1 has joined #bitcoin-wizards
fanquake1 has left #bitcoin-wizards [#bitcoin-wizards]
fanquake has quit [Ping timeout: 245 seconds]
<afdudley>
is there a good reference for time-lock encryption somewhere? is there a non-bitcoin/trusted third party implementation somewhere?
<maaku>
afdudley: i don't think there is a bitcoin implementation either :P
<afdudley>
indeed :D
isis has quit [Quit: she probably switched to carrier pidgeons]
<dgenr8>
petertodd: then i must have misunderstood your 140 chars
<petertodd>
dgenr8: the problem is that not all nodes have the exact same clock; when you let the tx into the mempool is irrelevant so long as it's based on the local idea of what time it is
<petertodd>
dgenr8: incidentally, you can doublespend coinbase that way pretty easily
<dgenr8>
petertodd: if you let it in 2 hours before locktime, even nodes with slow clocks should have it when final
<petertodd>
dgenr8: sigh.... again, that changes nothing. go try this yourself
<dgenr8>
petertodd: have you described this somewhere?
HostFat has quit [Ping timeout: 272 seconds]
<petertodd>
dgenr8: no, why would I? it's pretty obvious how it works once you remember how nLockTime-by-time works
<dgenr8>
petertodd: so we know what "it" is
<petertodd>
dgenr8: meh, I don't get paid to fix zeroconf problems...
<dgenr8>
petertodd: what's your price
<petertodd>
dgenr8: $250/hr
<dgenr8>
petertodd: how many hours will it take
<petertodd>
dgenr8: dunno, it's probably not a fixable problem
<petertodd>
dgenr8: and frankly, given that I'm going to get accused of having bad incentives for this... nah, screw it, I don't want the work
<dgenr8>
petertodd: ... i meant to fix zeroconf completely.
<petertodd>
dgenr8: do you want to still have a decentralized system? because if so, that's impossible
<dgenr8>
petertodd: was sure a highball estimate was coming ;)
<petertodd>
dgenr8: I'm not going to wreck my reputation on something stupid
GGuyZ has quit [Quit: GGuyZ]
ThomasV has quit [Ping timeout: 272 seconds]
<dgenr8>
petertodd: question - how long should the tx replacement "feature" be available? did we get lucky and 10+-10 min is just right? or would it be nice to explicitly reneg txes for a longer period?
<petertodd>
dgenr8: huh?
<dgenr8>
petertodd: from your writings, i get the impression that RBF is a really cool feature
<petertodd>
dgenr8: I mean, what does "10+-10" min have to do with it?
arubi has quit [Quit: Leaving]
<dgenr8>
petertodd: that's how long RBF works, generally. until next block. i use +-10 min as the standard dev. is 10 minutes
<petertodd>
dgenr8: no, RBF works until the tx gets *into* a block
<dgenr8>
petertodd: hence "generally"
Guest45171 has quit [Remote host closed the connection]
<petertodd>
dgenr8: I still don't see your point
<dgenr8>
petertodd: no point, just a question
priidu has joined #bitcoin-wizards
<petertodd>
dgenr8: block interval is based on latency considerations; shorter block intervals reduce security significantly. Is 10 minutes optimal? Who knows, but like most things in security, arguing about how low we can reduce our security margin and still get away with it is dumb.
<dgenr8>
petertodd: well that answers A question
jeremyrubin has joined #bitcoin-wizards
Mably has joined #bitcoin-wizards
kmels has quit [Ping timeout: 256 seconds]
<Luke-Jr>
I'd argue that once it gets in a block, you don't *need* the replacement feature anymore ;)
frankenmint has joined #bitcoin-wizards
akrmn has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 276 seconds]
arubi has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
Mably has quit [Ping timeout: 240 seconds]
blackwraith has joined #bitcoin-wizards
priidu has quit [Ping timeout: 246 seconds]
blackwraith has quit [Ping timeout: 256 seconds]
wallet42 has quit [Quit: Leaving.]
jcorgan has joined #bitcoin-wizards
go1111111 has quit [Ping timeout: 264 seconds]
rusty has quit [Ping timeout: 240 seconds]
priidu has joined #bitcoin-wizards
Mably has joined #bitcoin-wizards
hktud0 has quit [Read error: Connection reset by peer]
wallet42 has joined #bitcoin-wizards
hktud0 has joined #bitcoin-wizards
go1111111 has joined #bitcoin-wizards
blackwraith has joined #bitcoin-wizards
priidu has quit [Ping timeout: 264 seconds]
Logicwax has quit [Ping timeout: 258 seconds]
Giszmo has quit [Quit: Leaving.]
DougieBot5000 has quit [Quit: Leaving]
blackwraith has quit [Quit: Leaving]
Logicwax has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 265 seconds]
kgk has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Pan0ram1x has quit [Ping timeout: 265 seconds]
b_lumenkraft has joined #bitcoin-wizards
Pan0ram1x has joined #bitcoin-wizards
rht_ has quit [Quit: Connection closed for inactivity]
<Taek>
ethereum learns that running implementations of consensus code in multiple languages can lead to hardforks
zooko has quit [Ping timeout: 244 seconds]
<hulkhogan_>
i sort of don't understand why they had to reimplement it three or more times just to launch it
antanst has quit [Ping timeout: 256 seconds]
<adlai>
it was lonely without all the python and C++ clients
Hunger- has joined #bitcoin-wizards
arubi_ has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 272 seconds]
priidu has joined #bitcoin-wizards
ryanxcharles has joined #bitcoin-wizards
hearn has quit [Ping timeout: 272 seconds]
<Eliel>
maybe they want to avoid getting locked into a single implementation by diversifying early?
hearn has joined #bitcoin-wizards
hearn has quit [Ping timeout: 272 seconds]
<gmaxwell>
Eliel: unavoidable; certantly good to have multiple implementations to help _expose_ issues; but that doesn't itself remove the consensus risk from it.
hearn has joined #bitcoin-wizards
Guest95228 has quit [Ping timeout: 272 seconds]
Guest95228 has joined #bitcoin-wizards
priidu has quit [Quit: Leaving]
arubi_ has quit [Ping timeout: 240 seconds]
dc17523be3 has quit [Ping timeout: 245 seconds]
jmcn has joined #bitcoin-wizards
jmcn_ has quit [Ping timeout: 276 seconds]
mrkent has quit [Remote host closed the connection]
dc17523be3 has joined #bitcoin-wizards
arubi_ has joined #bitcoin-wizards
Quanttek has quit [Ping timeout: 264 seconds]
Guyver2 has quit [Remote host closed the connection]
kheplo_ has joined #bitcoin-wizards
felipelalli has quit [Remote host closed the connection]
hashtag_ has quit [Ping timeout: 244 seconds]
HostFat_ has quit [Ping timeout: 250 seconds]
priidu has joined #bitcoin-wizards
nemild has quit [Quit: nemild]
rustyn has quit []
b_lumenkraft has quit [Quit: b_lumenkraft]
rustyn has joined #bitcoin-wizards
zz_lnovy is now known as lnovy
belcher has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
antgreen has quit [Remote host closed the connection]
GGuyZ has joined #bitcoin-wizards
arubi_ has quit [Quit: Leaving]
dc17523be3 has quit [Ping timeout: 272 seconds]
nemild has joined #bitcoin-wizards
<GGuyZ>
Not really bitcoin but perhaps someone could help :)
<GGuyZ>
I'm trying to prove that a given set of shares cannot reconstruct a valid degree t polynomial. The verifier should at most know a commitment of these shares, but not the shares themselves. Any idea how to solve this? I'm thinking SNARKs but not sure if that's a good fit.
belcher has quit [Quit: Leaving]
<GGuyZ>
G*
<gmaxwell>
join #btcd
<gmaxwell>
oops
lclc_ has quit [Ping timeout: 256 seconds]
nemild has quit [Quit: nemild]
dc17523be3 has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
temujin has quit [Ping timeout: 246 seconds]
<GGuyZ>
Actually I have a solution
<gmaxwell>
GGuyZ: sorry just saw your question. Your question is insufficently clear to me.
<gmaxwell>
Soemone can always know more shares that they leave out of the proof.
melvster has quit [Ping timeout: 256 seconds]
melvster has joined #bitcoin-wizards
chmod755 has quit [Quit: Leaving]
Guest95228 has quit [Ping timeout: 256 seconds]
kheplo_ has quit [Quit: Leaving]
<GGuyZ>
Thanks,
HostFat has joined #bitcoin-wizards
Guest95228 has joined #bitcoin-wizards
<GGuyZ>
I'll try to be more clear if the line of thinking I'm trying doesn't work out. Tried to keep my question brief but I see why it lacks substance that way.
Guest95228 has quit [Ping timeout: 245 seconds]
adam3us has joined #bitcoin-wizards
Guest95228 has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
zooko has joined #bitcoin-wizards
<gmaxwell>
yea, understood. Sometimes it's just hard to tell what you're trying to accomplish. I'm guessing you want some commitment X and then prove that x,y,z,C(q),C(r) where x,y,z are shares of X and C(q), R(r) are commitments to shares of x.
dc17523be3 has quit [Ping timeout: 246 seconds]
<gmaxwell>
(where X = C(x)) and some verifier wants to know that the shares agree with C(x).
<gmaxwell>
So long as your commitment scheme is additively homorphic you should just be able to take the shares and the commited shares and interpoate the commitment to x.
<gmaxwell>
and if you have all the shares (in either direct or commited form) then you can just try every interpolation.
<gmaxwell>
(uh, I made some variable name screwups above; so ignoring those...)
Burrito has quit [Quit: Leaving]
DougieBot5000 has quit [Quit: Leaving]
Mably has quit [Ping timeout: 252 seconds]
hearn has quit [Ping timeout: 265 seconds]
hearn has joined #bitcoin-wizards
dc17523be3 has joined #bitcoin-wizards
nemild has joined #bitcoin-wizards
nemild has quit [Quit: nemild]
nemild has joined #bitcoin-wizards
<andytoshi>
GGuyZ: ignoring concerns about what your goal is (and if it can be subverted by simply hiding information, say), it's unlikely you can prove anything about polynomial construct
<andytoshi>
constructibility without something as powerful as multilinear maps
<andytoshi>
well, if you are OK with having large proofs, you can prove that a bunch of points G, xG, x^2G, x^3G, etc are constructed honestly with simultaneous schnorr signatures, cf http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.117.5343 which does something similar. then you can prove linear equations in x, x^2, x^3, etc using standard discrete log techniques
wallet42 has quit [Quit: Leaving.]
<gmaxwell>
HostFat: Your post is uninformed with respect to how block propagation works.
zooko has quit [Ping timeout: 256 seconds]
<gmaxwell>
HostFat: most large miners (and anyone who wants) use the block relay protocol for relaying blocks, it transmits blocks with time which is essentially unrelated to the size of the blocks.
nemild has quit [Quit: nemild]
<gmaxwell>
(it's technically linear but with a very small constant)
<HostFat>
do you mean transmitting to other miners or to all nodes?
<gmaxwell>
HostFat: To whatever extent the size/time relation is consequential thats a pressure to centeralize in and of itself, since the more centeralized party isn't harmed by those costs.
<gmaxwell>
HostFat: to anyone interested in recieving them efficiently; though transmitting to other nodes isn't time critical in terms of miners incomes or incentives.
dEBRUYNE_ has quit [Read error: Connection reset by peer]
<HostFat>
so there is something that I don't know and/or missing. Can a miner release a 100 MB block all the time and still arrive before miners that release blocks of 1 MB?
<gmaxwell>
HostFat: Yes.
<HostFat>
woha!
<gmaxwell>
HostFat: Almost all (or all, if you just avoid adding very new txn to your blocks) the transactions are already communicated and verified; and don't need to be transmitted again.
<gmaxwell>
HostFat: The block relay protocol just sends a list of two byte indexes to previously communicted txids/txn; technically is possible to build protocols even more efficient than that using set reconcilation; but at two bytes per transaction you can specify all the transactions for a block hundreds of megs in size without a round trip; and its already widely deployed. Future protocols that just sen
<gmaxwell>
d the discrepency between the block and an implied mempool would be even more efficient but because of cpu costs aren't likely a win without really gigantic blocks.
zooko has joined #bitcoin-wizards
<gmaxwell>
But even if we ignore this, and pretend the block relay protocol didn't exist and wasn't widely used-- go with your original knoweldge: lets say it is proportional. In that world miners could immediately make more income by moving to a bigger pool, which can produce bigger blocks for a given amount of orphaning risk; as the pool will not orphan itself.
<HostFat>
hmm, but smaller pools/miners will still able to arrive to more nodes than the bigger pool, and even if there are two bigger pools, they will compete each other to arrive to the majority of nodes (if we still think that tis relay protocol doesn't exist)
<HostFat>
by making smaller blocks
StephenM347 has quit []
<gmaxwell>
HostFat: if you imagine it doesn't exist, thats true but you can always increase your competitiveness by either increasing centeralization or decreasing blocksize. And if you are more centeralized than someone else you can use a larger block size (more fee income), meaning that if mining is at an equlibrium you might be making 0.1% more (say) and turning a profit, while the less centeralized min
<gmaxwell>
er is losing money.
<gmaxwell>
Block relay protocol was created to try to mitigate some of that centeralization pressure that was pushing the network to only one or two pools last year-ish.
<HostFat>
so the block relay protocol is enabled for all nodes currently, right?
se3000 has left #bitcoin-wizards [#bitcoin-wizards]
<gmaxwell>
HostFat: it's something you download seperately. I think all major miners use it (they'd be foolish not to!) but there is no way to tell for sure. In any case, since anyone can trivially install it and we know that most of the hashpower uses it, it more or less moots your argument about some kind of market force there. (since the thing you'd do isn't decrease your blocksize, you'd install the blo
<gmaxwell>
ck relay network client)
<HostFat>
ok
<phantomcircuit>
HostFat, it's almost important to note that larger miners can afford significantly more bandwidth than smaller decentralized miners
<phantomcircuit>
to give you an idea i had a 10gbps line pushing blocks out in addition to the relay network
<phantomcircuit>
(even the 10gbps line wasn't enough, to get really good propagation i was proposing 10x that)
<HostFat>
that its true, but I don't see this as a problem, if it spread in a good way to all the nodes, than it's ok.
<gmaxwell>
HostFat: There is another bit to consider there. Technically as a miner your income is optimized if only half the hashrate (including yourself) hears your block quickly; it's preferable that the rest takes a while to hear it (as it increases their orphaning rate).
kmels has quit [Ping timeout: 245 seconds]
<HostFat>
the example of the 56k is good explain this I think
<gmaxwell>
I don't believe anyone substantive is acting so strategically now; but if you want to terms about income maximizing behavior and market forces, it's something to consider; esp since the system self adapts towards zero profits. Meaning that it's possible that anyone who doesn't engage in that behavior may end up operating at a loss.
<HostFat>
"it's something you download seperately. I think all major miners use it" so the majority of nodes aren't using it
<gmaxwell>
(and the selfish mining paper argues that the above also means that if a pool mines selfishly they only want it to be heard by a third (themselves included), and if so additional participants will make more if they join their pool vs some other one... e.g. arguing the marginal return on centeralizating instead of the direct effect shifts the threshold to 1/3rd instead of 1/2.)
<gmaxwell>
HostFat: They're not-- but it doesn't matter to miners what non-miners are using for that. (presumably they'll someday use it: it _halves_ the amount of bandwidth staying in sync with the blockchain takes; it just hasn't been a priority to formalize the protocol for use in Bitcoin Core)
DougieBot5000 has joined #bitcoin-wizards
SubCreative has joined #bitcoin-wizards
<HostFat>
so if there will be the block relay protocol on all the nodes, than it will be more likely a CPU problem than a bandwitch problem, right?
<gmaxwell>
HostFat: accepting a block is neglible CPU, because again, the transactions are almots all (or all if miners delay accepting txn into blocks) already verified and relayed. They don't get verified a second time.
<gmaxwell>
So the only cpu thats technically needed at accept time is verifying the hash agreement. And a boring desktop cpu can do on the order of 24 million sha256() compression calls in a second.
<gmaxwell>
Before all the caching and such some miners had taken to just disabling validation on their nodes. :( (we recently had a problem with a miner with 1-2%-ish of the hashrate running with all signature validation disabled; causing them to mine transactions that were non-standard and had some risk of forking the network)
<HostFat>
so now in this future case (block relay protocol on all the nodes), I'm missing the problem for bigger blocks ...
<gmaxwell>
Presumably because you misunderstood the problem in the first place? :)
<HostFat>
probably :)
<HostFat>
I thought that it was a bandwitch problem
<gmaxwell>
None of this reduces the cost of verifying the network (except by constant factors), it only takes it out of the critical path of accepting a block.
<HostFat>
and by what I'm understanding about the block relay protocol, it seems fixing it
<HostFat>
hmm
<gmaxwell>
It's a one time halving of bandwidth costs, but you still must recive, verify, and potentially store the transactoin data.