Re: [bitcoin-dev] Voting by locking coins

[Hector Chu via bitcoin-dev]

Also there may need to be weighting depending on how long the coins have
been locked for, to stop voting at the last minute having an undue
influence.

On 8 August 2015 at 07:27, Hector Chu  wrote:

> Has there ever been any discussion of locking coins till a certain date
> for casting votes on an issue?
>
> Say that the date for counting votes is 3 months from now. Every one who
> wants to cast a vote must lock coins until the vote closes (using CLTV). To
> increase the weight of your vote, lock more coins. Write your choice in the
> scriptPubKey or an OP_RETURN data output.
>
> On the date the vote closes the nodes tally up the coin values for the
> various vote options, and the choice with the highest total is the winner.
>
> Not saying this could be used to solve the block size issue necessarily,
> but we could have choices like:
> 1) Keep block size the same
> 2) Reduce block size by 10%.
> 3) Increase block size by 10%.
>
> The vote could be a rolling one. When the present vote is decided the vote
> for the next 3 months starts.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Voting by locking coins

[Hector Chu via bitcoin-dev]

Has there ever been any discussion of locking coins till a certain date for
casting votes on an issue?

Say that the date for counting votes is 3 months from now. Every one who
wants to cast a vote must lock coins until the vote closes (using CLTV). To
increase the weight of your vote, lock more coins. Write your choice in the
scriptPubKey or an OP_RETURN data output.

On the date the vote closes the nodes tally up the coin values for the
various vote options, and the choice with the highest total is the winner.

Not saying this could be used to solve the block size issue necessarily,
but we could have choices like:
1) Keep block size the same
2) Reduce block size by 10%.
3) Increase block size by 10%.

The vote could be a rolling one. When the present vote is decided the vote
for the next 3 months starts.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] trust

[Thomas Zander via bitcoin-dev]

On Friday 7. August 2015 23.53.43 Adam Back wrote:
> On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
> > As we concluded in our previous email, the need to run a node is inversely
> > proportional to the ability (or willingness) to trust others.
[]
> > And lets face it, practically everyone trusts others with their money
> > today.

> Bitcoin's very reason for existence is to avoid that need.  For people
> fully happy to trust others with their money, Bitcoin may not be as
> interesting to them.

I'm making this a thread of its own because this is very serious.

The idea that Bitcoins very reason for existence is to avoid trusting anyone 
but yourself is something I've heard before, and I have to comment because it 
is a destructive thought. It is very much untrue because we don't live in a 
black/white world.

If you look at the history of money (500 years is enough) you may know about 
business being done in the late 1600s in Europe that included essentially a 
general ledger that every merchant used and had his own copy of (at least 
their own bits).
Merchant in France used a system that when they bought stock from one company
they didn't give them money, they instead gave them a IOU-style piece of 
paper.  To break your promise meant to be evicted from their money system.
Which to a merchant in that time is equal to starvation.

The point was NOT to trust no-one, the point was to trust everyone, but keep 
everyone honest by keeping the ledger open and publicly available.


Bitcoins current model to decentralize and distribute trust has historical 
precedent and is known to work. It was abandoned when Newton started the mint 
in London because that allowed international trade. And their system didn't 
scale.


On a tangent;
What we saw with the Internet is growth because of a lack of centralized 
controller. This does not mean lack of trust in your neighbours. Internet grew 
because permissionless innovation was allowed. Not by going from one extreme 
of central trust to the other extreme of no trust.
It flourished just by stepping out of the trust-one party extreme.

What Adam Black and probably some others must understand is that there is a 
whole spectrum between having a monopoly on trust and every player having 
their own node.

Bitcoin sole reason for existence is because it is the first every system that 
has global reach and does not need a central trusted party.
It is, in other words, the first alternative that for the very first time in 
centuries that allows innovation without permission.


> For people
> fully happy to trust others with their money, Bitcoin may not be as
> interesting to them.

So, this is to black/white. And also wrong.

This thinking will block growth towards the thing you want, and leave you 
without any toys at all.
For instance it is perfectly all right to have a central player in a poor 
country that helps millions of unbanked to use Bitcoin as their first 
international payment system.


I can only try to convince you to change your worldview be explaining some 
history and concepts you may have missed, if you don't thats fine with me. 
I do, however, have to ask you to assume people will not like Bitcoin and will 
not use it because they don't fit your worldview. That will ultimately hurt 
billions of people.
-- 
Thomas Zander
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Mark Friedenbach via bitcoin-dev]

Then I would suggest working on payment channel networks. No decrease of
the interblock time will ever compete with the approximately instant time
it takes to validate a microchannel payment.

On Fri, Aug 7, 2015 at 4:08 PM, Sergio Demian Lerner <
sergio.d.ler...@gmail.com> wrote:

> In some rare occasions in everyday life, what matters is seconds. Like
> when paying for parking in the car while some other cars are behind you in
> the line. You don't want them to get upset.
>
> I takes me tens of minutes to shop. But once you choose your merchandise
> and your payment starts processing, if the payment system allows several
> payments to be pending simultaneously and you're not blocking the next
> person to pay, then I don't care waiting some minutes for confirmation. But
> saving 10 minutes of confirmation is a lot.
>
> I ague that our time is mostly measured in minutes (but I don't have any
> sociological, cultural, genetic or anthropological evidence). It takes
> minutes to read an e-mail, minutes to correct a bug, minutes to have lunch,
> minutes to drive to the office, minutes to talk to your kids. A payment
> taking 1 minute is much better than a payment taking 10. If I could choose
> a single thing to change to Bitcoin, I would lower the payment time, even
> within the minute scale.
>
> Sergio
>
>
>
> On Fri, Aug 7, 2015 at 7:46 PM, Natanael  wrote:
>
>> Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org>:
>> >
>> > Mark,
>> > It took you 3 minutes to respond to my e-mail. And I responded to you 4
>> minutes later. If you had responded to me in 10 minutes, I would be of out
>> the office and we wouldn't have this dialogue. So 5 minutes is a lot of
>> time.
>> >
>> > Obviously this is not a technical response to the technical issues you
>> argue. But "minutes" is a time scale we humans use to measure time very
>> often.
>>
>> But what's more likely to matter is seconds. What you need then is some
>> variant of multisignature notaries (Greenaddress.it, lightning network),
>> where the combination of economic incentives and legal liability gives you
>> the assurance of doublespend protection from the time of publication of the
>> transaction to the first block confirmation.
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Sergio Demian Lerner via bitcoin-dev]

In some rare occasions in everyday life, what matters is seconds. Like when
paying for parking in the car while some other cars are behind you in the
line. You don't want them to get upset.

I takes me tens of minutes to shop. But once you choose your merchandise
and your payment starts processing, if the payment system allows several
payments to be pending simultaneously and you're not blocking the next
person to pay, then I don't care waiting some minutes for confirmation. But
saving 10 minutes of confirmation is a lot.

I ague that our time is mostly measured in minutes (but I don't have any
sociological, cultural, genetic or anthropological evidence). It takes
minutes to read an e-mail, minutes to correct a bug, minutes to have lunch,
minutes to drive to the office, minutes to talk to your kids. A payment
taking 1 minute is much better than a payment taking 10. If I could choose
a single thing to change to Bitcoin, I would lower the payment time, even
within the minute scale.

Sergio



On Fri, Aug 7, 2015 at 7:46 PM, Natanael  wrote:

> Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
> >
> > Mark,
> > It took you 3 minutes to respond to my e-mail. And I responded to you 4
> minutes later. If you had responded to me in 10 minutes, I would be of out
> the office and we wouldn't have this dialogue. So 5 minutes is a lot of
> time.
> >
> > Obviously this is not a technical response to the technical issues you
> argue. But "minutes" is a time scale we humans use to measure time very
> often.
>
> But what's more likely to matter is seconds. What you need then is some
> variant of multisignature notaries (Greenaddress.it, lightning network),
> where the combination of economic incentives and legal liability gives you
> the assurance of doublespend protection from the time of publication of the
> transaction to the first block confirmation.
>
___
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

[Adam Back via bitcoin-dev]

Please try to focus on constructive technical comments.

On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
 wrote:
> What will the backlash be when people here that are pushing for "off-chain-
> transactions" fail to produce a properly working alternative, which
> essentially means we have to say NO to more users.

But > 99% of Bitcoin transactions are already off-chain.  There are
multiple competing companies offering consumer & retail service with
off-chain settlement.

I wasnt clear but it seemed in your previous mail that you seemed to
say you dont mind trusting other people with your money, and so
presumably you are OK using these services, and so have no problem?

> At this time and this size of bitcoin community, my personal experience (and
> I've been part of many communities) saying NO to new customers

Who said no to anything?  The systems of off-chain transfer already
exist and are by comparison to Bitcoins protocol simple and rapid to
adapt and scale.

Indications are that we can even do off-chain at scale with Bitcoin
similar trust-minimisation with lightning, and duplex payment
channels; and people are working on that right now.

I think it would be interesting and useful for someone, with an
interest in low trust, high scale transactions, to work on and propose
an interoperability standard and API for such off-chain services to be
accessed by wallets, and perhaps periodic on-chain inter-service
netting.

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Mark Friedenbach via bitcoin-dev]

Actually I gave a cached answer earlier which on further review may need
updating. (Bad Mark!)

I presume by "what's more likely to matter is seconds" you are referencing
point of sale. As you mention yourself, lightning network or green address
style payment escrow obviates the need for short inter-block times.

But with lightning there is a danger of channels being exhausted in the
time between blocks, causing the need for new channels to be established.
So lightning does in fact benefit from moderately shorter inter-block
times, although how much of an issue this will be is anyone's guess now.

Still the first two points about larger SPV proofs and selfish mining still
hold true, which sets the bar particularly high for justifying more
frequent blocks.

On Fri, Aug 7, 2015 at 3:46 PM, Natanael  wrote:

> Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
> >
> > Mark,
> > It took you 3 minutes to respond to my e-mail. And I responded to you 4
> minutes later. If you had responded to me in 10 minutes, I would be of out
> the office and we wouldn't have this dialogue. So 5 minutes is a lot of
> time.
> >
> > Obviously this is not a technical response to the technical issues you
> argue. But "minutes" is a time scale we humans use to measure time very
> often.
>
> But what's more likely to matter is seconds. What you need then is some
> variant of multisignature notaries (Greenaddress.it, lightning network),
> where the combination of economic incentives and legal liability gives you
> the assurance of doublespend protection from the time of publication of the
> transaction to the first block confirmation.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Adam Back via bitcoin-dev]

On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
 wrote:
> the need an individual has for running a node is a completely different 
> concept than the
> need for nodes to exist.  And, really, you are describing miners, not nodes.

It's not as simple as trusting miners, Bitcoin security needs some
reasonable portion of economic interest to be validating their receipt
of coins against a full node they run.

I do it myself because I dont want to lose money, as do many power
users.  Most bitcoin ecosystem companies do it.  You dont have to run
it all the time, just sync it when you want to check your own coin
receipt with higher assurance.

> As we concluded in our previous email, the need to run a node is inversely
> proportional to the ability (or willingness) to trust others.

Even if you are willing to trust others, trusting miners or random
full nodes would be unsafe if not for the reasonable portion of
economic interest validating their own received coins.  That holds
miners honest, otherwise they could more easily present fake
information to SPV users.

> And lets face it, practically everyone trusts others with their money today.

Bitcoin's very reason for existence is to avoid that need.  For people
fully happy to trust others with their money, Bitcoin may not be as
interesting to them.

>> If the impact of the system goes u[p], so should the - joint - incentives to
>> keep it secure. And I think we're (slowly) failing at that.
>
> That is your opinion.

What Pieter said is an accurate summary and non-controversial.

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Natanael via bitcoin-dev]

Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> Mark,
> It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have this dialogue. So 5 minutes is a lot of
time.
>
> Obviously this is not a technical response to the technical issues you
argue. But "minutes" is a time scale we humans use to measure time very
often.

But what's more likely to matter is seconds. What you need then is some
variant of multisignature notaries (Greenaddress.it, lightning network),
where the combination of economic incentives and legal liability gives you
the assurance of doublespend protection from the time of publication of the
transaction to the first block confirmation.
___
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

[Thomas Zander via bitcoin-dev]

On Friday 7. August 2015 19.33.34 Jorge Timón via bitcoin-dev wrote:
> When "the network runs out of capacity" (when we hit the limit) do we
> expect anything to happen apart from minimum market fees rising (above
> zero)?

How many clients actually evict transactions from their mempool currently? If 
the backlog grows infinitely (as a result of more in than out), that would be 
a problem.
How many wallets re-transmit their transaction when your local full nodes 
mempool no longer has it? Problem.

What will the backlash be when people here that are pushing for "off-chain-
transactions" fail to produce a properly working alternative, which 
essentially means we have to say NO to more users. We can't service you, 
sorry. Please go away.

At this time and this size of bitcoin community, my personal experience (and 
I've been part of many communities) saying NO to new customers will kill the 
product totally. Or, if we are lucky, just make an altcoin that quickly 
becomes the de-facto standard.
-- 
Thomas Zander
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Thomas Zander via bitcoin-dev]

On Friday 7. August 2015 20.10.48 Pieter Wuille wrote:
> But if the reason for increasing is because you fear a change of economics,
> then it means you prefer not dealing with that change. 

Let me quote yourself;

On Thursday 6. August 2015 17.26.11 Pieter Wuille via bitcoin-dev wrote:
> I believe that it is essential to not take unnecessary risks,
> and find a non-controversial solution.

You want to change the basic economics of Bitcoin itself.
If anything is "unnecessary risks", that would be a clear contender.

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

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Thomas Zander via bitcoin-dev]

On Friday 7. August 2015 20.10.48 Pieter Wuille wrote:
> On Aug 7, 2015 7:50 PM, "Gavin Andresen"  wrote:
> > I believe people in the Bitcoin ecosystem will choose different
> > tradeoffs, and I believe that is OK-- people should be free to make those
> > tradeoffs.
> 
> I agree. Though I believe that the blockchain itself cannot offer many
> tradeoffs, and by trying to make it scale we hurt the whole system. The
> place to introduce tradeoffs is in layers on top - there you can build
> systems with various levels of trust without hurting others.

Pieter, you either misunderstood or misquoted Gavin here.
The tradeoffs Gavin talks about are about trusting your own node or using a 
centralized system (as the two extremes in a spectrum).

Your answer talks about something completely different. Not sure how your 
answer fits in this conversation, although, you do seem to use these 
misunderstandings often to push your own position in a way that to the naive 
reader it sounds like others agree with you.  Please try to be more concise 
and on-topic.

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Sergio Demian Lerner via bitcoin-dev]

Mark,
It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have this dialogue. So 5 minutes is a lot of
time.

Obviously this is not a technical response to the technical issues you
argue. But "minutes" is a time scale we humans use to measure time very
often.

:)




On Fri, Aug 7, 2015 at 6:27 PM, Mark Friedenbach 
wrote:

> Because halving the block interval comes with costs to SPV proofs (which
> double the number of headers) and mining centralization (doubles the
> selfish mining effect of latency) for the questionable benefit of a block
> expectation time that is still measured in minutes, not seconds.
>
> Doubling the block size is safer than halving the block interval, for the
> same effect in aggregate transactions per second.
>
> On Fri, Aug 7, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> What would you do?
>>
>> a. Double the block size
>> b. Reduce the block rate to a half (average 5 minute blocks)
>>
>> Suppose this is a one time hard fork. There no drastic technical problems
>> with any of them: "SPV" mining and the relay network has shown that block
>> propagation is not an issue for such as small change. Mining centralization
>> won't radically change for a 2x adjustment.
>>
>> So what would be best for Bitcoin?
>>
>> I suspect some (if not most of you) would choose b. Because reducing the
>> block interval saves us real time. Waiting 30 minutes for a 3-block
>> confirmation is... such a long time! Time that we value. Time that
>> sometimes we waste waiting. Time that makes a difference for us. Doubling
>> the block size does not change the user perception of Bitcoin in any way.
>>
>> Then why most discussions go around doubling the block size?
>>
>> Each change require less than 20 lines of code (*) in the reference code,
>> and minimum change in other wallets.
>>
>> Currently there is no idle mining hardware for hire, so the security of
>> six 10-minute block confirmation is equivalent to the security of six
>> 5-minute block confirmations, as described in Satoshi's paper (if there
>> were 51% spare mining hardware for hire, then obviously hiring that
>> hardware for 30 minutes would cost less than hiring it for 1 hour).
>>
>> Why we discuss a 2x block size increase and not a 1/2 block interval
>> reduction? Aren't we Bitcoin users after all?
>>
>> Best regards,
>>  Sergio.
>>
>> (*) b requires increasing the transaction version number, to support the
>> old nLockTime rate.
>>
>>
>>
>> ___
>> 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] Fwd: Block size following technological growth

[Thomas Zander via bitcoin-dev]

On Friday 7. August 2015 19.09.30 Pieter Wuille wrote:
> > And you do the same thing again; you dismiss the need factor.
> 
> Of course there is a need. It's the primary mechanism that keeps Bitcoin
> secure and immune from malicious influence.

I see a pretty big problem if this really is your insight, the need an 
individual has for running a node is a completely different concept than the 
need for nodes to exist.  And, really, you are describing miners, not nodes.

good thing is that you seem to agree with me as your continue with;

> Of course not everyone needs to run a node. 

Thats the 'need' I was talking about.
As we concluded in our previous email, the need to run a node is inversely 
proportional to the ability (or willingness) to trust others.
And lets face it, practically everyone trusts others with their money today.


> But that leaves the
> responsibility on us - the community - to help the situation by not making
> it too hard to run a node. And I see the block size as the primary way
> through which we do that.

That won't really have any influence, economics 101 says that it doesn't work 
that way.  Lowering the cost on a product won't make it sell more without the 
people wanting or needing the product.

> If the impact of the system goes u[p], so should the - joint - incentives to
> keep it secure. And I think we're (slowly) failing at that.

That is your opinion. At least, I don't see that conclusion supported by 
evidence.
I'll defer to Gavins emails that countered this point better.

-- 
Thomas Zander
___
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

[Jim Phillips via bitcoin-dev]

On Fri, Aug 7, 2015 at 10:16 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> But perhaps there is some "use" for ultra-low-priority unreliable
> transactions (... despite DoS attacks).
>

I can think of a variety of protocols that broadcast information and don't
really care about whether it gets delivered.. Think of everything that uses
UDP on TCP/IP. The most basic thing I can think of would be low-priority
notifications that are sent to the entire Bitcoin universe, but don't need
to persist. The protocol provides for a signed and thus verified message,
and a method for broadcasting it to every node that might be interested in
seeing it. If it never makes it into a block, so be it. If it does, so be
it.

--
*James G. Phillips IV*



*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Mark Friedenbach via bitcoin-dev]

Because halving the block interval comes with costs to SPV proofs (which
double the number of headers) and mining centralization (doubles the
selfish mining effect of latency) for the questionable benefit of a block
expectation time that is still measured in minutes, not seconds.

Doubling the block size is safer than halving the block interval, for the
same effect in aggregate transactions per second.

On Fri, Aug 7, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What would you do?
>
> a. Double the block size
> b. Reduce the block rate to a half (average 5 minute blocks)
>
> Suppose this is a one time hard fork. There no drastic technical problems
> with any of them: "SPV" mining and the relay network has shown that block
> propagation is not an issue for such as small change. Mining centralization
> won't radically change for a 2x adjustment.
>
> So what would be best for Bitcoin?
>
> I suspect some (if not most of you) would choose b. Because reducing the
> block interval saves us real time. Waiting 30 minutes for a 3-block
> confirmation is... such a long time! Time that we value. Time that
> sometimes we waste waiting. Time that makes a difference for us. Doubling
> the block size does not change the user perception of Bitcoin in any way.
>
> Then why most discussions go around doubling the block size?
>
> Each change require less than 20 lines of code (*) in the reference code,
> and minimum change in other wallets.
>
> Currently there is no idle mining hardware for hire, so the security of
> six 10-minute block confirmation is equivalent to the security of six
> 5-minute block confirmations, as described in Satoshi's paper (if there
> were 51% spare mining hardware for hire, then obviously hiring that
> hardware for 30 minutes would cost less than hiring it for 1 hour).
>
> Why we discuss a 2x block size increase and not a 1/2 block interval
> reduction? Aren't we Bitcoin users after all?
>
> Best regards,
>  Sergio.
>
> (*) b requires increasing the transaction version number, to support the
> old nLockTime rate.
>
>
>
> ___
> 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] If you had a single chance to double the transactions/second Bitcoin allows...

[Sergio Demian Lerner via bitcoin-dev]

What would you do?

a. Double the block size
b. Reduce the block rate to a half (average 5 minute blocks)

Suppose this is a one time hard fork. There no drastic technical problems
with any of them: "SPV" mining and the relay network has shown that block
propagation is not an issue for such as small change. Mining centralization
won't radically change for a 2x adjustment.

So what would be best for Bitcoin?

I suspect some (if not most of you) would choose b. Because reducing the
block interval saves us real time. Waiting 30 minutes for a 3-block
confirmation is... such a long time! Time that we value. Time that
sometimes we waste waiting. Time that makes a difference for us. Doubling
the block size does not change the user perception of Bitcoin in any way.

Then why most discussions go around doubling the block size?

Each change require less than 20 lines of code (*) in the reference code,
and minimum change in other wallets.

Currently there is no idle mining hardware for hire, so the security of six
10-minute block confirmation is equivalent to the security of six 5-minute
block confirmations, as described in Satoshi's paper (if there were 51%
spare mining hardware for hire, then obviously hiring that hardware for 30
minutes would cost less than hiring it for 1 hour).

Why we discuss a 2x block size increase and not a 1/2 block interval
reduction? Aren't we Bitcoin users after all?

Best regards,
 Sergio.

(*) b requires increasing the transaction version number, to support the
old nLockTime rate.
___
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

[Dave Hudson via bitcoin-dev]

> On 7 Aug 2015, at 16:17, Ryan Butler via bitcoin-dev 
>  wrote:
> 
> A raspberry pie 2 node on reasonable Internet connection with a reasonable 
> hard drive can run a node with 8 or 20mb blocks easily.
> 
I'm curious as I've not seen any data on this subject. How fast can a RP2 do 
the necessary cryptographic calculations to validate blocks of various sizes?

While everyone tends to talk in terms of 10 minutes per block that is, of 
course, only a typical time and doesn't account for situations in which 2 or 
more blocks are found in quick succession (which, of course, happens on a daily 
basis). At what point does, say, an RP2 node fail to be able to validate a 
second or third block because it's still not finished processing the first?

If someone were to be playing games with the system and mining transactions 
without first broadcasting them to the network then how long would that take? 
This would in essence define the ability to DoS lower-performance nodes 
(ignoring all of the other usual considerations such as bandwidth, etc).

___
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

[Ryan Butler via bitcoin-dev]

Peter's proposal undercuts matching blocksize growth to technological
progress not limiting centralization pressure.  They are somewhat related,
but I want to be clear on what I originally stated.  I would also point out
that Peter's proposal lacks this technical criteria as well.

That being said, I think designing any growth rates on theoretical
centralization pressure is not sensible and Peter's proposal rightly
excludes it and attempts instead for a very gradual increase over time
attempting to match blocksize growth that is consistent with technological
bandwidth growth.  The problem is that it ignores the last 6 years (we are
already "behind") and underestimates bandwidth and storage growth. (See
Nielsen's law which states 50% and has held for 30 years).

Peter seems to be of the belief that since bitcoin will never be able to
handle all the world's transactions we should instead "...decrease the need
for trust required in off-chain systems...".  This is akin to basing all
the world's transactions on a small settlement layer, much like balancing a
pyramid upside down it will topple.

I'm of the belief that the "reasonable node" test is a simple enough test
to maintain decentralization.

A raspberry pie 2 node on reasonable Internet connection with a reasonable
hard drive can run a node with 8 or 20mb blocks easily.

As Peter's proposal indicates, "If over time, this growth factor is beyond
what the actual technology offers, the intention should be to soft fork a
tighter limit."  I wholeheartedly agree, which is why we should plan to be
ahead of the curve...not behind it.
On Aug 7, 2015 2:15 PM, "Mark Friedenbach"  wrote:

> Surely you have some sort of empirical measurement demonstrating the
> validity of that statement? That is to say you've established some
> technical criteria by which to determine how much centralization pressure
> is too much, and shown that Pieter's proposal undercuts expected progress
> in that area?
>
> On Fri, Aug 7, 2015 at 12:07 PM, Ryan Butler 
> wrote:
>
>> Clarification...
>>
>> These are not mutually exclusive.  We can design an increase to blocksize
>> that increases available space on chain AND follow technological
>> evolution.  Peter's latest proposal is way too conservative on that front.
>>
>> And given Peter's assertion that demand is infinite there will still be a
>> an ocean of off chain transactions for the likes of blockstream to address.
>> On Aug 7, 2015 1:57 PM, "Ryan Butler"  wrote:
>>
>>> Who said anything about scaling bitcoin to visa levels now?  We're
>>> talking about an increase now that scales into the future at a rate that is
>>> consistent with technological progress.
>>>
>>> Peter himself said "So, I think the block size should follow
>>> technological evolution...".
>>>
>>> The blocksize increase proposals have been modeled around this very
>>> thing.  It's reasonable to increase the blocksize to a point that a
>>> reasonable person, with reasonable equipment and internet access can run a
>>> node or even a miner with acceptable orphan rates.  Most miners are spv
>>> mining anyways.  The 8 or even 20 MB limits are within those parameters.
>>>
>>> These are not mutually exclusive.  We can design an increase to
>>> blocksize that addresses both demand exceeding the available space AND
>>> follow technological evolution.  Peter's latest proposal is way too
>>> conservative on that front.
>>> On Aug 7, 2015 1:25 PM, "Mark Friedenbach"  wrote:
>>>
 Please don't put words into Pieter's mouth. I guarantee you everyone
 working on Bitcoin in their heart of hearts would prefer everyone in the
 world being able to use the Bitcoin ledger for whatever purpose, if there
 were no cost.

 But like any real world engineering issue, this is a matter of
 tradeoffs. At the extreme it is simply impossible to scale Bitcoin to the
 terrabyte sized blocks that would be necessary to service the entire
 world's financial transactions. Not without sacrificing entirely the
 protection of policy neutrality achieved through decentralization. And as
 that is Bitcoin's only advantage over traditional consensus systems, you
 would have to wonder what the point of such an endeavor would be.

 So *somewhere* you have to draw the line, and transactions below that
 level are simply pushed into higher level or off-chain protocols.

 The issue, as Pieter and Jorge have been pointing out, is that
 technical discussion over where that line should be has been missing from
 this debate.

 On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

> Interesting position there Peter...you fear more people actually using
> bitcoin.  The less on chain transactions the lower the velocity and the
> lower the value of the network.  I would be careful what you ask for
> because you end up having nothing left to even root the security o

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

[Mark Friedenbach via bitcoin-dev]

Surely you have some sort of empirical measurement demonstrating the
validity of that statement? That is to say you've established some
technical criteria by which to determine how much centralization pressure
is too much, and shown that Pieter's proposal undercuts expected progress
in that area?

On Fri, Aug 7, 2015 at 12:07 PM, Ryan Butler  wrote:

> Clarification...
>
> These are not mutually exclusive.  We can design an increase to blocksize
> that increases available space on chain AND follow technological
> evolution.  Peter's latest proposal is way too conservative on that front.
>
> And given Peter's assertion that demand is infinite there will still be a
> an ocean of off chain transactions for the likes of blockstream to address.
> On Aug 7, 2015 1:57 PM, "Ryan Butler"  wrote:
>
>> Who said anything about scaling bitcoin to visa levels now?  We're
>> talking about an increase now that scales into the future at a rate that is
>> consistent with technological progress.
>>
>> Peter himself said "So, I think the block size should follow
>> technological evolution...".
>>
>> The blocksize increase proposals have been modeled around this very
>> thing.  It's reasonable to increase the blocksize to a point that a
>> reasonable person, with reasonable equipment and internet access can run a
>> node or even a miner with acceptable orphan rates.  Most miners are spv
>> mining anyways.  The 8 or even 20 MB limits are within those parameters.
>>
>> These are not mutually exclusive.  We can design an increase to blocksize
>> that addresses both demand exceeding the available space AND follow
>> technological evolution.  Peter's latest proposal is way too conservative
>> on that front.
>> On Aug 7, 2015 1:25 PM, "Mark Friedenbach"  wrote:
>>
>>> Please don't put words into Pieter's mouth. I guarantee you everyone
>>> working on Bitcoin in their heart of hearts would prefer everyone in the
>>> world being able to use the Bitcoin ledger for whatever purpose, if there
>>> were no cost.
>>>
>>> But like any real world engineering issue, this is a matter of
>>> tradeoffs. At the extreme it is simply impossible to scale Bitcoin to the
>>> terrabyte sized blocks that would be necessary to service the entire
>>> world's financial transactions. Not without sacrificing entirely the
>>> protection of policy neutrality achieved through decentralization. And as
>>> that is Bitcoin's only advantage over traditional consensus systems, you
>>> would have to wonder what the point of such an endeavor would be.
>>>
>>> So *somewhere* you have to draw the line, and transactions below that
>>> level are simply pushed into higher level or off-chain protocols.
>>>
>>> The issue, as Pieter and Jorge have been pointing out, is that technical
>>> discussion over where that line should be has been missing from this debate.
>>>
>>> On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Interesting position there Peter...you fear more people actually using
 bitcoin.  The less on chain transactions the lower the velocity and the
 lower the value of the network.  I would be careful what you ask for
 because you end up having nothing left to even root the security of these
 off chain transactions with and then neither will exist.

 Nobody ever said you wouldn't run out of capacity at any size.  It's
 quite the fallacy to draw the conclusion from that statement that block
 size should remain far below a capacity it can easily maintain which would
 bring more users/velocity/value to the system.  The outcomes of both of
 those scenarios are asymmetric.  A higher block size can support more users
 and volume.

 Raising the blocksize isn't out of fear.  It's the realization that we
 are at a point where we can raise it and support more users and
 transactions while keeping the downsides to a minimum (centralization etc).
 On Aug 7, 2015 11:28 AM, "Pieter Wuille via bitcoin-dev" <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <
> gavinandre...@gmail.com> wrote:
>
>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <
>> pieter.wui...@gmail.com> wrote:
>>
>>> I guess my question (and perhaps that's what Jorge is after): do you
>>> feel that blocks should be increased in response to (or for fear of) 
>>> such a
>>> scenario.
>>>
>>
>> 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 s

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

[Ryan Butler via bitcoin-dev]

Clarification...

These are not mutually exclusive.  We can design an increase to blocksize
that increases available space on chain AND follow technological
evolution.  Peter's latest proposal is way too conservative on that front.

And given Peter's assertion that demand is infinite there will still be a
an ocean of off chain transactions for the likes of blockstream to address.
On Aug 7, 2015 1:57 PM, "Ryan Butler"  wrote:

> Who said anything about scaling bitcoin to visa levels now?  We're talking
> about an increase now that scales into the future at a rate that is
> consistent with technological progress.
>
> Peter himself said "So, I think the block size should follow technological
> evolution...".
>
> The blocksize increase proposals have been modeled around this very
> thing.  It's reasonable to increase the blocksize to a point that a
> reasonable person, with reasonable equipment and internet access can run a
> node or even a miner with acceptable orphan rates.  Most miners are spv
> mining anyways.  The 8 or even 20 MB limits are within those parameters.
>
> These are not mutually exclusive.  We can design an increase to blocksize
> that addresses both demand exceeding the available space AND follow
> technological evolution.  Peter's latest proposal is way too conservative
> on that front.
> On Aug 7, 2015 1:25 PM, "Mark Friedenbach"  wrote:
>
>> Please don't put words into Pieter's mouth. I guarantee you everyone
>> working on Bitcoin in their heart of hearts would prefer everyone in the
>> world being able to use the Bitcoin ledger for whatever purpose, if there
>> were no cost.
>>
>> But like any real world engineering issue, this is a matter of tradeoffs.
>> At the extreme it is simply impossible to scale Bitcoin to the terrabyte
>> sized blocks that would be necessary to service the entire world's
>> financial transactions. Not without sacrificing entirely the protection of
>> policy neutrality achieved through decentralization. And as that is
>> Bitcoin's only advantage over traditional consensus systems, you would have
>> to wonder what the point of such an endeavor would be.
>>
>> So *somewhere* you have to draw the line, and transactions below that
>> level are simply pushed into higher level or off-chain protocols.
>>
>> The issue, as Pieter and Jorge have been pointing out, is that technical
>> discussion over where that line should be has been missing from this debate.
>>
>> On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Interesting position there Peter...you fear more people actually using
>>> bitcoin.  The less on chain transactions the lower the velocity and the
>>> lower the value of the network.  I would be careful what you ask for
>>> because you end up having nothing left to even root the security of these
>>> off chain transactions with and then neither will exist.
>>>
>>> Nobody ever said you wouldn't run out of capacity at any size.  It's
>>> quite the fallacy to draw the conclusion from that statement that block
>>> size should remain far below a capacity it can easily maintain which would
>>> bring more users/velocity/value to the system.  The outcomes of both of
>>> those scenarios are asymmetric.  A higher block size can support more users
>>> and volume.
>>>
>>> Raising the blocksize isn't out of fear.  It's the realization that we
>>> are at a point where we can raise it and support more users and
>>> transactions while keeping the downsides to a minimum (centralization etc).
>>> On Aug 7, 2015 11: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:

> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <
> pieter.wui...@gmail.com> wrote:
>
>> I guess my question (and perhaps that's what Jorge is after): do you
>> feel that blocks should be increased in response to (or for fear of) 
>> such a
>> scenario.
>>
>
> 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. Whatever size blocks are actually produced, I believe
 the result will either be something people consider too small to be
 competitive ("you mean Bitcoin can only do 24 tra

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

[Ryan Butler via bitcoin-dev]

Who said anything about scaling bitcoin to visa levels now?  We're talking
about an increase now that scales into the future at a rate that is
consistent with technological progress.

Peter himself said "So, I think the block size should follow technological
evolution...".

The blocksize increase proposals have been modeled around this very thing.
It's reasonable to increase the blocksize to a point that a reasonable
person, with reasonable equipment and internet access can run a node or
even a miner with acceptable orphan rates.  Most miners are spv mining
anyways.  The 8 or even 20 MB limits are within those parameters.

These are not mutually exclusive.  We can design an increase to blocksize
that addresses both demand exceeding the available space AND follow
technological evolution.  Peter's latest proposal is way too conservative
on that front.
On Aug 7, 2015 1:25 PM, "Mark Friedenbach"  wrote:

> Please don't put words into Pieter's mouth. I guarantee you everyone
> working on Bitcoin in their heart of hearts would prefer everyone in the
> world being able to use the Bitcoin ledger for whatever purpose, if there
> were no cost.
>
> But like any real world engineering issue, this is a matter of tradeoffs.
> At the extreme it is simply impossible to scale Bitcoin to the terrabyte
> sized blocks that would be necessary to service the entire world's
> financial transactions. Not without sacrificing entirely the protection of
> policy neutrality achieved through decentralization. And as that is
> Bitcoin's only advantage over traditional consensus systems, you would have
> to wonder what the point of such an endeavor would be.
>
> So *somewhere* you have to draw the line, and transactions below that
> level are simply pushed into higher level or off-chain protocols.
>
> The issue, as Pieter and Jorge have been pointing out, is that technical
> discussion over where that line should be has been missing from this debate.
>
> On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Interesting position there Peter...you fear more people actually using
>> bitcoin.  The less on chain transactions the lower the velocity and the
>> lower the value of the network.  I would be careful what you ask for
>> because you end up having nothing left to even root the security of these
>> off chain transactions with and then neither will exist.
>>
>> Nobody ever said you wouldn't run out of capacity at any size.  It's
>> quite the fallacy to draw the conclusion from that statement that block
>> size should remain far below a capacity it can easily maintain which would
>> bring more users/velocity/value to the system.  The outcomes of both of
>> those scenarios are asymmetric.  A higher block size can support more users
>> and volume.
>>
>> Raising the blocksize isn't out of fear.  It's the realization that we
>> are at a point where we can raise it and support more users and
>> transactions while keeping the downsides to a minimum (centralization etc).
>> On Aug 7, 2015 11: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:
>>>
 On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille >>> > wrote:

> I guess my question (and perhaps that's what Jorge is after): do you
> feel that blocks should be increased in response to (or for fear of) such 
> a
> scenario.
>

 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. Whatever size blocks are actually produced, I believe
>>> the result will either be something people consider too small to be
>>> competitive ("you mean Bitcoin can only do 24 transactions per second?"
>>> sounds almost the same as "you mean Bitcoin can only do 3 transactions per
>>> second?"), or something that is very centralized in practice, and likely
>>> both.
>>>
>>>
 And if so, if that is a reason for increase now, won't it be a reason
> for an increase later as well? It is my impression that your answer is 
> yes,
> that this is why you want to increase the block size quickly and
> significantly, but correct me if I'm wrong.
>

 Sure, it might be a reason for an increase later. Here's my message t

[bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

[Wei via bitcoin-dev]

Hi,

Hope it is OK to post this on the list, was not sure where else to post 
for answers from Bitcoin-Qt client developers.


As part of the Open Bitcoin Privacy Project’s ongoing wallet privacy 
measurement efforts, we’ve selected the Bitcoin-Qt client v0.11.0 for 
inclusion into our 2015 mid year survey.


While our volunteers will be performing a series of functional tests by 
interacting with your application directly, several of the features we’d 
like to examine are not easily discernible by non-developers, and for 
this reason we’re asking for your help.


If you can answer the following questions about your wallet’s behavior 
it will assist us with the process of accurately rating your wallet’s 
privacy features.


Transaction Formatting

1.	Does your application take any steps to create ambiguity between 
transactions which unavoidably spend from multiple addresses at the same 
time and intentional mixing transactions?
2.	What algorithms does your application use for ordering inputs and 
outputs in a transaction? In particular, how do you handle the change 
output and do you take into account common practices of other wallet 
applications when determining ordering?
3.	Does your application minimize the harmful effects of address reuse 
by spending every spendable input (“sweeping”) from an address when a 
transaction is created?

4.  Does your application fully implement BIP 62?

Mixing

5.  If your application supports mixing:
a.	What is the average number of participants a user can expect to 
interact with on a typical join transaction?
b.	Does your application attempt to construct join transactions in a way 
that avoids distinguishing them from non-join transactions?
c.	Does your application perform any kind of reversibility analysis on 
join transactions prior to presenting them to the user for confirmation?
d.	Is the mixing technique employed secure against correlation attacks 
by the facilitator, such as a CoinJoin server or off-chain mixing 
service?
e.	Is the mixing technique employed secure against theft of funds by the 
facilitator or its participants?


Donations

6.  If your application has a fee or donation to the developers feature:
a.	What steps do you take to make the donations indistinguishable from 
regular spend in terms of output sizes and destination addresses?


Balance Queries and Tx Broadcasting

7.	Please describe how your application obtains balance information in 
terms of how queries from the user’s device can reveal a connection 
between the addresses in their wallet.
a.	Does the application keep a complete copy of the blockchain locally 
(full node)?
b.	Does the user’s device provide a filter which matches some fraction 
of the blockchain while providing a false positive rate (bloom or prefix 
filters)?
i.	If so, approximately what fraction of the blockchain does the filter 
match in a default configuration (0% - 100%)?

c.  Does the user’s device query all of their addresses at the same time?
d.	Does the user’s device query addresses individually in a manner that 
does not allow the query responder to correlate queries for different 
addresses?
e.	Can users opt to obtain their balance information via Tor (or 
equivalent means)?
8.	Does the applications route outgoing transactions independently from 
the manner in which it obtains balance information? Can users opt to 
have their transactions submitted to the Bitcoin network via Tor (or an 
equivalent means) independently of how they obtain their balance 
information?
9.	If your application supports multiple identities/wallets, does each 
one connect to the network as if it were completely independent from the 
other?
a.	Does the application ever request balance information for addresses 
belonging to multiple identities in the same network query?
b.	Are outgoing transactions from multiple identities routed 
independently of each other to the Bitcoin network?
c.	When an identity/wallet is deleted, does the deletion process 
eliminate all evidence from the user's device that the wallet was 
previously installed?


Network Privacy

10.	When a user performs a backup operation for their wallet, does this 
generate any automatic network activity, such as a web query or email?
11.	Does your application perform any lookup external to the user’s 
device related to identifying transaction senders or recipients?
12.	Does you application connect to known endpoints which would be 
visible to an ISP, such as your domain?
13.	If your application connects directly to nodes in the Bitcoin P2P 
network, does it either use an unremarkable user agent string (Bitcoin 
Core. BitcoinJ, etc), or randomize its user agent on each connection?


Physical Access

14.	Does the application uninstall process for your application 
eliminate all evidence from the user's device that the application was 
previously installed? Does it also eliminate wallet data?
15.	Does your application use techniques such as s

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

[Peter R via bitcoin-dev]

> ...blocks are found at random intervals.
> 
> Every once in a while the network will get lucky and we'll find six blocks in 
> ten minutes. If you are deciding what transaction fee to put on your 
> transaction, and you're willing to wait until that six-blocks-in-ten-minutes 
> once-a-week event, submit your transaction with a low fee.
> 
> All the higher-fee transactions waiting to be confirmed will get confirmed in 
> the first five blocks and, if miners don't have any floor on the fee they'll 
> accept (they will, but lets pretend they won't) then your very-low-fee 
> transaction will get confirmed.
> 
> In the limit, that logic becomes "wait an infinite amount of time, pay zero 
> fee."
> ...
> 
> Gavin Andresen

Yes, I see this as correct as well.  If demand for space within a particular 
block is elevated (e.g., when the network has not found a block for 30 
minutes), the minimum fee density for inclusion will be greater than the 
minimum fee density when demand for space is low (e.g., when the network has 
found several blocks in quick succession, as Gavin pointed out).  Lower-fee 
paying transaction will just wait to be included at one of the network lulls 
where a bunch of blocks were found quickly in a row.  

The feemarket.pdf paper ( 
https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf ) shows that this 
will always be the case so long as the block space supply curve (i.e., the cost 
in BTC/byte to supply additional space within a block [rho]) is a 
monotonically-increasing function of the block size (refer to Fig. 6 and Table 
1).  The curve will satisfy this condition provided the propagation time for 
block solutions grows faster than log Q where Q is the size of the block.  
Assuming that block solutions are propagated across physical channels, and that 
the quantity of pure information communicated per solution is proportional to 
the amount of information contained within the block, then the communication 
time will always grow asymptotically like O(Q) as per the Shannon-Hartely 
theorem, and the fee market will be healthy.  

Best regards,
Peter

___
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

[Simon Liu via bitcoin-dev]

That's a good question.

An argument has been put forward that a larger block size would reduce
the security of the network, so does the converse hold?


On 08/07/2015 11:17 AM, jl2012 via bitcoin-dev wrote:

> What if we reduce the block size to 0.125MB? That will allow 0.375tx/s.
> If 3->24 sounds "almost the same", 3->0.375 also sounds almost the same.
> We will have 5 full nodes, instead of 5000, since it is so
> affordable to run a full node.
> 
> If 0.125MB sounds too extreme, what about 0.5/0.7/0.9MB? Are we going to
> have more full nodes?
> 
> No, I'm not trolling. I really want someone to tell me why we
> should/shouldn't reduce the block size. Are we going to have more or
> less full nodes if we reduce the block size?
> ___
> 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

[Bryan Bishop via bitcoin-dev]

On Fri, Aug 7, 2015 at 1:17 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> No, I'm not trolling. I really want someone to tell me why we
> should/shouldn't reduce the block size. Are we going to have more or less
> full nodes if we reduce the block size?


Some arguments have floated around that even in the absence of "causing an
increase in the number of full nodes", that a reduction of the max block
size might be beneficial for other reasons, such as bandwidth saturation
benefits. Also less time spent validating transactions because of the fewer
transactions.

- 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

[Mark Friedenbach via bitcoin-dev]

Please don't put words into Pieter's mouth. I guarantee you everyone
working on Bitcoin in their heart of hearts would prefer everyone in the
world being able to use the Bitcoin ledger for whatever purpose, if there
were no cost.

But like any real world engineering issue, this is a matter of tradeoffs.
At the extreme it is simply impossible to scale Bitcoin to the terrabyte
sized blocks that would be necessary to service the entire world's
financial transactions. Not without sacrificing entirely the protection of
policy neutrality achieved through decentralization. And as that is
Bitcoin's only advantage over traditional consensus systems, you would have
to wonder what the point of such an endeavor would be.

So *somewhere* you have to draw the line, and transactions below that level
are simply pushed into higher level or off-chain protocols.

The issue, as Pieter and Jorge have been pointing out, is that technical
discussion over where that line should be has been missing from this debate.

On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Interesting position there Peter...you fear more people actually using
> bitcoin.  The less on chain transactions the lower the velocity and the
> lower the value of the network.  I would be careful what you ask for
> because you end up having nothing left to even root the security of these
> off chain transactions with and then neither will exist.
>
> Nobody ever said you wouldn't run out of capacity at any size.  It's quite
> the fallacy to draw the conclusion from that statement that block size
> should remain far below a capacity it can easily maintain which would bring
> more users/velocity/value to the system.  The outcomes of both of those
> scenarios are asymmetric.  A higher block size can support more users and
> volume.
>
> Raising the blocksize isn't out of fear.  It's the realization that we are
> at a point where we can raise it and support more users and transactions
> while keeping the downsides to a minimum (centralization etc).
> On Aug 7, 2015 11: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:
>>
>>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille 
>>> wrote:
>>>
 I guess my question (and perhaps that's what Jorge is after): do you
 feel that blocks should be increased in response to (or for fear of) such a
 scenario.

>>>
>>> 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. Whatever size blocks are actually produced, I believe
>> the result will either be something people consider too small to be
>> competitive ("you mean Bitcoin can only do 24 transactions per second?"
>> sounds almost the same as "you mean Bitcoin can only do 3 transactions per
>> second?"), or something that is very centralized in practice, and likely
>> both.
>>
>>
>>> And if so, if that is a reason for increase now, won't it be a reason
 for an increase later as well? It is my impression that your answer is yes,
 that this is why you want to increase the block size quickly and
 significantly, but correct me if I'm wrong.

>>>
>>> Sure, it might be a reason for an increase later. Here's my message to
>>> in-the-future Bitcoin engineers:  you should consider raising the maximum
>>> block size if needed and you think the benefits of doing so (like increased
>>> adoption or lower transaction fees or increased reliability) outweigh the
>>> costs (like higher operating costs for full-nodes or the disruption caused
>>> by ANY consensus rule change).
>>>
>>
>> In general that sounds reasonable, but it's a dangerous precedent to make
>> technical decisions based on a fear of change of economics...
>>
>> --
>> 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.li

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

[Anthony Towns via bitcoin-dev]

On 8 August 2015 at 00:57, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I answered:
>
>> > 1. If you are willing to wait an infinite amount of time, I think the
>> > minimum fee will always be zero or very close to zero, so I think it's a
>> > silly question.
>
> That's not what I'm thinking. It is just an observation based on the fact
> that blocks are found at random intervals.
>
Every once in a while the network will get lucky and we'll find six blocks
> in ten minutes. If you are deciding what transaction fee to put on your
> transaction, and you're willing to wait until that
> six-blocks-in-ten-minutes once-a-week event, submit your transaction with a
> low fee.
>
All the higher-fee transactions waiting to be confirmed will get confirmed
> in the first five blocks and, if miners don't have any floor on the fee
> they'll accept (they will, but lets pretend they won't) then your
> very-low-fee transaction will get confirmed.
>

​That depends a bit on how ra​tional miners are, doesn't it? Once the block
subsidy is retired, hashpower is only paid for by fees -- and if there's no
fee paying transactions in the queue, then there's no reward for applying
hashpower, so mining a block won't even pay for your costs. In that case,
better to switch to hatching something else (an altcoin with less fees than
bitcoin has on average but more than nothing, eg), or put your hashing
hardward into a low power mode so you at least cut costs.

That will only be needed for a short while though -- presumably enough
transactions will come in in the next five or ten minutes for a block to be
worth mining again, so maybe implementing that decision process is more
costly than the money you'd save.

​(C​
onversely, when the queue is over-full because there's been no blocks found
for a while, that should mean you can fill a block with higher-than-average
fee transactions, so I'd expect some miners to switch hashpower from
altcoins and sidechains to catch the temporary chance of higher revenue
blocks.
​Both tendencies would help reduce the variance in block time, compared to
a steady hashrate, which would probably be a good thing for the network as
a whole)​


I think the same incentives apply with mining being paid for by assurance
contracts rather than directly by transaction fees -- if you get a bunch of
blocks done quickly, the existing assurance contracts are dealt with just
as well as if it had taken longer; so you want to wait until new ones come
in rather than spend your hashpower for no return.

​All of this only applies once fees make up a significant portion of the
payment for mining a block, though.​

Cheers,
aj

-- 
Anthony Towns 
___
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

[jl2012 via bitcoin-dev]

Pieter Wuille via bitcoin-dev 於 2015-08-07 12:28 寫到:

On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen
 wrote:


On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille
 wrote:


I guess my question (and perhaps that's what Jorge is after): do
you feel that blocks should be increased in response to (or for
fear of) such a scenario.


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. Whatever size blocks are actually
produced, I believe the result will either be something people
consider too small to be competitive ("you mean Bitcoin can only do 24
transactions per second?" sounds almost the same as "you mean Bitcoin
can only do 3 transactions per second?"), or something that is very
centralized in practice, and likely both.


What if we reduce the block size to 0.125MB? That will allow 0.375tx/s. 
If 3->24 sounds "almost the same", 3->0.375 also sounds almost the same. 
We will have 5 full nodes, instead of 5000, since it is so 
affordable to run a full node.


If 0.125MB sounds too extreme, what about 0.5/0.7/0.9MB? Are we going to 
have more full nodes?


No, I'm not trolling. I really want someone to tell me why we 
should/shouldn't reduce the block size. Are we going to have more or 
less full nodes if we reduce the block size?

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

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Pieter Wuille via bitcoin-dev]

On Aug 7, 2015 7:50 PM, "Gavin Andresen"  wrote:
>
>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> If the incentives for running a node don't weight up against the
cost/difficulty using a full node yourself for a majority of people in the
ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
improvement over other systems is the lack of need for trust, I believe
that with increased adoption should also come an increased (in absolute
terms) incentive for people to use a full node. I'm seeing the opposite
trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem decide
to trust nothing but the genesis block hash (decide to run a full node)
there is a problem?

I shouldn't have said majority, sorry. But I do believe that as the odds at
stake in the system go up, so should those who take an interest in
verifying. That doesn't seem to be the case, and is a problem, where that
is a result of the block chain size or not.

> If so, then we do have a fundamental difference of opinion, but I've
misunderstood how you think about trust/centralization/convenience
tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different
tradeoffs, and I believe that is OK-- people should be free to make those
tradeoffs.

I agree. Though I believe that the blockchain itself cannot offer many
tradeoffs, and by trying to make it scale we hurt the whole system. The
place to introduce tradeoffs is in layers on top - there you can build
systems with various levels of trust without hurting others.

> And given that the majority of people in the ecosystem were deciding that
using a centralized service or an SPV-level-security wallet was better even
two or three years ago when blocks were tiny (I'd have to go back and dig
up number-of-full-nodes and number-of-active-wallets at the big web-wallet
providers, but I bet there were an order of magnitude more people using
centralized services than running full nodes even back then).

That's inevitable, I'm sure.

> I firmly believe that block size has very little to do with the decision
to run a full node or not.

Within certain limits, maybe not. Within certain limits, maybe it also does
not incentivize trusted miner setups like SPV mining (which hurt the
security of SPV nodes tremendously).

But if the reason for increasing is because you fear a change of economics,
then it means you prefer not dealing with that change. I believe you prefer
not dealing with it ever, and would rather have a system where as much as
possible happens on-chain, even when we unknowingly go beyond those limits.
I think we don't do the ecosystem a service by promising that such a future
is possible without compromises.

So, I think the block size should follow technological evolution, and not
reenforce the belief that the block size should follow demand. There will
always be demand, and we should learn to deal with it.

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

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Jameson Lopp via bitcoin-dev]

Anecdotally I've seen two primary reasons posed for not running a node:

1) For enthusiasts who want to altruistically run a node at home, it's
usually a bandwidth / quality of service problem. There are tools to help
work around this, but most users aren't sysadmins and would prefer a simple
configuration option in bitcoind and a slider / selector in the QT client
to throttle the total bandwidth usage. This issue has been open for years:
https://github.com/bitcoin/bitcoin/issues/273 - if you want to make it
easier for enthusiasts to run nodes, I'd start there.

2) For businesses, it's not so much an issue with the resources of
installing / running / maintaining a node, it's an issue with the lack of
indexing options offered by bitcoind. Thus the business will also need to
run their own indexing solution - an out-of-the-box solution such as
Insight or Toshi might work, but for more custom indexing you have to roll
your own software - this is where it actually becomes expensive.

Depending upon the query volume / latency needs of the business, it may not
make sense to bother administering bitcoind instances, the indexing
software, and its databases - using a third party API will probably be more
efficient.

- Jameson

On Fri, Aug 7, 2015 at 1:50 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> If the incentives for running a node don't weight up against the
>> cost/difficulty using a full node yourself for a majority of people in the
>> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
>> improvement over other systems is the lack of need for trust, I believe
>> that with increased adoption should also come an increased (in absolute
>> terms) incentive for people to use a full node. I'm seeing the opposite
>> trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem decide
> to trust nothing but the genesis block hash (decide to run a full node)
> there is a problem?
>
> If so, then we do have a fundamental difference of opinion, but I've
> misunderstood how you think about trust/centralization/convenience
> tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different tradeoffs,
> and I believe that is OK-- people should be free to make those tradeoffs.
>
> And given that the majority of people in the ecosystem were deciding that
> using a centralized service or an SPV-level-security wallet was better even
> two or three years ago when blocks were tiny (I'd have to go back and dig
> up number-of-full-nodes and number-of-active-wallets at the big web-wallet
> providers, but I bet there were an order of magnitude more people using
> centralized services than running full nodes even back then), I firmly
> believe that block size has very little to do with the decision to run a
> full node or not.
>
>
> --
> --
> Gavin Andresen
>
>
> ___
> 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] Fwd: Block size following technological growth

[Gavin Andresen via bitcoin-dev]

On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the incentives for running a node don't weight up against the
> cost/difficulty using a full node yourself for a majority of people in the
> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
> improvement over other systems is the lack of need for trust, I believe
> that with increased adoption should also come an increased (in absolute
> terms) incentive for people to use a full node. I'm seeing the opposite
> trend, and that is worrying IMHO.


Are you saying that unless the majority of people in the ecosystem decide
to trust nothing but the genesis block hash (decide to run a full node)
there is a problem?

If so, then we do have a fundamental difference of opinion, but I've
misunderstood how you think about trust/centralization/convenience
tradeoffs in the past.

I believe people in the Bitcoin ecosystem will choose different tradeoffs,
and I believe that is OK-- people should be free to make those tradeoffs.

And given that the majority of people in the ecosystem were deciding that
using a centralized service or an SPV-level-security wallet was better even
two or three years ago when blocks were tiny (I'd have to go back and dig
up number-of-full-nodes and number-of-active-wallets at the big web-wallet
providers, but I bet there were an order of magnitude more people using
centralized services than running full nodes even back then), I firmly
believe that block size has very little to do with the decision to run a
full node or not.


-- 
--
Gavin Andresen
___
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

[Ryan Butler via bitcoin-dev]

Interesting position there Peter...you fear more people actually using
bitcoin.  The less on chain transactions the lower the velocity and the
lower the value of the network.  I would be careful what you ask for
because you end up having nothing left to even root the security of these
off chain transactions with and then neither will exist.

Nobody ever said you wouldn't run out of capacity at any size.  It's quite
the fallacy to draw the conclusion from that statement that block size
should remain far below a capacity it can easily maintain which would bring
more users/velocity/value to the system.  The outcomes of both of those
scenarios are asymmetric.  A higher block size can support more users and
volume.

Raising the blocksize isn't out of fear.  It's the realization that we are
at a point where we can raise it and support more users and transactions
while keeping the downsides to a minimum (centralization etc).
On Aug 7, 2015 11: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:
>
>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille 
>> wrote:
>>
>>> I guess my question (and perhaps that's what Jorge is after): do you
>>> feel that blocks should be increased in response to (or for fear of) such a
>>> scenario.
>>>
>>
>> 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. Whatever size blocks are actually produced, I believe
> the result will either be something people consider too small to be
> competitive ("you mean Bitcoin can only do 24 transactions per second?"
> sounds almost the same as "you mean Bitcoin can only do 3 transactions per
> second?"), or something that is very centralized in practice, and likely
> both.
>
>
>> And if so, if that is a reason for increase now, won't it be a reason for
>>> an increase later as well? It is my impression that your answer is yes,
>>> that this is why you want to increase the block size quickly and
>>> significantly, but correct me if I'm wrong.
>>>
>>
>> Sure, it might be a reason for an increase later. Here's my message to
>> in-the-future Bitcoin engineers:  you should consider raising the maximum
>> block size if needed and you think the benefits of doing so (like increased
>> adoption or lower transaction fees or increased reliability) outweigh the
>> costs (like higher operating costs for full-nodes or the disruption caused
>> by ANY consensus rule change).
>>
>
> In general that sounds reasonable, but it's a dangerous precedent to make
> technical decisions based on a fear of change of economics...
>
> --
> 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

[Jorge Timón via bitcoin-dev]

On Aug 7, 2015 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.

What are the other 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.

When "the network runs out of capacity" (when we hit the limit) do we
expect anything to happen apart from minimum market fees rising (above
zero)?
Obviously any consequences of fees rising are included in this concern.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Pieter Wuille via bitcoin-dev]

On Fri, Aug 7, 2015 at 7:00 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > If the incentives for running a node don't weight up against the
> > cost/difficulty using a full node yourself for a majority of people in
> the
> > ecosystem, I would argue that there is a problem. As Bitcoin's
> fundamental
> > improvement over other systems is the lack of need for trust, I believe
> > that with increased adoption should also come an increased (in absolute
> > terms) incentive for people to use a full node. I'm seeing the opposite
> > trend, and that is worrying IMHO.
>
> And you do the same thing again; you dismiss the need factor.
>

Of course there is a need. It's the primary mechanism that keeps Bitcoin
secure and immune from malicious influence.

Of course not everyone needs to run a node. But that leaves the
responsibility on us - the community - to help the situation by not making
it too hard to run a node. And I see the block size as the primary way
through which we do that.

If the impact of the system goes us, so should the - joint - incentives to
keep it secure. And I think we're (slowly) failing at that.

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

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Thomas Zander via bitcoin-dev]

On Friday 7. August 2015 18.30.28 Pieter Wuille wrote:
> On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev <
> > But your conclusion that low node count is an indication that its hard
> > to run one discards your own point.  You forget the point that running
> > a node is only needed if you don't know anyone you can trust to run it
> > for you.  I'm  pretty darn sure that this will have a bigger effect on
> > nodecount than how hard it is.
> 
> I never said it is the only factor that influences node count.

You wrote;
>  They are an indication of how hard [node count] is (for various 
>  reasons) to run/use a full node, and thus provide feedback.

You clearly indicated that node count is an indicator of how hard it is to run 
a node.
Thats like saying something is too expensive because we don't sell enough. It 
forgets to ask the question of need. Do people want it.

Like in our case the need to run a node in the first place.


> If the incentives for running a node don't weight up against the
> cost/difficulty using a full node yourself for a majority of people in the
> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
> improvement over other systems is the lack of need for trust, I believe
> that with increased adoption should also come an increased (in absolute
> terms) incentive for people to use a full node. I'm seeing the opposite
> trend, and that is worrying IMHO.

And you do the same thing again; you dismiss the need factor.

Most merchants have no need for a node, most miners don't even want to run one 
anymore. Users don't make a significant amount of payments to care.

Any conclusions with regards to difficulty of running a node based on max-
blocksize is speculation without numbers; the only numbers you have is 
historical node count, and they don't mean shit because the need has not 
grown.
For instance, merchants are told to trust someone like bitpay.


Historical node-count says nothing. Anyone using it for the blocksize debate 
is speculating without basis.
-- 
Thomas Zander
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Pieter Wuille via bitcoin-dev]

On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> You make a logical fallacy;
>
> I would agree that nodes are there for people to stop trusting someone that
> they have no trust-relationship with.
>

Yay, trust!


> But your conclusion that low node count is an indication that its hard to
> run
> one discards your own point.  You forget the point that running a node is
> only
> needed if you don't know anyone you can trust to run it for you.  I'm
> pretty
> darn sure that this will have a bigger effect on nodecount than how hard it
> is.
>

I never said it is the only factor that influences node count.

Or, in other words, without a need to run a node you can't judge the
> difficulty of why there aren't more running.
>

If the incentives for running a node don't weight up against the
cost/difficulty using a full node yourself for a majority of people in the
ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
improvement over other systems is the lack of need for trust, I believe
that with increased adoption should also come an increased (in absolute
terms) incentive for people to use a full node. I'm seeing the opposite
trend, and that is worrying IMHO.

-- 
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

[Pieter Wuille via bitcoin-dev]

On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen 
wrote:

> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille 
> wrote:
>
>> I guess my question (and perhaps that's what Jorge is after): do you feel
>> that blocks should be increased in response to (or for fear of) such a
>> scenario.
>>
>
> 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. Whatever size blocks are actually produced, I believe
the result will either be something people consider too small to be
competitive ("you mean Bitcoin can only do 24 transactions per second?"
sounds almost the same as "you mean Bitcoin can only do 3 transactions per
second?"), or something that is very centralized in practice, and likely
both.


> And if so, if that is a reason for increase now, won't it be a reason for
>> an increase later as well? It is my impression that your answer is yes,
>> that this is why you want to increase the block size quickly and
>> significantly, but correct me if I'm wrong.
>>
>
> Sure, it might be a reason for an increase later. Here's my message to
> in-the-future Bitcoin engineers:  you should consider raising the maximum
> block size if needed and you think the benefits of doing so (like increased
> adoption or lower transaction fees or increased reliability) outweigh the
> costs (like higher operating costs for full-nodes or the disruption caused
> by ANY consensus rule change).
>

In general that sounds reasonable, but it's a dangerous precedent to make
technical decisions based on a fear of change of economics...

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

Re: [bitcoin-dev] Eli Dourado on "governance"

[Thomas Zander via bitcoin-dev]

On Monday 3. August 2015 11.22.14 Gavin Andresen via bitcoin-dev wrote:
> (my only big disagreement with those predictions is the 'Number of nodes'
> -- I don't think replace-by-fee would affect that number, and I think even
> with no change we will see the number of full nodes on the network drop to
> a couple thousand, because the general-purpose-home-PC is headed the way of
> the dodo []

On the other hand, things like the Raspberry PI and similar hardware are 
gaining ground fast. And they can run a node just fine.
I have many friends that run such small hardware for things like Owncloud.org 
because it is decentralized.  When Bitcoin gets traction with these people, I 
have no doubt a nice portion of them will run a node for the same reason they 
are running their private cloud. Trust No One.

Or, in other words, when Bitcoin grows in popularity and more people find it 
interesting (and we fix longstanding issues in Core), the desktop node that 
eventually get shut down will be replaced with the next generation hardware of 
a different kind of Bitcoin user.
-- 
Thomas Zander
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Thomas Zander via bitcoin-dev]

On Thursday 6. August 2015 20.52.28 Pieter Wuille via bitcoin-dev wrote:
> It's about reduction of trust. Running a full node and using it verify your
> transactions is how you get personal assurance that everyone on the network
> is following the rules. And if you don't do so yourself, the knowledge that
> others are using full nodes and relying on them is valuable. Someone just
> running 1000 nodes in a data center and not using them for anything does
> not do anything for this, it's adding network capacity without use.
> 
> That doesn't mean that the full node count (or the reachable full node
> count even) are meaningless numbers. They are an indication of how hard it
> is (for various reasons) to run/use a full node, and thus provide feedback.
> But they are not the goal, just an indicator.

You make a logical fallacy;

I would agree that nodes are there for people to stop trusting someone that 
they have no trust-relationship with.

But your conclusion that low node count is an indication that its hard to run 
one discards your own point.  You forget the point that running a node is only 
needed if you don't know anyone you can trust to run it for you.  I'm pretty 
darn sure that this will have a bigger effect on nodecount than how hard it 
is.
Or, in other words, without a need to run a node you can't judge the 
difficulty of why there aren't more running.


>From another mail;
On Thursday 6. August 2015 17.26.11 Pieter Wuille via bitcoin-dev wrote:
> Maybe. But I believe that it is essential to not take unnecessary risks,
> and find a non-controversial solution.

This is a very political answer; it doesn't actually say anything since 
'unnecessary' is a personal judgment. Everyone will agree with you, but that 
doesn't mean anything.

-- 
Tom Zander
___
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

[Gavin Andresen via bitcoin-dev]

On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille 
wrote:

> I guess my question (and perhaps that's what Jorge is after): do you feel
> that blocks should be increased in response to (or for fear of) such a
> scenario.
>

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.


And if so, if that is a reason for increase now, won't it be a reason for
> an increase later as well? It is my impression that your answer is yes,
> that this is why you want to increase the block size quickly and
> significantly, but correct me if I'm wrong.
>

Sure, it might be a reason for an increase later. Here's my message to
in-the-future Bitcoin engineers:  you should consider raising the maximum
block size if needed and you think the benefits of doing so (like increased
adoption or lower transaction fees or increased reliability) outweigh the
costs (like higher operating costs for full-nodes or the disruption caused
by ANY consensus rule change).


-- 
--
Gavin Andresen
___
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

[Pieter Wuille via bitcoin-dev]

On Fri, Aug 7, 2015 at 4:57 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Every once in a while the network will get lucky and we'll find six blocks
> in ten minutes. If you are deciding what transaction fee to put on your
> transaction, and you're willing to wait until that
> six-blocks-in-ten-minutes once-a-week event, submit your transaction with a
> low fee.
>
> All the higher-fee transactions waiting to be confirmed will get confirmed
> in the first five blocks and, if miners don't have any floor on the fee
> they'll accept (they will, but lets pretend they won't) then your
> very-low-fee transaction will get confirmed.
>
> In the limit, that logic becomes "wait an infinite amount of time, pay
> zero fee."
>

That's only the case when the actual rate of transactions with a non-zero
fee is below what fits in blocks. If the total production rate is higher,
even without configured floor by miners, a free transaction won't ever be
mined, as there will always be some backlog of non-free transaction. Not
saying that this is a likely outcome - it would inevitably mean that people
are creating transactions without any guarantee that they'll be mined,
which may not be what anyone is interested in. But perhaps there is some
"use" for ultra-low-priority unreliable transactions (... despite DoS
attacks).

>
> So... I have no idea what the 'market minimum fee' will be, because I have
> no idea how long people will be willing to wait, how many times they'll be
> willing to retransmit a low-fee transaction that gets evicted from
> memory-limited memory pools, or how much memory miners will be willing to
> dedicate to storing transactions that won't confirm for a long time because
> they're waiting for a flurry of blocks to be found.
>

Fair enough, I don't think anyone knows.

I guess my question (and perhaps that's what Jorge is after): do you feel
that blocks should be increased in response to (or for fear of) such a
scenario. And if so, if that is a reason for increase now, won't it be a
reason for an increase later as well? It is my impression that your answer
is yes, that this is why you want to increase the block size quickly and
significantly, but correct me if I'm wrong.

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

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

[Gavin Andresen via bitcoin-dev]

Popping this into it's own thread:

Jorge asked:

> >> 1) If "not now", when will it be a good time to let the "market
> >> minimum fee for miners to mine a transaction" rise above zero?
>

I answered:


> > 1. If you are willing to wait an infinite amount of time, I think the
> > minimum fee will always be zero or very close to zero, so I think it's a
> > silly question.
>

Which Jorge misinterpreted to mean that I think there will always be at
least one miner willing to mine a transaction for free.

That's not what I'm thinking. It is just an observation based on the fact
that blocks are found at random intervals.

Every once in a while the network will get lucky and we'll find six blocks
in ten minutes. If you are deciding what transaction fee to put on your
transaction, and you're willing to wait until that
six-blocks-in-ten-minutes once-a-week event, submit your transaction with a
low fee.

All the higher-fee transactions waiting to be confirmed will get confirmed
in the first five blocks and, if miners don't have any floor on the fee
they'll accept (they will, but lets pretend they won't) then your
very-low-fee transaction will get confirmed.

In the limit, that logic becomes "wait an infinite amount of time, pay zero
fee."

So... I have no idea what the 'market minimum fee' will be, because I have
no idea how long people will be willing to wait, how many times they'll be
willing to retransmit a low-fee transaction that gets evicted from
memory-limited memory pools, or how much memory miners will be willing to
dedicate to storing transactions that won't confirm for a long time because
they're waiting for a flurry of blocks to be found.

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

Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation

[jl2012 via bitcoin-dev]

Your proposal fails here:
"If the block defined in the Guarantee Message has not been shown"

What is blockchain? You can see blockchain as a mechanism to prove 
something has been shown by certain order. Therefore, it is not possible 
to prove something has not been shown with blockchain.


Your proposal works only with a centralized trusted party.

Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev 於 2015-08-05 15:07 寫到:

Hello all.

We’d like to share an idea we have to dramatically increase the
bitcoin block propagation speed after a new block has been mined for
the first time.


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