path: root/5d/2685a760f80294e023fd6ed5528ea0f5d21836

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mike@coinlab.com>) id 1Sfarb-0005jB-Ek
	for bitcoin-development@lists.sourceforge.net;
	Fri, 15 Jun 2012 18:03:15 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com
	designates 209.85.212.47 as permitted sender)
	client-ip=209.85.212.47; envelope-from=mike@coinlab.com;
	helo=mail-vb0-f47.google.com; 
Received: from mail-vb0-f47.google.com ([209.85.212.47])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1SfarZ-0001Cd-5N
	for bitcoin-development@lists.sourceforge.net;
	Fri, 15 Jun 2012 18:03:15 +0000
Received: by vbbfr13 with SMTP id fr13so2143942vbb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 15 Jun 2012 11:03:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=6/M1M+xYvXW+GxyhoFbqCvs39HEFUzdYJLaCGjzZ2NA=;
	b=PYlGKLt0Crixqm8mGbiOQoTuxu2HtxB6En/crWzzrA/T7k+NvRtIpzHCzphnFP7Jfz
	lJ4TMGdI3Z1ijwGCgdEgk7422MRSepAwDZlBQ/ytdtYaLN6KgCwGBNBHvXyAztgGUS62
	CvgxJmJAMAMorS01qPcVYm+LZv/lnB1GevBUFpLMZ8sasjc2gB/D9tCHVWxFlOWt5vcR
	SrjMWw9BAPkw7TsGfi4GuUzmJFvvP3XTPw1RFnE4JQGM7sUtIRXzIUsQ3dXqVsNm4FBT
	jyKVCK7DML88xI6BpjeYUqXMogDsDWH3+5LDPD4SpqyP14XNx9Jkoed4CRTp8KO8lgBE
	W/cg==
MIME-Version: 1.0
Received: by 10.52.174.99 with SMTP id br3mr2793939vdc.85.1339781824375; Fri,
	15 Jun 2012 10:37:04 -0700 (PDT)
Received: by 10.52.68.212 with HTTP; Fri, 15 Jun 2012 10:37:04 -0700 (PDT)
In-Reply-To: <4FDB6946.2020400@justmoon.de>
References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
	<4FDB6946.2020400@justmoon.de>
Date: Fri, 15 Jun 2012 10:37:04 -0700
Message-ID: <CAErK2CgODFY7HMC-WZRAmts-6eOE074Tz4nX5Nr6EvB8o-QWJA@mail.gmail.com>
From: Mike Koss <mike@coinlab.com>
To: Stefan Thomas <moon@justmoon.de>
Content-Type: multipart/alternative; boundary=bcaec51ba443b7eadb04c2864361
X-Gm-Message-State: ALoCoQmrnxfBlMPuol/yy4iugbAt+uBYPZ4IP5CKHG0p/ZmJZteO5ScTo8ARm+gucc7Kt6SjbLvE
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1SfarZ-0001Cd-5N
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Near-term scalability
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
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:03:15 -0000

--bcaec51ba443b7eadb04c2864361
Content-Type: text/plain; charset=ISO-8859-1

Grouping mempool transactions based on fees of the group seems
an unnecessary complexity; it makes it harder to predict if an isolated
transaction has enough "juice" to be included in the next Block.

Given your point about economic actors adapting to conditions, would it not
be simpler to use a individual "fee per byte" priority algorithm and let
transaction generators distribute their fees accordingly (and more
predictably)?

This simpler algorithm will prune arbitrary transactions sub-optimally, but
has the benefit of being more understandable and predictable from the point
of view of transaction generators.

On Fri, Jun 15, 2012 at 9:56 AM, Stefan Thomas <moon@justmoon.de> wrote:

> Thanks Mike for the writeup - I'm very sad to have missed the discussion
> on IRC since fee economics are probably my favorite topic, but I'll try
> to contribute to the email discussion instead.
>
> > (4) Making the block size limit float is better than picking a new
> > arbitrary threshold.
>
> Fees are a product of both real and artificial limits to transaction
> validation.
>
> The artificial limits like the block size limit are essentially putting
> a floor on prices by limiting supply beyond what it would otherwise be.
> E.g. the network could confirm more transactions theoretically, but the
> block size limit prevents it.
>
> The real limits are the bandwidth, computing and memory resources of
> participating nodes. For the sake of argument suppose a 1 TB block was
> released into the network right now and we'll also assume there was no
> block size limit of any kind. Many nodes would likely not be able to
> successfully download this block in under 10-30 minutes, so there is a
> very good chance that other miners will have generated two blocks before
> this block makes its way to them.
>
> What does this mean? The miner generating a 1 TB block knows this would
> happen. So in terms of economic self interest he will generate the
> largest possible block that he is still confident that other miners will
> accept and process. A miner who receives a block will also consider
> whether to build on it based on whether they think other miners will be
> able to download it. In other words, if I receive a large block I may
> decide not to mine on it, because I believe that the majority of mining
> power will not mine on it - because it is either too large for them to
> download or because their rules against large blocks reject it.
>
> It's important to understand that in practice economic actors tend to
> plan ahead. In other words, if there is no block size limit that doesn't
> mean that there will be constant forks and total chaos. Rather, no miner
> will ever want to have a block rejected due to size, there is plenty of
> incentive to be conservative with your limits. Even if there are forks,
> this simply means that miners have decided that they can make more money
> by including more transactions at the cost of the occasional dud.
>
> Therefore, from an economic perspective, we do not need a global block
> size limit of any kind. As "guardians of the network" the only thing we
> need to do is to let miners figure out what they wanna do.
>
> HOWEVER, the existing economic incentives won't manifest unless somebody
> translates them into code. We have to give our users (miners & endusers)
> the tools to create a genuine fee-based verification market.
>
> On the miner side: I would make the block size limit configurable with a
> relatively high default. If the default is too low few people will
> bother changing it, which means that it is not worth changing (because a
> majority uses the default anyway), which means even fewer people will
> change it and so on.
>
> The block size limit should also be a soft rather than a hard limit -
> here are some ideas for this:
>
> - The default limit for accepting blocks from others should always be
> significantly greater than the default limit for blocks that the client
> itself will generate.
>
> - There should be different size limits for side chains that are longer
> than the currently active chain. In other words, I might reject a block
> for being slightly too large, but if everyone else accepts it I should
> eventually accept it too, and my client should also consider
> automatically raising my size limit if this happens a lot.
>
> The rationale for the soft limit is to allow for gradual upward
> adjustment. It needs to be risky for individual miners to raise the size
> of their blocks to new heights, but ideally there won't be one solid
> wall for them to run into.
>
> On the user side: I would display the fee on the Send Coins dialog and
> allow users to choose a different fee per transaction. We also talked
> about adding some UI feedback where the client tries to estimate how
> long a transaction will take to confirm given a certain fee, based on
> recent information about what it observed from the network. If the fee
> can be changed on the Send Coins tab, then this could be a red, yellow,
> green visual indication whether the fee is sufficient, adequate or
> dangerously low.
>
> A criticism one might raise is: "The block size limit is not to protect
> miners, but to protect end users who may have less resources than miners
> and can't download gigantic block chains." - That's a viewpoint that is
> certainly valid. I believe that we will be able to do a lot just with
> efficiency improvements, pruning, compression and whatnot. But when it
> comes down to it, I'd prefer a large network with cheap
> microtransactions even if that means that consumer hardware can't
> operate as a standalone validating node anymore. Headers-only mode is
> already a much-requested feature anyway and there are many ways of
> improving the security of various header-only or lightweight protocols.
>
> (I just saw Greg's message advocating the opposite viewpoint, I'll
> respond to that as soon as I can.)
>
>
> > (1) Change the mining code to group transactions together with their
> > mempool dependencies and then calculate all fees as a group.
>
> +1 Very good change. This would allow miners to maximize their revenue
> and in doing so better represent the existing priorities that users
> express through fees.
>
>
> > There was discussion of some one-off changes to address the current
> > situation, namely de-ranking transactions that re-use addresses.
>
> Discouraging address reuse will not change the amount of transactions, I
> think we all agree on that. As for whether it improves the
> prioritization, I'm not sure. Use cases that we seek to discourage may
> simply switch to random addresses and I don't agree in and of itself
> this is a benefit (see item 4 below). Here are a few reasons one might
> be against this proposal:
>
> 1) Certain use cases like green addresses will be forced to become more
> complicated than they would otherwise need to be.
>
> 2) It will be harder to read information straight out of the block
> chain, for example right now we can pretty easily see how much volume is
> caused by Satoshi Dice, perhaps allowing us to make better decisions.
>
> 3) The address index that is used by block explorers and lightweight
> client servers will grow unnecessarily (an address -> tx index will be
> larger if the number of unique addresses increases given the same number
> of txs), so for people like myself who work on that type of software
> you're actually making our scalability equation slightly worse.
>
> 4) You're forcing people into privacy best practices which you think are
> good, but others may not subscribe to. For example I have absolutely
> zero interest in privacy, anyone who cares that I buy Bitcoins with my
> salary and spend them on paragliding is welcome to know about it.
> Frankly, if I cared about privacy I wouldn't be using Bitcoin. If other
> people want to use mixing services and randomize their addresses and
> communicate through Tor that's fine, but the client shouldn't force me
> to do those things if I don't want to by "deprioritizing" my transactions.
>
> 5) We may not like firstbits, but the fact remains that for now they are
> extremely popular, because they improve the user experience where we
> failed to do so. If you deprioritize transactions to reused addresses
> you'll for example deprioritize all/most of Girls Gone Bitcoin, which
> (again, like it or not) is one of the few practical, sustainable niches
> that Bitcoin has managed to carve out for itself so far.
>
>
> > Having senders/buyers pay no fees is psychologically desirable even
> > though we all understand that eventually, somebody, somewhere will be
> > paying fees to use Bitcoin
>
> Free is just an extreme form of cheap, so if we can make transactions
> very cheap (through efficiency and very large blocks) then it will be
> easier for charitable miners to include free transactions. In practice,
> my prediction is that free transactions on the open network will simply
> not be possible in the long run. Dirty hacks aside there is simply no
> way of distinguishing a spam transaction from a charity-worthy
> transaction. So the way I envision free transactions in the future is
> that there may be miners in partnership with wallet providers like
> BlockChain.info that let you submit feeless transactions straight to
> them based on maybe a captcha or some ads. (For the purist, the captcha
> challenge and response could be communicated across the bitcoin network,
> but I think we agree that such things should ideally take place
> out-of-band.)
>
> That way, the available charity of miners who wish to include feeless
> transactions would go to human users as opposed to the potentially
> infinite demand of auto-generated feeless transactions.
>
>
>
> On 6/15/2012 1:29 PM, Mike Hearn wrote:
> > I had to hit the sack last night as it was 2am CET, but I'd like to
> > sum up the discussion we had on IRC about scalability and SatoshiDice
> > in particular.
> >
> > I think we all agreed on the following:
> >
> > - Having senders/buyers pay no fees is psychologically desirable even
> > though we all understand that eventually, somebody, somewhere will be
> > paying fees to use Bitcoin
> >
> > - In the ideal world Bitcoin would scale perfectly and there would be
> > no need for there to be some "winners" and some "losers" when it comes
> > to confirmation time.
> >
> > There was discussion of some one-off changes to address the current
> > situation, namely de-ranking transactions that re-use addresses. Gavin
> > and myself were not keen on this idea, primarily because it just
> > avoids the real problem and Bitcoin already has a good way to
> > prioritize transactions via the fees mechanism itself. The real issue
> > is that SatoshiDice does indeed pay fees and generates a lot of
> > transactions, pushing more traditional traffic out due to artificial
> > throttles.
> >
> > The following set of proposals were discussed:
> >
> > (1) Change the mining code to group transactions together with their
> > mempool dependencies and then calculate all fees as a group. A tx with
> > a fee of 1 BTC that depends on 5 txns with zero fees would result in
> > all 6 transactions being considered to have a fee of 1BTC and
> > therefore become prioritized for inclusion. This allows a transition
> > to "receiver pays" model for fees. There are many advantages. One is
> > that it actually makes sense ... it's always the receiver who wants
> > confirmations because it's the receiver that fears double spends.
> > Senders never do. What's more, whilst Bitcoin is designed to operate
> > on a zero-trust model in the real world trust often exists and it can
> > be used to optimize by passing groups of transactions around with
> > their dependencies, until that group passes a trust boundary and gets
> > broadcast with a send-to-self tx to add fees. Another advantage is it
> > simplifies usage for end users who primarily buy rather than sell,
> > because it avoids the need to guess at fees, one of the most
> > problematic parts of Bitcoins design now.
> >
> > The disadvantages are that it can result in extra transactions that
> > exist only for adding fees, and it requires a more modern payment
> > protocol than the direct-IP protocol Satoshi designed.
> >
> > It would help address the current situation by avoiding angry users
> > who want to buy things, but don't know what fee to set and so their
> > transactions get stuck.
> >
> > (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
> > avoid paying excessive fees and queue-jumping. Guess that's on my
> > plate.
> >
> > (3) Scalability improvements seem like a no brainer to everyone, it's
> > just a case of how complicated they are.
> >
> > (4) Making the block size limit float is better than picking a new
> > arbitrary threshold.
> >
> > On the forums Matt stated that block chain pruning was a no-go because
> > "it makes bitcoin more centralized". I think we've thrashed this one
> > out sufficiently well by now that there should be a united opinion on
> > it. There are technical ways to implement it such that there is no
> > change of trust requirements. All the other issues (finding archival
> > nodes, etc) can be again addressed with sufficient programming.
> >
> > For the case of huge blocks slowing down end user syncing and wasting
> > their resources, SPV clients like MultiBit and Android Wallet already
> > exist and will get better with time. If Jeff implements the bloom
> > filtering p2p commands I'll make bitcoinj use them and that'll knock
> > out excessive bandwidth usage and parse overheads from end users who
> > are on these clients. At some point Bitcoin-Qt can have a dual mode,
> > but who knows when that'll get implemented.
> >
> > Does that all sound reasonable?
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)

A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.

--bcaec51ba443b7eadb04c2864361
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Grouping mempool transactions based on fees of the group seems an=A0unneces=
sary=A0complexity; it makes it harder to predict if an isolated transaction=
 has enough &quot;juice&quot; to be included in the next Block.<div><br></d=
iv>
<div>Given your point about economic actors adapting to conditions, would i=
t not be simpler to use a individual &quot;fee per byte&quot; priority algo=
rithm and let transaction generators distribute their fees accordingly (and=
 more predictably)?</div>
<div><br></div><div>This simpler algorithm will prune arbitrary transaction=
s sub-optimally, but has the benefit of being more understandable and predi=
ctable from the point of view of transaction generators.<br><div><br><div c=
lass=3D"gmail_quote">
On Fri, Jun 15, 2012 at 9:56 AM, Stefan Thomas <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:moon@justmoon.de" target=3D"_blank">moon@justmoon.de</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Thanks Mike for the writeup - I&#39;m very sad to have missed the discussio=
n<br>
on IRC since fee economics are probably my favorite topic, but I&#39;ll try=
<br>
to contribute to the email discussion instead.<br>
<div class=3D"im"><br>
&gt; (4) Making the block size limit float is better than picking a new<br>
&gt; arbitrary threshold.<br>
<br>
</div>Fees are a product of both real and artificial limits to transaction<=
br>
validation.<br>
<br>
The artificial limits like the block size limit are essentially putting<br>
a floor on prices by limiting supply beyond what it would otherwise be.<br>
E.g. the network could confirm more transactions theoretically, but the<br>
block size limit prevents it.<br>
<br>
The real limits are the bandwidth, computing and memory resources of<br>
participating nodes. For the sake of argument suppose a 1 TB block was<br>
released into the network right now and we&#39;ll also assume there was no<=
br>
block size limit of any kind. Many nodes would likely not be able to<br>
successfully download this block in under 10-30 minutes, so there is a<br>
very good chance that other miners will have generated two blocks before<br=
>
this block makes its way to them.<br>
<br>
What does this mean? The miner generating a 1 TB block knows this would<br>
happen. So in terms of economic self interest he will generate the<br>
largest possible block that he is still confident that other miners will<br=
>
accept and process. A miner who receives a block will also consider<br>
whether to build on it based on whether they think other miners will be<br>
able to download it. In other words, if I receive a large block I may<br>
decide not to mine on it, because I believe that the majority of mining<br>
power will not mine on it - because it is either too large for them to<br>
download or because their rules against large blocks reject it.<br>
<br>
It&#39;s important to understand that in practice economic actors tend to<b=
r>
plan ahead. In other words, if there is no block size limit that doesn&#39;=
t<br>
mean that there will be constant forks and total chaos. Rather, no miner<br=
>
will ever want to have a block rejected due to size, there is plenty of<br>
incentive to be conservative with your limits. Even if there are forks,<br>
this simply means that miners have decided that they can make more money<br=
>
by including more transactions at the cost of the occasional dud.<br>
<br>
Therefore, from an economic perspective, we do not need a global block<br>
size limit of any kind. As &quot;guardians of the network&quot; the only th=
ing we<br>
need to do is to let miners figure out what they wanna do.<br>
<br>
HOWEVER, the existing economic incentives won&#39;t manifest unless somebod=
y<br>
translates them into code. We have to give our users (miners &amp; endusers=
)<br>
the tools to create a genuine fee-based verification market.<br>
<br>
On the miner side: I would make the block size limit configurable with a<br=
>
relatively high default. If the default is too low few people will<br>
bother changing it, which means that it is not worth changing (because a<br=
>
majority uses the default anyway), which means even fewer people will<br>
change it and so on.<br>
<br>
The block size limit should also be a soft rather than a hard limit -<br>
here are some ideas for this:<br>
<br>
- The default limit for accepting blocks from others should always be<br>
significantly greater than the default limit for blocks that the client<br>
itself will generate.<br>
<br>
- There should be different size limits for side chains that are longer<br>
than the currently active chain. In other words, I might reject a block<br>
for being slightly too large, but if everyone else accepts it I should<br>
eventually accept it too, and my client should also consider<br>
automatically raising my size limit if this happens a lot.<br>
<br>
The rationale for the soft limit is to allow for gradual upward<br>
adjustment. It needs to be risky for individual miners to raise the size<br=
>
of their blocks to new heights, but ideally there won&#39;t be one solid<br=
>
wall for them to run into.<br>
<br>
On the user side: I would display the fee on the Send Coins dialog and<br>
allow users to choose a different fee per transaction. We also talked<br>
about adding some UI feedback where the client tries to estimate how<br>
long a transaction will take to confirm given a certain fee, based on<br>
recent information about what it observed from the network. If the fee<br>
can be changed on the Send Coins tab, then this could be a red, yellow,<br>
green visual indication whether the fee is sufficient, adequate or<br>
dangerously low.<br>
<br>
A criticism one might raise is: &quot;The block size limit is not to protec=
t<br>
miners, but to protect end users who may have less resources than miners<br=
>
and can&#39;t download gigantic block chains.&quot; - That&#39;s a viewpoin=
t that is<br>
certainly valid. I believe that we will be able to do a lot just with<br>
efficiency improvements, pruning, compression and whatnot. But when it<br>
comes down to it, I&#39;d prefer a large network with cheap<br>
microtransactions even if that means that consumer hardware can&#39;t<br>
operate as a standalone validating node anymore. Headers-only mode is<br>
already a much-requested feature anyway and there are many ways of<br>
improving the security of various header-only or lightweight protocols.<br>
<br>
(I just saw Greg&#39;s message advocating the opposite viewpoint, I&#39;ll<=
br>
respond to that as soon as I can.)<br>
<div class=3D"im"><br>
<br>
&gt; (1) Change the mining code to group transactions together with their<b=
r>
&gt; mempool dependencies and then calculate all fees as a group.<br>
<br>
</div>+1 Very good change. This would allow miners to maximize their revenu=
e<br>
and in doing so better represent the existing priorities that users<br>
express through fees.<br>
<div class=3D"im"><br>
<br>
&gt; There was discussion of some one-off changes to address the current<br=
>
&gt; situation, namely de-ranking transactions that re-use addresses.<br>
<br>
</div>Discouraging address reuse will not change the amount of transactions=
, I<br>
think we all agree on that. As for whether it improves the<br>
prioritization, I&#39;m not sure. Use cases that we seek to discourage may<=
br>
simply switch to random addresses and I don&#39;t agree in and of itself<br=
>
this is a benefit (see item 4 below). Here are a few reasons one might<br>
be against this proposal:<br>
<br>
1) Certain use cases like green addresses will be forced to become more<br>
complicated than they would otherwise need to be.<br>
<br>
2) It will be harder to read information straight out of the block<br>
chain, for example right now we can pretty easily see how much volume is<br=
>
caused by Satoshi Dice, perhaps allowing us to make better decisions.<br>
<br>
3) The address index that is used by block explorers and lightweight<br>
client servers will grow unnecessarily (an address -&gt; tx index will be<b=
r>
larger if the number of unique addresses increases given the same number<br=
>
of txs), so for people like myself who work on that type of software<br>
you&#39;re actually making our scalability equation slightly worse.<br>
<br>
4) You&#39;re forcing people into privacy best practices which you think ar=
e<br>
good, but others may not subscribe to. For example I have absolutely<br>
zero interest in privacy, anyone who cares that I buy Bitcoins with my<br>
salary and spend them on paragliding is welcome to know about it.<br>
Frankly, if I cared about privacy I wouldn&#39;t be using Bitcoin. If other=
<br>
people want to use mixing services and randomize their addresses and<br>
communicate through Tor that&#39;s fine, but the client shouldn&#39;t force=
 me<br>
to do those things if I don&#39;t want to by &quot;deprioritizing&quot; my =
transactions.<br>
<br>
5) We may not like firstbits, but the fact remains that for now they are<br=
>
extremely popular, because they improve the user experience where we<br>
failed to do so. If you deprioritize transactions to reused addresses<br>
you&#39;ll for example deprioritize all/most of Girls Gone Bitcoin, which<b=
r>
(again, like it or not) is one of the few practical, sustainable niches<br>
that Bitcoin has managed to carve out for itself so far.<br>
<div class=3D"im"><br>
<br>
&gt; Having senders/buyers pay no fees is psychologically desirable even<br=
>
&gt; though we all understand that eventually, somebody, somewhere will be<=
br>
&gt; paying fees to use Bitcoin<br>
<br>
</div>Free is just an extreme form of cheap, so if we can make transactions=
<br>
very cheap (through efficiency and very large blocks) then it will be<br>
easier for charitable miners to include free transactions. In practice,<br>
my prediction is that free transactions on the open network will simply<br>
not be possible in the long run. Dirty hacks aside there is simply no<br>
way of distinguishing a spam transaction from a charity-worthy<br>
transaction. So the way I envision free transactions in the future is<br>
that there may be miners in partnership with wallet providers like<br>
BlockChain.info that let you submit feeless transactions straight to<br>
them based on maybe a captcha or some ads. (For the purist, the captcha<br>
challenge and response could be communicated across the bitcoin network,<br=
>
but I think we agree that such things should ideally take place<br>
out-of-band.)<br>
<br>
That way, the available charity of miners who wish to include feeless<br>
transactions would go to human users as opposed to the potentially<br>
infinite demand of auto-generated feeless transactions.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On 6/15/2012 1:29 PM, Mike Hearn wrote:<br>
&gt; I had to hit the sack last night as it was 2am CET, but I&#39;d like t=
o<br>
&gt; sum up the discussion we had on IRC about scalability and SatoshiDice<=
br>
&gt; in particular.<br>
&gt;<br>
&gt; I think we all agreed on the following:<br>
&gt;<br>
&gt; - Having senders/buyers pay no fees is psychologically desirable even<=
br>
&gt; though we all understand that eventually, somebody, somewhere will be<=
br>
&gt; paying fees to use Bitcoin<br>
&gt;<br>
&gt; - In the ideal world Bitcoin would scale perfectly and there would be<=
br>
&gt; no need for there to be some &quot;winners&quot; and some &quot;losers=
&quot; when it comes<br>
&gt; to confirmation time.<br>
&gt;<br>
&gt; There was discussion of some one-off changes to address the current<br=
>
&gt; situation, namely de-ranking transactions that re-use addresses. Gavin=
<br>
&gt; and myself were not keen on this idea, primarily because it just<br>
&gt; avoids the real problem and Bitcoin already has a good way to<br>
&gt; prioritize transactions via the fees mechanism itself. The real issue<=
br>
&gt; is that SatoshiDice does indeed pay fees and generates a lot of<br>
&gt; transactions, pushing more traditional traffic out due to artificial<b=
r>
&gt; throttles.<br>
&gt;<br>
&gt; The following set of proposals were discussed:<br>
&gt;<br>
&gt; (1) Change the mining code to group transactions together with their<b=
r>
&gt; mempool dependencies and then calculate all fees as a group. A tx with=
<br>
&gt; a fee of 1 BTC that depends on 5 txns with zero fees would result in<b=
r>
&gt; all 6 transactions being considered to have a fee of 1BTC and<br>
&gt; therefore become prioritized for inclusion. This allows a transition<b=
r>
&gt; to &quot;receiver pays&quot; model for fees. There are many advantages=
. One is<br>
&gt; that it actually makes sense ... it&#39;s always the receiver who want=
s<br>
&gt; confirmations because it&#39;s the receiver that fears double spends.<=
br>
&gt; Senders never do. What&#39;s more, whilst Bitcoin is designed to opera=
te<br>
&gt; on a zero-trust model in the real world trust often exists and it can<=
br>
&gt; be used to optimize by passing groups of transactions around with<br>
&gt; their dependencies, until that group passes a trust boundary and gets<=
br>
&gt; broadcast with a send-to-self tx to add fees. Another advantage is it<=
br>
&gt; simplifies usage for end users who primarily buy rather than sell,<br>
&gt; because it avoids the need to guess at fees, one of the most<br>
&gt; problematic parts of Bitcoins design now.<br>
&gt;<br>
&gt; The disadvantages are that it can result in extra transactions that<br=
>
&gt; exist only for adding fees, and it requires a more modern payment<br>
&gt; protocol than the direct-IP protocol Satoshi designed.<br>
&gt;<br>
&gt; It would help address the current situation by avoiding angry users<br=
>
&gt; who want to buy things, but don&#39;t know what fee to set and so thei=
r<br>
&gt; transactions get stuck.<br>
&gt;<br>
&gt; (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to<br=
>
&gt; avoid paying excessive fees and queue-jumping. Guess that&#39;s on my<=
br>
&gt; plate.<br>
&gt;<br>
&gt; (3) Scalability improvements seem like a no brainer to everyone, it&#3=
9;s<br>
&gt; just a case of how complicated they are.<br>
&gt;<br>
&gt; (4) Making the block size limit float is better than picking a new<br>
&gt; arbitrary threshold.<br>
&gt;<br>
&gt; On the forums Matt stated that block chain pruning was a no-go because=
<br>
&gt; &quot;it makes bitcoin more centralized&quot;. I think we&#39;ve thras=
hed this one<br>
&gt; out sufficiently well by now that there should be a united opinion on<=
br>
&gt; it. There are technical ways to implement it such that there is no<br>
&gt; change of trust requirements. All the other issues (finding archival<b=
r>
&gt; nodes, etc) can be again addressed with sufficient programming.<br>
&gt;<br>
&gt; For the case of huge blocks slowing down end user syncing and wasting<=
br>
&gt; their resources, SPV clients like MultiBit and Android Wallet already<=
br>
&gt; exist and will get better with time. If Jeff implements the bloom<br>
&gt; filtering p2p commands I&#39;ll make bitcoinj use them and that&#39;ll=
 knock<br>
&gt; out excessive bandwidth usage and parse overheads from end users who<b=
r>
&gt; are on these clients. At some point Bitcoin-Qt can have a dual mode,<b=
r>
&gt; but who knows when that&#39;ll get implemented.<br>
&gt;<br>
&gt; Does that all sound reasonable?<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; Live Security Virtual Conference<br>
&gt; Exclusive live event will cover all the ways today&#39;s security and<=
br>
&gt; threat landscape has changed and how IT managers can respond. Discussi=
ons<br>
&gt; will include endpoint security, mobile security and the latest in malw=
are<br>
&gt; threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/50=
122263/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/=
50122263/</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today&#39;s security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Mike Koss<div>CTO, CoinLab</div><div>(425) 246-7701 (m)</div><div><br></div=
><div><a href=3D"http://coinlab.com/a-bitcoin-primer.pdf" target=3D"_blank"=
>A Bitcoin Primer</a>=A0- What you need to know about Bitcoins.</div>
<br>
</div></div>

--bcaec51ba443b7eadb04c2864361--