Regardless of the XT debate, centralization on reddit and bitcointalk has
become a critical issue for the bitcoin community. A few anonymous people
control both these forums, giving them unprecedented power to manipulate
discussion, alter reputation, ban users, and even to facilitate scammers in
jl2...@xbt.hk writes:
> Rusty Russell 於 2015-08-26 23:08 寫到:
>> - We should immediately deploy an IsStandard() rule which insists that
>> nSequence is 0x or 0, so nobody screws themselves when we
>> soft fork and they had random junk in there.
>
> This is not needed because BIP68 is not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Related:
https://github.com/bitcoin/bitcoin/issues/6568
Kristov Atlas via bitcoin-dev:
> Hi Wei,
>
> As you know, I'm not a developer of Bitcoin-Qt, but we'll need to
> make our best guesses for these answers if the developers won't
> reply. I'm g
On 8/30/2015 9:54 AM, Peter R wrote:
> Like Daniele pointed out, the greedy algorithm assumed in the paper is
> asymptotically optimal in such a case.
I'm convinced.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxf
"However, that is outside the scope of the result that an individual
miner's profit per block is always maximized at a finite block size Q* if
Shannon Entropy about each transaction is communicated during the block
solution announcement. This result is important because it explains how a
minimum f
Hi Daniele,
I don't think there is any contention over the idea that miners that control a
larger percentage of the hash rate, h / H, have a profitability advantage if
you hold all the other variables of the miner's profit equation constant. I
think this is important: it is a centralizing fact
Since my longer post seems to be caught in moderator purgatory I will
rehash its results into this much smaller message. I apologize for the
spamming.
I present a theorem whose thesis is obvious to many.
*THESIS: All hashrates* *h' > h generate a revenue per unit of hash v' >
v. *
Let us absurdl
Hi Wei,
As you know, I'm not a developer of Bitcoin-Qt, but we'll need to make our
best guesses for these answers if the developers won't reply. I'm going to
post my best guesses here so that people reading the list have a short
window of opportunity to correct me if they wish.
On Fri, Aug 7, 20
Here is a short review of previously-proposed and exotic SIGHASH types.
SIGHASH_MULTIPLE
SIGHASH_LIST:
https://bitcointalk.org/index.php?topic=252960.0
https://bitcointalk.org/index.php?topic=212555.0
SIGHASH_MULTIPLE
SIGHASH_WITHINPUTVALUE:
https://bitcointalk.org/index.php?topic=191003.0
SIGHA
On Sun, Aug 30, 2015 at 7:13 PM, wrote:
> This is based on the assumption that miners would always like to use up the
> last byte of the available block size. However, this is just not true:
>
> 1. The 6 year blockchain history has shown that most miners have a soft cap
> with their block size.
>
Before miners get angry, consider that whatever the community does will
attempt to preserve the efforts you have made to make Bitcoin a success.
Paragraph five, below, includes a provision to protect you, so please don't
write me off.
The competition is essential to protecting the data in the bloc
Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到:
I still don't see the point in having a lower moving size maximum.
If 8 MB is mining-centralization-safe, let's move directly to 8 MB
without adding this seemingly useless extra complexity.
If it's not, mining voting on a lower moving maximum w
Hello Tom, Daniele --
Thank you Tom for pointing out the knapsack problem to all of us. I will
include a note about it when I make the other corrections to the Fee Market
paper.
I agree with what Daniele said previously. The other "non-greedy" solutions to
the knapsack problem are most relev
Sorry to be off-topic but SNR of the mailing list is really getting
ridiculous.
Stop trolling and feeding the trolls.
Before you click "send", remember that your message will be sent to the
inbox of hundreds or thousands of people.
Ref:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev
No No
On Aug 30, 2015, 14:47, at 14:47, s7r via bitcoin-dev
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>2^256 x _NO_
>
>On 8/28/2015 5:00 AM, odinn via bitcoin-dev wrote:
>> No.
>>
>> On 08/27/2015 01:10 AM, prabhat via bitcoin-dev wrote:
>>> Hi,
>>
>>> I am proposing to crea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
2^256 x _NO_
On 8/28/2015 5:00 AM, odinn via bitcoin-dev wrote:
> No.
>
> On 08/27/2015 01:10 AM, prabhat via bitcoin-dev wrote:
>> Hi,
>
>> I am proposing to create a AML-KYC module to control the network
>> and also qualify use cases in OFAC co
I think that the argument for Peter's optimal block construction algorithm
(leading to the definition of the Fee Demand Curve) is that in the limit of
a mempool with a very large number of transactions, you should be able to
assume that for any given transaction [image: i] of size [image: s_i] and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is looking very good also (you've already seen it, but just
adding it to thread):
https://data.bitcoinity.org/bitcoin/block_size_votes/7d?c=block_size_vot
es&r=hour&t=bar
(site by Kacper Cieśla (comboy))
On 08/25/2015 01:46 AM, Christian Decker
Hi Greg,
>> I agree that miners may change their level of centralization. This neither
>> affects the model nor the results presented in the paper.
>
> It has tremdous significance to the real-world impact of your results.
The paper makes no claims about "miners changing their level of
central
19 matches
Mail list logo
