Re: [bitcoin-dev] Your Gmaxwell exchange

2015-08-30 Thread Peter R via bitcoin-dev
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

Re: [bitcoin-dev] Your Gmaxwell exchange

2015-08-30 Thread Adam Ritter via bitcoin-dev
I don't really see any problem with the paper: All it states is that having the assumption that miners don't centralize, transaction fees don't go to zero even without the blocksize limit. I think we can accept this as a nice academic research, and I believe that it's true. Still, it doesn't have

Re: [bitcoin-dev] Unlimited Max Blocksize (reprise)

2015-08-30 Thread Daniele Pinna via bitcoin-dev
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

Re: [bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests

2015-08-30 Thread Peter R via bitcoin-dev
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

Re: [bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests

2015-08-30 Thread Daniele Pinna via bitcoin-dev
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

Re: [bitcoin-dev] Unlimited Max Blocksize (reprise)

2015-08-30 Thread Tom Harding via bitcoin-dev
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

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

2015-08-30 Thread Jorge Timón via bitcoin-dev
On Sun, Aug 30, 2015 at 7:13 PM, jl2...@xbt.hk 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

Re: [bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

2015-08-30 Thread 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 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,

[bitcoin-dev] Proof of Work algorithm vs mining centralization

2015-08-30 Thread Dave Scotese via bitcoin-dev
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

[bitcoin-dev] ERRATA CORRIGE + Short Theorem

2015-08-30 Thread Daniele Pinna via bitcoin-dev
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

[bitcoin-dev] Unlimited Max Blocksize (reprise)

2015-08-30 Thread Peter R via bitcoin-dev
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

Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin

2015-08-30 Thread s7r via bitcoin-dev
-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 compliant

Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin

2015-08-30 Thread Vinyas via bitcoin-dev
No No On Aug 30, 2015, 14:47, at 14:47, s7r via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org 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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

2015-08-30 Thread Rusty Russell via bitcoin-dev
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 active

Re: [bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

2015-08-30 Thread odinn via bitcoin-dev
-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 going