Re: [Bitcoin-development] soft-fork block size increase(extensionblocks)

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

Re: [Bitcoin-development] The Bitcoin Node Market

> Would SPV wallets have to pay to connect to the network too? The cost to compute and deliver the requested data will be pushed to the users of that node. This is the same way all costs, fees, and taxes of any business are always paid by its customers. The Bitcoin Network will not thrive in a de

Re: [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork

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?

Re: [Bitcoin-development] The Bitcoin Node Market

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: sick...@gmail.com Sent: Monday, June 15, 2015 12:18 PM To: Raystonn . Cc: Bitcoin Dev Subject: Re: [Bitcoin-development

[Bitcoin-development] The Bitcoin Node Market

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 op

Re: [Bitcoin-development] comments on BIP 100

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

Re: [Bitcoin-development] User vote in blocksize through fees

Adding back the list. Did not intend to remove it. Apologies. On 13 Jun 2015 4:52 pm, Raystonn wrote:Based on my observations, what the majority of Bitcoin users want is a system that can carry more transactions per second than any existing payment system while retaining most of the security

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

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

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

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

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit

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

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit

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

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

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit

ers, 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: Dr

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

ing. 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 wo

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

emory 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

[Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

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

[Bitcoin-development] We are filling most blocks right now - Let's change the max blocksize default

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 cha

Re: [Bitcoin-development] Block Size Increase Requirements

Stop trying to dictate block growth limits.  Block size will be determined by competition between miners and availability of transactions, not through hard-coded limits.  I see now the temporary 1MB limit was a mistake.  It should have gone in as a dynamic limit that scales with average block size.

Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

My fear now is too much unnecessary complexity.  More complex means brittle code, but also fewer programmers working on this, which is a risk. We shouldn't delay forever until every potential solution has been explored.  There's always going to be one more thing to explore. On 29 May 2015 5:16 pm,

Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

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 seei

Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

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:

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

Trust, regulation, law, and the threat of force.  Are you serious? On 26 May 2015 11:38 am, Allen Piscitello wrote:What prevents you from writing a bad check using today's systems?On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe wrote:What prevents RBF from being used for fr

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

very least the amount spent should be removed as a factor, or fees are unlikely to ever be paid by those who can afford them.  We can reassess the role age plays later.  One change at a time is better. On 9 May 2015 12:52 pm, Jim Phillips wrote:On Sat, May 9, 2015 at 2:43 PM, Raystonn <rayst

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

llips wrote:On Sat, May 9, 2015 at 2:25 PM, Raystonn <raystonn@hotmail.com> wrote:Lack of privacy is viral.  We shouldn't encourage policy in most wallets that discourages privacy.  It adversely affects privacy across the entire network.How about this as a happy medium default policy: Rather t

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

Lack of privacy is viral.  We shouldn't encourage policy in most wallets that discourages privacy.  It adversely affects privacy across the entire network. On 9 May 2015 12:17 pm, Jim Phillips wrote:On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille wrote:It's a very complex

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

It seems to me all this would do is encourage 0-transaction blocks, crippling the network. Individual blocks don't have a "maximum" block size, they have an actual block size. Rational miners would pick blocks to minimize difficulty, lowering the "effective" maximum block size as defined by th

Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41

Fail, Damian.  Not even a half-good attempt. -Raystonn On 8 May 2015 3:15 pm, Damian Gomez wrote:On Fri, May 8, 2015 at 3:12 PM, Damian Gomez <dgomez1092@gmail.com> wrote:let me continue my conversation: as the development of this transactions would be indiscated as a ByteArray of On Fri,

Re: [Bitcoin-development] Block Size Increase

fact, as blocks fill it could make the problem worse.  This feature means more transactions after all.  So I would expect huge fee spikes, or a return to zombie transactions if fee caps are implemented by wallets. -Raystonn On 8 May 2015 1:55 pm, Mark Friedenbach wrote:The problems with that are

Re: [Bitcoin-development] Block Size Increase

-Raystonn On 8 May 2015 1:41 pm, Mark Friedenbach wrote: > > Transactions don't expire. But if the wallet is online, it can periodically > choose to release an already created transaction with a higher fee. This > requires replace-by-fee to be sufficiently deployed, however. > &

Re: [Bitcoin-development] Block Size Increase

advertise to the network.  Users set the priority in the wallet, and the wallet software translates it to a specific fee curve used in the series of expiring transactions.  In this manner, transactions are never left hanging for days, and probably not even for hours. -Raystonn On 8 May 2015 1:17 pm