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
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 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
> 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
> 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
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
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
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
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
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
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
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
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
>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 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
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
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
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
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
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
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
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
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
> 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
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%,
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
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
> 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
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
archive nodes.
>
>
> Further discussion about disk space requirements should be taken to
> another thread.
>
>
> --
Andrew Johnson
-- next part --
An HTML attachment was
> > 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
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
> 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
> 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
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
> 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'
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
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
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
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
40 matches
Mail list logo
