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
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
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
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?
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
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
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
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
: 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
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
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
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.
Trust, regulation, law, and the threat of force. Are you serious?
On 26 May 2015 11:38 am, Allen Piscitello allen.piscite...@gmail.com wrote:What prevents you from writing a bad check using todays systems?On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe danny.thorpe@gmail.com wrote:What prevents RBF
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 j...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:43 PM, Raystonn
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 j...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille pieter.wuille@gmail.com wrote:Its
...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:25 PM, Raystonn raystonn@hotmail.com wrote:Lack of privacy is viral. We shouldnt 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 than
-Raystonn
On 8 May 2015 1:41 pm, Mark Friedenbach m...@friedenbach.org 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
, 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 m...@friedenbach.org wrote:The problems
Fail, Damian. Not even a half-good attempt.
-Raystonn
On 8 May 2015 3:15 pm, Damian Gomez dgomez1...@gmail.com 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
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 the
to 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
21 matches
Mail list logo
