Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Venzen Khaosan via bitcoin-dev 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Your concern for adoption is valid yet there are a few assumptions in
your discussion and they are a common thread in the current wave of
"bigger blocksize" topics.

1) Supplying bigger blocks will meet the demand of more people:

Anyone can transact via Bitcoin. By increasing blocksize and making
more transactions possible at low fees, what's to stop a large
corporation, bank or government from using the protocol as a cheap
settlement mechanism. They don't have to fund or develop their own
(well, Ecuador has, for this exact use-case) and perhaps the utility
and capacity of the Bitcoin network means reliability and low fees
(cheaper than a bank clearance, say) for their use-case. In the
process they hog xMB of space in each block and discussion about a
capacity limit continues in this list. Increased supply *will* be
utilized - by all kinds of entities - not only the girl next-door and
the unbanked proletariat.

2) Dissatisfied users will move to alt-coins so Bitcoin better be
careful...

The assumption here is that the best skills and most able minds are
fairly evenly distributed amongst alt-coin dev teams. I doubt this is
true and the notion underestimates the quality of developer that is
attracted to Bitcoin Core to apply themselves to this project, often
self-funded. There are few (if any) comparable cryptocurrencies or cc
dev teams out there. Hence the Bitcoin market cap, the large
stakeholder industry, and the established brand.

3) Bitcoin is better money.

Yes, indeed. It's genius and revolution. Yet, it does not fit every
use-case. I know people don't like it when I make this example, but
it's the truth where I live, and by extension, in many places in the
world:

I live in rural Southeast Asia. Some houses have electricity and some
don't: by choice, because rural lifestyle in the tropics does not
always require you to have electricity. People charge their mobile
phones at the community eating house every other day. The electricity
supply is unreliable. I've had to rig a solar charging system to a
UPS, but most people around here have no choice but to deal with
intermittent power cuts. The local market has a diesel generator, so
constant electricity, but if a power cut lasts for long enough the
local cellular mast battery backup depletes and then there is no
cellular connectivity - the only means of accessing the internet.

Now, how does one expect this community to use or adopt
cryptocurrency? They are mostly unbanked, get paid fiat wages at the
end of the week and spend fiat on commodities, rent, food and
entertainment like the rest of the world. But Bitcoin is not a "better
money" in their case, and who knows for how long this condition will
remain true.

4) TBD

The notion that there be dragons at the capacity limit is unfounded
and reactionary. We have to make the journey and find out what is, in
fact, there at the edge - as many others have argued in the list. This
is our opportunity to make scientific observation and discovery for
the benefit of Bitcoin - while it is still in its early years and the
capacity limit untested.

Who knows? The outcome may be an informed decision to implement bigger
blocks. Informed. Based not on fear and uncertainty but on empirical
observation and facts.



On 08/12/2015 04:39 AM, Michael Naber via bitcoin-dev wrote:
> Sure, most people probably would be happy with cheaper off-chain 
> systems. There already are and will probably continue to be more 
> transactions happening off-chain partly for this very reason.
> That's not the issue we're trying to address though: The main chain
> is the lynch-pin to the whole system. We've got to do a good job
> meeting demand that people have for wanting to utilize the
> main-chain, or else we'll risk being replaced by some other
> main-chain solution that does it better.
> 
> On Tue, Aug 11, 2015 at 4:34 PM, Adam Back  > wrote:
> 
> So if they dont care about decentralisation, they'll be happy
> using cheaper off-chain systems, right?
> 
> Adam
> 
> On 11 August 2015 at 22:30, Angel Leon  > wrote:
>> tell that to people in poor countries, or even in first world
> countries. The
>> competitive thing here is a deal breaker for a lot of people who
> have no
>> clue/don't care for decentralization, they just want to send
>> money
> from A to
>> B, like email.
>> 
>> http://twitter.com/gubatron
>> 
>> On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev 
>>  > wrote:
>>> 
>>> I dont think Bitcoin being cheaper is the main characteristic
>>> of Bitcoin.  I think the interesting thing is trustlessness -
>>> being able to transact without relying on third parties.
>>> 
>>> Adam
>>> 
>>> 
>>> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev 
>>>  > wrote:
 The only reason why Bitcoin has grown the way it has, and in
> f

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Venzen Khaosan via bitcoin-dev 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 08/12/2015 10:35 AM, Elliot Olds via bitcoin-dev wrote:
> On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille via bitcoin-dev 
>  > wrote:
> 
> On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber 
> mailto:mickey...@gmail.com>> wrote:
> 
> Bitcoin would be better money than current money even if it were a 
> bit more expensive to transact, simply because of its other great 
> characteristics (trustlessness, limited supply, etc). However...
> it is not better than something else sharing all those same 
> characteristics but which is also less expensive. The best money 
> will win, and if Bitcoin doesn't increase capacity then it won't 
> remain the best.
> 
> 
> If it is less expensive, it is harder to be reliable (because it's
>  easier for a sudden new use case to outbid the available space), 
> which is less useful for a payment mechanism.
> 
> 
> It depends on which use case's reliability that you focus on. For 
> any specific use case of Bitcoin, that use case will be more 
> reliable with a larger block size (ignoring centralization 
> effects).

I read through your message and see the point you're trying to make,
but would like to point out that it is not useful to talk about
hypothetical scenarios involving Bitcoin that include the supposition
"ignoring centralization effects".

Decentralization concerns are fundamental to this innovation, else it
loses its meaning and value. And that's the trade-off that Pieter,
Jorge, Martin, Adam and others have referring to during the past 24
hours: in order to have a secure Bitcoin that is not vulnerable to
centralization, certain sacrifices have to be made and the Consensus
Rule of a relatively small blocksize is the main protection we
currently have.

There are a lot of "larger blocks, more transactions" arguments being
made that overlook this core axiom of decentralization. That is why
the developers and thinkers with the deepest understanding of this
protocol are pointing out the need for another layer on top of
Bitcoin. That is where the scaling can take place to cater for the
use-cases of more txns, quicker txns, remittance, etc. and with it
increased adoption.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVys/tAAoJEGwAhlQc8H1mDOAH/1JRseGJWFKGsb4v7rapdcuY
V6t4EAeoz8q7xvn1SeOdXzwY1wTOiThwqaWEnEzRfFoW6JYhsHx3rQa9D+s8z2Bq
+lQ4oqkpOCcM6J3WAevzggWdzdP+xF8ztaRG5ynOge+m2lb1A2liadjSaeREz8/v
kEFSfT2V+QbmF+plkXtr7g0efMQq97Qv71hZ8tD+kmVMe5PDmARNwumzwIZ33H0z
eiCK3zombKVYNx7bw20pv8GhWp9z7LsKLJpLwKtuTxjgxG+NYi2FcbVwt3R9MB6/
TBsT4pmIvu29bIqWL2MDYLLnbU+cQTJNFSrrJar/aukqd5YlRDrY2Ikz82Ku86E=
=1bDu
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Elliot Olds via bitcoin-dev 
On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber 
> wrote:
>
>> Bitcoin would be better money than current money even if it were a bit
>> more expensive to transact, simply because of its other great
>> characteristics (trustlessness, limited supply, etc). However... it is not
>> better than something else sharing all those same characteristics but which
>> is also less expensive. The best money will win, and if Bitcoin doesn't
>> increase capacity then it won't remain the best.
>>
>
> If it is less expensive, it is harder to be reliable (because it's easier
> for a sudden new use case to outbid the available space), which is less
> useful for a payment mechanism.
>

It depends on which use case's reliability that you focus on. For any
specific use case of Bitcoin, that use case will be more reliable with a
larger block size (ignoring centralization effects).

The effect that I think you're talking about is that with lower fees, some
use cases will exist that otherwise wouldn't have been possible with higher
fees / smaller blocks, and these "low fee only" use cases will not be as
reliable as the use cases you'd see with high fees. But that puts you in a
position or arguing that it's better that low fee use cases never exist at
all, than existing at some high risk of being priced out eventually. Do we
know with high confidence how high tx fees will be in the future? Should it
be up to us discourage low fee use cases from being tried, because we think
the risk that they'll later be priced out is too great? Shouldn't we let
the people developing those use cases make that call? Maybe they don't mind
the unreliability. Maybe it's worth it to them if their use case only lasts
for a few months.

The important point to note is that the reliability of a use case is
determined by the fees that people are willing to pay for that use case,
not the fees that are actually paid. If big banks are willing to pay $1 /
tx for some use case right now, but they only need 200 of these txns per
block, then they might be paying only 5 cents / tx because no one is
forcing them to pay more. The fact that they're only paying 5 cents / tx
now doesn't make them any more vulnerable to new use cases than if they
were paying $1 / tx now. If a new use case started bidding up tx fees, the
banks would just increase their tx fees as high as they needed to (up to
$1).

The reason that larger block sizes increase reliability for any given use
case is that (a) You will never be priced out of blocks by a use case that
is only willing to pay lower fees than you. This is true regardless of the
block size. At worst they'll just force you to pay more in fees and lose
some of your consumer surplus. (b) If a use case is willing to pay higher
fees than you, then they're basically stepping ahead of you in line for
block space and pushing you closer to the edge of not being included in
blocks. The more space that exists between your use case and the marginal
use cases that are just barely getting included in blocks, the less
vulnerable you are to getting pushed out of blocks by new use cases.

If this is tricky to understand, here's an example that will make it clear:

Assume blocks can hold 2000 txns per MB. Before the new use case is
discovered, demand looks like this:

500 txns will pay $1 fees
1000 txns will pay 50 cent fees
2000 txns will pay 5 cent fees
8000 txns will pay 2 cent fees
15,000 txns will pay 1 cent fees.
100,000 txns will pay 0.01 cent fees.

So at a block size of 1MB, fees are 5 cents and user surplus is $925 per
block ($0.95 * 500 + 0.45 * 1000).
At a block size of 8 MB, fees are 1 cent and user surplus is $1,145 per
block ($0.99 * 500 + 0.49 * 1000 + $0.04 * 2000 + $0.01 * 8000).

Now a new use case comes into play and this is added to demand:

3000 txns will pay $5 / tx

That demand changes the scenarios like such:

At 1 MB fees jump to $5, user surplus is $0, and the $925 of value the
previous users were getting is lost. All existing use cases are priced out,
because there wasn't enough room in the blocks to accommodate them plus
this new use case.

At 8 MB, fees would stay at 1 cent, user surplus would be $16,115, and $0
in value would be lost (3000 users who were paying 1 cent for txns that
they valued only at 1 cent would stop making txns). All use cases
corresponding to the txns that were willing to pay at least 2 cents are
still viable, because there was enough space in blocks to accommodate them
plus the 3000 new high fee txns.

Let's say you're running the service that represents the 2000 txns willing
to pay 5 cents each on the demand curve specified above. Let's say you're
worried about being priced out of blocks. Which situation do you want to be
in, the one with 1 MB blocks or 8 MB blocks? It's pretty clear that your
best chance to remain viable is with larger blocks.
__

[bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Corey Haddad via bitcoin-dev 
On Tur, Aug 11, 2015 at 07:08 AM, *Mark Friedenbach* via bitcoin-dev <

bitcoin-dev at lists.linuxfoundation.org
>
wrote:


>Neither one of those assertions is clear. Keep in mind the goal is to have
>Bitcoin survive active censorship. Presumably that means being able to run
>a node even in the face of a hostile ISP or government. Furthermore, it
>means being location independent and being able to move around. In many
>places the higher the bandwidth requirements the fewer the number of ISPs
>that are available to service you, and the more visible you are.

>It may also be necessary to be able to run over Tor. And not just today's
>Tor which is developed, serviced, and supported by the US government, but a
>Tor or I2P that future governments have turned hostile towards and actively
>censor or repress. Or existing authoritative governments, for that matter.
>How much bandwidth would be available through those connections?

>It may hopefully never be necessary to operate under such constraints,
>except by freedom seeking individuals within existing totalitarian regimes.
>However the credible threat of doing so may be what keeps Bitcoin from
>being repressed in the first place. Lose the capability to go underground,
>and it will be pressured into regulation, eventually.

I agree on the importance of having the credible threat of being able to
operate in the underground, and for the reasons you outlined.  However, I
see that threat as being inherent in the now-public-knowledge that a system
like Bitcoin can exist.  The smart governments already know that
Bitcoin-like systems are unstoppable phenomena, that they can operate over
Tor and I2P, that they can and do run without central servers, and that
they can be run on commodity hardware without detection.  Bitcoin itself
does not need to constantly operate in survival-mode, hunkered down, and
always ready for big brother’s onslaught, to benefit from the protection of
the ‘credible threat’.

It’s important to accurately asses the level of threat the Bitcoin system
faces from regulation, legislation, and government ‘operations’.  If we are
too paranoid, we are going to waste resources or forgo opportunities in the
name of, essentially, baseless fear.  When I got involved with this project
in 2012, no one really knew how governments were going to react.  Had an
all out war-on-Bitcoin been declared, I think it’s pretty safe to say the
structure of the network would look different than it does today.  We would
probably be discussing ways to disguise Bitcoin traffic to look like VoIP
calls, not talking about how to best scale the network.  In light of the
current regulatory climate surrounding Bitcoin, I believe the best security
against a state-sponsored / political crackdown to be gained at this time
comes from growing the user base and use cases, as opposed to hardening and
fortifying the protocol.  Uber is a great example of this form of
security-though-adoption, as was mentioned earlier today on this mailing
list.

If there are security or network-hardening measures that don’t come at the
expense of growing the user base and use cases, then there is no reason not
to adopt them.  The recent improvements in Tor routing are a great example
of a security improvement that in no meaningful way slows Bitcoin’s
potential growth.  How does this relate to the Blocksize debate?  Let’s
accept that 8 MB blocks might cause a little bit, and perhaps even a
‘medium bit’ (however that is measured), of centralization.  Although the
network might be slightly more vulnerable to government attack, if millions
more people are able to join the system as a result, I’d wager the overall
security situation would be stronger, owning to greatly decreased risk of
attack.

-Corey (CubicEarth)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Eric Voskuil via bitcoin-dev 
Hi Michael,

> One of the key characteristics toward that is Bitcoin being
> inexpensive to transact.

What you seem to be missing is *why* bitcoin is better money. Have you
considered why is it comparatively inexpensive to transact in a medium
that is based on such a highly inefficient technology?

You might want to consider that these two considerations are not
independent. The reduced cost of transacting (and carrying) Bitcoin is a
direct consequence of its trustless nature. Any compromise in that
nature will eliminate that advantage, and therefore Bitcoin.

Bitcoin is designed to solve only one problem that other systems do not.
To accomplish this it makes significant compromises in other areas. The
benefit of this solution is that it cannot be effectively controlled by
the state. As a result, all of the associated overhead is eliminated.
Hence the net cost benefit despite high technical costs.

So this is a case where you should be careful what you wish for.

e

On 08/11/2015 02:18 PM, Michael Naber via bitcoin-dev wrote:
> The only reason why Bitcoin has grown the way it has, and in fact the
> only reason why we're all even here on this mailing list talking about
> this, is because Bitcoin is growing, since it's "better money than other
> money". One of the key characteristics toward that is Bitcoin being
> inexpensive to transact. If that characteristic is no longer true, then
> Bitcoin isn't going to grow, and in fact Bitcoin itself will be replaced
> by better money that is less expensive to transfer.
> 
> So the importance of this issue cannot be overstated -- it's compete or
> die for Bitcoin -- because people want to transact with global consensus
> at high volume, and because technology exists to service that want, then
> it's going to be met. This is basic rules of demand and supply. I don't
> necessarily disagree with your position on only wanting to support
> uncontroversial commits, but I think it's important to get consensus on
> the criticality of the block size issue: do you agree, disagree, or not
> take a side, and why?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Tom Harding via bitcoin-dev 

On 8/11/2015 2:23 PM, Adam Back via bitcoin-dev wrote:

I dont think Bitcoin being cheaper is the main characteristic of
Bitcoin.  I think the interesting thing is trustlessness - being able
to transact without relying on third parties.



That rules out Lightning Network.

Lightning relies on third parties all over the place.  Many things must 
be done right, and on-time by N intermediate third parties (subject to 
business pressures and regulation) or your payment will not work.


Lightning hubs can't steal your money.  Yay!  But banks stealing your 
payment money is not a problem with today's payment systems. Some real 
problems with those systems are:


 - Limited ACCESS to payment systems
 - High FEES
 - Transaction AMOUNT restrictions
 - FRAUD due to weak technology
 - CURRENCY conversions

Plain old bitcoin solves all of these problems.

Bitcoin does have challenges.  THROUGHPUT and TIME-TO-RELIABILITY are 
critical ones.  DECENTRALIZATION and PRIVACY must not be degraded.  
These challenges can be met and exceeded.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread odinn via bitcoin-dev 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Angel,

On 08/11/2015 02:14 AM, Angel Leon via bitcoin-dev wrote:
> -policy neutrality. - It can't be censored. - it can't be shut
> down - and the rules cannot change from underneath you.
> 
> except it can be shutdown the minute it actually gets used by its 
> inability to scale.
> 
> what's the point of having all this if nobody can use it? what's
> the point of going through all that energy and CO2 for a mere 
> 24,000 transactions an hour?
> 
> It's clear that it's just a matter of time before it collapses.
> 
> Here's a simple proposal (concept) that doesn't pretend to set a
> fixed block size limit as you can't ever know the demands the
> future will bring
> https://gist.github.com/gubatron/143e431ee01158f27db4

This seems to be a really good idea... May I add in here something
that's been dismissed before but I will mention it again anyway...

http://is.gd/DiFuRr "dynamic block size adjustment"
My sense has been that something like this could be coupled with
Garzik's BIP 100.  For some reason I keep getting attacked for saying
this.

/RantOff

> 
> We don't need to go as far as countries with hyper inflation trying
> to use the technology to make it collapse, anybody here who has
> distributed commercial/free end user software knows that any small
> company out there installs more copies in a couple weeks than all
> the bitcoin users we have at the moment, all we need is a single
> company/project with a decent amount of users who are now enabled
> to transact directly on the blockchain to screw it all up (perhaps
> OpenBazaar this winter could make this whole thing come down,
> hopefully they'll take this debate and the current limitations
> before their release, and boy are they coding nonstop on it now
> that they got funded), the last of your fears should be a malicious
> government trying to shut you down, for that to happen you must
> make an impact first, for now this is a silly game in the grand 
> scheme of things.
> 
> And you did sound pretty bad, all of his points were very valid and
> they share the concern of many people, many investors,
> entrepreneurs putting shitload of money, time and their lives on a
> much larger vision than that of a network that does a mere 3,500
> tx/hour, but some people seem to be able to live in impossible or
> useless ideals.
> 
> It's simply irresponsible to not want to give the network a chance
> to grow a bit more. Miners centralizing is inevitable given the POW
> based consensus, hobbists-mining is only there for countries with
> very cheap energy.
> 
> If things remain this way, this whole thing will be a massive
> failure and it will probably take another decade before we can open
> our mouths about cryptocurrencies, decentralization and what not,
> and this stubornness will be the one policy that censored everyone,
> that shutdown everyone, that made the immutable rules not matter.
> 
> Perhaps it will be Stellar what ends up delivering at this stubborn
> pace.
> 
> http://twitter.com/gubatron
> 
> On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev 
>  > wrote:
> 
>> It follows then, that if we make a decision now which destroys
>> that property, which makes it possible to censor bitcoin, to deny
>> service, or to pressure miners into changing rules contrary to
>> user interests, then Bitcoin is no longer interesting.
> 
> You asked to be convinced of the need for bigger blocks. I gave
> that. What makes you think bitcoin will break when more people use
> it?
> 
> Sent on the go, excuse the brevity. *From: *Mark Friedenbach *Sent:
> *Tuesday, 11 August 2015 08:10 *To: *Thomas Zander *Cc: *Bitcoin
> Dev *Subject: *Re: [bitcoin-dev] Fees and the block-finding
> process
> 
> 
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev 
>  > wrote:
> 
> On Monday 10. August 2015 23.03.39  Mark 
> Friedenbach wrote:
>> This is where things diverge. It's fine to pick a new limit or
>> growth trajectory. But defend it with data and reasoned
>> analysis.
> 
> We currently serve about 0,007% of the world population sending 
> maybe one transaction a month. This can only go up.
> 
> There are about 20 currencies in the world that are unstable and 
> showing early signs of hyperinflation. If even small percentage of
> these people cash-out and get Bitcoins for their savings you'd have
> the amount of people using Bitcoin as savings go from maybe half a
> million to 10 million in the space of a couple of months. Why so
> fast? Because all the world currencies are linked. Practically all
> currencies follow the USD, and while that one may stay robust and
> standing, the linkage has been shown in the past to cause 
> chain-effects.
> 
> It is impossible to predict how much uptake Bitcoin will take, but
> we have seen big rises in price as Cyprus had a bailin and then
> when Greece first showed bad signs

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread odinn via bitcoin-dev 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello, I thought these were good points, but I have a couple questions..
.

On 08/11/2015 12:08 AM, Mark Friedenbach via bitcoin-dev wrote:
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev 
>  > wrote:
> 
> On Monday 10. August 2015 23.03.39  Mark 
> Friedenbach wrote:
>> This is where things diverge. It's fine to pick a new limit or
>> growth trajectory. But defend it with data and reasoned
>> analysis.
> 
> We currently serve about 0,007% of the world population sending 
> maybe one transaction a month. This can only go up.
> 
> There are about 20 currencies in the world that are unstable and 
> showing early signs of hyperinflation. If even small percentage of
> these people cash-out and get Bitcoins for their savings you'd have
> the amount of people using Bitcoin as savings go from maybe half a
> million to 10 million in the space of a couple of months. Why so
> fast? Because all the world currencies are linked. Practically all
> currencies follow the USD, and while that one may stay robust and
> standing, the linkage has been shown in the past to cause 
> chain-effects.
> 
> It is impossible to predict how much uptake Bitcoin will take, but 
> we have seen big rises in price as Cyprus had a bailin and then
> when Greece first showed bad signs again. Lets do our due diligence
> and agree that in the current world economy there are sure signs
> that people are considering Bitcoin on a big scale.
> 
> Bigger amount of people holding Bitcoin savings won't make the 
> transaction rate go up very much, but if you have feet on the
> ground you already see that people go back to barter in countries
> like Poland, Ireland, Greece etc. And Bitcoin will be an
> alternative to good to ignore.  Then transaction rates will go up.
> Dramatically.
> 
> If you are asking for numbers, that is a bit tricky. Again; we are
> at 0,007%... Thats like a f-ing rounding error in the world
> economy. You can't reason from that. Its like using a float to do
> calculations that you should have done in a double and getting
> weird output.
> 
> Bottom line is that a maximum size of 8Mb blocks is not that odd. 
> Because a 20 times increase is very common in a "company" that is
> about 6 years old. For instance Android was about that age when it
> started to get shipped by non- Google companies. There the increase
> was substantially bigger and the company backing it was definitely
> able to change direction faster than the Bitcoin oiltanker can
> change direction.
> 
> ...
> 
> Another metric to remember; if you follow hackernews (well, the 
> incubator more than the linked articles) you'd be exposed to the
> thinking of these startups. Their only criteria is growth. and this
> is rather substantial growth. Like 150% per month.  Naturally, most
> of these build on top of html or other existing technologies.  But
> the point is that exponential growth is expected in any startup.
> They typically have a much much more agressive timeline, though.
> Every month instead of every year. Having exponential growth in the
> blockchain is really not odd and even if we have LN or sidechains
> or the next changetip, this space will be used. And we will still
> have scarcity.
> 
> 
> I'm sorry, I really don't want to sound like a jerk, but not a
> single word of that mattered. Yes we all want Bitcoin to scale such
> that every person in the world can use it without difficulty.
> However if that were all that we cared about then I would be remiss
> if I did not point out that there are plenty of better, faster, and
> cheaper solutions to finding global consensus over a payment ledger
> than Bitcoin. Architectures which are algorithmically superior in
> their scaling properties. Indeed they are already implemented and
> you can use them today:
> 
> https://www.stellar.org/ http://opentransactions.org/
> 
> So why do I work on Bitcoin, and why do I care about the outcome of
> this debate? Because Bitcoin offers one thing, and one thing only
> which alternative architectures fundamentally lack: policy
> neutrality. It can't be censored, it can't be shut down, and the
> rules cannot change from underneath you. *That* is what Bitcoin
> offers that can't be replicated at higher scale with a SQL database
> and an audit log.
> 
> It follows then, that if we make a decision now which destroys
> that property, which makes it possible to censor bitcoin, to deny
> service, or to pressure miners into changing rules contrary to user
> interests, then Bitcoin is no longer interesting. We might as well
> get rid of mining at that point and make Bitcoin look like Stellar
> or Open-Transactions because at least then we'd scale even better
> and not be pumping millions of tons of CO2 into the atmosphere from
> running all those ASICs.
> 
> On the other side, 3Tb harddrives are sold, which take 8Mb blocks 
> without problems.
> 
> 
> Straw man, storage is n

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Elliot Olds via bitcoin-dev 
On Fri, Aug 7, 2015 at 9:28 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen 
> wrote:
>
>> I think there are multiple reasons to raise the maximum block size, and
>> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
>> of the reasons.
>>
>> I take the opinion of smart engineers who actually do resource planning
>> and have seen what happens when networks run out of capacity very seriously.
>>
>
> This is a fundamental disagreement then. I believe that the demand is
> infinite if you don't set a fee minimum (and I don't think we should), and
> it just takes time for the market to find a way to fill whatever is
> available - the rest goes into off-chain systems anyway. You will run out
> of capacity at any size, and acting out of fear of that reality does not
> improve the system.
>

I think the case for increasing block size can be made without appealing to
fear of unknown effects of a fee market developing. I agree with you that
the most likely outcome is that fees will rise to a new equilibrium as
competition for block space increases, and some use cases will get priced
out of the market. If fees rise high enough, the effects of this can be
pretty bad though. I get the sense that you don't think high fees are that
bad / low fees are that good.

Can you let me know which of these statements related to low fees you
disagree with?

(0) Bitcoin's security will eventually have to be paid for almost entirely
via txn fees.

(1) A future in which lots of users are making on chain txns and each
paying 5 cents/tx is more sustainable than one in which a smaller number of
users are paying $3/tx, all else being equal (pretend the centralization
pressures are very low in both instances, and each scenario results in the
same amount of total tx fees).

(2) It's important that Bitcoin become widely used to protect the network
against regulators (note how political pressure from users who like Uber
have had a huge effect on preventing Uber from being banned in many
locations).

(3) There are potentially a lot of valuable use cases that can benefit from
Bitcoin's decentralization which can work at 5 cents / tx but are nonviable
at $3 / tx. Allowing fees to stay at $3 / tx and pricing out all the viable
use cases between $3 and 5 cents / tx would likely result in a significant
loss of utility for people who want these use cases to work.

(4) The Lightning Network will be a lot less appealing at $3 / tx than 5
cents / tx, because it'll require much larger anchor txn values to
sufficiently amortize the costs of the Bitcoin tx fees, and having to pay
$3 each time your counter-party misbehaves is somewhat painful.

(5) Assuming that Bitcoin is somewhat likely to end up in the "lots of
users, lower fees" situation described in (1), it's important that people
can experiment with low fee use cases now so that these use cases have time
to be discovered, be improved, and become popular before Bitcoin's security
relies exclusively on fees.


Finally, here's a type of question that devs on this list really don't like
answering but which I think is more informative than almost any other: If
you knew that hard forking to 4 MB soon would keep fees around 5 cents
(with a fee market) for the next two years, and that remaining at 1 MB
would result in fees of around $1 for the next two years, would you be in
favor of the 4 MB hard fork? (I know our knowledge of the decentralization
risks isn't very complete now, but assume you had to make a decision given
the state of your knowledge now).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Angel Leon via bitcoin-dev 
> So if they dont care about decentralisation, they'll be happy using cheaper
off-chain systems, right?

You betcha! Just talk to a regular people and try to sell them on the
different scenarios.

They will start using something cheaper/faster the minute it comes along
from the banking industry, just to give you a real world example, this week
I've been dreading the idea of having to go to the bank to make a couple of
cash deposits. If I could open my bank's web page right now and do a very
simple interbank transaction (without having to convince the to let me link
their accounts to mine, with the process that takes like 2 days when they
deposit 2 different cent amounts...) just here within the retarded US
banking system... which has clearly realized the threat from
cryptocurrencies as evidenced on many banker conferences this year.

They will come up with ways to allow us to do person to person transfers,
but this will surely be limited to transactions within the country,
international remittances still have a great chance of being disrupted by
Bitcoin, if and only if, it will be cheap, otherwise the western unions and
xooms of the world will still rule.

Please get out of our your academic cocoon for a bit, talk to real people,
try to convince them to use Bitcoin, and think how hard it will be to make
the sell if on top you tell them... "it costs more... but it's
decentralized!" LOL

http://twitter.com/gubatron

On Tue, Aug 11, 2015 at 5:34 PM, Adam Back  wrote:

> So if they dont care about decentralisation, they'll be happy using
> cheaper off-chain systems, right?
>
> Adam
>
> On 11 August 2015 at 22:30, Angel Leon  wrote:
> > tell that to people in poor countries, or even in first world countries.
> The
> > competitive thing here is a deal breaker for a lot of people who have no
> > clue/don't care for decentralization, they just want to send money from
> A to
> > B, like email.
> >
> > http://twitter.com/gubatron
> >
> > On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> >  wrote:
> >>
> >> I dont think Bitcoin being cheaper is the main characteristic of
> >> Bitcoin.  I think the interesting thing is trustlessness - being able
> >> to transact without relying on third parties.
> >>
> >> Adam
> >>
> >>
> >> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
> >>  wrote:
> >> > The only reason why Bitcoin has grown the way it has, and in fact the
> >> > only
> >> > reason why we're all even here on this mailing list talking about
> this,
> >> > is
> >> > because Bitcoin is growing, since it's "better money than other
> money".
> >> > One
> >> > of the key characteristics toward that is Bitcoin being inexpensive to
> >> > transact. If that characteristic is no longer true, then Bitcoin isn't
> >> > going
> >> > to grow, and in fact Bitcoin itself will be replaced by better money
> >> > that is
> >> > less expensive to transfer.
> >> >
> >> > So the importance of this issue cannot be overstated -- it's compete
> or
> >> > die
> >> > for Bitcoin -- because people want to transact with global consensus
> at
> >> > high
> >> > volume, and because technology exists to service that want, then it's
> >> > going
> >> > to be met. This is basic rules of demand and supply. I don't
> necessarily
> >> > disagree with your position on only wanting to support uncontroversial
> >> > commits, but I think it's important to get consensus on the
> criticality
> >> > of
> >> > the block size issue: do you agree, disagree, or not take a side, and
> >> > why?
> >> >
> >> >
> >> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <
> pieter.wui...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >> >>  wrote:
> >> >>>
> >> >>> Hitting the limit in and of itself is not necessarily a bad thing.
> The
> >> >>> question at hand is whether we should constrain that limit below
> what
> >> >>> technology is capable of delivering. I'm arguing that not only we
> >> >>> should
> >> >>> not, but that we could not even if we wanted to, since competition
> >> >>> will
> >> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> >> >>> some
> >> >>> other product / fork.
> >> >>
> >> >>
> >> >> The question is not what the technology can deliver. The question is
> >> >> what
> >> >> price we're willing to pay for that. It is not a boolean "at this
> size,
> >> >> things break, and below it, they work". A small constant factor
> >> >> increase
> >> >> will unlikely break anything in the short term, but it will come with
> >> >> higher
> >> >> centralization pressure of various forms. There is discussion about
> >> >> whether
> >> >> these centralization pressures are significant, but citing that it's
> >> >> artificially constrained under the limit is IMHO a misrepresentation.
> >> >> It is
> >> >> constrained to aim for a certain balance between utility and risk,
> and
> >> >> neither extreme is interesting, while possibly still "working".
> >> >>
>

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Pieter Wuille via bitcoin-dev 
On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber  wrote:

> Bitcoin would be better money than current money even if it were a bit
> more expensive to transact, simply because of its other great
> characteristics (trustlessness, limited supply, etc). However... it is not
> better than something else sharing all those same characteristics but which
> is also less expensive. The best money will win, and if Bitcoin doesn't
> increase capacity then it won't remain the best.
>

If it is less expensive, it is harder to be reliable (because it's easier
for a sudden new use case to outbid the available space), which is less
useful for a payment mechanism.

If it has better scale (with the same technology), it will have higher
centralization pressure. The higher price you potentially pay (in fees) to
get your transactions on a smaller block chain is the price of higher
security and independence. Perhaps the compromise is not at the optimal
place, but please stop saying "below what the technology can do". The
technology can "do" gigabyte blocks I'm sure, If you accept that you need a
small cluster to keep up with validation, and all blocks are produced by a
single miner cartel.

IMHO, Bitcoin (or any cryptocurrency) on-chain as a payment system is:
* Expensive: there is a (known in advance and agreed upon) inflation that
we're using to pay miners. But by holding Bitcoin you're paying for the
security of the system, even if it is not in fees.
* Unreliable: you never know when suddenly there will be more higher-fee
transactions that outbid you.
* Slow, unless you already trust the sender to not double spend (in which
case you don't actually need the security of the blockchain).

I don't know the future, and I don't know what use cases will develop and
what they'll want to pay or what reliability they need. But let's please
not throw out the one quality that Bitcoin is still good at: lack of
centralized parties to trust.

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
Sure, most people probably would be happy with cheaper off-chain systems.
There already are and will probably continue to be more transactions
happening off-chain partly for this very reason. That's not the issue we're
trying to address though: The main chain is the lynch-pin to the whole
system. We've got to do a good job meeting demand that people have for
wanting to utilize the main-chain, or else we'll risk being replaced by
some other main-chain solution that does it better.

On Tue, Aug 11, 2015 at 4:34 PM, Adam Back  wrote:

> So if they dont care about decentralisation, they'll be happy using
> cheaper off-chain systems, right?
>
> Adam
>
> On 11 August 2015 at 22:30, Angel Leon  wrote:
> > tell that to people in poor countries, or even in first world countries.
> The
> > competitive thing here is a deal breaker for a lot of people who have no
> > clue/don't care for decentralization, they just want to send money from
> A to
> > B, like email.
> >
> > http://twitter.com/gubatron
> >
> > On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> >  wrote:
> >>
> >> I dont think Bitcoin being cheaper is the main characteristic of
> >> Bitcoin.  I think the interesting thing is trustlessness - being able
> >> to transact without relying on third parties.
> >>
> >> Adam
> >>
> >>
> >> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
> >>  wrote:
> >> > The only reason why Bitcoin has grown the way it has, and in fact the
> >> > only
> >> > reason why we're all even here on this mailing list talking about
> this,
> >> > is
> >> > because Bitcoin is growing, since it's "better money than other
> money".
> >> > One
> >> > of the key characteristics toward that is Bitcoin being inexpensive to
> >> > transact. If that characteristic is no longer true, then Bitcoin isn't
> >> > going
> >> > to grow, and in fact Bitcoin itself will be replaced by better money
> >> > that is
> >> > less expensive to transfer.
> >> >
> >> > So the importance of this issue cannot be overstated -- it's compete
> or
> >> > die
> >> > for Bitcoin -- because people want to transact with global consensus
> at
> >> > high
> >> > volume, and because technology exists to service that want, then it's
> >> > going
> >> > to be met. This is basic rules of demand and supply. I don't
> necessarily
> >> > disagree with your position on only wanting to support uncontroversial
> >> > commits, but I think it's important to get consensus on the
> criticality
> >> > of
> >> > the block size issue: do you agree, disagree, or not take a side, and
> >> > why?
> >> >
> >> >
> >> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <
> pieter.wui...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >> >>  wrote:
> >> >>>
> >> >>> Hitting the limit in and of itself is not necessarily a bad thing.
> The
> >> >>> question at hand is whether we should constrain that limit below
> what
> >> >>> technology is capable of delivering. I'm arguing that not only we
> >> >>> should
> >> >>> not, but that we could not even if we wanted to, since competition
> >> >>> will
> >> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> >> >>> some
> >> >>> other product / fork.
> >> >>
> >> >>
> >> >> The question is not what the technology can deliver. The question is
> >> >> what
> >> >> price we're willing to pay for that. It is not a boolean "at this
> size,
> >> >> things break, and below it, they work". A small constant factor
> >> >> increase
> >> >> will unlikely break anything in the short term, but it will come with
> >> >> higher
> >> >> centralization pressure of various forms. There is discussion about
> >> >> whether
> >> >> these centralization pressures are significant, but citing that it's
> >> >> artificially constrained under the limit is IMHO a misrepresentation.
> >> >> It is
> >> >> constrained to aim for a certain balance between utility and risk,
> and
> >> >> neither extreme is interesting, while possibly still "working".
> >> >>
> >> >> Consensus rules are what keeps the system together. You can't simply
> >> >> switch to new rules on your own, because the rest of the system will
> >> >> end up
> >> >> ignoring you. These rules are there for a reason. You and I may agree
> >> >> about
> >> >> whether the 21M limit is necessary, and disagree about whether we
> need
> >> >> a
> >> >> block size limit, but we should be extremely careful with change. My
> >> >> position as Bitcoin Core developer is that we should merge consensus
> >> >> changes
> >> >> only when they are uncontroversial. Even when you believe a more
> >> >> invasive
> >> >> change is worth it, others may disagree, and the risk from
> disagreement
> >> >> is
> >> >> likely larger than the effect of a small block size increase by
> itself:
> >> >> the
> >> >> risk that suddenly every transaction can be spent twice (once on each
> >> >> side
> >> >> of the fork), the very thing that the block chain was de

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
Bitcoin would be better money than current money even if it were a bit more
expensive to transact, simply because of its other great characteristics
(trustlessness, limited supply, etc). However... it is not better than
something else sharing all those same characteristics but which is also
less expensive. The best money will win, and if Bitcoin doesn't increase
capacity then it won't remain the best.

On Tue, Aug 11, 2015 at 4:23 PM, Adam Back  wrote:

> I dont think Bitcoin being cheaper is the main characteristic of
> Bitcoin.  I think the interesting thing is trustlessness - being able
> to transact without relying on third parties.
>
> Adam
>
>
> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
>  wrote:
> > The only reason why Bitcoin has grown the way it has, and in fact the
> only
> > reason why we're all even here on this mailing list talking about this,
> is
> > because Bitcoin is growing, since it's "better money than other money".
> One
> > of the key characteristics toward that is Bitcoin being inexpensive to
> > transact. If that characteristic is no longer true, then Bitcoin isn't
> going
> > to grow, and in fact Bitcoin itself will be replaced by better money
> that is
> > less expensive to transfer.
> >
> > So the importance of this issue cannot be overstated -- it's compete or
> die
> > for Bitcoin -- because people want to transact with global consensus at
> high
> > volume, and because technology exists to service that want, then it's
> going
> > to be met. This is basic rules of demand and supply. I don't necessarily
> > disagree with your position on only wanting to support uncontroversial
> > commits, but I think it's important to get consensus on the criticality
> of
> > the block size issue: do you agree, disagree, or not take a side, and
> why?
> >
> >
> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille 
> > wrote:
> >>
> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >>  wrote:
> >>>
> >>> Hitting the limit in and of itself is not necessarily a bad thing. The
> >>> question at hand is whether we should constrain that limit below what
> >>> technology is capable of delivering. I'm arguing that not only we
> should
> >>> not, but that we could not even if we wanted to, since competition will
> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> some
> >>> other product / fork.
> >>
> >>
> >> The question is not what the technology can deliver. The question is
> what
> >> price we're willing to pay for that. It is not a boolean "at this size,
> >> things break, and below it, they work". A small constant factor increase
> >> will unlikely break anything in the short term, but it will come with
> higher
> >> centralization pressure of various forms. There is discussion about
> whether
> >> these centralization pressures are significant, but citing that it's
> >> artificially constrained under the limit is IMHO a misrepresentation.
> It is
> >> constrained to aim for a certain balance between utility and risk, and
> >> neither extreme is interesting, while possibly still "working".
> >>
> >> Consensus rules are what keeps the system together. You can't simply
> >> switch to new rules on your own, because the rest of the system will
> end up
> >> ignoring you. These rules are there for a reason. You and I may agree
> about
> >> whether the 21M limit is necessary, and disagree about whether we need a
> >> block size limit, but we should be extremely careful with change. My
> >> position as Bitcoin Core developer is that we should merge consensus
> changes
> >> only when they are uncontroversial. Even when you believe a more
> invasive
> >> change is worth it, others may disagree, and the risk from disagreement
> is
> >> likely larger than the effect of a small block size increase by itself:
> the
> >> risk that suddenly every transaction can be spent twice (once on each
> side
> >> of the fork), the very thing that the block chain was designed to
> prevent.
> >>
> >> My personal opinion is that we should aim to do a block size increase
> for
> >> the right reasons. I don't think fear of rising fees or unreliability
> should
> >> be an issue: if fees are being paid, it means someone is willing to pay
> >> them. If people are doing transactions despite being unreliable, there
> must
> >> be a use for them. That may mean that some use cases don't fit anymore,
> but
> >> that is already the case.
> >>
> >> --
> >> Pieter
> >>
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Adam Back via bitcoin-dev 
So if they dont care about decentralisation, they'll be happy using
cheaper off-chain systems, right?

Adam

On 11 August 2015 at 22:30, Angel Leon  wrote:
> tell that to people in poor countries, or even in first world countries. The
> competitive thing here is a deal breaker for a lot of people who have no
> clue/don't care for decentralization, they just want to send money from A to
> B, like email.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
>  wrote:
>>
>> I dont think Bitcoin being cheaper is the main characteristic of
>> Bitcoin.  I think the interesting thing is trustlessness - being able
>> to transact without relying on third parties.
>>
>> Adam
>>
>>
>> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
>>  wrote:
>> > The only reason why Bitcoin has grown the way it has, and in fact the
>> > only
>> > reason why we're all even here on this mailing list talking about this,
>> > is
>> > because Bitcoin is growing, since it's "better money than other money".
>> > One
>> > of the key characteristics toward that is Bitcoin being inexpensive to
>> > transact. If that characteristic is no longer true, then Bitcoin isn't
>> > going
>> > to grow, and in fact Bitcoin itself will be replaced by better money
>> > that is
>> > less expensive to transfer.
>> >
>> > So the importance of this issue cannot be overstated -- it's compete or
>> > die
>> > for Bitcoin -- because people want to transact with global consensus at
>> > high
>> > volume, and because technology exists to service that want, then it's
>> > going
>> > to be met. This is basic rules of demand and supply. I don't necessarily
>> > disagree with your position on only wanting to support uncontroversial
>> > commits, but I think it's important to get consensus on the criticality
>> > of
>> > the block size issue: do you agree, disagree, or not take a side, and
>> > why?
>> >
>> >
>> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille 
>> > wrote:
>> >>
>> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
>> >>  wrote:
>> >>>
>> >>> Hitting the limit in and of itself is not necessarily a bad thing. The
>> >>> question at hand is whether we should constrain that limit below what
>> >>> technology is capable of delivering. I'm arguing that not only we
>> >>> should
>> >>> not, but that we could not even if we wanted to, since competition
>> >>> will
>> >>> deliver capacity for global consensus whether it's in Bitcoin or in
>> >>> some
>> >>> other product / fork.
>> >>
>> >>
>> >> The question is not what the technology can deliver. The question is
>> >> what
>> >> price we're willing to pay for that. It is not a boolean "at this size,
>> >> things break, and below it, they work". A small constant factor
>> >> increase
>> >> will unlikely break anything in the short term, but it will come with
>> >> higher
>> >> centralization pressure of various forms. There is discussion about
>> >> whether
>> >> these centralization pressures are significant, but citing that it's
>> >> artificially constrained under the limit is IMHO a misrepresentation.
>> >> It is
>> >> constrained to aim for a certain balance between utility and risk, and
>> >> neither extreme is interesting, while possibly still "working".
>> >>
>> >> Consensus rules are what keeps the system together. You can't simply
>> >> switch to new rules on your own, because the rest of the system will
>> >> end up
>> >> ignoring you. These rules are there for a reason. You and I may agree
>> >> about
>> >> whether the 21M limit is necessary, and disagree about whether we need
>> >> a
>> >> block size limit, but we should be extremely careful with change. My
>> >> position as Bitcoin Core developer is that we should merge consensus
>> >> changes
>> >> only when they are uncontroversial. Even when you believe a more
>> >> invasive
>> >> change is worth it, others may disagree, and the risk from disagreement
>> >> is
>> >> likely larger than the effect of a small block size increase by itself:
>> >> the
>> >> risk that suddenly every transaction can be spent twice (once on each
>> >> side
>> >> of the fork), the very thing that the block chain was designed to
>> >> prevent.
>> >>
>> >> My personal opinion is that we should aim to do a block size increase
>> >> for
>> >> the right reasons. I don't think fear of rising fees or unreliability
>> >> should
>> >> be an issue: if fees are being paid, it means someone is willing to pay
>> >> them. If people are doing transactions despite being unreliable, there
>> >> must
>> >> be a use for them. That may mean that some use cases don't fit anymore,
>> >> but
>> >> that is already the case.
>> >>
>> >> --
>> >> Pieter
>> >>
>> >
>> >
>> > ___
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> ___
>> bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Pieter Wuille via bitcoin-dev 
On Tue, Aug 11, 2015 at 11:30 PM, Angel Leon via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> tell that to people in poor countries, or even in first world countries.
> The competitive thing here is a deal breaker for a lot of people who have
> no clue/don't care for decentralization,
>

Then they also don't need their transactions to be on the blockchain, right?

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
Re: "In my opinion the main source of disagreement is that one: how the
maximum block size limits centralization."

I generally agree with that, but I would add that centralization is only a
goal insofar as it serves things like reliability, transaction integrity,
capacity, and accessibility. More broadly: how do you think that moving the
block size from 1MB to 8MB would materially impact these things?

Re: "That's why I cannot understand the urgency to rise the maximum size."

This issue is urgent because the difference between bitcoin being a success
and it being forgotten hinges on it being "better money" than other money.
If people want a money that can process lots and lots of transactions at
low cost, they're going to get it so long as technology can give it to
them. While it's not critical we raise the block size this very moment
since we're not hitting the capacity wall right now, based on the way
growth spikes in Bitcoin have occurred in the past we, may hit that
capacity wall soon and suddenly. And the moment we do, then Bitcoin may no
longer be "better money" since there's a big opportunity for other money
with higher throughput and lower fees to take its place.

On Tue, Aug 11, 2015 at 2:45 PM, Jorge Timón  wrote:

>
> On Aug 11, 2015 8:55 PM, "Michael Naber"  wrote:
> >
> > It generally doesn't matter that every node validate your coffee
> transaction, and those transactions can and will probably be moved onto
> offchain solutions in order to avoid paying the cost of achieving global
> consensus. But you still don't get to set the cost of global consensus
> artificially. Market forces will ensure that supply will meet demand there,
> so if there is demand for access to global consensus, and technology exists
> to meet that demand at a cost of one cent per transaction -- or whatever
> the technology-limited cost of global consensus happens to be -- then
> that's what the market will supply.
>
> Assuming we maintain any block size maximum consensus rule, the market
> will adapt to whatever maximum size is imposed by the consensus rules.
> For example, with the current demand and the current consensus block size
> maximum, the market has settled on a minimum fee of zero satoshis per
> transaction. That's why I cannot understand the urgency to rise the maximum
> size.
>
> In any case, yhe consensus maximum shouldn't be based on current or
> projected demand, only on centralization concerns, which is what the
> consensus rule serves for (to limit centralization).
> For example, Gavin advocates for 20 MB because he is not worried about how
> that could increase centralization because he believes it won't.
> I can't agree with that because I believe 20 MB could make mining
> centralization (and centralization in general) much worse.
>
> But if I have to chose between 2 "centralization safe" sizes, sure, the
> bigger the better, why not.
> In my opinion the main source of disagreement is that one: how the maximum
> block size limits centralization.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Angel Leon via bitcoin-dev 
tell that to people in poor countries, or even in first world countries.
The competitive thing here is a deal breaker for a lot of people who have
no clue/don't care for decentralization, they just want to send money from
A to B, like email.

http://twitter.com/gubatron

On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I dont think Bitcoin being cheaper is the main characteristic of
> Bitcoin.  I think the interesting thing is trustlessness - being able
> to transact without relying on third parties.
>
> Adam
>
>
> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
>  wrote:
> > The only reason why Bitcoin has grown the way it has, and in fact the
> only
> > reason why we're all even here on this mailing list talking about this,
> is
> > because Bitcoin is growing, since it's "better money than other money".
> One
> > of the key characteristics toward that is Bitcoin being inexpensive to
> > transact. If that characteristic is no longer true, then Bitcoin isn't
> going
> > to grow, and in fact Bitcoin itself will be replaced by better money
> that is
> > less expensive to transfer.
> >
> > So the importance of this issue cannot be overstated -- it's compete or
> die
> > for Bitcoin -- because people want to transact with global consensus at
> high
> > volume, and because technology exists to service that want, then it's
> going
> > to be met. This is basic rules of demand and supply. I don't necessarily
> > disagree with your position on only wanting to support uncontroversial
> > commits, but I think it's important to get consensus on the criticality
> of
> > the block size issue: do you agree, disagree, or not take a side, and
> why?
> >
> >
> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille 
> > wrote:
> >>
> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >>  wrote:
> >>>
> >>> Hitting the limit in and of itself is not necessarily a bad thing. The
> >>> question at hand is whether we should constrain that limit below what
> >>> technology is capable of delivering. I'm arguing that not only we
> should
> >>> not, but that we could not even if we wanted to, since competition will
> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> some
> >>> other product / fork.
> >>
> >>
> >> The question is not what the technology can deliver. The question is
> what
> >> price we're willing to pay for that. It is not a boolean "at this size,
> >> things break, and below it, they work". A small constant factor increase
> >> will unlikely break anything in the short term, but it will come with
> higher
> >> centralization pressure of various forms. There is discussion about
> whether
> >> these centralization pressures are significant, but citing that it's
> >> artificially constrained under the limit is IMHO a misrepresentation.
> It is
> >> constrained to aim for a certain balance between utility and risk, and
> >> neither extreme is interesting, while possibly still "working".
> >>
> >> Consensus rules are what keeps the system together. You can't simply
> >> switch to new rules on your own, because the rest of the system will
> end up
> >> ignoring you. These rules are there for a reason. You and I may agree
> about
> >> whether the 21M limit is necessary, and disagree about whether we need a
> >> block size limit, but we should be extremely careful with change. My
> >> position as Bitcoin Core developer is that we should merge consensus
> changes
> >> only when they are uncontroversial. Even when you believe a more
> invasive
> >> change is worth it, others may disagree, and the risk from disagreement
> is
> >> likely larger than the effect of a small block size increase by itself:
> the
> >> risk that suddenly every transaction can be spent twice (once on each
> side
> >> of the fork), the very thing that the block chain was designed to
> prevent.
> >>
> >> My personal opinion is that we should aim to do a block size increase
> for
> >> the right reasons. I don't think fear of rising fees or unreliability
> should
> >> be an issue: if fees are being paid, it means someone is willing to pay
> >> them. If people are doing transactions despite being unreliable, there
> must
> >> be a use for them. That may mean that some use cases don't fit anymore,
> but
> >> that is already the case.
> >>
> >> --
> >> Pieter
> >>
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Adam Back via bitcoin-dev 
I dont think Bitcoin being cheaper is the main characteristic of
Bitcoin.  I think the interesting thing is trustlessness - being able
to transact without relying on third parties.

Adam


On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
 wrote:
> The only reason why Bitcoin has grown the way it has, and in fact the only
> reason why we're all even here on this mailing list talking about this, is
> because Bitcoin is growing, since it's "better money than other money". One
> of the key characteristics toward that is Bitcoin being inexpensive to
> transact. If that characteristic is no longer true, then Bitcoin isn't going
> to grow, and in fact Bitcoin itself will be replaced by better money that is
> less expensive to transfer.
>
> So the importance of this issue cannot be overstated -- it's compete or die
> for Bitcoin -- because people want to transact with global consensus at high
> volume, and because technology exists to service that want, then it's going
> to be met. This is basic rules of demand and supply. I don't necessarily
> disagree with your position on only wanting to support uncontroversial
> commits, but I think it's important to get consensus on the criticality of
> the block size issue: do you agree, disagree, or not take a side, and why?
>
>
> On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille 
> wrote:
>>
>> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
>>  wrote:
>>>
>>> Hitting the limit in and of itself is not necessarily a bad thing. The
>>> question at hand is whether we should constrain that limit below what
>>> technology is capable of delivering. I'm arguing that not only we should
>>> not, but that we could not even if we wanted to, since competition will
>>> deliver capacity for global consensus whether it's in Bitcoin or in some
>>> other product / fork.
>>
>>
>> The question is not what the technology can deliver. The question is what
>> price we're willing to pay for that. It is not a boolean "at this size,
>> things break, and below it, they work". A small constant factor increase
>> will unlikely break anything in the short term, but it will come with higher
>> centralization pressure of various forms. There is discussion about whether
>> these centralization pressures are significant, but citing that it's
>> artificially constrained under the limit is IMHO a misrepresentation. It is
>> constrained to aim for a certain balance between utility and risk, and
>> neither extreme is interesting, while possibly still "working".
>>
>> Consensus rules are what keeps the system together. You can't simply
>> switch to new rules on your own, because the rest of the system will end up
>> ignoring you. These rules are there for a reason. You and I may agree about
>> whether the 21M limit is necessary, and disagree about whether we need a
>> block size limit, but we should be extremely careful with change. My
>> position as Bitcoin Core developer is that we should merge consensus changes
>> only when they are uncontroversial. Even when you believe a more invasive
>> change is worth it, others may disagree, and the risk from disagreement is
>> likely larger than the effect of a small block size increase by itself: the
>> risk that suddenly every transaction can be spent twice (once on each side
>> of the fork), the very thing that the block chain was designed to prevent.
>>
>> My personal opinion is that we should aim to do a block size increase for
>> the right reasons. I don't think fear of rising fees or unreliability should
>> be an issue: if fees are being paid, it means someone is willing to pay
>> them. If people are doing transactions despite being unreliable, there must
>> be a use for them. That may mean that some use cases don't fit anymore, but
>> that is already the case.
>>
>> --
>> Pieter
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
The only reason why Bitcoin has grown the way it has, and in fact the only
reason why we're all even here on this mailing list talking about this, is
because Bitcoin is growing, since it's "better money than other money". One
of the key characteristics toward that is Bitcoin being inexpensive to
transact. If that characteristic is no longer true, then Bitcoin isn't
going to grow, and in fact Bitcoin itself will be replaced by better money
that is less expensive to transfer.

So the importance of this issue cannot be overstated -- it's compete or die
for Bitcoin -- because people want to transact with global consensus at
high volume, and because technology exists to service that want, then it's
going to be met. This is basic rules of demand and supply. I don't
necessarily disagree with your position on only wanting to support
uncontroversial commits, but I think it's important to get consensus on the
criticality of the block size issue: do you agree, disagree, or not take a
side, and why?


On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille 
wrote:

> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hitting the limit in and of itself is not necessarily a bad thing. The
>> question at hand is whether we should constrain that limit below what
>> technology is capable of delivering. I'm arguing that not only we should
>> not, but that we could not even if we wanted to, since competition will
>> deliver capacity for global consensus whether it's in Bitcoin or in some
>> other product / fork.
>>
>
> The question is not what the technology can deliver. The question is what
> price we're willing to pay for that. It is not a boolean "at this size,
> things break, and below it, they work". A small constant factor increase
> will unlikely break anything in the short term, but it will come with
> higher centralization pressure of various forms. There is discussion about
> whether these centralization pressures are significant, but citing that
> it's artificially constrained under the limit is IMHO a misrepresentation.
> It is constrained to aim for a certain balance between utility and risk,
> and neither extreme is interesting, while possibly still "working".
>
> Consensus rules are what keeps the system together. You can't simply
> switch to new rules on your own, because the rest of the system will end up
> ignoring you. These rules are there for a reason. You and I may agree about
> whether the 21M limit is necessary, and disagree about whether we need a
> block size limit, but we should be extremely careful with change. My
> position as Bitcoin Core developer is that we should merge consensus
> changes only when they are uncontroversial. Even when you believe a more
> invasive change is worth it, others may disagree, and the risk from
> disagreement is likely larger than the effect of a small block size
> increase by itself: the risk that suddenly every transaction can be spent
> twice (once on each side of the fork), the very thing that the block chain
> was designed to prevent.
>
> My personal opinion is that we should aim to do a block size increase for
> the right reasons. I don't think fear of rising fees or unreliability
> should be an issue: if fees are being paid, it means someone is willing to
> pay them. If people are doing transactions despite being unreliable, there
> must be a use for them. That may mean that some use cases don't fit
> anymore, but that is already the case.
>
> --
> Pieter
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
I'm not sure whether removing the limit at the protocol-level would lead to
government by miners who might reject blocks which were too big, but I
probably wouldn't want to take that risk. I think we should probably keep a
block size limit in the protocol, but that we should increase it to be as
high as "technology can provide." Toward that: I don't necessarily think
that node-count in and of itself should be the metric for evaluating what
technology can provide, as much as the goal that the chain be inexpensive
to validate given the capabilities of present technology -- so if I can
lease a server in a datacenter which can validate the chain and my total
cost to do that is just a few dollars, then we're probably ok.

Of course there's also the issue that we maintain enough geographic /
political distribution to keep the network reliable, but I think we're far
from being in danger on the reliability front. So maybe my criteria that
the chain be validated at low cost is the wrong focus, but if it is than
what's the appropriate criteria for deciding whether it's safe by standards
of "today's technology" to raise the limit at the protocol level?

On Tue, Aug 11, 2015 at 2:53 PM, Jorge Timón  wrote:

>
> On Aug 11, 2015 9:37 PM, "Michael Naber"  wrote:
>
> > Hitting the limit in and of itself is not necessarily a bad thing. The
> question at hand is whether we should constrain that limit below what
> technology is capable of delivering. I'm arguing that not only we should
> not, but that we could not even if we wanted to, since competition will
> deliver capacity for global consensus whether it's in Bitcoin or in some
> other product / fork.
>
> You didn't answer the 2 questions...
> Anyway, if we don't care about centralization at all, we can just remove
> the limit: that's what "technology can provide".
> Maybe in that case it is developers who move to a decentralized
> competitor...
>
> > On Tue, Aug 11, 2015 at 2:27 PM, Jorge Timón  wrote:
> >>
> >>
> >> On Aug 11, 2015 8:46 PM, "Michael Naber"  wrote:
> >> >
> >> > Hi Jorge: Many people would like to participate in a global consensus
> network -- which is a network where all the participating nodes are aware
> of and agree upon every transaction. Constraining Bitcoin capacity below
> the limits of technology will only push users seeking to participate in a
> global consensus network to other solutions which have adequate capacity,
> such as BitcoinXT or others. Note that lightning / hub and spoke do not
> meet requirements for users wishing to participate in global consensus,
> because they are not global consensus networks, since all participating
> nodes are not aware of all transactions.
> >>
> >> Even if you are right, first fees will raise and that will be what
> pushes people to other altcoins, no?
> >> Can we agree that the first step in any potentially bad situation is
> hitting the limit and then fees rising as a consequence?
> >
> >
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Adam Back via bitcoin-dev 
I think everyone is expending huge effort on design, analysis and
implementation of the lowest cost technology for Bitcoin.

Changing parameters doesnt create progress on scalability fundamentals -
there really is an inherent cost and security / throughput tradeoff to
blockchains.  Security is quite central to this discussion.  It is
unrealistic in my opinion to suppose that everything can fit directly
on-chain in the fullest Bitcoin adoption across cash-payments, internet of
things, QoS, micropayments, share-trading, derivates etc.  Hence the
interest in protocols like lightning (encourage you and others to read the
paper, blog posts and implementation progress on the lightning-dev mailing
list).

Mid-term different tradeoffs can happen that are all connected to and
building on Bitcoin.  But whatever technologies win out for scale, they all
depend on Bitcoin security - anything built on Bitcoin requires a secure
base.  So I think it is logical that we strive to maintain and improve
Bitcoin security.  Long-term tradeoffs that significantly weaken security
for throughput or other considerations should be built on top of Bitcoin,
and avoiding creating a one-size fits all unfortunate compromise that
weakens Bitcoin to the lowest common denominator of centralisation,
insecurity and throughput tradeoffs.  This pattern (secure base, other
protocols built on top) is already the status quo - probably > 99% of
Bitcoin transactions are off-chain already (in exchanges, web wallets
etc).  And there are various things that can and are being done to improve
the security of those solutions, with provable reserves, periodic on-chain
settlement, netting, lightning like protocols and other things probably
still to be invented.

Some of the longer term things we probably dont know yet, but the future is
NOT bleak.  Lots of scope for technology improvement.

Adam


On 11 August 2015 at 20:26, Michael Naber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> All things considered, if people want to participate in a global consensus
> network, and the technology exist to do it at a lower cost, then is it
> sensible or even possible to somehow arbitrarily set the price of
> participating in a global consensus network to be expensive? Can someone
> please walk me through how that's expected to play out because I'm really
> having a hard time understanding how it could work.
>
>
>
> On Tue, Aug 11, 2015 at 2:00 PM, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> More people using Bitcoin does not necessarily mean more transactions
>> being processed by the block chain. Satoshi was forward-thinking enough to
>> include a powerful script-signature system, something which has never
>> really existed before. Though suffering from some limitations to be sure,
>> this smart contract execution framework is expressive enough to enable a
>> wide variety of new features without changing bitcoin itself.
>>
>> One of these invented features is micropayment channels -- the ability
>> for two parties to rapidly exchange funds while only settling the final
>> balance to the block chain, and to do so in an entirely trustless way.
>> Right now people don't use scripts to do interesting things like this, but
>> there is absolutely no reason why they can't. Lightning network is a vision
>> of a future where everyone uses a higher-layer protocol for their
>> transactions which only periodically settle on the block chain. It is
>> entirely possible that you may be able to do all your day-to-day
>> transactions in bitcoin yet only settle accounts every other week, totaling
>> 13kB per year. A 1MB block could support that level of usage by 4 million
>> people, which is many orders of magnitude more than the number of people
>> presently using bitcoin on a day to day basis.
>>
>> And that, by the way, is without considering as-yet uninvented
>> applications of existing or future script which will provide even further
>> improvements to scale. This is very fertile ground being explored by very
>> few people. One thing I hope to come out of this block size debate is a lot
>> more people (like Joseph Poon) looking at how bitcoin script can be used to
>> enable new and innovative resource-efficient and privacy-enhancing payment
>> protocols.
>>
>> The network has room to grow. It just requires wallet developers and
>> other infrastructure folk to step up to the plate and do their part in
>> deploying this technology.
>>
>> On Tue, Aug 11, 2015 at 2:14 AM, Angel Leon  wrote:
>>
>>> - policy neutrality.
>>> - It can't be censored.
>>> - it can't be shut down
>>> - and the rules cannot change from underneath you.
>>>
>>> except it can be shutdown the minute it actually gets used by its
>>> inability to scale.
>>>
>>> what's the point of having all this if nobody can use it?
>>> what's the point of going through all that energy and CO2 for a mere
>>> 24,000 transactions an hour?
>>>
>>> It's clear that it's

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Jorge Timón via bitcoin-dev 
On Aug 11, 2015 9:37 PM, "Michael Naber"  wrote:

> Hitting the limit in and of itself is not necessarily a bad thing. The
question at hand is whether we should constrain that limit below what
technology is capable of delivering. I'm arguing that not only we should
not, but that we could not even if we wanted to, since competition will
deliver capacity for global consensus whether it's in Bitcoin or in some
other product / fork.

You didn't answer the 2 questions...
Anyway, if we don't care about centralization at all, we can just remove
the limit: that's what "technology can provide".
Maybe in that case it is developers who move to a decentralized
competitor...

> On Tue, Aug 11, 2015 at 2:27 PM, Jorge Timón  wrote:
>>
>>
>> On Aug 11, 2015 8:46 PM, "Michael Naber"  wrote:
>> >
>> > Hi Jorge: Many people would like to participate in a global consensus
network -- which is a network where all the participating nodes are aware
of and agree upon every transaction. Constraining Bitcoin capacity below
the limits of technology will only push users seeking to participate in a
global consensus network to other solutions which have adequate capacity,
such as BitcoinXT or others. Note that lightning / hub and spoke do not
meet requirements for users wishing to participate in global consensus,
because they are not global consensus networks, since all participating
nodes are not aware of all transactions.
>>
>> Even if you are right, first fees will raise and that will be what
pushes people to other altcoins, no?
>> Can we agree that the first step in any potentially bad situation is
hitting the limit and then fees rising as a consequence?
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Pieter Wuille via bitcoin-dev 
On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hitting the limit in and of itself is not necessarily a bad thing. The
> question at hand is whether we should constrain that limit below what
> technology is capable of delivering. I'm arguing that not only we should
> not, but that we could not even if we wanted to, since competition will
> deliver capacity for global consensus whether it's in Bitcoin or in some
> other product / fork.
>

The question is not what the technology can deliver. The question is what
price we're willing to pay for that. It is not a boolean "at this size,
things break, and below it, they work". A small constant factor increase
will unlikely break anything in the short term, but it will come with
higher centralization pressure of various forms. There is discussion about
whether these centralization pressures are significant, but citing that
it's artificially constrained under the limit is IMHO a misrepresentation.
It is constrained to aim for a certain balance between utility and risk,
and neither extreme is interesting, while possibly still "working".

Consensus rules are what keeps the system together. You can't simply switch
to new rules on your own, because the rest of the system will end up
ignoring you. These rules are there for a reason. You and I may agree about
whether the 21M limit is necessary, and disagree about whether we need a
block size limit, but we should be extremely careful with change. My
position as Bitcoin Core developer is that we should merge consensus
changes only when they are uncontroversial. Even when you believe a more
invasive change is worth it, others may disagree, and the risk from
disagreement is likely larger than the effect of a small block size
increase by itself: the risk that suddenly every transaction can be spent
twice (once on each side of the fork), the very thing that the block chain
was designed to prevent.

My personal opinion is that we should aim to do a block size increase for
the right reasons. I don't think fear of rising fees or unreliability
should be an issue: if fees are being paid, it means someone is willing to
pay them. If people are doing transactions despite being unreliable, there
must be a use for them. That may mean that some use cases don't fit
anymore, but that is already the case.

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Jorge Timón via bitcoin-dev 
On Aug 11, 2015 8:55 PM, "Michael Naber"  wrote:
>
> It generally doesn't matter that every node validate your coffee
transaction, and those transactions can and will probably be moved onto
offchain solutions in order to avoid paying the cost of achieving global
consensus. But you still don't get to set the cost of global consensus
artificially. Market forces will ensure that supply will meet demand there,
so if there is demand for access to global consensus, and technology exists
to meet that demand at a cost of one cent per transaction -- or whatever
the technology-limited cost of global consensus happens to be -- then
that's what the market will supply.

Assuming we maintain any block size maximum consensus rule, the market will
adapt to whatever maximum size is imposed by the consensus rules.
For example, with the current demand and the current consensus block size
maximum, the market has settled on a minimum fee of zero satoshis per
transaction. That's why I cannot understand the urgency to rise the maximum
size.

In any case, yhe consensus maximum shouldn't be based on current or
projected demand, only on centralization concerns, which is what the
consensus rule serves for (to limit centralization).
For example, Gavin advocates for 20 MB because he is not worried about how
that could increase centralization because he believes it won't.
I can't agree with that because I believe 20 MB could make mining
centralization (and centralization in general) much worse.

But if I have to chose between 2 "centralization safe" sizes, sure, the
bigger the better, why not.
In my opinion the main source of disagreement is that one: how the maximum
block size limits centralization.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
Jorge, As long as Bitcoin remains the best global consensus network -- and
part of being best means being reasonably priced -- then no I don't think
people will be pushed into altcoins. Better money ultimately displaces
worse money, so I don't see a driving force for people to move to other
altcoins as long as Bitcoin remains competitive.

Hitting the limit in and of itself is not necessarily a bad thing. The
question at hand is whether we should constrain that limit below what
technology is capable of delivering. I'm arguing that not only we should
not, but that we could not even if we wanted to, since competition will
deliver capacity for global consensus whether it's in Bitcoin or in some
other product / fork.


On Tue, Aug 11, 2015 at 2:27 PM, Jorge Timón  wrote:

>
> On Aug 11, 2015 8:46 PM, "Michael Naber"  wrote:
> >
> > Hi Jorge: Many people would like to participate in a global consensus
> network -- which is a network where all the participating nodes are aware
> of and agree upon every transaction. Constraining Bitcoin capacity below
> the limits of technology will only push users seeking to participate in a
> global consensus network to other solutions which have adequate capacity,
> such as BitcoinXT or others. Note that lightning / hub and spoke do not
> meet requirements for users wishing to participate in global consensus,
> because they are not global consensus networks, since all participating
> nodes are not aware of all transactions.
>
> Even if you are right, first fees will raise and that will be what pushes
> people to other altcoins, no?
> Can we agree that the first step in any potentially bad situation is
> hitting the limit and then fees rising as a consequence?
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Jorge Timón via bitcoin-dev 
On Aug 11, 2015 8:46 PM, "Michael Naber"  wrote:
>
> Hi Jorge: Many people would like to participate in a global consensus
network -- which is a network where all the participating nodes are aware
of and agree upon every transaction. Constraining Bitcoin capacity below
the limits of technology will only push users seeking to participate in a
global consensus network to other solutions which have adequate capacity,
such as BitcoinXT or others. Note that lightning / hub and spoke do not
meet requirements for users wishing to participate in global consensus,
because they are not global consensus networks, since all participating
nodes are not aware of all transactions.

Even if you are right, first fees will raise and that will be what pushes
people to other altcoins, no?
Can we agree that the first step in any potentially bad situation is
hitting the limit and then fees rising as a consequence?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
All things considered, if people want to participate in a global consensus
network, and the technology exist to do it at a lower cost, then is it
sensible or even possible to somehow arbitrarily set the price of
participating in a global consensus network to be expensive? Can someone
please walk me through how that's expected to play out because I'm really
having a hard time understanding how it could work.



On Tue, Aug 11, 2015 at 2:00 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> More people using Bitcoin does not necessarily mean more transactions
> being processed by the block chain. Satoshi was forward-thinking enough to
> include a powerful script-signature system, something which has never
> really existed before. Though suffering from some limitations to be sure,
> this smart contract execution framework is expressive enough to enable a
> wide variety of new features without changing bitcoin itself.
>
> One of these invented features is micropayment channels -- the ability for
> two parties to rapidly exchange funds while only settling the final balance
> to the block chain, and to do so in an entirely trustless way. Right now
> people don't use scripts to do interesting things like this, but there is
> absolutely no reason why they can't. Lightning network is a vision of a
> future where everyone uses a higher-layer protocol for their transactions
> which only periodically settle on the block chain. It is entirely possible
> that you may be able to do all your day-to-day transactions in bitcoin yet
> only settle accounts every other week, totaling 13kB per year. A 1MB block
> could support that level of usage by 4 million people, which is many orders
> of magnitude more than the number of people presently using bitcoin on a
> day to day basis.
>
> And that, by the way, is without considering as-yet uninvented
> applications of existing or future script which will provide even further
> improvements to scale. This is very fertile ground being explored by very
> few people. One thing I hope to come out of this block size debate is a lot
> more people (like Joseph Poon) looking at how bitcoin script can be used to
> enable new and innovative resource-efficient and privacy-enhancing payment
> protocols.
>
> The network has room to grow. It just requires wallet developers and other
> infrastructure folk to step up to the plate and do their part in deploying
> this technology.
>
> On Tue, Aug 11, 2015 at 2:14 AM, Angel Leon  wrote:
>
>> - policy neutrality.
>> - It can't be censored.
>> - it can't be shut down
>> - and the rules cannot change from underneath you.
>>
>> except it can be shutdown the minute it actually gets used by its
>> inability to scale.
>>
>> what's the point of having all this if nobody can use it?
>> what's the point of going through all that energy and CO2 for a mere
>> 24,000 transactions an hour?
>>
>> It's clear that it's just a matter of time before it collapses.
>>
>> Here's a simple proposal (concept) that doesn't pretend to set a fixed
>> block size limit as you can't ever know the demands the future will bring
>> https://gist.github.com/gubatron/143e431ee01158f27db4
>>
>> We don't need to go as far as countries with hyper inflation trying to
>> use the technology to make it collapse, anybody here who has distributed
>> commercial/free end user software knows that any small company out there
>> installs more copies in a couple weeks than all the bitcoin users we have
>> at the moment, all we need is a single company/project with a decent amount
>> of users who are now enabled to transact directly on the blockchain to
>> screw it all up (perhaps OpenBazaar this winter could make this whole thing
>> come down, hopefully they'll take this debate and the current limitations
>> before their release, and boy are they coding nonstop on it now that they
>> got funded), the last of your fears should be a malicious government trying
>> to shut you down, for that to happen you must make an impact first, for now
>> this is a silly game in the grand scheme of things.
>>
>> And you did sound pretty bad, all of his points were very valid and they
>> share the concern of many people, many investors, entrepreneurs putting
>> shitload of money, time and their lives on a much larger vision than that
>> of a network that does a mere 3,500 tx/hour, but some people seem to be
>> able to live in impossible or useless ideals.
>>
>> It's simply irresponsible to not want to give the network a chance to
>> grow a bit more. Miners centralizing is inevitable given the POW based
>> consensus, hobbists-mining is only there for countries with very cheap
>> energy.
>>
>> If things remain this way, this whole thing will be a massive failure and
>> it will probably take another decade before we can open our mouths about
>> cryptocurrencies, decentralization and what not, and this stubornness will
>> be the one policy that censored everyone, that shutdown everyone,

Re: [bitcoin-dev] CFP Bitcoin Scalability Workshop (Sept 12-13), Montreal Canada

2015-08-11 Thread Mark Friedenbach via bitcoin-dev 
I want to put a big thank-you out to Pindar, Warren, and others in the
organizing committee who I know must have put in a lot of hours to make
this happen. I will be attending, and I hope to see many of you there too.
It is my sincere hope that the academic structure of a workshop will help
break down some of the communication walls that have arisen in this debate,
and help us all work towards finding a compromise towards scaling bitcoin,
something we all want to see happen.

On Tue, Aug 11, 2015 at 1:45 AM, Pindar Wong via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin Scalability Workshops
>
> In recent months the Bitcoin development community has faced difficult
> discussions of how to safely improve the scalability and decentralized
> nature of the Bitcoin network. To aid the technical consensus building
> process we are organizing a pair of workshops to collect technical
> criteria, present proposals and evaluate technical materials and data with
> academic discipline and analysis that fully considers the complex tradeoffs
> between decentralization, utility, security and operational realities. This
> may be considered as similar in intent and process to the NIST-SHA3 design
> process where performance and security were in a tradeoff for a security
> critical application.
>
> Since Bitcoin is a P2P currency with many stakeholders, it is important to
> collect requirements as broadly as possible, and through the process
> enhance everyone’s understanding of the technical properties of Bitcoin to
> help foster an inclusive, transparent, and informed process.
>
> Those with technical interest are invited to participate in this pair of
> workshops with the following intent:
>
> Phase 1: Scene setting, evaluation criteria, and tradeoff analysis.
>
> Montreal, Canada: September 12th-13th, 2015
>
> Scalability is not a single parameter; there are many opportunities to
> make the Bitcoin protocol more efficient and better able to service the
> needs of its growing userbase. Each approach to further scaling the Bitcoin
> blockchain involves implicit trade offs of desired properties of the whole
> system. As a community we need to raise awareness of the complex and subtle
> issues involved, facilitate deeper research and testing of existing
> proposals, and motivate future work in this area.
>
> The purpose of this workshop is to discuss the general tradeoffs and
> requirements of any proposal to scale Bitcoin beyond its present limits.
> Session topics are to include the presentation of experimental data
> relating to known bottlenecks of Bitcoin’s continued growth and analysis of
> implicit tradeoffs involved in general strategies for enabling future
> growth.
>
> This event will not host sessions on the topic of any specific proposals
> involving changes to the Bitcoin protocol. Such proposals would be the
> topic of a 2nd, follow-on Phase 2 workshop described below; this event is
> intended to “set the stage” for work on and evaluation of specific
> proposals in the time between the workshops.
>
> Phase 2 will be planned out further as part of Phase 1 with input from the
> participants.
>
> Phase 2: Presentation and review of technical proposals, with simulation,
> benchmark results.
>
> Hong Kong, SAR, China: TBD Nov/Dec 2015
>
> Hopefully to be easier for the Chinese miners to attend, the second
> workshop pertaining to actual block size proposals is to be planned for
> Hong Kong roughly in the late November to December timeframe.
>
> The purpose of this workshop is to present and review actual proposals for
> scaling Bitcoin against the requirements gathered in Phase 1. Multiple
> competing proposals will be presented, with experimental data, and compared
> against each other. The goal is to raise awareness of scalability issues
> and build a pathway toward consensus for increasing Bitcoin’s transaction
> processing capacity or, barring that, identify key areas of further
> required research and next steps for moving forward.
>
> Preliminarily, Phase 2 will be a time to share results from experiments
> performed as a result of Phase 1 and an opportunity to discuss new
> developments.
>
> How do the Workshops work?
>
>-
>
>Both events will be live-streamed with remote participation
>facilitated via IRC for parallel online discussion and passing questions to
>the event.
>-
>
>These workshops aim to facilitate the existing Bitcoin Improvement
>Proposals (BIP)[1] process. Most work will be done outside of the workshops
>in the intervening months. The workshops serve to be additive to the design
>and review process by raising awareness of diverse points of view, studies,
>simulations, and proposals.
>-
>
>Travel, venue details, and accommodation recommendation are available
>at scalingbitcoin.org. Registration begins August 12th at an
>early-bird ticket price of $150 USD until September 3rd. The ticket prices
>do not come clos

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Mark Friedenbach via bitcoin-dev 
More people using Bitcoin does not necessarily mean more transactions being
processed by the block chain. Satoshi was forward-thinking enough to
include a powerful script-signature system, something which has never
really existed before. Though suffering from some limitations to be sure,
this smart contract execution framework is expressive enough to enable a
wide variety of new features without changing bitcoin itself.

One of these invented features is micropayment channels -- the ability for
two parties to rapidly exchange funds while only settling the final balance
to the block chain, and to do so in an entirely trustless way. Right now
people don't use scripts to do interesting things like this, but there is
absolutely no reason why they can't. Lightning network is a vision of a
future where everyone uses a higher-layer protocol for their transactions
which only periodically settle on the block chain. It is entirely possible
that you may be able to do all your day-to-day transactions in bitcoin yet
only settle accounts every other week, totaling 13kB per year. A 1MB block
could support that level of usage by 4 million people, which is many orders
of magnitude more than the number of people presently using bitcoin on a
day to day basis.

And that, by the way, is without considering as-yet uninvented applications
of existing or future script which will provide even further improvements
to scale. This is very fertile ground being explored by very few people.
One thing I hope to come out of this block size debate is a lot more people
(like Joseph Poon) looking at how bitcoin script can be used to enable new
and innovative resource-efficient and privacy-enhancing payment protocols.

The network has room to grow. It just requires wallet developers and other
infrastructure folk to step up to the plate and do their part in deploying
this technology.

On Tue, Aug 11, 2015 at 2:14 AM, Angel Leon  wrote:

> - policy neutrality.
> - It can't be censored.
> - it can't be shut down
> - and the rules cannot change from underneath you.
>
> except it can be shutdown the minute it actually gets used by its
> inability to scale.
>
> what's the point of having all this if nobody can use it?
> what's the point of going through all that energy and CO2 for a mere
> 24,000 transactions an hour?
>
> It's clear that it's just a matter of time before it collapses.
>
> Here's a simple proposal (concept) that doesn't pretend to set a fixed
> block size limit as you can't ever know the demands the future will bring
> https://gist.github.com/gubatron/143e431ee01158f27db4
>
> We don't need to go as far as countries with hyper inflation trying to use
> the technology to make it collapse, anybody here who has distributed
> commercial/free end user software knows that any small company out there
> installs more copies in a couple weeks than all the bitcoin users we have
> at the moment, all we need is a single company/project with a decent amount
> of users who are now enabled to transact directly on the blockchain to
> screw it all up (perhaps OpenBazaar this winter could make this whole thing
> come down, hopefully they'll take this debate and the current limitations
> before their release, and boy are they coding nonstop on it now that they
> got funded), the last of your fears should be a malicious government trying
> to shut you down, for that to happen you must make an impact first, for now
> this is a silly game in the grand scheme of things.
>
> And you did sound pretty bad, all of his points were very valid and they
> share the concern of many people, many investors, entrepreneurs putting
> shitload of money, time and their lives on a much larger vision than that
> of a network that does a mere 3,500 tx/hour, but some people seem to be
> able to live in impossible or useless ideals.
>
> It's simply irresponsible to not want to give the network a chance to grow
> a bit more. Miners centralizing is inevitable given the POW based
> consensus, hobbists-mining is only there for countries with very cheap
> energy.
>
> If things remain this way, this whole thing will be a massive failure and
> it will probably take another decade before we can open our mouths about
> cryptocurrencies, decentralization and what not, and this stubornness will
> be the one policy that censored everyone, that shutdown everyone, that made
> the immutable rules not matter.
>
> Perhaps it will be Stellar what ends up delivering at this stubborn pace.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> >It follows then, that if we make a decision now which destroys that
>> property, which makes it possible to censor bitcoin, to deny service, or to
>> pressure miners into changing rules contrary to user interests, then
>> Bitcoin is no longer interesting.
>>
>> You asked to be convinced of the need for bigger blocks. I gave that.
>> What makes you think bitco

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
Lightning *depends* on global consensus in order to function. You can't use
it without a global consensus network at all. So given that there is
absolutely a place for a global consensus network, we need to decide
whether the cost to participate in that global consensus will be limited
above or below the capability of technology. In a world where anybody can
step up and fork the code, it's going to be hard for anyone to artificially
set the price of participating in global consensus at a rate higher than
what technology can deliver...

On Tue, Aug 11, 2015 at 1:51 PM, Bryan Bishop  wrote:

> On Tue, Aug 11, 2015 at 1:46 PM, Michael Naber via bitcoin-dev
>  wrote:
> > Note that lightning / hub and spoke do not meet requirements for users
> > wishing to participate in global consensus, because they are not global
> > consensus networks, since all participating nodes are not aware of all
> > transactions.
>
> You don't need consensus on the lightning network because you are
> using bitcoin consensus anyway. Commitment transactions are deep
> enough in the blockchain history that removing that transaction from
> the history is impractical. The remaining guarantees are ensured by
> the properties of the scripts in the transaction. You don't need to
> see all the transactions, but you do need to look at the transactions
> you are given and draw conclusions based on the details to see whether
> their commitments are valid or the setup wasn't broken.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
It generally doesn't matter that every node validate your coffee
transaction, and those transactions can and will probably be moved onto
offchain solutions in order to avoid paying the cost of achieving global
consensus. But you still don't get to set the cost of global consensus
artificially. Market forces will ensure that supply will meet demand there,
so if there is demand for access to global consensus, and technology exists
to meet that demand at a cost of one cent per transaction -- or whatever
the technology-limited cost of global consensus happens to be -- then
that's what the market will supply.

It would be like if Amazon suddenly said that they were going to be
charging $5 / gb / month to store data in s3. Can't do it. Technology
exists to bring about cloud storage at $0.01 / GB / month, so they don't
just get to set the price different from the capabilities of technology or
they'll get replaced by a competitor. Same applies to Bitcoin.




On Tue, Aug 11, 2015 at 1:48 PM, Mark Friedenbach 
wrote:

> Michael, why does it matter that every node in the world process and
> validate your morning coffee transaction? Why does it matter to anyone
> except you and the coffee vendor?
>
> On Tue, Aug 11, 2015 at 11:46 AM, Michael Naber via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Jorge: Many people would like to participate in a global consensus
>> network -- which is a network where all the participating nodes are aware
>> of and agree upon every transaction. Constraining Bitcoin capacity below
>> the limits of technology will only push users seeking to participate in a
>> global consensus network to other solutions which have adequate capacity,
>> such as BitcoinXT or others. Note that lightning / hub and spoke do not
>> meet requirements for users wishing to participate in global consensus,
>> because they are not global consensus networks, since all participating
>> nodes are not aware of all transactions.
>>
>>
>>
>>
>> On Tue, Aug 11, 2015 at 12:47 PM, Jorge Timón <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>> On Aug 11, 2015 12:14 AM, "Thomas Zander via bitcoin-dev" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> >
>>> > On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
>>> > > Gavin, I interpret the absence of response to these questions as a
>>> > > sign that everybody agrees that  there's no other reason to increase
>>> > > the consensus block size other than to avoid minimum market fees from
>>> > > rising (above zero).
>>> > > Feel free to correct that notion at any time by answering the
>>> > > questions yourself.
>>> > > In fact if any other "big block size advocate" thinks there's more
>>> > > reason I would like to hear their reasons too.
>>> >
>>> > See my various emails in the last hour.
>>>
>>> I've read them. I have read gavin's blog posts as well, several times.
>>> I still don't see what else can we fear from not increasing the size
>>> apart from fees maybe rising and making some problems that need to be
>>> solved rewardless of the size more visible (like a dumb unbounded mempool
>>> design).
>>>
>>> This discussion is frustrating for everyone. I could also say "This have
>>> been explained many times" and similar things, but that's not productive.
>>> I'm not trying to be obstinate, please, answer what else is to fear or
>>> admit that all your feas are just potential consequences of rising fees.
>>>
>>> With the risk of sounding condescending or aggressive...Really, is not
>>> that hard to answer questions directly and succinctly. We should all be
>>> friends with clarity. Only fear, uncertainty and doubt are enemies of
>>> clarity. But you guys on the "bigger blocks side" don't want to spread fud,
>>> do you?
>>> Please, prove paranoid people like me wrong on this point, for the good
>>> of this discussion. I really don't know how else to ask this without
>>> getting a link to something I have already read as a response.
>>>
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Bryan Bishop via bitcoin-dev 
On Tue, Aug 11, 2015 at 1:46 PM, Michael Naber via bitcoin-dev
 wrote:
> Note that lightning / hub and spoke do not meet requirements for users
> wishing to participate in global consensus, because they are not global
> consensus networks, since all participating nodes are not aware of all
> transactions.

You don't need consensus on the lightning network because you are
using bitcoin consensus anyway. Commitment transactions are deep
enough in the blockchain history that removing that transaction from
the history is impractical. The remaining guarantees are ensured by
the properties of the scripts in the transaction. You don't need to
see all the transactions, but you do need to look at the transactions
you are given and draw conclusions based on the details to see whether
their commitments are valid or the setup wasn't broken.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Mark Friedenbach via bitcoin-dev 
Michael, why does it matter that every node in the world process and
validate your morning coffee transaction? Why does it matter to anyone
except you and the coffee vendor?

On Tue, Aug 11, 2015 at 11:46 AM, Michael Naber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Jorge: Many people would like to participate in a global consensus
> network -- which is a network where all the participating nodes are aware
> of and agree upon every transaction. Constraining Bitcoin capacity below
> the limits of technology will only push users seeking to participate in a
> global consensus network to other solutions which have adequate capacity,
> such as BitcoinXT or others. Note that lightning / hub and spoke do not
> meet requirements for users wishing to participate in global consensus,
> because they are not global consensus networks, since all participating
> nodes are not aware of all transactions.
>
>
>
>
> On Tue, Aug 11, 2015 at 12:47 PM, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> On Aug 11, 2015 12:14 AM, "Thomas Zander via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
>> > > Gavin, I interpret the absence of response to these questions as a
>> > > sign that everybody agrees that  there's no other reason to increase
>> > > the consensus block size other than to avoid minimum market fees from
>> > > rising (above zero).
>> > > Feel free to correct that notion at any time by answering the
>> > > questions yourself.
>> > > In fact if any other "big block size advocate" thinks there's more
>> > > reason I would like to hear their reasons too.
>> >
>> > See my various emails in the last hour.
>>
>> I've read them. I have read gavin's blog posts as well, several times.
>> I still don't see what else can we fear from not increasing the size
>> apart from fees maybe rising and making some problems that need to be
>> solved rewardless of the size more visible (like a dumb unbounded mempool
>> design).
>>
>> This discussion is frustrating for everyone. I could also say "This have
>> been explained many times" and similar things, but that's not productive.
>> I'm not trying to be obstinate, please, answer what else is to fear or
>> admit that all your feas are just potential consequences of rising fees.
>>
>> With the risk of sounding condescending or aggressive...Really, is not
>> that hard to answer questions directly and succinctly. We should all be
>> friends with clarity. Only fear, uncertainty and doubt are enemies of
>> clarity. But you guys on the "bigger blocks side" don't want to spread fud,
>> do you?
>> Please, prove paranoid people like me wrong on this point, for the good
>> of this discussion. I really don't know how else to ask this without
>> getting a link to something I have already read as a response.
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Michael Naber via bitcoin-dev 
Hi Jorge: Many people would like to participate in a global consensus
network -- which is a network where all the participating nodes are aware
of and agree upon every transaction. Constraining Bitcoin capacity below
the limits of technology will only push users seeking to participate in a
global consensus network to other solutions which have adequate capacity,
such as BitcoinXT or others. Note that lightning / hub and spoke do not
meet requirements for users wishing to participate in global consensus,
because they are not global consensus networks, since all participating
nodes are not aware of all transactions.




On Tue, Aug 11, 2015 at 12:47 PM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Aug 11, 2015 12:14 AM, "Thomas Zander via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
> > > Gavin, I interpret the absence of response to these questions as a
> > > sign that everybody agrees that  there's no other reason to increase
> > > the consensus block size other than to avoid minimum market fees from
> > > rising (above zero).
> > > Feel free to correct that notion at any time by answering the
> > > questions yourself.
> > > In fact if any other "big block size advocate" thinks there's more
> > > reason I would like to hear their reasons too.
> >
> > See my various emails in the last hour.
>
> I've read them. I have read gavin's blog posts as well, several times.
> I still don't see what else can we fear from not increasing the size apart
> from fees maybe rising and making some problems that need to be solved
> rewardless of the size more visible (like a dumb unbounded mempool design).
>
> This discussion is frustrating for everyone. I could also say "This have
> been explained many times" and similar things, but that's not productive.
> I'm not trying to be obstinate, please, answer what else is to fear or
> admit that all your feas are just potential consequences of rising fees.
>
> With the risk of sounding condescending or aggressive...Really, is not
> that hard to answer questions directly and succinctly. We should all be
> friends with clarity. Only fear, uncertainty and doubt are enemies of
> clarity. But you guys on the "bigger blocks side" don't want to spread fud,
> do you?
> Please, prove paranoid people like me wrong on this point, for the good of
> this discussion. I really don't know how else to ask this without getting a
> link to something I have already read as a response.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Jorge Timón via bitcoin-dev 
On Aug 11, 2015 12:14 AM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
> > Gavin, I interpret the absence of response to these questions as a
> > sign that everybody agrees that  there's no other reason to increase
> > the consensus block size other than to avoid minimum market fees from
> > rising (above zero).
> > Feel free to correct that notion at any time by answering the
> > questions yourself.
> > In fact if any other "big block size advocate" thinks there's more
> > reason I would like to hear their reasons too.
>
> See my various emails in the last hour.

I've read them. I have read gavin's blog posts as well, several times.
I still don't see what else can we fear from not increasing the size apart
from fees maybe rising and making some problems that need to be solved
rewardless of the size more visible (like a dumb unbounded mempool design).

This discussion is frustrating for everyone. I could also say "This have
been explained many times" and similar things, but that's not productive.
I'm not trying to be obstinate, please, answer what else is to fear or
admit that all your feas are just potential consequences of rising fees.

With the risk of sounding condescending or aggressive...Really, is not that
hard to answer questions directly and succinctly. We should all be friends
with clarity. Only fear, uncertainty and doubt are enemies of clarity. But
you guys on the "bigger blocks side" don't want to spread fud, do you?
Please, prove paranoid people like me wrong on this point, for the good of
this discussion. I really don't know how else to ask this without getting a
link to something I have already read as a response.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

2015-08-11 Thread Simon Liu via bitcoin-dev 
There's also an interesting question posted over at Reddit - will
Lightning payment hubs be treated as money transmitters in the US?

https://www.reddit.com/r/bitcoin_uncensored/comments/3gjnmd/lightning_may_not_be_a_scaling_solution/

A payment hub operator working with brand name merchants like Disney and
Gap would most likely adopt any licensing and AML/KYC regulations.

Some folk might thus find themselves forced to use anonymous hubs with
strict routing requirements to avoid commercial hubs.  Given the reduced
number of available channels, this could drive up lightning network fees
for those folk.

Of course, two parties can avoid any intermediary by using a regular
on-chain transaction, but it might not be feasible if Bitcoin is
operating as a settlement network with high transaction fees.


On 08/11/2015 02:01 AM, Hector Chu via bitcoin-dev wrote:
> Lightning will never catch on as it basically demands that everyone who
> uses it to become a speculator. Payment hubs and merchants will be at
> the mercy of the bitcoin price while their funds stay locked up in
> payment channels. This idea is a dead-end.
> 
> On 10 August 2015 at 22:43, Adam Back via bitcoin-dev
>  > wrote:
> 
> In terms of usage I think you'd more imagine a wallet that basically
> parks Bitcoins onto channels at all times, so long as they are
> routable there is no loss, and the scalability achieved thereby is
> strongly advantageous, and there is even the potential for users to
> earn fees by having their wallets participate in channel rebalancing
> (where hubs pay users to rebalance channels - end up with the same net
> position but move funds from one user-owned channel to another.)
> Exchange deposit, withdrawal, payments, even in-exchange trades can
> usefully happen in lightning for faster, cheaper more scalable
> transactions.
> 
> Adam
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Jorge Timón via bitcoin-dev 
On Aug 9, 2015 10:44 PM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
>> > Someone mentioned that when the backlog grows faster than it shrinks,
that
>> > is a real problem.  I don't think it is.  It is a problem for those who
>> > don't wait for even one confirmation
>>
>> The mention you refer to was about the fact that the software doesn't
cope
>> well with a continuously growing mempool.
>> If Bitcoind starts eating more and more memory, I expect lots of people
that
>> run it now to turn it off.
>
>
> That is a real problem then.  While emptying the mempool faster with
bigger blocks will help to reduce the occurrence of that problem, I propose
a user-configurable default limit to the size of the mempool as a permanent
solution regardless of block size.  "This software has stopped consuming
memory necessary to validate transactions.  You can override this by ..."
If anyone feels that protecting those running full nodes from bitcoind
eating more and more memory this way is a good idea, I can make a BIP out
of it if that would help.

You are completely right: this problem has nothing to do with the consensus
block size maximum and it has to be solved regardless of what the maximum
is. No BIP is necessary for this. The "doing nothing side" has been working
on this too:
https://github.com/bitcoin/bitcoin/pull/6470
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Future Of Bitcoin-Cores Wallet

2015-08-11 Thread Jeff Garzik via bitcoin-dev 
+1  Glad to see this work.

The Bitcoin Core wallet is a bit neglected these days - maintained but not
advancing.



On Tue, Aug 11, 2015 at 5:02 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi
> (excuse my english; it’s not my native language)
>
> As you might noticed, bitcoin-cores wallet didn’t got that much focus
> during the last month (even years?).
> Wallet development has mostly moved towards SPV (bitcoinj), thin
> clients (Electrum), centralized web middleware (Copay, Greenaddress,
> etc.).
>
> Obviously this direction was highly appreciated by users who now can
> now run a bitcoin-client (SPV / thin client) on a smartphone or on a
> computer with tiny available resources.
>
> Full validation slowly gets a privilege of people who can manage to
> run bitcoin-core on a VPS or different server like system.
> Thought, i think, running a full node wallet could be end user
> friendly with some changes in the current concept.
>
> Today a standard user can download a 1080p 10GB movie over iTunes (in
> background) and simultaneous play a CPU/GPU extensive 3D game on a
> standard computer.
> Why do people think (and it might is) running a full node is so painful?
>
> Mainly it could be because bitcoin-core has been focused on doing
> validation as quick as possible (okay for a server, not desirable for
> a wallet background service).
>
> I could see the following strategy:
> - - end user focused full node wallet would have enabled pruning by
> default (~2GB disk usage).
> - - throttled validation (flexible CPU usage, user selectable, maybe
> ~20% by default).
> - - throttled block download (bandwidth).
> - - SPV during catch up (initial sync as also when catching up multiple
> days because user/node was offline).
> - - Disable bloom filtering if there is enough bandwith, keep blocks for
> later validation.
> - - when node is in sync, switch from SPV to full validation (maybe
> maintain to lists/dbs of wtx or re-validate after full catchup and
> display potential conflicts).
> - - participate in p2p, but with limits/throttling (service limited
> amount of blocks, tx [TBD]).
>
> Why?
> - - This could increase the amount of participating full nodes while
> giving users more privacy and security.
> - - Create a counterweight against SPV/thin clients (avoid wallet
> development centralization, could be helpful once/if attacks agains
> SPV/thin clients are becoming real).
> - - Slowly complete full validation (can take ~1-2 weeks) and thereforce
> increase privacy (avoid bloomfilters) and security.
>
> What about SPV together with a full node?
> Sounds good in theory. But who can run a full node (see above)? How is
> the channel secured (against MITM, privacy) between the SPV client and
> the trusted full node? How hard is it to setup and maintain a secure
> tunnel between a smartphone SPV and a full node over the p2p (8333)
> channel? How about examine the mempool for fee calculations and
> (maybe) upcoming CPFP like approaches, etc.?
>
> How about smartphones?
> Obviously the above solution won’t probably work on a smartphone (to
> much bandwidth and CPU usage). But do you carry your whole saving in
> your physical wallet with you? Maybe a smartphone does hold keys which
> protects low value / daily spendings like a physical wallet (=SPV okay).
> My personal long term vision of that use-case is, that groups of
> people who trust each other (a family, etc.) might run one or multiple
> full node(s) on a hardened system (something similar to the bitnodes
> hardware) where the system could serve smartphones over something like
> a stratum server (electrum) or bitpays wallet-service does (index
> blockchain, additional wallet services). Every member still holds it’s
> keys but they trust the connected full node (full nodes does address
> index, balance calculation, multisig arrangements and maybe even coin
> selection).
>
> Since about one year i slowly work toward this direction. It took me a
> while to commit myself to a strategy (and i still shake from time to
> time).
> At the moment I am working on a wallet focused bitcoin-core fork with
> the ability to re-merge it to the bitcoin-core branch (keep the fork
> rebased).
> Long term goal is, to decouple the both (wallet / core) by using
> bitcoin-core as a library (static or shared) for the wallet side
> (which is possible already now)
>
> To myself: I work in the bitcoin-space full-time and completely
> independent (not employed or influenced by a bitcoin related company)
> with no business interest, though, i think the acquired know-how can
> be valuable within the next serval years. And i won’t have any regrets
> if my work turns out to be unless and ends up in trash.
>
> I have set up this mail to avoid parallelism on a works stream (if
> there is any). Of course i would really appreciate if other developers
> are willing to join the team by reviewing, concept criti

Re: [bitcoin-dev] Future Of Bitcoin-Cores Wallet

2015-08-11 Thread Sriram Karra via bitcoin-dev 
On Tue, Aug 11, 2015 at 4:33 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hey Jonas,
>
> I think your analysis of what (some) users need is a good one.
>
> We've discussed this before so I know you prefer your current approach,
> but I personally would take a slightly different path to reach the same end:
>
>1. Support serving of SPV wallets from pruned storage. This means some
>protocol upgrades, BIPs, etc. It helps all SPV wallets, including on 
> phones.
>2. Then make a bitcoinj based desktop wallet app, that contains a
>bundled bitcoind.
>
> It makes a lot of sense to have single set of reference implementations
for the different components. So unless you also support something you have
not explicitly stated - get rid of bitcoin-qt in its current form, the
above does not meet the spirit of Jonas' original post - which makes a load
of sense to me.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Thomas Zander via bitcoin-dev 
On Tuesday 11. August 2015 00.08.42 Mark Friedenbach wrote:
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
> So why do I work on Bitcoin, [] It can't
> be censored, it can't be shut down, and the rules cannot change from
> underneath you.

Fully agreed, and I like that a lot as well.

> It may hopefully never be necessary to operate under such constraints,
> except by freedom seeking individuals within existing totalitarian regimes.

I think remembering the Internet architecture here is viable.
There is a saying that censorship on the internet is seen as a defect and 
route around. Bitcoin follows the same concept, and arguable is even better at 
it since transactions don't have to be delivered to the network in real time. 
It can be shipped by carrier pigeon in the extreme case ;)
Or though smileys over skype chat...


> However the credible threat of doing so may be what keeps Bitcoin from
> being repressed in the first place. Lose the capability to go underground,
> and it will be pressured into regulation, eventually.

I understand your point, its a good one.

Here is my counter argument; countries (or states) that fail to legally get 
the bandwidth to do mining, are not an indicator for the success of Bitcoin.
Tor will work fine with a full node (or gnunet, if you want), just make sure 
you take the transmission delays into account.
And naturally, there is the point that actual end users don't need a full 
node. The system as a whole will work just fine for people in totalitarian 
regimes as long as 100% of the world doesn't reach that point.
With various nodes in Sealand (near the UK) and miners in China, the system 
would still work for users in New York.

> > Remember 8Gb/block still doesn't support VISA/Mastercard.
> 
> No, it doesn't. And 8GB/block is ludicrously large -- it would absolutely,
> without any doubt destroy the very nature of Bitcoin, turning it into a
> fundamentally uninteresting reincarnation of the existing financial system.
> And still be unable to compete with VISA/Mastercard.
> 
> So why then the pressure to go down a route that WILL lead to failure by
> your own metrics?

Naturally, I was referring to the existing proposal that 8Gb blocks would be 
reached only in many years. Its a really long way away.

And if you read my previous replies on this thread you can see a more 
substantial argument which I'll make brief here;
I'm not suggesting we scale the blocksize to accomodate for the next 10 years 
of growth.
Instead I'm suggesting that we use solutions like Lightning and sidechains and 
anything people can invent as soon as possible.  But we need bigger blocks as 
well. Because not any single solution is the answer, we need a combination of 
multiple.

There really is no reason to suspect we can't actually increase the blocksize 
in some months as the first thing we do.

-- 
Thomas Zander
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Future Of Bitcoin-Cores Wallet

2015-08-11 Thread Mike Hearn via bitcoin-dev 
Hey Jonas,

I think your analysis of what (some) users need is a good one.

We've discussed this before so I know you prefer your current approach, but
I personally would take a slightly different path to reach the same end:

   1. Support serving of SPV wallets from pruned storage. This means some
   protocol upgrades, BIPs, etc. It helps all SPV wallets, including on phones.
   2. Then make a bitcoinj based desktop wallet app, that contains a
   bundled bitcoind.
   3. Make the app sync TWO wallets simultaneously, one from the P2P
   network as today, and another from the local bitcoind via a local socket
   (or even just passing buffers around internally)
   4. The app should then switch from using the wallet synced to P2P to the
   wallet synced to localhost when the latter is fully caught up, and back
   again when the local node is behind.
   5. If there's a discrepancy, alert the user.

There are big advantages of taking this path! They are:

   - The switching back and forth between local full-security mode (which
   may be behind) and remote SPV security (fully synced) is instant and
   transparent to the user. This is important for laptop users who don't run a
   local node all the time. The different audit levels can be reflected in the
   UI in some way.

   - The bitcoinj wallet code already has support for things like
   multi-sig, BIP32, seed words, micropayment channels, etc. You can disable
   Bloom filtering if you like (download full blocks).

   - You can do a local RPC or JNI/JNA call to get fee estimates, if wanted.

   - The modern JVM tools and languages are much, much more productive than
   working with C++.


If you want a thing that runs a home server, then the best way to do that
IMO would be to bundle Tor and make it auto-register a Tor hidden service.
Then you can just define a QR code standard for 'pairing' a wallet to a
.onion address. Any bitcoinj based wallet can sync to it, and as it's your
own node, you can use a Bloom filter sized to give virtually no false
positives. No additional indexing is then required.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Angel Leon via bitcoin-dev 
- policy neutrality.
- It can't be censored.
- it can't be shut down
- and the rules cannot change from underneath you.

except it can be shutdown the minute it actually gets used by its inability
to scale.

what's the point of having all this if nobody can use it?
what's the point of going through all that energy and CO2 for a mere 24,000
transactions an hour?

It's clear that it's just a matter of time before it collapses.

Here's a simple proposal (concept) that doesn't pretend to set a fixed
block size limit as you can't ever know the demands the future will bring
https://gist.github.com/gubatron/143e431ee01158f27db4

We don't need to go as far as countries with hyper inflation trying to use
the technology to make it collapse, anybody here who has distributed
commercial/free end user software knows that any small company out there
installs more copies in a couple weeks than all the bitcoin users we have
at the moment, all we need is a single company/project with a decent amount
of users who are now enabled to transact directly on the blockchain to
screw it all up (perhaps OpenBazaar this winter could make this whole thing
come down, hopefully they'll take this debate and the current limitations
before their release, and boy are they coding nonstop on it now that they
got funded), the last of your fears should be a malicious government trying
to shut you down, for that to happen you must make an impact first, for now
this is a silly game in the grand scheme of things.

And you did sound pretty bad, all of his points were very valid and they
share the concern of many people, many investors, entrepreneurs putting
shitload of money, time and their lives on a much larger vision than that
of a network that does a mere 3,500 tx/hour, but some people seem to be
able to live in impossible or useless ideals.

It's simply irresponsible to not want to give the network a chance to grow
a bit more. Miners centralizing is inevitable given the POW based
consensus, hobbists-mining is only there for countries with very cheap
energy.

If things remain this way, this whole thing will be a massive failure and
it will probably take another decade before we can open our mouths about
cryptocurrencies, decentralization and what not, and this stubornness will
be the one policy that censored everyone, that shutdown everyone, that made
the immutable rules not matter.

Perhaps it will be Stellar what ends up delivering at this stubborn pace.

http://twitter.com/gubatron

On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >It follows then, that if we make a decision now which destroys that
> property, which makes it possible to censor bitcoin, to deny service, or to
> pressure miners into changing rules contrary to user interests, then
> Bitcoin is no longer interesting.
>
> You asked to be convinced of the need for bigger blocks. I gave that.
> What makes you think bitcoin will break when more people use it?
>
> Sent on the go, excuse the brevity.
> *From: *Mark Friedenbach
> *Sent: *Tuesday, 11 August 2015 08:10
> *To: *Thomas Zander
> *Cc: *Bitcoin Dev
> *Subject: *Re: [bitcoin-dev] Fees and the block-finding process
>
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
>> > This is where things diverge. It's fine to pick a new limit or growth
>> > trajectory. But defend it with data and reasoned analysis.
>>
>> We currently serve about 0,007% of the world population sending maybe one
>> transaction a month.
>> This can only go up.
>>
>> There are about 20 currencies in the world that are unstable and showing
>> early
>> signs of hyperinflation. If even small percentage of these people
>> cash-out and
>> get Bitcoins for their savings you'd have the amount of people using
>> Bitcoin
>> as savings go from maybe half a million to 10 million in the space of a
>> couple
>> of months. Why so fast? Because all the world currencies are linked.
>> Practically all currencies follow the USD, and while that one may stay
>> robust
>> and standing, the linkage has been shown in the past to cause
>> chain-effects.
>>
>> It is impossible to predict how much uptake Bitcoin will take, but we have
>> seen big rises in price as Cyprus had a bailin and then when Greece first
>> showed bad signs again.
>> Lets do our due diligence and agree that in the current world economy
>> there
>> are sure signs that people are considering Bitcoin on a big scale.
>>
>> Bigger amount of people holding Bitcoin savings won't make the transaction
>> rate go up very much, but if you have feet on the ground you already see
>> that
>> people go back to barter in countries like Poland, Ireland, Greece etc.
>> And Bitcoin will be an alternative to good to ignore.  Then transaction
>> rates
>> will go up. Dramatically.
>>
>> If you are asking for numbers, that is a bit tricky. Again;

[bitcoin-dev] Future Of Bitcoin-Cores Wallet

2015-08-11 Thread Jonas Schnelli via bitcoin-dev 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi
(excuse my english; it’s not my native language)

As you might noticed, bitcoin-cores wallet didn’t got that much focus
during the last month (even years?).
Wallet development has mostly moved towards SPV (bitcoinj), thin
clients (Electrum), centralized web middleware (Copay, Greenaddress,
etc.).

Obviously this direction was highly appreciated by users who now can
now run a bitcoin-client (SPV / thin client) on a smartphone or on a
computer with tiny available resources.

Full validation slowly gets a privilege of people who can manage to
run bitcoin-core on a VPS or different server like system.
Thought, i think, running a full node wallet could be end user
friendly with some changes in the current concept.

Today a standard user can download a 1080p 10GB movie over iTunes (in
background) and simultaneous play a CPU/GPU extensive 3D game on a
standard computer.
Why do people think (and it might is) running a full node is so painful?

Mainly it could be because bitcoin-core has been focused on doing
validation as quick as possible (okay for a server, not desirable for
a wallet background service).

I could see the following strategy:
- - end user focused full node wallet would have enabled pruning by
default (~2GB disk usage).
- - throttled validation (flexible CPU usage, user selectable, maybe
~20% by default).
- - throttled block download (bandwidth).
- - SPV during catch up (initial sync as also when catching up multiple
days because user/node was offline).
- - Disable bloom filtering if there is enough bandwith, keep blocks for
later validation.
- - when node is in sync, switch from SPV to full validation (maybe
maintain to lists/dbs of wtx or re-validate after full catchup and
display potential conflicts).
- - participate in p2p, but with limits/throttling (service limited
amount of blocks, tx [TBD]).

Why?
- - This could increase the amount of participating full nodes while
giving users more privacy and security.
- - Create a counterweight against SPV/thin clients (avoid wallet
development centralization, could be helpful once/if attacks agains
SPV/thin clients are becoming real).
- - Slowly complete full validation (can take ~1-2 weeks) and thereforce
increase privacy (avoid bloomfilters) and security.

What about SPV together with a full node?
Sounds good in theory. But who can run a full node (see above)? How is
the channel secured (against MITM, privacy) between the SPV client and
the trusted full node? How hard is it to setup and maintain a secure
tunnel between a smartphone SPV and a full node over the p2p (8333)
channel? How about examine the mempool for fee calculations and
(maybe) upcoming CPFP like approaches, etc.?

How about smartphones?
Obviously the above solution won’t probably work on a smartphone (to
much bandwidth and CPU usage). But do you carry your whole saving in
your physical wallet with you? Maybe a smartphone does hold keys which
protects low value / daily spendings like a physical wallet (=SPV okay).
My personal long term vision of that use-case is, that groups of
people who trust each other (a family, etc.) might run one or multiple
full node(s) on a hardened system (something similar to the bitnodes
hardware) where the system could serve smartphones over something like
a stratum server (electrum) or bitpays wallet-service does (index
blockchain, additional wallet services). Every member still holds it’s
keys but they trust the connected full node (full nodes does address
index, balance calculation, multisig arrangements and maybe even coin
selection).

Since about one year i slowly work toward this direction. It took me a
while to commit myself to a strategy (and i still shake from time to
time).
At the moment I am working on a wallet focused bitcoin-core fork with
the ability to re-merge it to the bitcoin-core branch (keep the fork
rebased).
Long term goal is, to decouple the both (wallet / core) by using
bitcoin-core as a library (static or shared) for the wallet side
(which is possible already now)

To myself: I work in the bitcoin-space full-time and completely
independent (not employed or influenced by a bitcoin related company)
with no business interest, though, i think the acquired know-how can
be valuable within the next serval years. And i won’t have any regrets
if my work turns out to be unless and ends up in trash.

I have set up this mail to avoid parallelism on a works stream (if
there is any). Of course i would really appreciate if other developers
are willing to join the team by reviewing, concept critism or
contributing code at https://github.com/jonasschnelli/bitcoin.

Any forms of criticism and any ideas are highly appreciated.


—
/jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVyboPAAoJECnUvLZBb1PsgkkQAKySrksCclbfwIsf1L4Jwaxp
nWmUhlXa3lIoxKG3eYZMPVugFX/LFKtmNqypQJ8whUjF2K5ZwIW1Boosl13cBkE9
2EIAMcBrpah0pwzomJ9ViLArl+7t6ksLR5qWJsgJsLnWlaW4c/1KwjGkYTZ6++VC
8O3M3HrdwT3fnrK35XJXTIhpF

Re: [bitcoin-dev] What Lightning Is

2015-08-11 Thread Hector Chu via bitcoin-dev 
Lightning will never catch on as it basically demands that everyone who
uses it to become a speculator. Payment hubs and merchants will be at the
mercy of the bitcoin price while their funds stay locked up in payment
channels. This idea is a dead-end.

On 10 August 2015 at 22:43, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> In terms of usage I think you'd more imagine a wallet that basically
> parks Bitcoins onto channels at all times, so long as they are
> routable there is no loss, and the scalability achieved thereby is
> strongly advantageous, and there is even the potential for users to
> earn fees by having their wallets participate in channel rebalancing
> (where hubs pay users to rebalance channels - end up with the same net
> position but move funds from one user-owned channel to another.)
> Exchange deposit, withdrawal, payments, even in-exchange trades can
> usefully happen in lightning for faster, cheaper more scalable
> transactions.
>
> Adam
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] CFP Bitcoin Scalability Workshop (Sept 12-13), Montreal Canada

2015-08-11 Thread Pindar Wong via bitcoin-dev 
Bitcoin Scalability Workshops

In recent months the Bitcoin development community has faced difficult
discussions of how to safely improve the scalability and decentralized
nature of the Bitcoin network. To aid the technical consensus building
process we are organizing a pair of workshops to collect technical
criteria, present proposals and evaluate technical materials and data with
academic discipline and analysis that fully considers the complex tradeoffs
between decentralization, utility, security and operational realities. This
may be considered as similar in intent and process to the NIST-SHA3 design
process where performance and security were in a tradeoff for a security
critical application.

Since Bitcoin is a P2P currency with many stakeholders, it is important to
collect requirements as broadly as possible, and through the process
enhance everyone’s understanding of the technical properties of Bitcoin to
help foster an inclusive, transparent, and informed process.

Those with technical interest are invited to participate in this pair of
workshops with the following intent:

Phase 1: Scene setting, evaluation criteria, and tradeoff analysis.

Montreal, Canada: September 12th-13th, 2015

Scalability is not a single parameter; there are many opportunities to make
the Bitcoin protocol more efficient and better able to service the needs of
its growing userbase. Each approach to further scaling the Bitcoin
blockchain involves implicit trade offs of desired properties of the whole
system. As a community we need to raise awareness of the complex and subtle
issues involved, facilitate deeper research and testing of existing
proposals, and motivate future work in this area.

The purpose of this workshop is to discuss the general tradeoffs and
requirements of any proposal to scale Bitcoin beyond its present limits.
Session topics are to include the presentation of experimental data
relating to known bottlenecks of Bitcoin’s continued growth and analysis of
implicit tradeoffs involved in general strategies for enabling future
growth.

This event will not host sessions on the topic of any specific proposals
involving changes to the Bitcoin protocol. Such proposals would be the
topic of a 2nd, follow-on Phase 2 workshop described below; this event is
intended to “set the stage” for work on and evaluation of specific
proposals in the time between the workshops.

Phase 2 will be planned out further as part of Phase 1 with input from the
participants.

Phase 2: Presentation and review of technical proposals, with simulation,
benchmark results.

Hong Kong, SAR, China: TBD Nov/Dec 2015

Hopefully to be easier for the Chinese miners to attend, the second
workshop pertaining to actual block size proposals is to be planned for
Hong Kong roughly in the late November to December timeframe.

The purpose of this workshop is to present and review actual proposals for
scaling Bitcoin against the requirements gathered in Phase 1. Multiple
competing proposals will be presented, with experimental data, and compared
against each other. The goal is to raise awareness of scalability issues
and build a pathway toward consensus for increasing Bitcoin’s transaction
processing capacity or, barring that, identify key areas of further
required research and next steps for moving forward.

Preliminarily, Phase 2 will be a time to share results from experiments
performed as a result of Phase 1 and an opportunity to discuss new
developments.

How do the Workshops work?

   -

   Both events will be live-streamed with remote participation facilitated
   via IRC for parallel online discussion and passing questions to the event.
   -

   These workshops aim to facilitate the existing Bitcoin Improvement
   Proposals (BIP)[1] process. Most work will be done outside of the workshops
   in the intervening months. The workshops serve to be additive to the design
   and review process by raising awareness of diverse points of view, studies,
   simulations, and proposals.
   -

   Travel, venue details, and accommodation recommendation are available at
   scalingbitcoin.org. Registration begins August 12th at an early-bird
   ticket price of $150 USD until September 3rd. The ticket prices do not come
   close to covering the venue expense and travel subsidies, hence the need
   for corporate sponsors.
   -

   Please see the FAQ at scalingbitcoin.org which should answer most other
   questions.


Travel Subsidies for Independent/Academic Researchers

There will be an application process for independent or academic
researchers to apply for travel assistance to help cover the expense of
airfare and hotel fees up to $1,000 per qualified presenter who intends to
give a presentation.  The four underwriters of this event have agreed to
jointly review applications and cover the travel subsidies for qualified
presenters. See scalingbitcoin.org for details.

Sponsors of the Montreal Workshop

The first workshop is hosted and with logistics handled by the Mo

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Thomas Zander via bitcoin-dev 
  >It follows then, that if we make a decision now which destroys that property, which makes it possible to censor bitcoin, to deny service, or to pressure miners into changing rules contrary to user interests, then Bitcoin is no longer interesting. You asked to be convinced of the need for bigger blocks. I gave that.What makes you think bitcoin will break when more people use it?Sent on the go, excuse the brevity. From: Mark FriedenbachSent: Tuesday, 11 August 2015 08:10To: Thomas ZanderCc: Bitcoin DevSubject: Re: [bitcoin-dev] Fees and the block-finding processOn Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev  wrote:On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
> This is where things diverge. It's fine to pick a new limit or growth
> trajectory. But defend it with data and reasoned analysis.

We currently serve about 0,007% of the world population sending maybe one
transaction a month.
This can only go up.

There are about 20 currencies in the world that are unstable and showing early
signs of hyperinflation. If even small percentage of these people cash-out and
get Bitcoins for their savings you'd have the amount of people using Bitcoin
as savings go from maybe half a million to 10 million in the space of a couple
of months. Why so fast? Because all the world currencies are linked.
Practically all currencies follow the USD, and while that one may stay robust
and standing, the linkage has been shown in the past to cause chain-effects.

It is impossible to predict how much uptake Bitcoin will take, but we have
seen big rises in price as Cyprus had a bailin and then when Greece first
showed bad signs again.
Lets do our due diligence and agree that in the current world economy there
are sure signs that people are considering Bitcoin on a big scale.

Bigger amount of people holding Bitcoin savings won't make the transaction
rate go up very much, but if you have feet on the ground you already see that
people go back to barter in countries like Poland, Ireland, Greece etc.
And Bitcoin will be an alternative to good to ignore.  Then transaction rates
will go up. Dramatically.

If you are asking for numbers, that is a bit tricky. Again; we are at
0,007%... Thats like a f-ing rounding error in the world economy. You can't
reason from that. Its like using a float to do calculations that you should
have done in a double and getting weird output.

Bottom line is that a maximum size of 8Mb blocks is not that odd. Because a 20
times increase is very common in a "company" that is about 6 years old.
For instance Android was about that age when it started to get shipped by non-
Google companies. There the increase was substantially bigger and the company
backing it was definitely able to change direction faster than the Bitcoin
oiltanker can change direction.

...

Another metric to remember; if you follow hackernews (well, the incubator more
than the linked articles) you'd be exposed to the thinking of these startups.
Their only criteria is growth. and this is rather substantial growth. Like
150% per month.  Naturally, most of these build on top of html or other
existing technologies.  But the point is that exponential growth is expected
in any startup.  They typically have a much much more agressive timeline,
though. Every month instead of every year.
Having exponential growth in the blockchain is really not odd and even if we
have LN or sidechains or the next changetip, this space will be used. And we
will still have scarcity. I'm sorry, I really don't want to sound like a jerk, but not a single word of that mattered. Yes we all want Bitcoin to scale such that every person in the world can use it without difficulty. However if that were all that we cared about then I would be remiss if I did not point out that there are plenty of better, faster, and cheaper solutions to finding global consensus over a payment ledger than Bitcoin. Architectures which are algorithmically superior in their scaling properties. Indeed they are already implemented and you can use them today:https://www.stellar.org/http://opentransactions.org/So why do I work on Bitcoin, and why do I care about the outcome of this debate? Because Bitcoin offers one thing, and one thing only which alternative architectures fundamentally lack: policy neutrality. It can't be censored, it

Re: [bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Mark Friedenbach via bitcoin-dev 
On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
> > This is where things diverge. It's fine to pick a new limit or growth
> > trajectory. But defend it with data and reasoned analysis.
>
> We currently serve about 0,007% of the world population sending maybe one
> transaction a month.
> This can only go up.
>
> There are about 20 currencies in the world that are unstable and showing
> early
> signs of hyperinflation. If even small percentage of these people cash-out
> and
> get Bitcoins for their savings you'd have the amount of people using
> Bitcoin
> as savings go from maybe half a million to 10 million in the space of a
> couple
> of months. Why so fast? Because all the world currencies are linked.
> Practically all currencies follow the USD, and while that one may stay
> robust
> and standing, the linkage has been shown in the past to cause
> chain-effects.
>
> It is impossible to predict how much uptake Bitcoin will take, but we have
> seen big rises in price as Cyprus had a bailin and then when Greece first
> showed bad signs again.
> Lets do our due diligence and agree that in the current world economy there
> are sure signs that people are considering Bitcoin on a big scale.
>
> Bigger amount of people holding Bitcoin savings won't make the transaction
> rate go up very much, but if you have feet on the ground you already see
> that
> people go back to barter in countries like Poland, Ireland, Greece etc.
> And Bitcoin will be an alternative to good to ignore.  Then transaction
> rates
> will go up. Dramatically.
>
> If you are asking for numbers, that is a bit tricky. Again; we are at
> 0,007%... Thats like a f-ing rounding error in the world economy. You can't
> reason from that. Its like using a float to do calculations that you should
> have done in a double and getting weird output.
>
> Bottom line is that a maximum size of 8Mb blocks is not that odd. Because
> a 20
> times increase is very common in a "company" that is about 6 years old.
> For instance Android was about that age when it started to get shipped by
> non-
> Google companies. There the increase was substantially bigger and the
> company
> backing it was definitely able to change direction faster than the Bitcoin
> oiltanker can change direction.
>
> ...
>
> Another metric to remember; if you follow hackernews (well, the incubator
> more
> than the linked articles) you'd be exposed to the thinking of these
> startups.
> Their only criteria is growth. and this is rather substantial growth. Like
> 150% per month.  Naturally, most of these build on top of html or other
> existing technologies.  But the point is that exponential growth is
> expected
> in any startup.  They typically have a much much more agressive timeline,
> though. Every month instead of every year.
> Having exponential growth in the blockchain is really not odd and even if
> we
> have LN or sidechains or the next changetip, this space will be used. And
> we
> will still have scarcity.


I'm sorry, I really don't want to sound like a jerk, but not a single word
of that mattered. Yes we all want Bitcoin to scale such that every person
in the world can use it without difficulty. However if that were all that
we cared about then I would be remiss if I did not point out that there are
plenty of better, faster, and cheaper solutions to finding global consensus
over a payment ledger than Bitcoin. Architectures which are algorithmically
superior in their scaling properties. Indeed they are already implemented
and you can use them today:

https://www.stellar.org/
http://opentransactions.org/

So why do I work on Bitcoin, and why do I care about the outcome of this
debate? Because Bitcoin offers one thing, and one thing only which
alternative architectures fundamentally lack: policy neutrality. It can't
be censored, it can't be shut down, and the rules cannot change from
underneath you. *That* is what Bitcoin offers that can't be replicated at
higher scale with a SQL database and an audit log.

It follows then, that if we make a decision now which destroys that
property, which makes it possible to censor bitcoin, to deny service, or to
pressure miners into changing rules contrary to user interests, then
Bitcoin is no longer interesting. We might as well get rid of mining at
that point and make Bitcoin look like Stellar or Open-Transactions because
at least then we'd scale even better and not be pumping millions of tons of
CO2 into the atmosphere from running all those ASICs.

On the other side, 3Tb harddrives are sold, which take 8Mb blocks without
> problems.
>

Straw man, storage is not an issue.


> You can buy broadband in every relevant country that easily supports the
> bandwidth we need. (remember we won't jump to 8Mb in a day, it will likely
> take at least 6 months).
>

Neither one of those assertions is clear. Keep in mind the goal is to ha