There is alot going on in this thread so I'll reply more broadly.
The original post and the assorted limit proposals---lead me to something
I think is worth reiterating: assuming Bitcoin adoption continues to grow at
similar or accelerating rates, then eventually the mempool is going to be
I don't know if i should response to this mail list or make a comment in
commit file (
https://github.com/sipa/bech32/commit/52b5a0fa6d3174c4150393fb7d6b58d34b4f5e0b#diff-d23a42e5c904045098e8f8b1189f481e
)
* Motivation:
Here I think it could worth to mention that 58 requires mathematical
operatio
I have heard such theory before, it's a complete mistake to think that
others would run full nodes to protect their business and then yours,
unless it is proven that they are decentralized and independent
Running a full node is trivial and not expensive for people who know how
to do it, even with
ese users from running a pruned node? Not every node
> > needs to store a complete copy of the blockchain.
> >
> >
> > Pruned nodes are not the default configuration, if it was the default
> > configuration then I think you would see far more users running a pruned
> > n
> It's a political assessment. Full nodes are the ultimate arbiters of
consensus.
That's not true unless miners are thought of as the identical to nodes,
which is has not been true for nearly 4 years now. Nodes arbitrating a
consensus the BU theory - that nodes can restrain miners - but it doesn'
Peter R said: "On that topic, are there any existing proposals detailing a
canonical ordering of the UTXO set and a scheme to calculate the root hash?"
I created such here: "A Commitment-suitable UTXO set "Balances" file data
structure":
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2
> Pruned nodes are not the default configuration, if it was the default
configuration then I think you would see far more users running a pruned
node.
Default configurations aren't a big enough deal to factor into the critical
discussion of node costs versus transaction fee cost. Default
configur
> Perhaps you are fortunate to have a home computer that has more than a
single 512GB SSD. Lots of consumer hardware has that little storage.
That's very poor logic, sorry. Restricted-space SSD's are not a
cost-effective hardware option for running a node. Keeping blocksizes
small has significan
eds to store a complete copy of the blockchain.
> >
> >
> > Pruned nodes are not the default configuration, if it was the default
> > configuration then I think you would see far more users running a pruned
> > node.
> >
> > But that would also substantially increas
> > When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.
> Why is that a given? Is there math that outlines what the risk levels
are for various configurations of node distribution
archive nodes.
>
>
> Further discussion about disk space requirements should be taken to
> another thread.
>
>
> --
Andrew Johnson
-- next part --
An HTML attachment was
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
> When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.
Why is that a given? Is there math that outlines what the risk levels are
for various configurations of node distributions, v
I think at least the three following things have to be done before the block
size can be increased by any significant amount:
1. A network protocol defined UTXO snapshot format be defined, UTXO snapshots
being created automatically in a deterministic periodic and low-cost fashion.
Ability to syn
I'm requesting feedback and corrections for the second edition of
"Mastering Bitcoin". Apologies if this is considered off-topic - it is only
my second message to this list in 4 years and I think it is relevant
because this book is the first source of information for many new bitcoin
developers.
T
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%,
> While Segwit's change from 1 mb size limit to 4 mb weight limit seems to
be controversial among some users [..] I don't think it's very interesting
to discuss further size increases.
I think the reason for this is largely because SegWit as a blocksize
increase isn't very satisfying. It resolves
Well it's not going off-topic since the btc folks need now to find a way
to counter the attack
The disk space story is know to be a non issue, because encouraging
people to run nodes while they don't know how to dedicate the right
storage space that is trivial and not expensive to get today is jus
I believe that as we continue to add users to the system by scaling
capacity that we will see more new nodes appear, but I'm at a bit of a loss
as to how to empirically prove it.
I do see your point on increasing load on archival nodes, but the majority
of that load is going to come from new nodes
What's stopping these users from running a pruned node? Not every node
needs to store a complete copy of the blockchain.
On Wed, Mar 29, 2017 at 11:18 AM David Vorick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Perhaps you are fortunate to have a home computer that has mor
On Mar 29, 2017 12:20 PM, "Andrew Johnson"
wrote:
What's stopping these users from running a pruned node? Not every node
needs to store a complete copy of the blockchain.
Pruned nodes are not the default configuration, if it was the default
configuration then I think you would see far more use
Perhaps you are fortunate to have a home computer that has more than a
single 512GB SSD. Lots of consumer hardware has that little storage. Throw
on top of it standard consumer usage, and you're often left with less than
200 GB of free space. Bitcoin consumes more than half of that, which feels
ver
Le 29/03/2017 à 17:57, David Vorick via bitcoin-dev a écrit :
> It's too expensive for a home user to run a full node, and user-run
> full nodes are what provide the strongest defence against political
> manuveuring.
Yes but what makes you think that "It's too expensive for a home user to
run a
Le 29/03/2017 à 11:16, Jared Lee Richardson via bitcoin-dev a écrit :
> Nodes process transactions and are paid nothing to do so, and their
> costs are 100x more relevant to the blocksize debate than a paper
> about miner costs.
>
> Miners are rewarded with fees; nodes are rewarded only by utilit
On Mar 29, 2017 9:50 AM, "Martin Lízner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Im tending to believe, that HF is necessary evil now.
I will firmly disagree. We know how to do a soft-fork blocksize increase.
If it is decided that a block size increase is justified, we ca
> On 29 Mar 2017, at 14:24, Emin Gün Sirer via bitcoin-dev
> wrote:
>
> >Even when several of the experts involved in the document you refer has my
> >respect and admiration, I do not agree with some of their conclusions
>
> I'm one of the co-authors of that study. I'd be the first to agree w
>Even when several of the experts involved in the document you refer has my
respect and admiration, I do not agree with some of their conclusions
I'm one of the co-authors of that study. I'd be the first to agree with
your conclusion
and argue that the 4MB size suggested in that paper should not b
On Wednesday, 29 March 2017 14:48:42 CEST Martin Stolze wrote:
> Your
> conception holds under the presupposition that all action of
> hash-power is motivated by 'rational' economic interest.
This shows you didn't think this through,
instead, the concept holds true when there is even a small sect
Sure it will be somewhat controversial initially, however, "miners",
will have additional incentive to listen to the network in order to
get transactions. It's not taking away from your personal choice, it's
adding additional choice to those that are disenfranchised by
hash-power centralization.
O
Ignoring your contradiction of the political and economical. Your
conception holds under the presupposition that all action of
hash-power is motivated by 'rational' economic interest. Specifically
a very strict distinction between the profitable and the unprofitable;
namely to include transactions
On Monday, 20 March 2017 21:12:36 CEST Martin Stolze via bitcoin-dev wrote:
> Background: The current protocol enables two parties to transact
> freely, however, transaction processors (block generators) have the
> authority to discriminate participants arbitrarily.
Nag; they don’t have any author
On Saturday, 18 March 2017 16:23:16 CEST Chris Stewart via bitcoin-dev
wrote:
> As everyone in the Bitcoin space knows, there is a massive scaling debate
> going on. One side wants to increase the block size via segwit, while the
> other side wants to increase via hard fork. I have strong opinions
As I alluded to before, certain language lends itself to simple conclusions.
You say that "miner" have simple profit motives and compete only in
their respective domains. But what is "mining"?
It is the process of acquiring a part of the block space. He who
acquires that space can decide over this
The bitcoin ecosystem is better off the more transactions are propogated
peer-to-peer than directly to miners. We want miners listening to the
network, not soliciting transactions directly from users. You whispering
your transactions to your miner-of-choice while I whisper to mine
contravenes a cri
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
> I suggest you take a look at this paper: http://fc16.ifca.ai/
bitcoin/papers/CDE+16.pdf It may help you form opinions based in science
rather than what appears to be nothing more than a hunch. It shows that
even 4MB is unsafe. SegWit provides up to this limit.
I find this paper wholly unconvi
> That said, for that to be alleviated we
could simply do something based on historical transaction growth (which
is somewhat linear, with a few inflection points),
Where do you get this? Transaction growth for the last 4 years averages to
+65% per year and the last 2 is +80% per year. That's ve
On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote:
> On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via bitcoin-dev
> wrote:
>> Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
>> In Bitcoin Wallet, I use Base 43 (alphabet:
>> "0123456789ABCDEFGHIJKLMNO
While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be
controversial among some users (I find that very often it is because they
have been confused about what segwit does or even outright lied about it) I
don't think it's very interesting to discuss further size increases.
I fi
On Saturday, March 25, 2017 3:30:22 AM Cameron Garnham via bitcoin-dev wrote:
> ==Definitions==
It's blank?
> ==Specification==
>
> Upon activation of the soft-fork (activation methodology undefined in this
> proposal), the following new rules become activated on the Bitcoin
> Network.
The acti
40 matches
Mail list logo
