Raystonn . [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-05-08 to 2021-05-22
💬 Posted a total of 32 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub18e464uqlzh9e8qm5dmnurg39za2s9t9uxg608eppvzkhr5q3uzfqg20rmx

Profile Code

nprofile1qqsru6a27q03tjunsd6xae7p5gj3w4gz4j7ryd8nusskptt36qg7pyspzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgjpx8pv

Publishing to

relay.nostr.band

Author Public Key

npub18e464uqlzh9e8qm5dmnurg39za2s9t9uxg608eppvzkhr5q3uzfqg20rmx

Show more details

Last Notes

2023-06-07 22:53:51

- reply

📅 Original date posted:2021-05-22
📝 Original message:None of these required a hard fork. I should rephrase my previous email to clarify the intended topic as hard consensus changes, requiring a hard fork. "Soft" forks can be useful.
Raystonn
________________________________
From: Jorge Timón <jtimon at jtimon.cc>
Sent: Saturday, May 22, 2021 7:55 AM
To: Raystonn . <raystonn at hotmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus protocol immutability is a feature
That is clearly not true. People entretain making changes to the protocol all the time. Bitcoin is far from perfect and not improving it would be stupid in my opinion.
Some improvements require changes to the consensus rules.
Recent changes include relative lock time verify or segwit. These are important changes that made things like lightning much easier and efficient than they could possibly be without them.
Taproot, which is a recent proposal, could help simplify the lightning protocol even further, and make it more efficient and its usage more private. And there are more use cases.
There have been consensus rule changes since bitcoin started, and with good reason. As a user, you can always oppose new changes. And if enough users agree with you, you will be able to maintain your own chain with the old rules. At the same time, there's nothing you can do to stop other users who want those changes from coordinating with each other to adopt them.
Perhaps you're interested in bip99, which discusses consensus rule changes in more detail.
On Sat, May 22, 2021, 13:09 Raystonn . via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
Suggestions to make changes to Bitcoin's consensus protocol will only ever be entertained if Bitcoin is completely dead without such a change. Any attempt to change consensus protocol without a clear and convincing demonstration to the entire network of participants that Bitcoin will die without that change is a waste of your own time. Bitcoin's resistance to consensus changes is a feature that makes it resistant to being coopted and corrupted. I recommend developers focus on making improvements that do not attempt to change the consensus protocol. Otherwise, you are simply working on an altcoin, which is off-topic here.
Raystonn
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210522/2047b810/attachment-0001.html>

2023-06-07 22:53:50

- reply

📅 Original date posted:2021-05-21
📝 Original message:Suggestions to make changes to Bitcoin's consensus protocol will only ever be entertained if Bitcoin is completely dead without such a change. Any attempt to change consensus protocol without a clear and convincing demonstration to the entire network of participants that Bitcoin will die without that change is a waste of your own time. Bitcoin's resistance to consensus changes is a feature that makes it resistant to being coopted and corrupted. I recommend developers focus on making improvements that do not attempt to change the consensus protocol. Otherwise, you are simply working on an altcoin, which is off-topic here.
Raystonn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210521/c4f8d8b0/attachment.html>

2023-06-07 18:01:03

- reply

📅 Original date posted:2017-05-09
📝 Original message:This study was released last week, detailing some attacks at the network layer: https://btc-hijack.ethz.ch/files/btc_hijack.pdf. Of the countermeasures discussed in the paper, the use of encryption to secure communications between nodes looks like low hanging fruit.
Raystonn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/6ad5633b/attachment.html>

2023-06-07 17:59:27

- reply

📅 Original date posted:2017-04-06
📝 Original message:Great catch, and a good proposal for a fix. Pushing the activation height out to allow existing hardware to enter obsolescence prior to activation may help reduce miner resistance. It may also avoid legal threats from those currently abusing. If miners still resist, the threat of an earlier activation height is a good negotiating tool.
Raystonn
On 5 Apr 2017 2:39 p.m., Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which
is exploited by ASICBOOST and the various steps which could be used to
block it in the network if it became a problem.
While most discussion of ASICBOOST has focused on the overt method
of implementing it, there also exists a covert method for using it.
As I explained one of the approaches to inhibit covert ASICBOOST I
realized that my words were pretty much also describing the SegWit
commitment structure.
The authors of the SegWit proposal made a specific effort to not be
incompatible with any mining system and, in particular, changed the
design at one point to accommodate mining chips with forced payout
addresses.
Had there been awareness of exploitation of this attack an effort
would have been made to avoid incompatibility-- simply to separate
concerns. But the best methods of implementing the covert attack
are significantly incompatible with virtually any method of
extending Bitcoin's transaction capabilities; with the notable
exception of extension blocks (which have their own problems).
An incompatibility would go a long way to explain some of the
more inexplicable behavior from some parties in the mining
ecosystem so I began looking for supporting evidence.
Reverse engineering of a particular mining chip has demonstrated
conclusively that ASICBOOST has been implemented
in hardware.
On that basis, I offer the following BIP draft for discussion.
This proposal does not prevent the attack in general, but only
inhibits covert forms of it which are incompatible with
improvements to the Bitcoin protocol.
I hope that even those of us who would strongly prefer that
ASICBOOST be blocked completely can come together to support
a protective measure that separates concerns by inhibiting
the covert use of it that potentially blocks protocol improvements.
The specific activation height is something I currently don't have
a strong opinion, so I've left it unspecified for the moment.
<pre>
BIP: TBD
Layer: Consensus
Title: Inhibiting a covert attack on the Bitcoin POW function
Author: Greg Maxwell <greg at xiph.org>
Status: Draft
Type: Standards Track
Created: 2016-04-05
License: PD
</pre>
==Abstract==
This proposal inhibits the covert exploitation of a known
vulnerability in Bitcoin Proof of Work function.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
==Motivation==
Due to a design oversight the Bitcoin proof of work function has a potential
attack which can allow an attacking miner to save up-to 30% of their energy
costs (though closer to 20% is more likely due to implementation overheads).
Timo Hanke and Sergio Demian Lerner claim to hold a patent on this attack,
which they have so far not licensed for free and open use by the public.
They have been marketing their patent licenses under the trade-name
ASICBOOST. The document takes no position on the validity or enforceability
of the patent.
There are two major ways of exploiting the underlying vulnerability: One
obvious way which is highly detectable and is not in use on the network
today and a covert way which has significant interaction and potential
interference with the Bitcoin protocol. The covert mechanism is not
easily detected except through its interference with the protocol.
In particular, the protocol interactions of the covert method can block the
implementation of virtuous improvements such as segregated witness.
Exploitation of this vulnerability could result in payoff of as much as
$100 million USD per year at the time this was written (Assuming at
50% hash-power miner was gaining a 30% power advantage and that mining
was otherwise at profit equilibrium). This could have a phenomenal
centralizing effect by pushing mining out of profitability for all
other participants, and the income from secretly using this
optimization could be abused to significantly distort the Bitcoin
ecosystem in order to preserve the advantage.
Reverse engineering of a mining ASIC from a major manufacture has
revealed that it contains an undocumented, undisclosed ability
to make use of this attack. (The parties claiming to hold a
patent on this technique were completely unaware of this use.)
On the above basis the potential for covert exploitation of this
vulnerability and the resulting inequality in the mining process
and interference with useful improvements presents a clear and
present danger to the Bitcoin system which requires a response.
==Background==
The general idea of this attack is that SHA2-256 is a merkle damgard hash
function which consumes 64 bytes of data at a time.
The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while
incriminating a 32-bit nonce which is at the end of this header data. This
means that the processing of the header involves two runs of the compression
function run-- one that consumes the first 64 bytes of the header and a
second which processes the remaining 16 bytes and padding.
The initial 'message expansion' operations in each step of the SHA2-256
function operate exclusively on that step's 64-bytes of input with no
influence from prior data that entered the hash.
Because of this if a miner is able to prepare a block header with
multiple distinct first 64-byte chunks but identical 16-byte
second chunks they can reuse the computation of the initial
expansion for multiple trials. This reduces power consumption.
There are two broad ways of making use of this attack. The obvious
way is to try candidates with different version numbers. Beyond
upsetting the soft-fork detection logic in Bitcoin nodes this has
little negative effect but it is highly conspicuous and easily
blocked.
The other method is based on the fact that the merkle root
committing to the transactions is contained in the first 64-bytes
except for the last 4 bytes of it. If the miner finds multiple
candidate root values which have the same final 32-bit then they
can use the attack.
To find multiple roots with the same trailing 32-bits the miner can
use efficient collision finding mechanism which will find a match
with as little as 2^16 candidate roots expected, 2^24 operations to
find a 4-way hit, though low memory approaches require more
computation.
An obvious way to generate different candidates is to grind the
coinbase extra-nonce but for non-empty blocks each attempt will
require 13 or so additional sha2 runs which is very inefficient.
This inefficiency can be avoided by computing a sqrt number of
candidates of the left side of the hash tree (e.g. using extra
nonce grinding) then an additional sqrt number of candidates of
the right side of the tree using transaction permutation or
substitution of a small number of transactions. All combinations
of the left and right side are then combined with only a single
hashing operation virtually eliminating all tree related
overhead.
With this final optimization finding a 4-way collision with a
moderate amount of memory requires ~2^24 hashing operations
instead of the >2^28 operations that would be require for
extra-nonce grinding which would substantially erode the
benefit of the attack.
It is this final optimization which this proposal blocks.
==New consensus rule==
Beginning block X and until block Y the coinbase transaction of
each block MUST either contain a BIP-141 segwit commitment or a
correct WTXID commitment with ID 0xaa21a9ef.
(See BIP-141 "Commitment structure" for details)
Existing segwit using miners are automatically compatible with
this proposal. Non-segwit miners can become compatible by simply
including an additional output matching a default commitment
value returned as part of getblocktemplate.
Miners SHOULD NOT automatically discontinue the commitment
at the expiration height.
==Discussion==
The commitment in the left side of the tree to all transactions
in the right side completely prevents the final sqrt speedup.
A stronger inhibition of the covert attack in the form of
requiring the least significant bits of the block timestamp
to be equal to a hash of the first 64-bytes of the header. This
would increase the collision space from 32 to 40 or more bits.
The root value could be required to meet a specific hash prefix
requirement in order to increase the computational work required
to try candidate roots. These change would be more disruptive and
there is no reason to believe that it is currently necessary.
The proposed rule automatically sunsets. If it is no longer needed
due to the introduction of stronger rules or the acceptance of the
version-grinding form then there would be no reason to continue
with this requirement. If it is still useful at the expiration
time the rule can simply be extended with a new softfork that
sets longer date ranges.
This sun-setting avoids the accumulation of technical debt due
to retaining enforcement of this rule when it is no longer needed
without requiring a hard fork to remove it.
== Overt attack ==
The non-covert form can be trivially blocked by requiring that
the header version match the coinbase transaction version.
This proposal does not include this block because this method
may become generally available without restriction in the future,
does not generally interfere with improvements in the protocol,
and because it is so easily detected that it could be blocked if
it becomes an issue in the future.
==Backward compatibility==
==Implementation==
==Acknowledgments==
==Copyright==
This document is placed in the public domain.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/d0ae8901/attachment-0001.html>

2023-06-07 17:58:26

- reply

📅 Original date posted:2017-03-29
📝 Original message:Low node costs are a good goal for nodes that handle transactions the node operator can afford. Nobody is going to run a node for a network they do not use for their own transactions. If transactions have fees that prohibit use for most economic activity, that means node count will drop until nodes are generally run by those who settle large amounts. That is very centralizing.
Raystonn
On 29 Mar 2017 12:14 p.m., Jared Lee Richardson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
In order for any blocksize increase to be agreed upon, more consensus is needed. The proportion of users believing no blocksize increases are needed is larger than the hardfork target core wants(95% consensus). The proportion of users believing in microtransactions for all is also larger than 5%, and both of those groups may be larger than 10% respectively. I don't think either the Big-blocks faction nor the low-node-costs faction have even a simple majority of support. Getting consensus is going to be a big mess, but it is critical that it is done.
On Wed, Mar 29, 2017 at 12:49 AM, Martin Lízner via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
If there should be a hard-fork, Core team should author the code. Other dev teams have marginal support among all BTC users.
Im tending to believe, that HF is necessary evil now. But lets do it in conservative approach:
- Fix historical BTC issues, improve code
- Plan HF activation date well ahead - 12 months+
- Allow increasing block size on year-year basis as Luke suggested
- Compromise with miners on initial block size bump (e.g. 2MB)
- SegWit
Martin Lizner
On Tue, Mar 28, 2017 at 6:59 PM, Wang Chun via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
I've proposed this hard fork approach last year in Hong Kong Consensus
but immediately rejected by coredevs at that meeting, after more than
one year it seems that lots of people haven't heard of it. So I would
post this here again for comment.
The basic idea is, as many of us agree, hard fork is risky and should
be well prepared. We need a long time to deploy it.
Despite spam tx on the network, the block capacity is approaching its
limit, and we must think ahead. Shall we code a patch right now, to
remove the block size limit of 1MB, but not activate it until far in
the future. I would propose to remove the 1MB limit at the next block
halving in spring 2020, only limit the block size to 32MiB which is
the maximum size the current p2p protocol allows. This patch must be
in the immediate next release of Bitcoin Core.
With this patch in core's next release, Bitcoin works just as before,
no fork will ever occur, until spring 2020. But everyone knows there
will be a fork scheduled. Third party services, libraries, wallets and
exchanges will have enough time to prepare for it over the next three
years.
We don't yet have an agreement on how to increase the block size
limit. There have been many proposals over the past years, like
BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
on. These hard fork proposals, with this patch already in Core's
release, they all become soft fork. We'll have enough time to discuss
all these proposals and decide which one to go. Take an example, if we
choose to fork to only 2MB, since 32MiB already scheduled, reduce it
from 32MiB to 2MB will be a soft fork.
Anyway, we must code something right now, before it becomes too late.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/c46dcb07/attachment-0001.html>

2023-06-07 15:44:05

- reply

📅 Original date posted:2015-07-29
📝 Original message:> When a category of users would get priced out because of the fee market, they would be free to use any altcoin they want.
I believe that pretty well sums up where we’re headed if transaction rate is artificially limited, whether that be by maximum block size limit or something else. A fee market will necessarily include more than just Bitcoin. The reality is it’s very easy to trade value across different blockchains, and thus a fee market will bleed value from Bitcoin and give it to alternative blockchains. If Bitcoin’s blocks are at maximum capacity, people will exchange for something that allows them to transact with a lesser fee, then make the desired payment. This adds value to the alternative blockchain and removes it from Bitcoin.
Anyone thinking the fee market can be restrained to Bitcoin alone is mistaken.
From: Vali Zero via bitcoin-dev
Sent: Wednesday, July 29, 2015 7:09 AM
To: bitcoin-dev at lists.linuxfoundation.org
Subject: [bitcoin-dev] 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.
http://twitter.com/gubatron
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/b16f0d17/attachment.html>

2023-06-07 15:44:04

- reply

📅 Original date posted:2015-07-29
📝 Original message:All of the properties you describe are also properties of many of the
alternative blockchains that currently exist. In this space, Bitcoin gives
up these advantages. Much like anywhere else where liquidity moves within a
system, value will move to the network of least friction. The reality right
now is it's very easy to move value from Bitcoin to another blockchain with
less friction. Because of this, there will never be a high value settlement
network created by an artificially imposed limit on transaction rate. The
value will simply bleed out of Bitcoin to alternative blockchains offering
lower fees if this is attempted. This is basic economics.
-----Original Message-----
From: Owen via bitcoin-dev
Sent: Wednesday, July 29, 2015 12:56 PM
To: Bitcoin Dev
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measureisn't
temporary
On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev:
>Consider this: the highest Bitcoin tx fees can possibly go is perhaps
>a
>little higher than what our competition charges. Too much higher than
>that,
>and people will just say, you know what .... I'll make a bank transfer.
>It's cheaper and not much slower, sometimes no slower at all.
I respectfully disagree with this analysis. The implication is that bitcoin
is merely one of a number of payment technologies. It's much more than that.
It's sound money, censorship resistance, personal control over money,
programmable money, and more. Without these attributes it's merely a really
inefficient way to do payments.
Given these advantages, there is no reason to believe the marginal cost of a
transaction can't far surpass that of a PayPal or bank transfer. I
personally would pay several multiples of the competitors' fees to continue
using bitcoin.
Sure, some marginal use cases will drop off with greater fees, but that's
normal and expected. These will be use cases where the user doesn't care
about bitcoin's advantages. We must be willing to let these use cases go
anyway, because we unfortunately don't have room on chain for everything
anyone might want to do.
Therefore, bitcoin tx fees can go much higher than the competition.
Remember how Satoshi referenced the banking crisis in his early work? The
2008 banking crisis was about a lot of things, but high credit card and
paypal fees wasnt one of them. There's more going on here than just
payments. Any speculative economic analysis would do better to include this
fact.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:43:56

- reply

📅 Original date posted:2015-07-29
📝 Original message:Gregory, can you please speak to the following points. I would like a
better understanding of your positions.
1) Do you believe that Bitcoin's future is as a high-value settlement
network?
2) Do you believe we need an artificial limit to transaction rate, perhaps
implemented as a maximum block size limit? If so, why?
3) Transaction fees will fluctuate with global economic conditions and
technology. Those free-market fluctuations should equally affect any
blockchain. However, if transaction fees on the Bitcoin network are pushed
artificially high, such as with an artificial limit to transaction rate only
applicable to Bitcoin, this will create a condition where some other
blockchains will have lower fees. How do you plan to address the bleeding
of value from Bitcoin to alternative lower-fee blockchains created by the
artificially-high bitcoin transaction fees when users begin looking for the
cheapest way to send value? Modern economic study has shown that liquidity
moves to the location of least friction.
4) If you believe it's not a problem to allow alternative blockchains to
leech some of Bitcoin's value, then:
a) How much value is it acceptable to lose?
b) How do you think this will affect Bitcoin miners, whose large
investments in hardware do not transfer to other blockchains?
c) How do you think this will affect the investors and holders of
bitcoin in general?
-----Original Message-----
From: Gregory Maxwell via bitcoin-dev
Sent: Wednesday, July 29, 2015 1:09 PM
To: Owen
Cc: Bitcoin Dev
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary
On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev:
>>Consider this: the highest Bitcoin tx fees can possibly go is perhaps
>>a
>>little higher than what our competition charges. Too much higher than
>>that,
>>and people will just say, you know what .... I'll make a bank transfer.
>>It's cheaper and not much slower, sometimes no slower at all.
>
> I respectfully disagree with this analysis. The implication is that
> bitcoin is merely one of a number of payment technologies. It's much more
> than that. It's sound money, censorship resistance, personal control over
> money, programmable money, and more. Without these attributes it's merely
> a really inefficient way to do payments.
>
> Given these advantages, there is no reason to believe the marginal cost of
> a transaction can't far surpass that of a PayPal or bank transfer. I
> personally would pay several multiples of the competitors' fees to
> continue using bitcoin.
>
> Sure, some marginal use cases will drop off with greater fees, but that's
> normal and expected. These will be use cases where the user doesn't care
> about bitcoin's advantages. We must be willing to let these use cases go
> anyway, because we unfortunately don't have room on chain for everything
> anyone might want to do.
>
> Therefore, bitcoin tx fees can go much higher than the competition.
>
> Remember how Satoshi referenced the banking crisis in his early work? The
> 2008 banking crisis was about a lot of things, but high credit card and
> paypal fees wasnt one of them. There's more going on here than just
> payments. Any speculative economic analysis would do better to include
> this fact.
Precisely. And as "just a payment system" Bitcoin is not an
especially great one: The design requirements for decenteralization
impose considerable costs. To the extent that the technology in
Bitcoin is useful at all for building "just another payment system"
this technology in in the process of being agressively copied by
parties with deep fiat relationships (including in partnership with
centeral banks). If the focus for Bitcoin's competative advantage
becomes exclusively "better" payments then it will almost certinatly
fail in the market-place against competing systems which avoid the
Bitcoin currency adoption related obsticles (but also gain none of
Bitcoin's important social/political promise).
Also, critically, if Bitcoin's security properties are manintained and
enhanced then Bitcoin can be used to build secure systems which _also_
accomidate those applications and we can have both. But if Bitcoin's
security properties are not strong then then advanced tools cannot be
built for it. E.g. atomic swaps make trustless trades with external
systems possible; but they are especially sensitive to long
reorginizations by miners... so they can only be securely used where
those reorgs are infeasable. So while I agree that we must be willing
to tolerate not catching every conceivable use case; most of the time
all that means is addressing them via a less direct but more focused
solution rather than ignoring them completely.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:43:56

- reply

📅 Original date posted:2015-07-29
📝 Original message:> Cheapest way to send value? Is this what Bitcoin is trying to do? So
> all of the smart contract, programmable money, consensus coding and
> tremendous developer effort is bent to the consumer demand for cheaper
> fees. Surely thou jests!
These other features can be replicated into any alternative blockchain,
including those with lower fees. In the open-source world of
cryptocurrency, no feature will remain a value-add for very long after it
has been identified to be such. Anything adding value will quickly be
absorbed into competing alternative blockchains. That will leave economic
policy as the distinguishing factor.
> ... it is not the case ... that reluctance to concede
> blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
> explained in this thread that the protocol's current state of
> development relies on blocksize for security and, ultimately, as a
> means of protecting its degree of decentralization.
A slow or lack of increase to maximum transaction rate will cause pressure
on fees. Whether this is the desired goal is not relevant. Everyone has
agreed this will be the outcome. As to a smaller block size being needed
for additional decentralization, one must simply ask how much we are all
willing to pay for that additional decentralization. It is likely that the
benefit thereto will have to be demonstrated by some power attacking and
destroying a less decentralized currency before the benefit of this feature
is given monetary value by the market. Until then, value will bleed to the
network with the least friction, because it will have the greatest ability
to grow its network effect. That means the blockchain with adequate
features and cheapest fees will eventually have the largest market share.
-----Original Message-----
From: Venzen Khaosan
Sent: Wednesday, July 29, 2015 3:11 PM
To: Raystonn .
Cc: bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raystonn, I'm aware that you're addressing your question to Greg
Maxwell, however a point you keep stating as fact calls for reference:
On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
[snip]
> How do you plan to address the bleeding of value from Bitcoin to
> alternative lower-fee blockchains created by the artificially-high
> bitcoin transaction fees when users begin looking for the cheapest
> way to send value?
Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!
> Modern economic study has shown that liquidity moves to the
> location of least friction.
Modern economic study? Can you please provide a link or reference to
the study you are referring to.
"liquidity moves to the location of least friction"
This sounds like "econo-speak" and makes no sense. The definition of
Liquidity is the degree to which an asset/security can be bought or
sold in the market without affecting the price.
That is why bitcoin is said to have low liquidity: buying or selling
only 100 BTC visibly affects the exchange price. You probably mean
"people like cheap fees", which is true, but as others have said,
because of Bitcoin's powerful features, they are willing to pay higher
fees and wait longer for transactions to execute.
As for your public cross-examination of Greg Maxwell, your case seems
to be made on the assumption that limiting the size of the blockchain
is an attempt to artificially raise tx fees, but it is not the case
(as you and others repeatedly argue) that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.
Surely, this is an obvious concern even for those who are campaigning
for the hare-brained ideal of making Bitcoin a "faster, cheaper
alternative" to visa or paypal? If we lose decentralization, we lose
the whole thing, right? Incorrect or correct?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
=lQvy
-----END PGP SIGNATURE-----

2023-06-07 15:43:55

- reply

📅 Original date posted:2015-07-29
📝 Original message:Eric, any plans to correct your article at https://bitcoinmagazine.com/21377/settling-block-size-debate/?
From: Mike Hearn via bitcoin-dev
Sent: Wednesday, July 29, 2015 4:15 AM
To: Eric Lombrozo
Cc: Bitcoin Dev
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
Irrelevant what term was used - and as brilliant as Satoshi might have been at some things, he obviously got this one wrong.
I don't think it's obvious. You may disagree, but don't pretend any of this stuff is obvious.
Consider this: the highest Bitcoin tx fees can possibly go is perhaps a little higher than what our competition charges. Too much higher than that, and people will just say, you know what .... I'll make a bank transfer. It's cheaper and not much slower, sometimes no slower at all.
And now consider that in many parts of the world bank transfers are free.
They aren't actually free, of course, but they appear to be free because the infrastructure for doing them is cross subsidised by the fees on other products and services, or hidden in the prices of goods sold.
So that's a market reality Bitcoin has to handle. It's already more expensive than the competition sometimes, but luckily not much more, and anyway Bitcoin has some features those other systems lack (and vice versa). So it can still be competitive.
But your extremely vague notion of a "fee market" neglects to consider that it already exists, and it's not a market of "Bitcoin users buying space in Bitcoin blocks". It's "users paying to move money".
You can argue with this sort of economic logic if you like, but don't claim this stuff is obvious.
Nobody threatened to start mining huge blocks given how relatively inexpensive it was to mine back then?
Not that I recall. It wasn't a response to any actual event, I think, but rather a growing realisation that the code was full of DoS attacks.
Guess what? SPV wallets are still not particularly widespread…and those that are out there are notoriously terrible at detecting network forks and making sure they are on the right one.
The most popular mobile wallet (measured by installs) on Android is SPV. It has between 500,000 and 1 million installs, whilst Coinbase has not yet crossed the 500,000 mark. One of the most popular wallets on iOS is SPV. If we had SPV wallets with better user interfaces on desktops, they'd be more popular there too (perhaps MultiBit HD can recapture some lost ground).
So I would argue that they are in fact very widespread.
Likewise, they are not "notoriously terrible" at detecting chain forks. That's a spurious idea that you and Patrick have been pushing lately, but they detect them and follow reorgs across them according to the SPV algorithm, which is based on most work done. This is exactly what they are designed to do.
Contrast this with other lightweight wallets which either don't examine the block chain or implement the algorithm incorrectly, and I fail to see how this can be described as "notoriously terrible".
I understand that initially it was desirable that transactions be free…but surely even Satoshi understood this couldn’t be perpetually self-sustaining…and that the ability to bid for inclusion in blocks would eventually become a crucial component of the network. Or were fees just added for decoration?
Fees were added as a way to get money to miners in a fair and decentralised way.
Attaching fees directly to all transactions is certainly one way to use that, but it's not the only way. As noted above, our competitors prefer a combination of price-hiding and cross subsidisation. Both of these can be implemented with tx fees, but not necessarily by trying to artificially limit supply, which is economically nonsensical.
We’re already more than six years into this. When were these mechanisms going to be developed and tested? After 10 years? 20? Perhaps after 1024 years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki)
Maybe when there is a need? I already discussed this topic of need here:
https://medium.com/@octskyward/hashing-7d04a887acc8
Right. Turns out the ledger structure is terrible for constructing the kinds of proofs that are most important to validators - i.e. whether an output exists, what its script and amounts are, whether it’s been spent, etc…
Validators don't require proofs. That's why they are validators.
I think you're trying to say the block chain doesn't provide the kinds of proofs that are most important to lightweight wallets. But I would disagree. Even with UTXO commitments, there can still be double spends out there in the networks memory pools you are unaware of. Merely being presented with a correctly signed transaction doesn't tell you a whole lot ..... if you wait for a block, you get the same level of proof regardless of whether there are UTXO commitments or not. If you don't then you still have to have some trust in your peers that you are seeing an accurate and full view of network traffic.
So whilst there are ways to make the protocol incrementally better, when you work through the use cases for these sorts of data structures and ask "how will this impact the user experience", the primary candidates so far don't seem to make much difference.
Remote attestation from secure hardware would make a big difference though. Then you could get rid of the waiting times entirely because you know the sending wallet won't double spend.
Yes, let’s wait until things are about to break before even beginning to address the issue…because we can “easily create” anything we haven’t invented yet at the last minute.
bitcoinj already has a micropayment channel implementation in it. There's a bit of work required to glue everything together, but it's not a massive project to start using this to pay nodes for their services.
But it's not needed right now: serving these clients is so darn cheap. And there is plenty of room for optimising things still further!
I’m one of the very few developers in this space that has actually tried *hard* to make your BIP37 work. Amongst the desktop wallets listed on bitcoin.org, there are only two that have always supported SPV (or at least I think MultiBit has always supported it, perhaps I’m wrong). One is MultiBit, the other one is mine. I give you credit for your work…perhaps you could be generous enough to extend me some credit too?
MultiBit has always supported it. I apologise for implying you have not built a wallet. I think yours is mSIGNA, right? Did it used to be called something else? I recognise the website design but must admit, I have not heard of mSIGNA before.
Regardless, as a fellow implementor, I would appreciate it more if you designed and implemented upgrades, rather than just trashing the work done so far as "notoriously terrible", Satoshi as "not a systems architect" and so on.
--------------------------------------------------------------------------------
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/dd6da285/attachment.html>

2023-06-07 15:43:12

- reply

📅 Original date posted:2015-07-23
📝 Original message:There is now a pull request to remove mention of "zero or low fees", "fast
international payments", and "instant peer-to-peer transactions" from
bitcoin.org. For those non-technical users who do not read source code,
this may come across as the breaking of the social contract on what Bitcoin
is ultimately intended to be. It looks like we already have a Reddit post
on the subject as well.
Raystonn

2023-06-07 15:40:54

- reply

📅 Original date posted:2015-06-28
📝 Original message:Write coalescing works fine when you have multiple writes headed to the same
(contiguous) location. Will lightning be useful when we have more unique
transactions being sent to different addresses, and not just multiple
transactions between the same sender and address? I have doubts.
-----Original Message-----
From: Adam Back
Sent: Sunday, June 28, 2015 5:37 AM
To: Benjamin
Cc: bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
On 28 June 2015 at 12:29, Benjamin <benjamin.l.cordes at gmail.com> wrote:
> I agree that naive scaling will likely lead to bad outcomes. They might
> have
> the advantage though, as this would mean not changing Bitcoin.
Sure we can work incrementally and carefully, and this is exactly what
Bitcoin has been doing, and *must* do for safety and security for the
last 5 years!
That doesnt mean that useful serious improvements have not been made.
> Level2 and Lightning is not well defined. If you move money to a third
> party, even if it is within the constrained of a locked contract, then I
> don't think that will solve the issues.
I think you misunderstand how lightning works. Every lightning
transaction *is* a valid bitcoin transaction that could be posted to
the Bitcoin network to reclaim funds if a hub went permanently
offline. It is just that while the hubs involved remain in service,
there is no need to do so. This is why it has been described as a
(write coalescing) write cache layer for Bitcoin.>
I believe people expect lightning to be peer 2 peer like bitcoin.
Adam
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:38:22

- reply

📅 Original date posted:2015-06-15
📝 Original message:http://xtnodes.com/
From: Brian Hoffman
Sent: Monday, June 15, 2015 3:56 PM
To: Faiz Khan
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork
Who is actually planning to move to Bitcoin-XT if this happens?
Just Gavin and Mike?
On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00 at gmail.com> wrote:
I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork:
"How do you plan to deal with security & incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control?"
I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)...
That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused.
Faiz
On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure at gmail.com> wrote:
On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike at plan99.net> wrote:
Re: anyone who agrees with noted non-programmers Mike&Gavin must be non-technical, stupid, uninformed, etc .... OK, go ahead and show them the error of their ways. Anyone can write blogs.
I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean "Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer". Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike.
- Bryan
http://heybryan.org/
1 512 203 0507
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
My regards,
Faiz Khan
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/5fad1561/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.JPG
Type: image/jpeg
Size: 22107 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/5fad1561/attachment.jpe>

2023-06-07 15:38:04

- reply

📅 Original date posted:2015-06-15
📝 Original message:I am only partially through the content at the below link, and I am very impressed. Has Justus Ranvier began work on implementation of the ideas contained therein?
From: sickpig at gmail.com
Sent: Monday, June 15, 2015 12:18 PM
To: Raystonn .
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] The Bitcoin Node Market
Sorry for top posting and the brevity but I'm typing from my phone
You shoud be interested in this post by Justus Ranvier then:
https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
On Jun 15, 2015 8:57 PM, "Raystonn ." <raystonn at hotmail.com> wrote:
I have been toying with an idea and figured I'd run it by everyone here
before investing further time in it. The goal here is to make it
sustainable, and perhaps profitable, to run full nodes on the Bitcoin
Network in the long term.
- Nodes can participate in a market wherein they are paid by nodes, wallets,
and other services to supply Bitcoin Network data. Payment should be based
on the cost imposed on the Node to do the work and send the data, but can be
set in any way the node operator desires. It's a free market.
- Nodes that are mostly leeching data from the Bitcoin Network, such as
those that do not receive inbound connections to port 8333, will send
payments to the nodes they connect to, but will likely receive no payments
from other nodes, wallets, and other services.
- Nodes that are providing balanced full service to the Bitcoin Network will
tend to have a balance of payments coming in and going out with regards to
other balanced full service nodes, leaving them revenue neutral there. But
they will receive payments from leech nodes, wallets, and other services.
The net effect here is that the cost to run nodes will be shared by those
who are using the Bitcoin network but not contributing by running a full
node. A market will develop for fees to connect to the Bitcoin Network
which should help cover the cost of running the Network. It's still
possible to continue offering access to your node for free as there is
nothing forcing you to charge a fee. But this isn't very sustainable
long-run. Market efficiencies should eventually mean nodes take in only
what is required to keep the Network operational.
Raystonn
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/9cdea836/attachment.html>

2023-06-07 15:38:03

- reply

📅 Original date posted:2015-06-15
📝 Original message:I have been toying with an idea and figured I'd run it by everyone here
before investing further time in it. The goal here is to make it
sustainable, and perhaps profitable, to run full nodes on the Bitcoin
Network in the long term.
- Nodes can participate in a market wherein they are paid by nodes, wallets,
and other services to supply Bitcoin Network data. Payment should be based
on the cost imposed on the Node to do the work and send the data, but can be
set in any way the node operator desires. It's a free market.
- Nodes that are mostly leeching data from the Bitcoin Network, such as
those that do not receive inbound connections to port 8333, will send
payments to the nodes they connect to, but will likely receive no payments
from other nodes, wallets, and other services.
- Nodes that are providing balanced full service to the Bitcoin Network will
tend to have a balance of payments coming in and going out with regards to
other balanced full service nodes, leaving them revenue neutral there. But
they will receive payments from leech nodes, wallets, and other services.
The net effect here is that the cost to run nodes will be shared by those
who are using the Bitcoin network but not contributing by running a full
node. A market will develop for fees to connect to the Bitcoin Network
which should help cover the cost of running the Network. It's still
possible to continue offering access to your node for free as there is
nothing forcing you to charge a fee. But this isn't very sustainable
long-run. Market efficiencies should eventually mean nodes take in only
what is required to keep the Network operational.
Raystonn

2023-06-07 15:38:00

- reply

📅 Original date posted:2015-06-15
📝 Original message:> The solution is to hard-fork and merge-mine. This way, both can live, and mining power is not divided.
No, this would essentially be blessing an increase to 42M bitcoins, half on each chain. You could expect a severe market price correction if this were to happen.
From: Rebroad (sourceforge)
Sent: Monday, June 15, 2015 4:16 AM
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] comments on BIP 100
My understanding of this debate is that there are some people who want to keep Bitcoin at 1MB block limit, and there are some who want to increase it.
I for one am curious to see how 1MB limited bitcoin evolves, and I believe we can all have a chance to see this AND hard-fork bitcoin to remove the block size restriction.
To remove the 1MB limit required a hard fork. This is not disputed. It's what we do with the original (1MB limit) bitcoin that concerns me (and other's I am sure).
What I would like to see is both being allowed to live. Harry Potter and Voldermort! (Except neither are evil!)
The solution is to hard-fork and merge-mine. This way, both can live, and mining power is not divided.
Dogecoin recently hardforked and this hardfork also involved switching to merge-mining, so it's been done successfully.
So, simply, bitcoin as it is doesn't need to actually fork, but instead, at a certain block size, a forked bitcoin with the blocksize lmit removed will start to be merge-mined alongside bitcoin. Miners can be ready for this. Wallets can be ready for this - in fact, for most wallets and merchants they will possibly want to default to the bigger blocksize fork since this caters for more transactions per block.
We still don't know how removing the block limit will pan out and what other problems with scalability will arise in the future, so by preserving the original bitcoin, we keep diversity, and people won't feel their investments in bitcoin are being unnecessarily put at risk (as their investments will stay in both the new and the old bitcoin).
The bitcoin core developers can implement a patch like the one recently used for dogecoin, to allow the chain to fork at a set point, where at which point, bitcoins will be split into the new and the old. Branding will be an important issue here I think, so that there is as little confusion as possible. I think this is a small price to pay in return for not killing the original bitcoin (even if it's true that Satoshi did intend to remove the 1MB limit at some point).
If I'm missing something obvious please let me know.
On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn <mike at plan99.net> wrote:
The fact that using a centralized service is easier isn't a good reason IMHO. It disregards the long-term, and introduces systemic risk.
Well sure, that's easy for you to say, but you have a salary :) Other developers may find the incremental benefits of decentralisation low vs adding additional features, for instance, and who is to say they are wrong?
But in cases where using a decentralized approach doesn't *add* anything, I cannot reasonably promote it, and that's why I was against getutxos in the P2P protocol.
It does add something though! It means, amongst other things, I can switch of all my servers, walk away for good, discard this Mike Hearn pseudonym I invented for Bitcoin and the app will still work :) Surely that is an important part of being decentralised?
It also means that as the underlying protocol evolves over time, getutxos can evolve along side it. P2P protocol gets encrypted/authenticated? Great, one more additional bit of security. If one day miners commit to UTXO sets, great, one more additional bit of security. When we start including input values in the signature hash, great ... one more step up in security.
Anyway, I didn't really want to reopen this debate. I just point out that third party services are quite happy to provide whatever developers need to build great apps, even if doing so fails to meet some kind of perfect cryptographic ideal. And that's why they're winning devs.
Now back to your regularly scheduled block size debates ...
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/aa747543/attachment.html>

2023-06-07 15:37:09

- reply

📅 Original date posted:2015-06-08
📝 Original message:> Bitcoin is a global consensus system - if you're (sic) bandwidth isn't
> sufficient to keep up you are not part of the consensus.
Bandwidth can be purchased. Infrastructure to handled increasing
transaction volume can be purchased. The very fees being paid by a spammer
will be used to increase the miners' ability to absorb even more fees. The
blocksize limit cannot respond in such a dynamic way to attacks. Miners
cannot buy a greater blocksize limit in response to a spammer that is paying
high fees to deny transaction confirmation to the rest of the planet in an
attempt to destroy the network. The blocksize limit is creating an attack
that can be maintained forever by any organization that can afford to fill
the blocks. This attack would get incredibly cheaper once the BTCUSD market
tanks in response to the lack of usability of the Bitcoin network, meaning
it would be a self-reinforcing attack that would likely destroy Bitcoin for
as long as an attacker wants to keep it up, or until you patch it to remove
the limit after-the-fact, which might be too little too late.
If this isn't fixed, I would expect to see it carried out at some point by
someone with a large short position in BTCUSD.
-----Original Message-----
From: Peter Todd
Sent: Monday, June 08, 2015 3:18 PM
To: Raystonn .
Cc: Patrick Mccorry (PGR) ; Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential
solution described: Dropped-transaction spam attack against the blocksize
limit
On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote:
> >There will always be a blocksize limit based on technological
> >considerations - the network has a finite bandwidth limit.
>
> A bandwidth limit is not the same as a blocksize limit. Bandwidth
> is unique to every individual. Miners in China have different
> bandwidth and connectivity than miners in the U.S., for example.
> But the block size limit is dictated for eveyone. They are not
> comparable.
Bitcoin is a global consensus system - if you're bandwidth isn't
sufficient to keep up you are not part of the consensus.
The blocksize limit *is* what determines the minimum bandwidth required
to stay in consensus.
> >Without a blocksize limit the attacker would just flood the
> >network until the bandwidth usage became so great that consensus
> >would fail, rendering Bitcoin both worthless, and insecure.
>
> No, with no blocksize limit, a spammer would would flood the network
> with transactions until they ran out of money. Meanwhile, everyone
> would jump on board trying to mine the blocks to collect the fees
> from the spammers. It could be one of the greatest transfers of
> wealth ever. Bitcoin infrastructure would build up to handle the
> required bandwidth, paid for by the very entity spamming the
> network. Bitcoin would flourish, growing wildly as long as the fees
> kept coming. This is antifragility at its best.
Again, in your scenario if the bandwidth consumed by those transactions
was sufficiently high, the network would collapse because consensus
would fail.
Why wouldn't that bandwidth be high enough to cause that collapse?
Because of the blocksize limit! (combined with an intelligent mempool
that increases the minimum fee/KB appropriately - we don't have that
yet)
> >The worst an attacker flooding the network with transactions with
> >a blocksize limit can do is raise costs, without harming security.
>
> No, at attacker flooding the network with transactions with a
> blocksize limit can keep their fees high enough that perhaps 1% of
> transactions coming from real end-users go through. At this point
> everyone would give up on Bitcoin as it would become completely
> unusable. The BTCUSD market would tank, making it even easier to
> pay the transaction fees to keep real transactions out of blocks, as
> it would continue to become cheaper and eventually cost-free to
> obtain the bitcoin fees through market purchase.
I already did the math for you on that: the maximum transaction fee
you'd see in that kind of attack is around $2.5 USD/tx. That definitely
is not high enough to make Bitcoin non-viable - I personally could
easily afford fees like that for about 90% of my transactions this year
by value, as I mainly use Bitcoin to get paid by my clients around the
world. In fact, just today O'Reilly paid $15 USD to send me a wire
transfer for expenses related to a conference I was invited too.
A much more realistic transaction flood scenario - one that didn't raise
serious questions about whether or not the attacker could afford to 51%
attack Bitcoin - would raise tx fees to something more like $0.25/tx

2023-06-07 15:37:08

- reply

📅 Original date posted:2015-06-08
📝 Original message:> There will always be a blocksize limit based on technological
> considerations - the network has a finite bandwidth limit.
A bandwidth limit is not the same as a blocksize limit. Bandwidth is unique
to every individual. Miners in China have different bandwidth and
connectivity than miners in the U.S., for example. But the block size limit
is dictated for eveyone. They are not comparable.
> Without a blocksize limit the attacker would just flood the network until
> the bandwidth usage became so great that consensus would fail, rendering
> Bitcoin both worthless, and insecure.
No, with no blocksize limit, a spammer would would flood the network with
transactions until they ran out of money. Meanwhile, everyone would jump on
board trying to mine the blocks to collect the fees from the spammers. It
could be one of the greatest transfers of wealth ever. Bitcoin
infrastructure would build up to handle the required bandwidth, paid for by
the very entity spamming the network. Bitcoin would flourish, growing
wildly as long as the fees kept coming. This is antifragility at its best.
> The worst an attacker flooding the network with transactions with a
> blocksize limit can do is raise costs, without harming security.
No, at attacker flooding the network with transactions with a blocksize
limit can keep their fees high enough that perhaps 1% of transactions coming
from real end-users go through. At this point everyone would give up on
Bitcoin as it would become completely unusable. The BTCUSD market would
tank, making it even easier to pay the transaction fees to keep real
transactions out of blocks, as it would continue to become cheaper and
eventually cost-free to obtain the bitcoin fees through market purchase.
-----Original Message-----
From: Peter Todd
Sent: Monday, June 08, 2015 2:44 PM
To: Raystonn .
Cc: Patrick Mccorry (PGR) ; Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential
solution described: Dropped-transaction spam attack against the blocksize
limit
On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote:
> > the attack would be expensive.
>
> For attacks being waged to destroy Bitcoin by filling all blocks with spam
> transactions, the attack succeeds when the attacker is well funded. This
> gives well-funded private and/or public entities the means to destroy
> Bitcoin if they desire. This is only true after the block size limit was
> implemented. Without the block size limit, the spam doesn’t harm Bitcoin.
> It simply enriches miners at the cost of the spammers, which is a nicely
> antifragile quality.
There will always be a blocksize limit based on technological
considerations - the network has a finite bandwidth limit.
Without a blocksize limit the attacker would just flood the network until
the bandwidth usage became so great that consensus would fail, rendering
Bitcoin both worthless, and insecure.
The worst an attacker flooding the network with transactions with a
blocksize limit can do is raise costs, without harming security. Keep in
mind, that at some point it'd be cheaper to just 51% attack the network.
Based on the current block subsidy of 25BTC/MB that's at the point where
transaction fees are 25mBTC/KB, which corresponds to <$2/tx fees - not that
cheap, but still quite affordable for a large percentage of Bitcoin's users
right now. And that's the *absolute worst-case* attack possible.

2023-06-07 15:37:08

- reply

📅 Original date posted:2015-06-08
📝 Original message:> the only way a transaction can be removed from a Bitcoin Core mempool is
> through it getting mined, double-spent, or the node restarting.
Right. And that results in some transactions with insufficient fees getting
dropped today after many hours.
> The protection that we have against that attack is that you need access to
> a lot of bitcoins to pay enough fees.
That's no protection against a well-funded private and/or public entity.
Without the block size limit, this attack doesn't exist. It would simply
result in a transfer of wealth from spammer to miners, which is a nicely
antifragile response for the Bitcoin network.
-----Original Message-----
From: Peter Todd
Sent: Monday, June 08, 2015 2:33 PM
To: Raystonn .
Cc: Patrick Mccorry (PGR) ; Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential
solution described: Dropped-transaction spam attack against the blocksize
limit
> > there is no memory pool cap currently
>
> Real hardware does not have an infinite amount of RAM. Memory pool sizes
> cannot grow unbounded. Some transactions with insufficient fees do get
> dropped today after many hours.
Actually they don't, which is an unfortunate problem with the existing
mempool implementation; the only way a transaction can be removed from a
Bitcoin Core mempool is through it getting mined, double-spent, or the
node restarting.
The protection that we have against that attack is that you need access
to a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum
relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
consumed, and furthermore, actually getting that many transactions to
propagate over the network is non-trivial. (no, I'm not going to tell
you how)
The obvious solution is to cap the size of the mempool and evict
transactions lowest fee/KB first, but if you do that they you (further)
break zeroconf security. On the other hand, if you don't break zeroconf
security an attacker can prevent reasonable fee transactions from
propagating.
I probably should get around to fixing this...

2023-06-07 15:37:08

- reply

📅 Original date posted:2015-06-08
📝 Original message:Not forgetting, simply deferring discussion on that. We’ve a much smaller limit to deal with right now. But even that limit would have to go to remove this attack.
From: Btc Drak
Sent: Monday, June 08, 2015 3:07 PM
To: Raystonn .
Cc: Peter Todd ; Bitcoin Dev ; Patrick Mccorry (PGR)
Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit
On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . <raystonn at hotmail.com> wrote:
No, with no blocksize limit, a spammer would would flood the network with
transactions until they ran out of money.
I think you are forgetting even if you remove the blocksize limit, there is still a hard message size limit imposed by the p2p protocol. Block would de-facto be limited to this size.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150608/e53bf0b4/attachment.html>

2023-06-07 15:37:06

- reply

📅 Original date posted:2015-06-08
📝 Original message:> the attack would be expensive.
For attacks being waged to destroy Bitcoin by filling all blocks with spam transactions, the attack succeeds when the attacker is well funded. This gives well-funded private and/or public entities the means to destroy Bitcoin if they desire. This is only true after the block size limit was implemented. Without the block size limit, the spam doesn’t harm Bitcoin. It simply enriches miners at the cost of the spammers, which is a nicely antifragile quality.
For attacks being waged to push up minimum fees for the benefit of miners, by filling the mempool with enough spam transactions with the floor fee to cover a new block every time another block is discovered, they stand to gain. Whatever fees they are paying, real transactions will have to pay more to get through. It can be a net gain depending on how many miners are participating.
From: Patrick Mccorry (PGR)
Sent: Monday, June 08, 2015 2:21 PM
To: Raystonn .
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
If I were a miner under this attack, I would just use the spam to fill up blocks alongside normal transactions maximising my profit.
You are assuming here that you can identify which transactions are spam, and which are not, and then segregate the spam into a separate channels of transactions for inclusion on a 50/50 basis alongside other transactions. There is no guarantee you will be able to identify those transactions. Sure, if you can do that, then the easy fix is just to put them into a lower class channel of transactions that guarantee no pressure on the non-spam transactions. But it's just not possible to do this in any meaningful way. If you wanted to try, it would certainly add quite a bit of cost and complexity on the miner's side, and you aren't going to get anything other than the simple spam that comes from the same set of addresses.
Well it depends how the transactions spam - if you do a huge link of transactions (one after another, with the total bitcoins "sent" being reduced by a fee each time) this is easily identifiable - if you were to do it using unlinked transactions then this would require 2x the setup (do a lot of mixing to get 1 million unlinked outputs and then commence attack) which doubles the cost of the attack.
If I were to spam a lot of transactions to fill the memory pool it would cost $120 every 10 minutes
You need to account for the transactions coming from real users. Every real transaction is approximately one less spam transaction you need to fill the blocks.
I was suggesting the cost of an adversary to send the spam - if he did manage to fill the entire block each time that's the maximum charge. Of course the costs get spread out if normal transactions are included.
there is no memory pool cap currently
Real hardware does not have an infinite amount of RAM. Memory pool sizes cannot grow unbounded. Some transactions with insufficient fees do get dropped today after many hours.
That's true that's why I used 250mb as an example to cost $30k. Cheap laptops today (around £300) come with 6gb ram - so the attack would be expensive.
I do doubt the miners codes probably are not prepared for an attack of this type - but it is really expensive to pull off from what I can see.
Sent from my iPhone
On 8 Jun 2015, at 22:14, Raystonn . <raystonn at hotmail.com> wrote:
If I were a miner under this attack, I would just use the spam to fill up blocks alongside normal transactions maximising my profit.
You are assuming here that you can identify which transactions are spam, and which are not, and then segregate the spam into a separate channels of transactions for inclusion on a 50/50 basis alongside other transactions. There is no guarantee you will be able to identify those transactions. Sure, if you can do that, then the easy fix is just to put them into a lower class channel of transactions that guarantee no pressure on the non-spam transactions. But it's just not possible to do this in any meaningful way. If you wanted to try, it would certainly add quite a bit of cost and complexity on the miner's side, and you aren't going to get anything other than the simple spam that comes from the same set of addresses.
If I were to spam a lot of transactions to fill the memory pool it would cost $120 every 10 minutes
You need to account for the transactions coming from real users. Every real transaction is approximately one less spam transaction you need to fill the blocks.
there is no memory pool cap currently
Real hardware does not have an infinite amount of RAM. Memory pool sizes cannot grow unbounded. Some transactions with insufficient fees do get dropped today after many hours.
-----Original Message----- From: Patrick Mccorry (PGR)
Sent: Monday, June 08, 2015 1:28 PM
To: Raystonn .
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
Please correct me if I'm wrong (hopefully understood it). I don't think normal users would need to pay a higher fee - as miners can just ignore the spam (since they will all be linked).
If I were to spam a lot of transactions to fill the memory pool it would cost $120 every 10 minutes (assuming 4,000 tx can fit inside a block and 3 cents per transaction), anything exceeding that may be considered "spam" - although I don't know if it would be "free" as the miner will eventually claim all the fees, delayed payment is probably a better way to describe it. IIRC, there is no memory pool cap currently. To spam 1 million transactions would cost $30k which would take up approx 250 blocks (around 250mb) which is around 42 hours to process. I think the memory pool can handle this data today (someone more knowledgeable can check this for me) - so the attack is v.expensive to carry out.
A good way to prevent this spamming the memory pool is to only accept up to a 'x' length of 0-confirmed transactions to make it more difficult to pull off (not impossible).
If I were a miner under this attack, I would just use the spam to fill up blocks alongside normal transactions maximising my profit.
Sent from my iPhone
On 8 Jun 2015, at 21:09, Raystonn . <raystonn at hotmail.com> wrote:
When implemented, the block size limit was put in place to prevent the
potential for a massive block to be used as an attack to benefit the miner
of that block. The theory goes that such a massive block would enrich its
miner by delaying other miners who are now busy downloading and validating
that huge block. The original miner of that large-block would be free to
continue hashing the next block, giving it an advantage.
Unfortunately, this block size limit opened a different attack. Prior to
the limit, any attempt to spam the network by anyone other than someone
mining their own transactions would have been economically unfeasible. As
every transaction would have a fee, there would have been a real cost for
every minute of spam. The end result would have been a transfer of wealth
from spammer to Bitcoin miners, which would have harmed the spammers and
encouraged further mining of Bitcoin, a very antifragile outcome.
But now we have the block size limit. Things are very different with this
feature in place. The beginning of a spam attack on the Bitcoin network
will incur transaction fees, just like before. But if spam continues at a
rate exceeding the block size limit long enough for transactions to be
dropped from mempools, the vast majority of spam transaction fees will never
have to be paid. In fact, as real users gain in desperation and pay higher
fees to get their transactions through in a timely manner, the spammers will
adjust their fees to minimize the cost of the attack and maximize
effectiveness. Using this method, they keep their fees at a point that
causes most of the spam transactions to be dropped without confirmation
(free spam), while forcing a floor for transaction fees. Thus, while spam
could be used by attackers to disable the network entirely, by paying
high-enough fees to actually fill the blocks with spam, it can also be used
by a single entity to force a transaction fee floor. Real users will be
forced to pay a transaction fee higher than the majority of the spam to get
their transactions confirmed. So this is an effective means for a minority
of miners to force higher fees through spam attacks, even in the face of
benevolent miners who would not support a higher fee floor by policy.
Miners would simply have no way to fix this, as they can only put in the
transactions that will fit under the block size limit.
In the face of such a spam attack, Bitcoin's credibility and usability would
be severely undermined. The block size limit enables this attack, and I now
argue for its removal. But we can't just remove it and ignore the problem
that it was intended to address. We need a new fix for the large-block
problem described in the first paragraph that does not suffer from the
dropped-transaction spam-attack problem that is enabled by the block size
limit today. My proposal is likely to be controversial, and I'm very much
open to hearing other better proposals.
Large blocks created by a miner as a means to spam other miners out of
competition is a problem because miners do not pay fees for their own
transactions when they mine them. They collect the fees they pay. This
breaks the economic barrier keeping people from spamming the network, as the
spamming is essentially free. The proposed fix is to add a new rule on how
fees are handled. Some amount of every fee should be considered as burned
and can never be spent. I will propose 50% of the fee here, but there may
be better numbers that can be discovered prior to putting this into place.
If we'd like miners to continue to collect the same fees after this change,
we can suggest the default fee per transaction to be doubled. Half of every
fee would be burned and disappear forever, effectively distributing the
value of those bitcoins across the entire money supply. The other half
would be collected by the miner of the block as is done today. This
solution would mean large blocks would cost a significant number of bitcoin
to create, even when all of the transactions are created by the miner of
that block. For this to work, we'd need to ensure a minimum fee is paid for
most of the transactions in every block, and the new transaction fee rule is
in place. Then the block size limit can be removed.
Raystonn
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150608/0ec8b183/attachment.html>

2023-06-07 15:37:05

- reply

📅 Original date posted:2015-06-08
📝 Original message:> If I were a miner under this attack, I would just use the spam to fill up
> blocks alongside normal transactions maximising my profit.
You are assuming here that you can identify which transactions are spam, and
which are not, and then segregate the spam into a separate channels of
transactions for inclusion on a 50/50 basis alongside other transactions.
There is no guarantee you will be able to identify those transactions.
Sure, if you can do that, then the easy fix is just to put them into a lower
class channel of transactions that guarantee no pressure on the non-spam
transactions. But it's just not possible to do this in any meaningful way.
If you wanted to try, it would certainly add quite a bit of cost and
complexity on the miner's side, and you aren't going to get anything other
than the simple spam that comes from the same set of addresses.
> If I were to spam a lot of transactions to fill the memory pool it would
> cost $120 every 10 minutes
You need to account for the transactions coming from real users. Every real
transaction is approximately one less spam transaction you need to fill the
blocks.
> there is no memory pool cap currently
Real hardware does not have an infinite amount of RAM. Memory pool sizes
cannot grow unbounded. Some transactions with insufficient fees do get
dropped today after many hours.
-----Original Message-----
From: Patrick Mccorry (PGR)
Sent: Monday, June 08, 2015 1:28 PM
To: Raystonn .
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential
solution described: Dropped-transaction spam attack against the block size
limit
Please correct me if I'm wrong (hopefully understood it). I don't think
normal users would need to pay a higher fee - as miners can just ignore the
spam (since they will all be linked).
If I were to spam a lot of transactions to fill the memory pool it would
cost $120 every 10 minutes (assuming 4,000 tx can fit inside a block and 3
cents per transaction), anything exceeding that may be considered "spam" -
although I don't know if it would be "free" as the miner will eventually
claim all the fees, delayed payment is probably a better way to describe it.
IIRC, there is no memory pool cap currently. To spam 1 million transactions
would cost $30k which would take up approx 250 blocks (around 250mb) which
is around 42 hours to process. I think the memory pool can handle this data
today (someone more knowledgeable can check this for me) - so the attack is
v.expensive to carry out.
A good way to prevent this spamming the memory pool is to only accept up to
a 'x' length of 0-confirmed transactions to make it more difficult to pull
off (not impossible).
If I were a miner under this attack, I would just use the spam to fill up
blocks alongside normal transactions maximising my profit.
Sent from my iPhone
> On 8 Jun 2015, at 21:09, Raystonn . <raystonn at hotmail.com> wrote:
>
> When implemented, the block size limit was put in place to prevent the
> potential for a massive block to be used as an attack to benefit the miner
> of that block. The theory goes that such a massive block would enrich its
> miner by delaying other miners who are now busy downloading and validating
> that huge block. The original miner of that large-block would be free to
> continue hashing the next block, giving it an advantage.
>
> Unfortunately, this block size limit opened a different attack. Prior to
> the limit, any attempt to spam the network by anyone other than someone
> mining their own transactions would have been economically unfeasible. As
> every transaction would have a fee, there would have been a real cost for
> every minute of spam. The end result would have been a transfer of wealth
> from spammer to Bitcoin miners, which would have harmed the spammers and
> encouraged further mining of Bitcoin, a very antifragile outcome.
>
> But now we have the block size limit. Things are very different with this
> feature in place. The beginning of a spam attack on the Bitcoin network
> will incur transaction fees, just like before. But if spam continues at a
> rate exceeding the block size limit long enough for transactions to be
> dropped from mempools, the vast majority of spam transaction fees will
> never
> have to be paid. In fact, as real users gain in desperation and pay
> higher
> fees to get their transactions through in a timely manner, the spammers
> will
> adjust their fees to minimize the cost of the attack and maximize
> effectiveness. Using this method, they keep their fees at a point that
> causes most of the spam transactions to be dropped without confirmation
> (free spam), while forcing a floor for transaction fees. Thus, while spam
> could be used by attackers to disable the network entirely, by paying
> high-enough fees to actually fill the blocks with spam, it can also be
> used
> by a single entity to force a transaction fee floor. Real users will be
> forced to pay a transaction fee higher than the majority of the spam to
> get
> their transactions confirmed. So this is an effective means for a
> minority
> of miners to force higher fees through spam attacks, even in the face of
> benevolent miners who would not support a higher fee floor by policy.
> Miners would simply have no way to fix this, as they can only put in the
> transactions that will fit under the block size limit.
>
> In the face of such a spam attack, Bitcoin's credibility and usability
> would
> be severely undermined. The block size limit enables this attack, and I
> now
> argue for its removal. But we can't just remove it and ignore the problem
> that it was intended to address. We need a new fix for the large-block
> problem described in the first paragraph that does not suffer from the
> dropped-transaction spam-attack problem that is enabled by the block size
> limit today. My proposal is likely to be controversial, and I'm very much
> open to hearing other better proposals.
>
> Large blocks created by a miner as a means to spam other miners out of
> competition is a problem because miners do not pay fees for their own
> transactions when they mine them. They collect the fees they pay. This
> breaks the economic barrier keeping people from spamming the network, as
> the
> spamming is essentially free. The proposed fix is to add a new rule on
> how
> fees are handled. Some amount of every fee should be considered as burned
> and can never be spent. I will propose 50% of the fee here, but there may
> be better numbers that can be discovered prior to putting this into place.
> If we'd like miners to continue to collect the same fees after this
> change,
> we can suggest the default fee per transaction to be doubled. Half of
> every
> fee would be burned and disappear forever, effectively distributing the
> value of those bitcoins across the entire money supply. The other half
> would be collected by the miner of the block as is done today. This
> solution would mean large blocks would cost a significant number of
> bitcoin
> to create, even when all of the transactions are created by the miner of
> that block. For this to work, we'd need to ensure a minimum fee is paid
> for
> most of the transactions in every block, and the new transaction fee rule
> is
> in place. Then the block size limit can be removed.
>
> Raystonn
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:37:04

- reply

📅 Original date posted:2015-06-09
📝 Original message:You are right of course. This will work. I like this idea more than my own proposed fix, as it doesn’t make any big changes to the economics of the system in the way that burning would have.
From: Gavin Andresen
Sent: Tuesday, June 09, 2015 11:25 AM
To: Raystonn .
Cc: Loi Luu ; Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <raystonn at hotmail.com> wrote:
That does sound good on the surface, but how do we enforce #1 and #2? They seem to be unenforceable, as a miner can adjust the size of the memory pool in his local source.
It doesn't have to be enforced. As long as a reasonable percentage of hash rate is following that policy an attacker that tries to flood the network will fail to prevent normal transaction traffic from going through and will just end up transferring some wealth to the miners.
Although the existing default mining policy (which it seems about 70% of hashpower follows) of setting aside some space for high-priority transactions regardless of fee might also be enough to cause this attack to fail in practice.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150609/77610583/attachment.html>

2023-06-07 15:37:03

- reply

📅 Original date posted:2015-06-09
📝 Original message:That does sound good on the surface, but how do we enforce #1 and #2? They seem to be unenforceable, as a miner can adjust the size of the memory pool in his local source.
From: Gavin Andresen
Sent: Tuesday, June 09, 2015 6:36 AM
To: Loi Luu
Cc: Raystonn . ; Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
How about this for mitigating this potential attack:
1. Limit the memory pool to some reasonable number of blocks-worth of transactions (e.g. 11)
2. If evicting transactions from the memory pool, prefer to evict transactions that are part of long chains of unconfirmed transactions.
3. Allow blocks to grow in size in times of high transaction demand.
The combination of (1) and (2) means an attacker needs to prepare lots of confirmed inputs to pull off the attack. By itself that means they MUST pay transaction fees.
(3) further mitigates the attack because it allows miners to just absorb fees that the attacker is throwing at miners.
On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu <loi.luuthe at gmail.com> wrote:
The proposed fix is to add a new rule on how
fees are handled. Some amount of every fee should be considered as burned
and can never be spent. I will propose 50% of the fee here, but there may
be better numbers that can be discovered prior to putting this into place.
If we'd like miners to continue to collect the same fees after this change,
we can suggest the default fee per transaction to be doubled
I would propose another practical rule rather than burning 50% of the fee. For example, you can
credit 50% of the transaction fee to the next block. Thus, the attacker cannot perform
the attack with 0-fee any more, yet you don't have to double the price of the TX fee for the fix.
Thanks,
Loi Luu.
On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . <raystonn at hotmail.com> wrote:
When implemented, the block size limit was put in place to prevent the
potential for a massive block to be used as an attack to benefit the miner
of that block. The theory goes that such a massive block would enrich its
miner by delaying other miners who are now busy downloading and validating
that huge block. The original miner of that large-block would be free to
continue hashing the next block, giving it an advantage.
Unfortunately, this block size limit opened a different attack. Prior to
the limit, any attempt to spam the network by anyone other than someone
mining their own transactions would have been economically unfeasible. As
every transaction would have a fee, there would have been a real cost for
every minute of spam. The end result would have been a transfer of wealth
from spammer to Bitcoin miners, which would have harmed the spammers and
encouraged further mining of Bitcoin, a very antifragile outcome.
But now we have the block size limit. Things are very different with this
feature in place. The beginning of a spam attack on the Bitcoin network
will incur transaction fees, just like before. But if spam continues at a
rate exceeding the block size limit long enough for transactions to be
dropped from mempools, the vast majority of spam transaction fees will never
have to be paid. In fact, as real users gain in desperation and pay higher
fees to get their transactions through in a timely manner, the spammers will
adjust their fees to minimize the cost of the attack and maximize
effectiveness. Using this method, they keep their fees at a point that
causes most of the spam transactions to be dropped without confirmation
(free spam), while forcing a floor for transaction fees. Thus, while spam
could be used by attackers to disable the network entirely, by paying
high-enough fees to actually fill the blocks with spam, it can also be used
by a single entity to force a transaction fee floor. Real users will be
forced to pay a transaction fee higher than the majority of the spam to get
their transactions confirmed. So this is an effective means for a minority
of miners to force higher fees through spam attacks, even in the face of
benevolent miners who would not support a higher fee floor by policy.
Miners would simply have no way to fix this, as they can only put in the
transactions that will fit under the block size limit.
In the face of such a spam attack, Bitcoin's credibility and usability would
be severely undermined. The block size limit enables this attack, and I now
argue for its removal. But we can't just remove it and ignore the problem
that it was intended to address. We need a new fix for the large-block
problem described in the first paragraph that does not suffer from the
dropped-transaction spam-attack problem that is enabled by the block size
limit today. My proposal is likely to be controversial, and I'm very much
open to hearing other better proposals.
Large blocks created by a miner as a means to spam other miners out of
competition is a problem because miners do not pay fees for their own
transactions when they mine them. They collect the fees they pay. This
breaks the economic barrier keeping people from spamming the network, as the
spamming is essentially free. The proposed fix is to add a new rule on how
fees are handled. Some amount of every fee should be considered as burned
and can never be spent. I will propose 50% of the fee here, but there may
be better numbers that can be discovered prior to putting this into place.
If we'd like miners to continue to collect the same fees after this change,
we can suggest the default fee per transaction to be doubled. Half of every
fee would be burned and disappear forever, effectively distributing the
value of those bitcoins across the entire money supply. The other half
would be collected by the miner of the block as is done today. This
solution would mean large blocks would cost a significant number of bitcoin
to create, even when all of the transactions are created by the miner of
that block. For this to work, we'd need to ensure a minimum fee is paid for
most of the transactions in every block, and the new transaction fee rule is
in place. Then the block size limit can be removed.
Raystonn
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150609/f1191f01/attachment.html>

2023-06-07 15:37:02

- reply

📅 Original date posted:2015-06-08
📝 Original message:When implemented, the block size limit was put in place to prevent the
potential for a massive block to be used as an attack to benefit the miner
of that block. The theory goes that such a massive block would enrich its
miner by delaying other miners who are now busy downloading and validating
that huge block. The original miner of that large-block would be free to
continue hashing the next block, giving it an advantage.
Unfortunately, this block size limit opened a different attack. Prior to
the limit, any attempt to spam the network by anyone other than someone
mining their own transactions would have been economically unfeasible. As
every transaction would have a fee, there would have been a real cost for
every minute of spam. The end result would have been a transfer of wealth
from spammer to Bitcoin miners, which would have harmed the spammers and
encouraged further mining of Bitcoin, a very antifragile outcome.
But now we have the block size limit. Things are very different with this
feature in place. The beginning of a spam attack on the Bitcoin network
will incur transaction fees, just like before. But if spam continues at a
rate exceeding the block size limit long enough for transactions to be
dropped from mempools, the vast majority of spam transaction fees will never
have to be paid. In fact, as real users gain in desperation and pay higher
fees to get their transactions through in a timely manner, the spammers will
adjust their fees to minimize the cost of the attack and maximize
effectiveness. Using this method, they keep their fees at a point that
causes most of the spam transactions to be dropped without confirmation
(free spam), while forcing a floor for transaction fees. Thus, while spam
could be used by attackers to disable the network entirely, by paying
high-enough fees to actually fill the blocks with spam, it can also be used
by a single entity to force a transaction fee floor. Real users will be
forced to pay a transaction fee higher than the majority of the spam to get
their transactions confirmed. So this is an effective means for a minority
of miners to force higher fees through spam attacks, even in the face of
benevolent miners who would not support a higher fee floor by policy.
Miners would simply have no way to fix this, as they can only put in the
transactions that will fit under the block size limit.
In the face of such a spam attack, Bitcoin's credibility and usability would
be severely undermined. The block size limit enables this attack, and I now
argue for its removal. But we can't just remove it and ignore the problem
that it was intended to address. We need a new fix for the large-block
problem described in the first paragraph that does not suffer from the
dropped-transaction spam-attack problem that is enabled by the block size
limit today. My proposal is likely to be controversial, and I'm very much
open to hearing other better proposals.
Large blocks created by a miner as a means to spam other miners out of
competition is a problem because miners do not pay fees for their own
transactions when they mine them. They collect the fees they pay. This
breaks the economic barrier keeping people from spamming the network, as the
spamming is essentially free. The proposed fix is to add a new rule on how
fees are handled. Some amount of every fee should be considered as burned
and can never be spent. I will propose 50% of the fee here, but there may
be better numbers that can be discovered prior to putting this into place.
If we'd like miners to continue to collect the same fees after this change,
we can suggest the default fee per transaction to be doubled. Half of every
fee would be burned and disappear forever, effectively distributing the
value of those bitcoins across the entire money supply. The other half
would be collected by the miner of the block as is done today. This
solution would mean large blocks would cost a significant number of bitcoin
to create, even when all of the transactions are created by the miner of
that block. For this to work, we'd need to ensure a minimum fee is paid for
most of the transactions in every block, and the new transaction fee rule is
in place. Then the block size limit can be removed.
Raystonn

2023-06-07 15:36:21

- reply

📅 Original date posted:2015-06-01
📝 Original message:We seem to be experiencing bursts of high transaction rate right now. https://blockchain.info/ shows nearly all blocks full. We should increase the default max block size to 1MB to give us more space where we see the 731MB blocks, as we don’t want to be limited by those who don’t bother to change the settings from the default, and thus probably aren’t paying attention to this whole discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/85679428/attachment.html>

2023-06-07 15:36:21

- reply

📅 Original date posted:2015-06-17
📝 Original message:Wow. That email was delayed by the list for quite some time. It was sent on 6/1.
From: Raystonn .
Sent: Monday, June 01, 2015 12:02 PM
To: Mike Hearn ; Adam Back
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] soft-fork block size increase(extensionblocks)
I also need to argue for increasing the default block limit to the full 1MB in the next release. We’re already hitting that limit in bursts of transactions, which puts pressure on the average displayed in the below graphs.
From: raystonn at hotmail.com
Sent: Monday, June 01, 2015 11:39 AM
To: Mike Hearn ; Adam Back
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks)
> And we're not going to get to VISA scale any time soon
No, not at these block size limits. The closer we get to the maximum block size, the slower we grow the average block size toward it. Number of transactions per day is of course highly correlated with average block size. Based on these graphs we can expect that hitting 1 million transactions per day will be impossible without raising the maximum block size.
https://blockchain.info/charts/avg-block-size?showDataPoints=false&show_header=true&daysAverageString=7&timespan=all&scale=1&address=
https://blockchain.info/charts/n-transactions?showDataPoints=false&timespan=all&show_header=true&daysAverageString=7&scale=1&address=
From: Mike Hearn
Sent: Monday, June 01, 2015 11:01 AM
To: Adam Back
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks)
(at reduced security if it has software that doesnt understand it)
Well, yes. Isn't that rather key to the issue? Whereas by simply increasing the block size, SPV wallets don't care (same security and protocol as before) and fully validating wallets can be updated with a very small code change.
A 1MB client wont even understand the difference between a 1MB and 8MB
out payment.
Let's say an old client makes a payment that only gets confirmed in an extension block. The wallet will think the payment is unconfirmed and show that to the user forever, no?
Can you walk through the UX for each case?
If I am not misremembering, I think you've sided typically
with the huge block, big data center only end of the spectrum.
It would be Satoshi, that argued that.
I think there must be a communication issue here somewhere. I'm not sure how this meme has taken hold amongst you guys, as I am the guy who wrote the scalability page back in 2011:
https://en.bitcoin.it/wiki/Scalability
It says:
The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops.
By "much higher rates" I meant VISA scale and by "high end server" I meant high end by today's standards not tomorrows. There's a big difference between a datacenter and a single server! By definition a single server is not a datacenter, although it would be conventional to place it in one. But even with the most wildly optimistic growth imaginable, I couldn't foresee a time when you needed more than a single machine to keep up with the transaction stream.
And we're not going to get to VISA scale any time soon: I don't think I've ever argued we will. If it does happen it would presumably be decades away. Again, short of some currently unimagined killer app.
So I don't believe I've ever argued this, and honestly I kinda feel people are putting words in my mouth.
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150617/ad3b151f/attachment.html>

2023-06-07 15:36:18

- reply

📅 Original date posted:2015-06-01
📝 Original message:> And we're not going to get to VISA scale any time soon
No, not at these block size limits. The closer we get to the maximum block size, the slower we grow the average block size toward it. Number of transactions per day is of course highly correlated with average block size. Based on these graphs we can expect that hitting 1 million transactions per day will be impossible without raising the maximum block size.
https://blockchain.info/charts/avg-block-size?showDataPoints=false&show_header=true&daysAverageString=7&timespan=all&scale=1&address=
https://blockchain.info/charts/n-transactions?showDataPoints=false&timespan=all&show_header=true&daysAverageString=7&scale=1&address=
From: Mike Hearn
Sent: Monday, June 01, 2015 11:01 AM
To: Adam Back
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks)
(at reduced security if it has software that doesnt understand it)
Well, yes. Isn't that rather key to the issue? Whereas by simply increasing the block size, SPV wallets don't care (same security and protocol as before) and fully validating wallets can be updated with a very small code change.
A 1MB client wont even understand the difference between a 1MB and 8MB
out payment.
Let's say an old client makes a payment that only gets confirmed in an extension block. The wallet will think the payment is unconfirmed and show that to the user forever, no?
Can you walk through the UX for each case?
If I am not misremembering, I think you've sided typically
with the huge block, big data center only end of the spectrum.
It would be Satoshi, that argued that.
I think there must be a communication issue here somewhere. I'm not sure how this meme has taken hold amongst you guys, as I am the guy who wrote the scalability page back in 2011:
https://en.bitcoin.it/wiki/Scalability
It says:
The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops.
By "much higher rates" I meant VISA scale and by "high end server" I meant high end by today's standards not tomorrows. There's a big difference between a datacenter and a single server! By definition a single server is not a datacenter, although it would be conventional to place it in one. But even with the most wildly optimistic growth imaginable, I couldn't foresee a time when you needed more than a single machine to keep up with the transaction stream.
And we're not going to get to VISA scale any time soon: I don't think I've ever argued we will. If it does happen it would presumably be decades away. Again, short of some currently unimagined killer app.
So I don't believe I've ever argued this, and honestly I kinda feel people are putting words in my mouth.
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/6ea5f791/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image[2].png
Type: image/png
Size: 53618 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/6ea5f791/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image[12].png
Type: image/png
Size: 50593 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/6ea5f791/attachment-0001.png>

2023-06-07 15:36:18

- reply

📅 Original date posted:2015-06-01
📝 Original message:I also need to argue for increasing the default block limit to the full 1MB in the next release. We’re already hitting that limit in bursts of transactions, which puts pressure on the average displayed in the below graphs.
From: raystonn at hotmail.com
Sent: Monday, June 01, 2015 11:39 AM
To: Mike Hearn ; Adam Back
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks)
> And we're not going to get to VISA scale any time soon
No, not at these block size limits. The closer we get to the maximum block size, the slower we grow the average block size toward it. Number of transactions per day is of course highly correlated with average block size. Based on these graphs we can expect that hitting 1 million transactions per day will be impossible without raising the maximum block size.
https://blockchain.info/charts/avg-block-size?showDataPoints=false&show_header=true&daysAverageString=7&timespan=all&scale=1&address=
https://blockchain.info/charts/n-transactions?showDataPoints=false&timespan=all&show_header=true&daysAverageString=7&scale=1&address=
From: Mike Hearn
Sent: Monday, June 01, 2015 11:01 AM
To: Adam Back
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks)
(at reduced security if it has software that doesnt understand it)
Well, yes. Isn't that rather key to the issue? Whereas by simply increasing the block size, SPV wallets don't care (same security and protocol as before) and fully validating wallets can be updated with a very small code change.
A 1MB client wont even understand the difference between a 1MB and 8MB
out payment.
Let's say an old client makes a payment that only gets confirmed in an extension block. The wallet will think the payment is unconfirmed and show that to the user forever, no?
Can you walk through the UX for each case?
If I am not misremembering, I think you've sided typically
with the huge block, big data center only end of the spectrum.
It would be Satoshi, that argued that.
I think there must be a communication issue here somewhere. I'm not sure how this meme has taken hold amongst you guys, as I am the guy who wrote the scalability page back in 2011:
https://en.bitcoin.it/wiki/Scalability
It says:
The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops.
By "much higher rates" I meant VISA scale and by "high end server" I meant high end by today's standards not tomorrows. There's a big difference between a datacenter and a single server! By definition a single server is not a datacenter, although it would be conventional to place it in one. But even with the most wildly optimistic growth imaginable, I couldn't foresee a time when you needed more than a single machine to keep up with the transaction stream.
And we're not going to get to VISA scale any time soon: I don't think I've ever argued we will. If it does happen it would presumably be decades away. Again, short of some currently unimagined killer app.
So I don't believe I've ever argued this, and honestly I kinda feel people are putting words in my mouth.
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/555a8150/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image[2].png
Type: image/png
Size: 53618 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/555a8150/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image[12].png
Type: image/png
Size: 50593 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/555a8150/attachment-0001.png>

2023-06-07 15:34:14

- reply

📅 Original date posted:2015-05-28
📝 Original message:I agree that developers should avoid imposing economic policy. It is dangerous for Bitcoin and the core developers themselves to become such a central point of attack for those wishing to disrupt Bitcoin. My opinion is these things are better left to a decentralized free market anyhow.
From: Gavin Andresen
Sent: Thursday, May 28, 2015 10:19 AM
To: Mike Hearn
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
On Thu, May 28, 2015 at 1:05 PM, Mike Hearn <mike at plan99.net> wrote:
Isn't that a step backwards, then? I see no reason for fee pressure to exist at the moment. All it's doing is turning away users for no purpose: mining isn't supported by fees, and the tiny fees we use right now seem to be good enough to stop penny flooding.
Why not set the max size to be 20x the average size? Why 2x, given you just pointed out that'd result in blocks shrinking rather than growing.
Twenty is scary.
And two is a very neutral number: if 50% of hashpower want the max size to grow as fast as possible and 50% are dead-set opposed to any increase in max size, then half produce blocks 2 times as big, half produce empty blocks, and the max size doesn't change. If it was 20, then a small minority of miners could force a max size increase. (if it is less than 2, then a minority of minors can force the block size down)
As for whether there "should" be fee pressure now or not: I have no opinion, besides "we should make block propagation faster so there is no technical reason for miners to produce tiny blocks." I don't think us developers should be deciding things like whether or not fees are too high, too low, .....
--
--
Gavin Andresen
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/21f0f238/attachment.html>

2023-06-07 15:34:13

- reply

📅 Original date posted:2015-05-29
📝 Original message:Regarding Tier’s proposal: The lower security you mention for extended blocks would delay, possibly forever, the larger blocks maximum block size that we want for the entire network. That doesn’t sound like an optimal solution.
Regarding consensus for larger maximum block size, what we are seeing on this list is typical of what we see in the U.S. Congress. Support for changes by the stakeholders (support for bills by the citizens as a whole) has become irrelevant to the probability of these changes being adopted. Lobbyists have all the sway in getting their policies enacted. In our case, I would bet on some lobbying of core developers by wealthy miners.
Someone recently proposed that secret ballots could help eliminate the power of lobbyists in Congress. Nobody invests in that which cannot be confirmed. Secret ballots mean the vote you are buying cannot be confirmed. Perhaps this will work for Bitcoin Core as well.
From: Tier Nolan
Sent: Friday, May 29, 2015 7:22 AM
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
On Fri, May 29, 2015 at 3:09 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
But if there is still no consensus among developers but the "bigger blocks now" movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens.
How do you define that the movement is successful?
Sorry again, I keep auto-sending from gmail when trying to delete.
In theory, using the "nuclear option", the block size can be increased via soft fork.
Version 4 blocks would contain the hash of the a valid extended block in the coinbase.
<block height> <32 byte extended hash>
To send coins to the auxiliary block, you send them to some template.
OP_P2SH_EXTENDED <scriptPubKey hash> OP_TRUE
This transaction can be spent by anyone (under the current rules). The soft fork would lock the transaction output unless it transferred money from the extended block.
To unlock the transaction output, you need to include the txid of transaction(s) in the extended block and signature(s) in the scriptSig.
The transaction output can be spent in the extended block using P2SH against the scriptPubKey hash.
This means that people can choose to move their money to the extended block. It might have lower security than leaving it in the root chain.
The extended chain could use the updated script language too.
This is obviously more complex than just increasing the size though, but it could be a fallback option if no consensus is reached. It has the advantage of giving people a choice. They can move their money to the extended chain or not, as they wish.
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/9eaf701c/attachment.html>

2023-06-07 15:33:32

- reply

📅 Original date posted:2015-05-08
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/78da0fd0/attachment.html>