1TB HDD is now available for under $40 USD. How is the 100GB storage
requirement preventing anyone from setting up full nodes?
On Apr 16, 2017 11:55 PM, "David Vorick via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> *Rationale:*
>
> A node that stores the full blockchain (I
"With a very powerful "Desktop" machine bitcoin-qt dominates CPU/GPU
resources."
That doesn't match my experience.
System responsiveness / user experience can suffer when running bitcoin-qt
on a spinning hard disk. Disk I/O load will cause the whole system to grind
and severely disrupt the user
What is the current behavior / cost that this proposal is trying to avoid?
Are ancient utxos required to be kept in memory always in a fully
validating node, or can ancient utxos get pushed out of memory like a
normal LRU caching db?
Thanks,
-Danny
On Dec 12, 2015 1:55 PM, "jl2012--- via
A signer modifying the order of inputs or changing outputs when
"re-signing" a transaction (which already has dependent child transactions
spending its outputs) seems like quite a different hazard than a malicious
third party modifying a transaction in the mempool by twiddling opcodes in
the
What does "package" mean here?
When you say 25 txs, does that mean maximum linked chain depth, or total
number of dependent transactions regardless of chain depth?
Thanks,
-Danny
On Mon, Oct 5, 2015 at 11:45 AM, Alex Morcos via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
What of this prior effort, proposing B-with-horizontal-bar (Ƀ)?
http://bitcoinsymbol.org/
They argue that B-with-2-vertical-bars is easily confused with the Thai
Bhat currency symbol, which is a B with a single vertical bar.
I'm not terribly fond of the B-with-horizontal-bar as a symbol, but it
The limits Alex proposed are generous (bordering on obscene!), but dropping
that down to allowing only two levels of chained unconfirmed transactions
is too tight.
Use case: Brokered asset transfers may require sets of transactions with a
dependency tree depth of 3 to be published together. ( N
amounts to “hey guys, let’s install the new version”
On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Deploying experimental code onto the live bitcoin blockchain seems
unnecessarily risky. Why not deploy a blocksize limit experiment for long
wrote:
Problem is if you know most of the people running the testnet personally
(as is pretty much the case with many current testnets) then the deployment
amounts to “hey guys, let’s install the new version”
On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev
bitcoin-dev
I like the simplicity of this approach. Demand driven response.
Is there really a need to reduce the max block size at all? It is just a
maximum limit, not a required size for every block. If a seasonal
transaction surge bumps the max block size limit up a notch, what harm is
there in leaving
Any idea what's going on with TestNet? No blocks for nearly 2 hours now,
according to multiple block explorers (blockr.io, my own bitcoin node, etc).
Prior to the last block (530516), there were a lot of blocks with zero
transactions and only an occasional block with a ton of txs.
Any info?
11 matches
Mail list logo
