Why Satoshi's temporary anti-spam measure isn't temporary

Forgot to include the list. 


From: Jean-Paul Kogelman <jeanpaulkogelman <at> me.com>
Date: July 31, 2015 at 4:02:20 PM PDT
To: Jorge Timón <jtimon <at> jtimon.cc>
Cc: milly <at> bitcoins.info
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary



You basically want 3 things:

- A Minimum Specification of hardware: This is the lowest hardware configuration Bitcoin Core will run on at maximum capacity.
- A theoretical model that takes into account all of the components in Bitcoin Core and how they affect Min Spec.
- A benchmark tool to measure how changes affect Min Spec (and for users to see how their hardware measures up to Min Spec).

jp

On Jul 31, 2015, at 02:31 PM, Jorge Timón via bitcoin-dev <bitcoin-dev <at> lists.linuxfoundation.org> wrote:

On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev
<bitcoin-dev <at> lists.linuxfoundation.org> wrote:
These are the types of things I have been discussing in relation to a
process:

-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achieve that goal.

Proposed changes would be measured against the same metrics and a risk
analysis done so it can be compared with the baseline.

For example, the block size debate would be discussed in the context of a
road map related to a goal of increase scaling. One of the metrics would be
a decentralization metric. (A framework for a decentralization metric is at
http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf).
Cost would be one aspect of the decentralization metric.

All this sounds very reasonable and useful.
And if a formal organization owns this "process", that's fine as well.
I still think hardforks need to be uncontroversial (using the vague "I
will know it when I see it" defintion) and no individual or
organization can be an "ultimate decider" or otherwise Bitcoin losses
all it's p2p nature (and this seems the point where you, Milly, and I
disagree).
But metrics and data tend to help when it comes to "I will know it
when I see it" and "evidences".
So, yes, by all means, let's have an imperfect decentralization metric
rather than not having anything to compare proposals. Competing
decentralization metrics can appear later: we need a first one first.
I would add that we should have sets of simulations being used to
calculate some of those metrics, but maybe I'm just going too deep
into details.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 via bitcoin-dev | 31 Jul 10:39 2015

A compromise between BIP101 and Pieter's proposal

There is a summary of the proposals in my previous mail at  
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html

I think there could be a compromise between Gavin's BIP101 and  
Pieter's proposal (called "BIP103" here). Below I'm trying to play  
with the parameters, which reasons:

1. Initiation: BIP34 style voting, with support of 750 out of the last  
1000 blocks. The "hardfork bit" mechanism might be used:  
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html

Rationale: This follows BIP101, to make sure the new chain is secure.  
Also, no miner would like to be the first one to mine a large block if  
they don't know how many others would accept it.

2. Starting date: 30 days after 75% miner support, but not before  
2016-01-12 00:00 UTC

Rationale: A 30-day grace period is given to make sure everyone has  
enough time to follow. This is a compromise between 14 day in BIP101  
and 1 year in BIP103. I tend to agree with BIP101. Even 1 year is  
given, people will just do it on the 364th day if they opt to  
procrastinate.

2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in  
China. Most pool operators and devs should be back from new year  
holiday and not sleeping. (If the initiation is delayed, we may  
require that it must be UTC Tuesday midnight)

3. The block size at 2016-01-12 will be 1,414,213 bytes, and  
multiplied by 1.414213 by every 2^23 seconds (97 days) until exactly  
8MB is reached on 2017-05-11.

Rationale: Instead of jumping to 8MB, I suggest to increase it  
gradually to 8MB in 16 months. 8MB should not be particularly painful  
to run even with current equipment (you may see my earlier post on  
bitctointalk: https://bitcointalk.org/index.php?topic=1054482.0). 8MB  
is also agreed by Chinese miners, who control >60% of the network.

4. After 8MB is reached, the block size will be increased by 6.714%  
every 97 days, which is equivalent to exactly octuple (8x) every 8.5  
years, or double every 2.9 years, or +27.67% per year. Stop growth at  
4096MB on 2042-11-17.

Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%  
p.a. of BIP101. This will take us almost 8 years from now just to go  
back to the original 32MB size (4 years for BIP101 and 22 years for  
BIP103)

SSD price is expected to drop by >50%/year in the coming years. In  
2020, we will only need to pay 2% of current price for SSD. 98% price  
reduction is enough for 40 years of 27.67% growth.
Source: http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures

Global bandwidth is expected to grow by 37%/year until 2021 so 27.67%  
should be safe at least for the coming 10 years.
Source:  
https://www.telegeography.com/research-services/global-bandwidth-forecast-service/

The final cap is a compromise between 8192MB <at> 2036 of BIP101 and  
2048MB <at> 2063 of BIP103

-----------------------------------

Generally speaking, I think we need to have a faster growth in the  
beginning, just to normalize the block size to a more reasonable one.  
After all, the 1MB cap was introduced when Bitcoin was practically  
worthless and with inefficient design. We need to decide a new  
"optimal" size based on current adoption and technology.

About "fee market": I do agree we need a fee market, but the fee  
pressure must not be too high at this moment when block reward is  
still miner's main income source. We already have a fee market: miners  
will avoid building big blocks with low fee because that will increase  
the orphan risk for nothing.

About "secondary layer": I respect everyone building secondary layer  
over the blockchain. However, while the SWIFT settlement network is  
processing 300tps, Bitcoin's current 7tps is just nothing more than an  
experiment. If the underlying settlement system does not have enough  
capacity, any secondary layer built on it will also fall apart. For  
example, people may DoS attack a Lightening network by provoking a  
huge amount of settlement request which some may not be confirmed on  
time. Ultimately, this will increase the risk of running a LN service  
and increase the tx fee inside LN. After all, the value of secondary  
layer primarily comes from instant confirmation, not scarcity of the  
block space.

LockUnspent not working, bug?

My first post to the list, not sure this is the right place, let me know if it is better to open an issue on GitHub.

This is occurring on OS X with Satoshi 0.11.0, the TXID and vout belong to the wallet:

command: lockunspent true "[ { \"txid\":
\"fd697746c67f68a206bb7377fd40f35d146cc5821883e4c4b6cbf82b48e62a13\", \"vout\": 1 } ]"
output: true
command: listlockunspent
Output:
[
]

Additionally after locking the TX with lockunspent I am able to spend it from the wallet.

Cheers,

Ian
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 via bitcoin-dev | 30 Jul 20:14 2015

A summary of block size hardfork proposals

Currently, there are 4 block size BIP by Bitcoin developers:

BIP100 by Jeff:  
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
BIP101 by Gavin:  
https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
BIP??? by Pieter (called "BIP103" below):  
https://gist.github.com/sipa/c65665fc360ca7a176a6

To facilitate further discussion, I'd like to summarize these  
proposals by a series of questions. Please correct me if I'm wrong.  
Something like sigop limit are less controversial and are not shown.

Should we use a BIP34-like voting mechanism to initiate the hardfork?
BIP100, 102, 103: No
BIP101: Yes

When should we initiate the hardfork?
BIP100: 2016-01-11
BIP101: 2 weeks after 75% miner support, but not before 2016-01-11
BIP102: 2015-11-11
BIP103: 2017-01-01

What should be the block size at initiation?
BIP100: 1MB
BIP101: 8MB
BIP102: 2MB
BIP103: 1MB

Should we allow further increase / decrease?
BIP100: By miner voting, 0.5x - 2x every 12000 blocks (~3 months)
BIP101: Double every 2 years, with interpolations in between (41.4% p.a.)
BIP102: No
BIP103: +4.4% every 97 days (double every 4.3 years, or 17.7% p.a.)

The earliest date for a >=2MB block?
BIP100: 2016-04-03 (assuming 10 minutes block)
BIP101: 2016-01-11
BIP102: 2015-11-11
BIP103: 2020-12-27

What should be the final block size?
BIP100: 32MB is the max, but it is possible to reduce by miner voting
BIP101: 8192MB
BIP102: 2MB
BIP103: 2048MB

When should we have the final block size?
BIP100: Decided by miners
BIP101: 30 years after initiation
BIP102: 2015-11-11
BIP103: 2063-07-09

Another block size limit solution - dynamic block size limit.

I propose to implement dynamic block size limit. Its short summary is here in doc:


Comments are allowed
--
Maksim Bozhko
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Block size following technological growth

Hello all,

here is a proposal for long-term scalability I've been working on: https://gist.github.com/sipa/c65665fc360ca7a176a6

Some things are not included yet, such as a testnet whose size runs ahead of the main chain, and the inclusion of Gavin's more accurate sigop checking after the hard fork.

Comments?

--
Pieter

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Data / Evidence regd "penalties" for not validating blocks (Was: Why Satoshi's temporary anti-spam measure isn't temporary)

On Wed, Jul 29, 2015 at 10:23 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev <at> lists.linuxfoundation.org> wrote:

On Wed, Jul 29, 2015 at 9:59 AM, Mike Hearn via bitcoin-dev


> Miners who don't validate have a habit of bleeding money:   that's the
> system working as designed.

The information I have currently is that the parties engaging in that
activity found it to be tremendously profitable, even including losses
from issues.

This got buried in another thread. Putting it out in case anyone has any insight. 

Does anyone have any data on which of the above two viewpoints is actually correct? Measuring / publishing these effects will go a long way in either (a) establishing credibility of the 'system design' or (b) trigger a conversation on what needs fixing.

If there is no such known data, and someone new to Bitcoin would like to do that, where would be a good place to start, if it is at all possible.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight

When it comes to define thresholds for consensus fork activation there
are 3 options that I know of and each of them has at least a
disadvantage that the other 2 lack:

-Block.nTime: It's not monotonic
-median time: You cannot validate it without context (in contrast,
nTime is contained in the block header and nHeight in the coinbase)
-block.nHeight: You cannot know the exact time when a given height
will be reached.

I personally think that nHeight's disadvantage is the less worse, but
others will likely disagree. The point is we need to find a solid
criteria to decide.

When combining the threshold with a later miner's "voting" (upgrade
confirmation) on top of it, not being monotonic may be a real problem.
Doing that on top of height seems straight forward: check if
(prevBlockIndex.nHeight > threshold &&
IsSuperMajority(...,prevBlockIndex,...))
With median time, seems safe too: if
(prevBlockIndex.CalculateMedianTime > threshold &&
IsSuperMajority(...,prevBlockIndex,...))
Just a little bit less efficient.
It would look more like if (IsSuperMajority(...,prevBlockIndex,...) &&
GetFirstBlockUsedInVoting(prevBlockIndex).nTime > threshold)

But in some cases (say, an emergency consensus fork) you won't combine
the mining confirmation, so you may not have the prevBlockIndex
available and you may need to pass the height or medianTime down.
If the current block is not accessible from wherever the check is
being made, you would need an additional blockTime parameter as well.

Are there any example cases where a rule activation check doesn't have
the block available?

Of course, let's consider the following hardfork example:

before the hardfork: consensus_size(tx) = real_size(tx)
after the hardfork: after consensus_size(tx) = real_size(tx) +
delta_utxo_size(tx)

that would allow miners to create bigger blocks if the transactions
help reducing the size of the utxo (and penalize transactions that
make the utxo grow by considering bigger when it comes to block
inclusion).

Well, at the block validation level (the most important one), you
obviously have block.nTime available.
But what if you're checking an unconfirmed transaction?
It's size (and thus it's validity and the policy relay decisions)
depends on whether the hardfork is activated or not.
So to check an unconfirmed transaction, you would need the block.nTime
of the next block, which is unpredictable (unless you're a miner)
because miners set those.

AcceptToMemoryPool already uses the nHeight (in fact, there's nHeight
and nSpendHeight there, not sure why we need to of them yet), so this
case would be trivial to implement.
Calculating the median time there wouldn't be difficult either: even
if globals weren't so heavily-used in AcceptToMemoryPool, the
prevIndex can always be passed down as parameter.

Some people may think that I'm discussing tiny details, but I would
really like that we can chose whatever is more generic for any type of
consensus fork and always use that from now on (instead of risking of
having to use 2 of them if we find out later that the chosen option is
not general enough).

It would be also nice to have only one uniform type of threshold in
Consensus::Params, and height seems to be the choice for softforks
that have been accepted long ago via miners'
voting/upgrade_confirmation, like in :
https://github.com/bitcoin/bitcoin/pull/5966/files

That doesn't mean it needs to necessarily be height: in a rebased
version of #5966 we could replace consensus.nBIP34Height = 227931 with
consensus.nBIP34Time = <something>.
But I would really like to have a uniform threshold mechanism instead
of using the 3 options depending on the fork.

I had assumed that height was the preferred option for everyone and
that's why I used it in
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
But judging from the existing blocksize hardfork proposals (using
block.nTime, the option I like less ) I was too fast there and clearly
I need to reopen the discussion.
Vali Zero via bitcoin-dev | 29 Jul 16:09 2015

Răspuns: Personal opinion on the fee market from a worried local trader

I am disappointed that you did not understand my point of view. Let me rephrase it for you,

People tipping, buying 0.99$ products and gamblers that need Bitcoin transactions *more* than the rest of the people will afford the fees that establish the equilibrium between demand and supply of Bitcoin transactions. The people are free to use they money for whatever they like, but you should understand that Bitcoin transactions are not free.

I was merely attempting to point out that spammers and gamblers would be the first ones that would go away. They would be free to spam or gamble, but they would have to pay for it.

When a category of users would get priced out because of the fee market, they would be free to use any altcoin they want.

Please understand that not everyone will leave. The more important players will remain, those that need it the most. The other players are free to use whatever altcoin they wish.


În Miercuri, 29 Iulie 2015 16:47:57, Angel Leon <gubatron <at> gmail.com> a scris:


"the gamblers and perhaps people transacting very low amounts. The people that actually need Bitcoin would remain."

so people tipping, buying $0.99 products, and gamblers actually don't need Bitcoin.
Who are you to say what people need to use money for?
This statement goes against the freedom of decentralization and financial freedom Bitcoin should be able to provide.

It's an open network and it will be used as most users see fit, and that requires a blocksize increase wether you like it or not, it's simple physics, other time wait times will become unbearable for those not willing to pay the high fees, if people leave, then it only mean bitcoins isn't useful, and if bitcoin isn't useful, it's worthless.




On Wed, Jul 29, 2015 at 9:27 AM, Vali Zero via bitcoin-dev <bitcoin-dev <at> lists.linuxfoundation.org> wrote:
Hello,

I have been reading an argument saying that paying higher fees would scare Bitcoin users and they would stop using it, preferring bank transfers or other payment methods. This does not make sense for me. If some users leave, then demand for bitcoin transactions goes down and so do the fees. The others remain.

Fee market means that an equilibrium is found between the demand for bitcoin transactions and the available supply (given by the block size). The fee is the price that finds this equilibrium.

If a fee market starts to exist, the first ones to leave are the spammers, probably followed by the gamblers and perhaps people transacting very low amounts. The people that actually need Bitcoin would remain.

Please allow this fee market to form...

In the absence of a functioning fee market, I will refuse to run Bitcoin code that increases the block size and will do my best to tell everyone I know not to upgrade towards running such code. If Bitcoin succombs to the free stuff army, I will sell all the coins and leave. Nothing is for free.

I apologize for any exagerations, but I just felt strongly towards expressing my opinion here. I'm only a local Bitcoin trader, computer engineer, with a reasonable understanding of free markets. And I'm running only one full node.

Kind regards,
Valentin


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Vali Zero via bitcoin-dev | 29 Jul 15:27 2015

Personal opinion on the fee market from a worried local trader

Hello,

I have been reading an argument saying that paying higher fees would scare Bitcoin users and they would stop using it, preferring bank transfers or other payment methods. This does not make sense for me. If some users leave, then demand for bitcoin transactions goes down and so do the fees. The others remain.

Fee market means that an equilibrium is found between the demand for bitcoin transactions and the available supply (given by the block size). The fee is the price that finds this equilibrium.

If a fee market starts to exist, the first ones to leave are the spammers, probably followed by the gamblers and perhaps people transacting very low amounts. The people that actually need Bitcoin would remain.

Please allow this fee market to form...

In the absence of a functioning fee market, I will refuse to run Bitcoin code that increases the block size and will do my best to tell everyone I know not to upgrade towards running such code. If Bitcoin succombs to the free stuff army, I will sell all the coins and leave. Nothing is for free.

I apologize for any exagerations, but I just felt strongly towards expressing my opinion here. I'm only a local Bitcoin trader, computer engineer, with a reasonable understanding of free markets. And I'm running only one full node.

Kind regards,
Valentin

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Why Satoshi's temporary anti-spam measure isn't temporary

I only got into Bitcoin in 2011, after the block size limit was already in place. After going through some
more of the early history of Bitcoin to better understand the origins of this, things are starting to come
into better perspective.

Initially there was no block size limit - it was thought that the fee market would naturally develop and
would impose economic constraints on growth. But this hypothesis failed after a sudden influx of new
uses. It was still too easy to attack the network. This idea had to wait until the network was more mature to
handle things.

Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then
increase it once we see how things work. So far so good…

Except…well:

1) We never really got to test things out…a fee market never really got created, we never got to see how fees
would really work in practice.

2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do
not get compensated…validation cost is externalized to the entire network.

3) Miners don’t even properly validate blocks. And the bigger the blocks get, the greater the propensity
to skip this step. Oops!

4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs
for their transactions never materialized.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Gmane