References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
	<4FDB6946.2020400@justmoon.de>
	<CAErK2CgODFY7HMC-WZRAmts-6eOE074Tz4nX5Nr6EvB8o-QWJA@mail.gmail.com>
Message-ID: <1339785500.74108.YahooMailNeo@web121006.mail.ne1.yahoo.com>
Date: Fri, 15 Jun 2012 11:38:20 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CAErK2CgODFY7HMC-WZRAmts-6eOE074Tz4nX5Nr6EvB8o-QWJA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] Near-term scalability
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

Forcing users to switch addresses per received payment to work around a bad=
 fee system would be a braindead decision. You might love software and play=
ing with web plugins, but not everyone does. Artists like Rap News can righ=
t now simply throw up an address and begin accepting donations. That's a hu=
gely powerful and impactful selling point for Bitcoin.=0A=0AI don't really =
see these problems as a concern. Stefan made an excellent post which touche=
d on this, in that miners have an incentive to keep block sizes low so that=
 their blocks propagate. The real problem here is not about block propagati=
on but the user experience. The way I see it, Bitcoin is becoming more spec=
ialised over time and part of that process is abstraction. In the past we a=
ll used the Satoshi client for mining, merchant functions, validating block=
s and personal uses. These are rapidly diverging, and managing the blockcha=
in is not something that user clients should be doing.=0A=0AMike is right w=
hen he says the network only needs a few thousand nodes to function fairly.=
 I am not worried about Bitcoin becoming corrupted because of it being a ne=
twork "by bankers for bankers" because unlike the conventional finance indu=
stry, there are no artificial barriers to entry beyond the base cost. This =
network would always be competitive and strictly operate based on market dy=
namics.=0A=0ACase in point: http://en.wikipedia.org/wiki/Coase_theorem=0A=
=0AWith strict property rights and zero (or low) transaction costs, the all=
ocation of a system does not matter. The system will make efficient use of =
its resources. I don't see why a cabal would try to corrupt Bitcoin at expe=
nse to themselves when a new competitor can enter the market and undercut t=
hem. It's why we expect the ROI on mining to be 0 or negative.=0A=0A=0AI fi=
gured out that if you trust data from a blockchain service and only accept =
data with multiple confirms from each connected service, then you can trivi=
ally calculate the probability of being fed corrupt data (assuming a fixed =
chance per server). In this way, the model is a fault tolerant byzantine sy=
stem. The chance of being manipulated falls expontentially as you add more =
servers. And these services can be made highly scalable if you see my BIP 3=
3.=0A=0Ahttps://en.bitcoin.it/wiki/BIP_0033=0A=0A__________________________=
______=0AFrom: Mike Koss <mike@coinlab.com>=0ATo: Stefan Thomas <moon@justm=
oon.de> =0ACc: bitcoin-development@lists.sourceforge.net =0ASent: Friday, J=
une 15, 2012 7:37 PM=0ASubject: Re: [Bitcoin-development] Near-term scalabi=
lity=0A=0A=0AGrouping mempool transactions based on fees of the group seems=
 an=A0unnecessary=A0complexity; it makes it harder to predict if an isolate=
d transaction has enough "juice" to be included in the next Block.=0A=0AGiv=
en your point about economic actors adapting to conditions, would it not be=
 simpler to use a individual "fee per byte" priority algorithm and let tran=
saction generators distribute their fees accordingly (and more predictably)=
?=0A=0AThis simpler algorithm will prune arbitrary transactions sub-optimal=
ly, but has the benefit of being more understandable and predictable from t=
he point of view of transaction generators.=0A=0A=0A=0AOn Fri, Jun 15, 2012=
 at 9:56 AM, Stefan Thomas <moon@justmoon.de> wrote:=0A=0AThanks Mike for t=
he writeup - I'm very sad to have missed the discussion=0A>on IRC since fee=
 economics are probably my favorite topic, but I'll try=0A>to contribute to=
 the email discussion instead.=0A>=0A>=0A>> (4) Making the block size limit=
 float is better than picking a new=0A>> arbitrary threshold.=0A>=0A>Fees a=
re a product of both real and artificial limits to transaction=0A>validatio=
n.=0A>=0A>The artificial limits like the block size limit are essentially p=
utting=0A>a floor on prices by limiting supply beyond what it would otherwi=
se be.=0A>E.g. the network could confirm more transactions theoretically, b=
ut the=0A>block size limit prevents it.=0A>=0A>The real limits are the band=
width, computing and memory resources of=0A>participating nodes. For the sa=
ke of argument suppose a 1 TB block was=0A>released into the network right =
now and we'll also assume there was no=0A>block size limit of any kind. Man=
y nodes would likely not be able to=0A>successfully download this block in =
under 10-30 minutes, so there is a=0A>very good chance that other miners wi=
ll have generated two blocks before=0A>this block makes its way to them.=0A=
>=0A>What does this mean? The miner generating a 1 TB block knows this woul=
d=0A>happen. So in terms of economic self interest he will generate the=0A>=
largest possible block that he is still confident that other miners will=0A=
>accept and process. A miner who receives a block will also consider=0A>whe=
ther to build on it based on whether they think other miners will be=0A>abl=
e to download it. In other words, if I receive a large block I may=0A>decid=
e not to mine on it, because I believe that the majority of mining=0A>power=
 will not mine on it - because it is either too large for them to=0A>downlo=
ad or because their rules against large blocks reject it.=0A>=0A>It's impor=
tant to understand that in practice economic actors tend to=0A>plan ahead. =
In other words, if there is no block size limit that doesn't=0A>mean that t=
here will be constant forks and total chaos. Rather, no miner=0A>will ever =
want to have a block rejected due to size, there is plenty of=0A>incentive =
to be conservative with your limits. Even if there are forks,=0A>this simpl=
y means that miners have decided that they can make more money=0A>by includ=
ing more transactions at the cost of the occasional dud.=0A>=0A>Therefore, =
from an economic perspective, we do not need a global block=0A>size limit o=
f any kind. As "guardians of the network" the only thing we=0A>need to do i=
s to let miners figure out what they wanna do.=0A>=0A>HOWEVER, the existing=
 economic incentives won't manifest unless somebody=0A>translates them into=
 code. We have to give our users (miners & endusers)=0A>the tools to create=
 a genuine fee-based verification market.=0A>=0A>On the miner side: I would=
 make the block size limit configurable with a=0A>relatively high default. =
If the default is too low few people will=0A>bother changing it, which mean=
s that it is not worth changing (because a=0A>majority uses the default any=
way), which means even fewer people will=0A>change it and so on.=0A>=0A>The=
 block size limit should also be a soft rather than a hard limit -=0A>here =
are some ideas for this:=0A>=0A>- The default limit for accepting blocks fr=
om others should always be=0A>significantly greater than the default limit =
for blocks that the client=0A>itself will generate.=0A>=0A>- There should b=
e different size limits for side chains that are longer=0A>than the current=
ly active chain. In other words, I might reject a block=0A>for being slight=
ly too large, but if everyone else accepts it I should=0A>eventually accept=
 it too, and my client should also consider=0A>automatically raising my siz=
e limit if this happens a lot.=0A>=0A>The rationale for the soft limit is t=
o allow for gradual upward=0A>adjustment. It needs to be risky for individu=
al miners to raise the size=0A>of their blocks to new heights, but ideally =
there won't be one solid=0A>wall for them to run into.=0A>=0A>On the user s=
ide: I would display the fee on the Send Coins dialog and=0A>allow users to=
 choose a different fee per transaction. We also talked=0A>about adding som=
e UI feedback where the client tries to estimate how=0A>long a transaction =
will take to confirm given a certain fee, based on=0A>recent information ab=
out what it observed from the network. If the fee=0A>can be changed on the =
Send Coins tab, then this could be a red, yellow,=0A>green visual indicatio=
n whether the fee is sufficient, adequate or=0A>dangerously low.=0A>=0A>A c=
riticism one might raise is: "The block size limit is not to protect=0A>min=
ers, but to protect end users who may have less resources than miners=0A>an=
d can't download gigantic block chains." - That's a viewpoint that is=0A>ce=
rtainly valid. I believe that we will be able to do a lot just with=0A>effi=
ciency improvements, pruning, compression and whatnot. But when it=0A>comes=
 down to it, I'd prefer a large network with cheap=0A>microtransactions eve=
n if that means that consumer hardware can't=0A>operate as a standalone val=
idating node anymore. Headers-only mode is=0A>already a much-requested feat=
ure anyway and there are many ways of=0A>improving the security of various =
header-only or lightweight protocols.=0A>=0A>(I just saw Greg's message adv=
ocating the opposite viewpoint, I'll=0A>respond to that as soon as I can.)=
=0A>=0A>=0A>=0A>> (1) Change the mining code to group transactions together=
 with their=0A>> mempool dependencies and then calculate all fees as a grou=
p.=0A>=0A>+1 Very good change. This would allow miners to maximize their re=
venue=0A>and in doing so better represent the existing priorities that user=
s=0A>express through fees.=0A>=0A>=0A>=0A>> There was discussion of some on=
e-off changes to address the current=0A>> situation, namely de-ranking tran=
sactions that re-use addresses.=0A>=0A>Discouraging address reuse will not =
change the amount of transactions, I=0A>think we all agree on that. As for =
whether it improves the=0A>prioritization, I'm not sure. Use cases that we =
seek to discourage may=0A>simply switch to random addresses and I don't agr=
ee in and of itself=0A>this is a benefit (see item 4 below). Here are a few=
 reasons one might=0A>be against this proposal:=0A>=0A>1) Certain use cases=
 like green addresses will be forced to become more=0A>complicated than the=
y would otherwise need to be.=0A>=0A>2) It will be harder to read informati=
on straight out of the block=0A>chain, for example right now we can pretty =
easily see how much volume is=0A>caused by Satoshi Dice, perhaps allowing u=
s to make better decisions.=0A>=0A>3) The address index that is used by blo=
ck explorers and lightweight=0A>client servers will grow unnecessarily (an =
address -> tx index will be=0A>larger if the number of unique addresses inc=
reases given the same number=0A>of txs), so for people like myself who work=
 on that type of software=0A>you're actually making our scalability equatio=
n slightly worse.=0A>=0A>4) You're forcing people into privacy best practic=
es which you think are=0A>good, but others may not subscribe to. For exampl=
e I have absolutely=0A>zero interest in privacy, anyone who cares that I bu=
y Bitcoins with my=0A>salary and spend them on paragliding is welcome to kn=
ow about it.=0A>Frankly, if I cared about privacy I wouldn't be using Bitco=
in. If other=0A>people want to use mixing services and randomize their addr=
esses and=0A>communicate through Tor that's fine, but the client shouldn't =
force me=0A>to do those things if I don't want to by "deprioritizing" my tr=
ansactions.=0A>=0A>5) We may not like firstbits, but the fact remains that =
for now they are=0A>extremely popular, because they improve the user experi=
ence where we=0A>failed to do so. If you deprioritize transactions to reuse=
d addresses=0A>you'll for example deprioritize all/most of Girls Gone Bitco=
in, which=0A>(again, like it or not) is one of the few practical, sustainab=
le niches=0A>that Bitcoin has managed to carve out for itself so far.=0A>=
=0A>=0A>=0A>> Having senders/buyers pay no fees is psychologically desirabl=
e even=0A>> though we all understand that eventually, somebody, somewhere w=
ill be=0A>> paying fees to use Bitcoin=0A>=0A>Free is just an extreme form =
of cheap, so if we can make transactions=0A>very cheap (through efficiency =
and very large blocks) then it will be=0A>easier for charitable miners to i=
nclude free transactions. In practice,=0A>my prediction is that free transa=
ctions on the open network will simply=0A>not be possible in the long run. =
Dirty hacks aside there is simply no=0A>way of distinguishing a spam transa=
ction from a charity-worthy=0A>transaction. So the way I envision free tran=
sactions in the future is=0A>that there may be miners in partnership with w=
allet providers like=0A>BlockChain.info that let you submit feeless transac=
tions straight to=0A>them based on maybe a captcha or some ads. (For the pu=
rist, the captcha=0A>challenge and response could be communicated across th=
e bitcoin network,=0A>but I think we agree that such things should ideally =
take place=0A>out-of-band.)=0A>=0A>That way, the available charity of miner=
s who wish to include feeless=0A>transactions would go to human users as op=
posed to the potentially=0A>infinite demand of auto-generated feeless trans=
actions.=0A>=0A>=0A>=0A>=0A>On 6/15/2012 1:29 PM, Mike Hearn wrote:=0A>> I =
had to hit the sack last night as it was 2am CET, but I'd like to=0A>> sum =
up the discussion we had on IRC about scalability and SatoshiDice=0A>> in p=
articular.=0A>>=0A>> I think we all agreed on the following:=0A>>=0A>> - Ha=
ving senders/buyers pay no fees is psychologically desirable even=0A>> thou=
gh we all understand that eventually, somebody, somewhere will be=0A>> payi=
ng fees to use Bitcoin=0A>>=0A>> - In the ideal world Bitcoin would scale p=
erfectly and there would be=0A>> no need for there to be some "winners" and=
 some "losers" when it comes=0A>> to confirmation time.=0A>>=0A>> There was=
 discussion of some one-off changes to address the current=0A>> situation, =
namely de-ranking transactions that re-use addresses. Gavin=0A>> and myself=
 were not keen on this idea, primarily because it just=0A>> avoids the real=
 problem and Bitcoin already has a good way to=0A>> prioritize transactions=
 via the fees mechanism itself. The real issue=0A>> is that SatoshiDice doe=
s indeed pay fees and generates a lot of=0A>> transactions, pushing more tr=
aditional traffic out due to artificial=0A>> throttles.=0A>>=0A>> The follo=
wing set of proposals were discussed:=0A>>=0A>> (1) Change the mining code =
to group transactions together with their=0A>> mempool dependencies and the=
n calculate all fees as a group. A tx with=0A>> a fee of 1 BTC that depends=
 on 5 txns with zero fees would result in=0A>> all 6 transactions being con=
sidered to have a fee of 1BTC and=0A>> therefore become prioritized for inc=
lusion. This allows a transition=0A>> to "receiver pays" model for fees. Th=
ere are many advantages. One is=0A>> that it actually makes sense ... it's =
always the receiver who wants=0A>> confirmations because it's the receiver =
that fears double spends.=0A>> Senders never do. What's more, whilst Bitcoi=
n is designed to operate=0A>> on a zero-trust model in the real world trust=
 often exists and it can=0A>> be used to optimize by passing groups of tran=
sactions around with=0A>> their dependencies, until that group passes a tru=
st boundary and gets=0A>> broadcast with a send-to-self tx to add fees. Ano=
ther advantage is it=0A>> simplifies usage for end users who primarily buy =
rather than sell,=0A>> because it avoids the need to guess at fees, one of =
the most=0A>> problematic parts of Bitcoins design now.=0A>>=0A>> The disad=
vantages are that it can result in extra transactions that=0A>> exist only =
for adding fees, and it requires a more modern payment=0A>> protocol than t=
he direct-IP protocol Satoshi designed.=0A>>=0A>> It would help address the=
 current situation by avoiding angry users=0A>> who want to buy things, but=
 don't know what fee to set and so their=0A>> transactions get stuck.=0A>>=
=0A>> (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to=
=0A>> avoid paying excessive fees and queue-jumping. Guess that's on my=0A>=
> plate.=0A>>=0A>> (3) Scalability improvements seem like a no brainer to e=
veryone, it's=0A>> just a case of how complicated they are.=0A>>=0A>> (4) M=
aking the block size limit float is better than picking a new=0A>> arbitrar=
y threshold.=0A>>=0A>> On the forums Matt stated that block chain pruning w=
as a no-go because=0A>> "it makes bitcoin more centralized". I think we've =
thrashed this one=0A>> out sufficiently well by now that there should be a =
united opinion on=0A>> it. There are technical ways to implement it such th=
at there is no=0A>> change of trust requirements. All the other issues (fin=
ding archival=0A>> nodes, etc) can be again addressed with sufficient progr=
amming.=0A>>=0A>> For the case of huge blocks slowing down end user syncing=
 and wasting=0A>> their resources, SPV clients like MultiBit and Android Wa=
llet already=0A>> exist and will get better with time. If Jeff implements t=
he bloom=0A>> filtering p2p commands I'll make bitcoinj use them and that'l=
l knock=0A>> out excessive bandwidth usage and parse overheads from end use=
rs who=0A>> are on these clients. At some point Bitcoin-Qt can have a dual =
mode,=0A>> but who knows when that'll get implemented.=0A>>=0A>> Does that =
all sound reasonable?=0A>>=0A>> -------------------------------------------=
-----------------------------------=0A>> Live Security Virtual Conference=
=0A>> Exclusive live event will cover all the ways today's security and=0A>=
> threat landscape has changed and how IT managers can respond. Discussions=
=0A>> will include endpoint security, mobile security and the latest in mal=
ware=0A>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263=
/=0A>> _______________________________________________=0A>> Bitcoin-develop=
ment mailing list=0A>> Bitcoin-development@lists.sourceforge.net=0A>> https=
://lists.sourceforge.net/lists/listinfo/bitcoin-development=0A>>=0A>=0A>=0A=
>--------------------------------------------------------------------------=
----=0A>Live Security Virtual Conference=0A>Exclusive live event will cover=
 all the ways today's security and=0A>threat landscape has changed and how =
IT managers can respond. Discussions=0A>will include endpoint security, mob=
ile security and the latest in malware=0A>threats. http://www.accelacomm.co=
m/jaw/sfrnl04242012/114/50122263/=0A>______________________________________=
_________=0A>Bitcoin-development mailing list=0A>Bitcoin-development@lists.=
sourceforge.net=0A>https://lists.sourceforge.net/lists/listinfo/bitcoin-dev=
elopment=0A>=0A=0A=0A-- =0AMike Koss=0ACTO, CoinLab=0A(425) 246-7701 (m)=0A=
=0AA Bitcoin Primer=A0- What you need to know about Bitcoins.=0A=0A--------=
----------------------------------------------------------------------=0ALi=
ve Security Virtual Conference=0AExclusive live event will cover all the wa=
ys today's security and =0Athreat landscape has changed and how IT managers=
 can respond. Discussions =0Awill include endpoint security, mobile securit=
y and the latest in malware =0Athreats. http://www.accelacomm.com/jaw/sfrnl=
04242012/114/50122263/=0A_______________________________________________=0A=
Bitcoin-development mailing list=0ABitcoin-development@lists.sourceforge.ne=
t=0Ahttps://lists.sourceforge.net/lists/listinfo/bitcoin-development