551300+ entries in 0.357s
ben_vulpes: gavinandresen: you cannot construct
this conversation on
the foundation of fees. you cannot possibly know how fees will behave in steady state or in perpetually inflating block size state.
gavinandresen: Pierre_Rochard: So, lets say we do see fees rise. How far do we let
them rise? Who decides?
Pierre_Rochard: gavinandresen:
that’s right,
that’s
the signal
to increase
the block size limit
gavinandresen: Pierre_Rochard: But you just said you want
to let fees go up high enough so, at
the margin, some people ARE
turned away.
ben_vulpes: don't address any of
the *only valid points* being made here.
Pierre_Rochard: gavinandresen:
then we see an acceleration of adoption of an altcoin / altcoins in general and react accordingly
ben_vulpes: non deterministic
transaction generation.
ben_vulpes: stale wallet backups
that your asshats are responsible for.
ben_vulpes: want
to
talk about what's hampering adoption?
Pierre_Rochard: gavinandresen: I
think Bitcoin’s overall value proposition is so overwhelming
that what’s hampering Bitcoin adoption is not
tx fees, it’s just
the Lindy effect of it being around long enough
gavinandresen: Pierre_Rochard: But we’d get probably at least six months, maybe a year or
two of substitution because it
takes
time
to roll out a hard forking change
ben_vulpes: gavinandresen: adoption is for
the masses. i don't give a single fuck about
the masses. bitcoin is not for
them now, nor will it ever be.
Pierre_Rochard: gavinandresen: because
the substitution would just be happening at
the margin
gavinandresen: Pierre_Rochard: Seems
to me it is better
to do everything we can
to encourage widespread adoption right now.
ben_vulpes: gavinandresen: and we have
the guns, coin and code on our side.
gavinandresen: Pierre_Rochard: but why would we want
to hit
the “then substitutes start happening” when we’re in Bitcoin’s infancy?
ben_vulpes: and our stake in
the ground (0.5.3) is our indictment of everything
that your people have done for
the past umpteen months.
ben_vulpes: gavinandresen: i'm pointing out
that
the only acceptable patch for wallets is
total removal.
Pierre_Rochard: gavinandresen: fee revenue growth, if it accelerates
then demand for btc
transactions is relatively inelastic,
the point at which it declerates indicates where substitution starts happening. If it’s right away,
then you’re right on
the economics. If its after a period of faster growth,
then we can see what bitcoin
transaction fee
the market will bear before switching
to substitutes
ben_vulpes: then you got hosed with
the whole "change address" debacle.
ben_vulpes: and so, you had
to
track "relevant
transactions" in
the wallet.
gavinandresen: Pierre_Rochard: … I misstated:
that will influence
the maximum possible block size....
ben_vulpes: the moronic quest
to make
the
thing occupy as little space on disk as possible precluded you people from selecting a queryable db
ben_vulpes: in fact
the entire wallet model is completely broken.
gavinandresen: Pierre_Rochard: what information will we get
that will influence how large
to make blocks?
ben_vulpes: gavinandresen:
the notion
that
the wallet code should be responsible for setting fees is utter braindamage.
Pierre_Rochard: then let’s stay
there for six months
to collect
the data
gavinandresen: Pierre_Rochard:
the 0.10 release’s wallet code includes floating fees, so over
the next couple months we should get a much better idea of what is happening fee-wise.
Pierre_Rochard: gavinandresen:
that we don’t increase
the limit until we see what happens
to
total fee revenue growth after a few months of full blocks
artifexd: Yeah. I found
the article
through my own education. I wanted
to see if it had already been discussed in here.
gavinandresen: Pierre_Rochard: if Satoshi hadn’t slapped on a 1MB blocksize limit, would you be lobbying for a hardfork now
to impose one?
☟︎ gavinandresen: asciilifeform: again, go read
the
technical road map post, section on pruning
the chain
gavinandresen: asciilifeform: storage is not
the bottleneck/cost, bandwidth is.
gavinandresen: davout: oh,
the IBLT stuff? yes,
that’d make propagation O(1), and
that’s what I mean when I say “when
that is fixed by protocol changes"
gavinandresen: davout: sorry, missed,
the question, real-world distraction…
gavinandresen: asciilifeform: if
there are no network protocol changes,
then we’re in
trouble, because number of full nodes may continue
to decline
davout: gavinandresen: you're not really answering
the question regarding headers-first
gavinandresen: asciilifeform: see my
technical roadmap post for what needs
to be done
to increase number of full nodes
gavinandresen: davout: when
that is fixed by protocol changes,
they will have some minimum costs
to processing
transations plus a little profit
davout: isn't
there a plan
to make block propagation O(1) by using headers-first?
ben_vulpes: Pierre_Rochard: you assume some kind of "goal", and
that
there's a "we" with it.
Pierre_Rochard: gavinandresen: I
think
the limit
that miners self-impose would not hold. I
think we see
that
today
gavinandresen: davout:
today, because bigger blocks
take a while
to propagate.
Pierre_Rochard: Now
this part may be controversial for some members of b-a, but it’s at
the point where fee revenue growth decelerates
that
the block size should be increased *marginally*, if
the goal is
to maximize fee revenue
gavinandresen: Pierre_Rochard: I
think you’re confusing
the limit miners self-impose with
the hard-coded upper limit
ben_vulpes: yeah, and again we're at
the "snapshot of a dynamic
thing
Pierre_Rochard: that would indicate
that demand is inelastic, and it would
tell us where
the upper bound on bitcoin
tx fees roughly is
ben_vulpes: let's at least hit
the steady state behavior before starting
to diddle with important economic variables like block size.
Pierre_Rochard: So here’s my hypothesis: if we allow
the network
to hit
the block size limit,
then we’ll see
the
transaction fee revenue growth *accelerate*, up until
the point
that substitution begins happening in earnest,
then
the fee revenue growth will *decelerate* or stall.
Pierre_Rochard: Second,
there is distance between
the
total
transaction costs of Bitcoin vs
the substitutes. So
there’s inelasticity in demand
ben_vulpes: there is only bitcoin, and if one cannot afford
the miners fees for inclusion in a block, one does not need
to
transfer bitcoins enough.
Pierre_Rochard: My response
to
that is
two-fold: if maximizing revenue
to miners is our goal,
then shifting marginal demand
to substitutes is fine.
Pierre_Rochard: my main disagreement is on
the economics side, you say “ Limit
the number of
transactions
that can happen on
the Bitcoin blockchain, and instead of paying higher fees people will perform
their
transactions somewhere else.”
☟︎ ben_vulpes: in any event, gavinandresen,
there'll be no more forks from you. you blew it back in
the day, and you lost
the initiative on
this one months ago.
davout: gavinandresen: "okey dokey,
then we might not have much
to
talk about if you want
to stick with OpenSSL bugs
that were included in
the protocol by mistake." <<< actually i distinctly remember mike hearn
telling me how
that particular bug was part of
the protocol and how it somehow justified not putting any effort
towards actually specifying anything, in a spec, not in code
kakobrekla: that like "dont worry we have 2 years
to 'fight'" and
then "o shit did we miss it?" 2 years later.
gavinandresen: felipelalli:
that’d be a fine way
to roll out
the change; I
think gmaxwell and sipa prefer
that plan.
felipelalli: gavinandresen:
theymos said: << (...) Make
the change now, but have it
take place at a particular date or block number 2 years in
the future.
Then when
the change actually happens, everyone will already be updated because almost no one uses 2-year-old software. Yes, 2 years is a long
time, but we'll survive. >> is
that possible and why it is a good or bad idea?
ben_vulpes: "oh look we're also
talking about improving
things over
there so you may as well roll over on
the megablocks issue"
ben_vulpes: the
topic under discussion is
the moronic megablock shit, not signature rules.
gavinandresen: okey dokey,
then we might not have much
to
talk about if you want
to stick with OpenSSL bugs
that were included in
the protocol by mistake.
ben_vulpes: not wherever you people get
together and wank about "innovation" in
the blockchain
felipelalli: increase
the 21M max coins is possible
through a hard fork?
ben_vulpes: well i can
tell you right now
there is zero support around here for changing
the protocol in any way.
gavinandresen: ben_vulpes: yes; a soft fork makes
the protocol more strict. You have
to hard fork
to make it more lenient.
gavinandresen: MP will bring all
the drama :-) I
try hard
to be drama-free.
davout: ben_vulpes: a soft fork is making
the set of valid blocks smaller, a hard fork is
the opposite
gavinandresen: a hard fork means everybody running a full node must upgrade, or
they will be on a different chain
☟︎ kakobrekla: ben_vulpes for drama you need GA and MP present at same
time.
gavinandresen: a soft fork means miners must upgrade, or
their blocks will be rejected.
☟︎ davout: felipelalli:
that was a soft fork
gavinandresen: …
that was a soft fork, not a hard fork, but it still caused people
to accuse me of
trying
to destroy Bitcoin
gavinandresen: felipelalli: when we did BIP16
to make multisig wallets easy
to deploy
felipelalli: gavinandresen: when was
the first
time
that you have "ruined" bitcoin?
gavinandresen: I came here so you can
tell me how I’m going
to ruin bitcoin (again…)
☟︎ diametric: nubbins`: are you actually going
to post a video
to prove a point
to one of his shills/
diametric: nubbins`: I've
thoroughly enjoyed
the woodcollector posts.
davout: "You are 100000% correct. It's funny how easy it is
to spot a statist who
thinks everything should be controlled instead of letting
the market do its job."
BingoBoingo: And like Ghandi he will
try
to ruin a good
thing.