From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <zgenjix@yahoo.com>) id 1SfbPh-0006yQ-Vk for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 18:38:29 +0000 X-ACL-Warn: Received: from nm22-vm1.bullet.mail.ne1.yahoo.com ([98.138.90.252]) by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1SfbPe-0005TN-8N for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 18:38:29 +0000 Received: from [98.138.90.52] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 18:38:20 -0000 Received: from [98.138.89.168] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 18:38:20 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 18:38:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 509061.83804.bm@omp1024.mail.ne1.yahoo.com Received: (qmail 63939 invoked by uid 60001); 15 Jun 2012 18:38:20 -0000 X-YMail-OSG: sDBEXVkVM1kyZ67H7hu7f2yLr3fIpf2QETGnqZpiWz88Vl. ScPz1vhEJO3bUgvDbGzEYqgdkTAXQ_eOcsylSwsbnZyaNajEBHBJ5j9qiHKP MDilcIVWXOtLC95TA87kROMM4ngtrocECgaYDwQXjrsK4wZ2IdlA7.mM37HR 601_6uJE4HE6emlIdr.4t44WEeu_7vSZ4G9L.npWchowxNzi5sLcuaFHDtob TrfvwPo3GME5u2ZyPFYLv4Y5ETAS88l.vEpiffqR8q0bpeNNLiQ3HCj3tzO4 QFzxqvrmw3TUDdHxYDOoJLR9LVxNaFmXhqxQ4ohZXs.CJWY0i6lueFq_buUH Dag8BBKbgEQs7G5vCVSMhPqEm9YE3YUTF.i2CCFMcDuoj1NAUdUW52pInP6T 2_BB2DkHLySoO.JdHulr_Qqw_KC6sVu7uaG6w8bbHd4eZQ0XKiNnUe2hToSr 1ayWkLDiQujdp2zClpBfpamLZd1pFOYeYUghMf6daszYBUbblWvK0SMADTSq _OXuaPtOsKweTUz5mvAQOYI2rEoUShjoHjih_bkVrGQ1nmgOPzTNX6h2Nv7G LEtqxVM2lXZUP36TkBGKyiKNyoAeF_d7YgcxzT1Yi6C.Gjm1buLZysDyN.nm P5LNhV_sehVGKFbkDu12Y9gHUWTcz8jaQc6YEw9jVnCptXCS2Xb8D75effrn CSNO5ojK5Dw0dF2zE76eHe5c- Received: from [213.129.230.10] by web121006.mail.ne1.yahoo.com via HTTP; Fri, 15 Jun 2012 11:38:20 PDT X-Mailer: YahooMailWebService/0.8.118.349524 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 X-Spam-Score: -0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.90.252 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 FSL_FREEMAIL_2 FSL_FREEMAIL_2 0.0 FSL_FREEMAIL_1 FSL_FREEMAIL_1 X-Headers-End: 1SfbPe-0005TN-8N Subject: Re: [Bitcoin-development] Near-term scalability X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki <zgenjix@yahoo.com> List-Id: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Fri, 15 Jun 2012 18:38:30 -0000 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