Re: [bitcoin-dev] Weak block thoughts...

Hi Gavin, One thing that's not clear to me is whether it is even necessary--from the perspective of the block size limit--to consider block propagation. Bitcoin has been successfully operating unconstrained by the block size limit over its entire history (except for in the past few months)--bl

Re: [bitcoin-dev] Weak block thoughts...

Thanks for the reply, Gavin. I agree on all points. Peter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

> On Oct 2, 2015, at 1:20 AM, Jorge Timón via bitcoin-dev > wrote: > On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" > > wrote: > > should an algorithm that guarantees protection from ASIC/FPGA optimization > > be found. > This is demonstr

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

Dear Bitcoin Development Community: I would like to share my opinion that Mike is correct regarding the soft fork versus hard fork debate. I agree that CLTV should be done with a hard fork for the reasons that Mike has discussed several times in the past (mainly that a hard forks requires activ

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

> On Oct 5, 2015, at 2:08 PM, Tom Zander via bitcoin-dev > wrote: > On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote: >> (In this case, I don't even believe we have any regulator >> contributors that disagree). > > Regular contributor? > > Please explain how for a fork in the protocol s

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

> On Oct 5, 2015, at 2:30 PM, Gregory Maxwell wrote: > > On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev > wrote: >> Once again, let’s use the current gridlock > > Allow me to state unequivocally-- since we've had problems with people > stating non-

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

> On Oct 5, 2015, at 6:37 PM, Tom Harding via bitcoin-dev > wrote: > > On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote: >> In this case, I don't even believe we have any regulator contributors >> that disagree. > > Since Gavin Andresen chose you to be one of 4 people who decides wh

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

> If we want decentralization (or even mere stability), we must impose a > counterbalancing rule such that each past commit makes one *less* likely to > get their next commit pulled. For example, a "one man one commit" policy. Haha great stuff, NotMike! Indeed, it’s not enough to keep the bloc

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

> On Oct 29, 2015, at 8:35 PM, Gregory Maxwell via bitcoin-dev > wrote: > > On Fri, Oct 30, 2015 at 3:04 AM, Simon Liu via bitcoin-dev > wrote: >> Given that UTXO storage is considered critical, it seems reasonable to > > This sounds like a misunderstanding of what consensus criticial means.

Re: [bitcoin-dev] How to evaluate block size increase suggestions.

> It looks like some specific meta-level criteria would help more at this point > than new proposals all exploring a different variants of block size increase > schedules. I agree. In fact, I’ll go meta on your meta and suggest that we should first discuss how Bitcoin should be governed in the

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

Hi Greg, Like you said, the issue with using more than one database technology is not that one node would prove that Block X is valid while the another node proves that Block X is NOT valid. Instead, the problem is that one node might say “valid” while the other node says “I don’t know.” It i

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

> On Nov 14, 2015, at 5:08 PM, Gregory Maxwell wrote: > > On Sun, Nov 15, 2015 at 1:02 AM, Peter R wrote: >> Hi Greg, >> >> Like you said, the issue with using more than one database technology is not >> that one node would prove that Block X is valid while the another node >> proves that Bl

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

> On Nov 14, 2015, at 6:10 PM, Gregory Maxwell wrote: > > On Sun, Nov 15, 2015 at 1:45 AM, Peter R wrote: >> My previous email described how Type 1 consensus failures can be safely >> dealt with. These include many kinds of database exceptions (e.g., the >> LevelDB fork at block #225,430), o

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

> On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote: >> A group of us have been exploring this “meta-cognition” idea with Bitcoin >> Unlimited. For example, Bitcoin Unlimited can be (optionally) made to >> automatically fork to the longest chain if it

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

Hi Greg, >> Thank you for conceding on that point. > > You're welcome, but I would have preferred that you instead of your > thanks you would have responded in kind and acknowledged my correction > that other consensus inconsistencies discovered in implementations > thus far (none, that I'm aware

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

> On Nov 15, 2015, at 3:28 AM, Jorge Timón wrote: > > Going back on topic, I believe libconsensus shouldn't depend on any > particular database because assuming it will continue to be stateless > (the current libbitcoinconsensus is stateless) end therefore has no > storage. Agreed. _

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

Hello Jorge: > > What rules does Bitcoin obey? > > Thanks to the worl of many people, part of the consensus rules are finally > encapsulated in the libbitcoinconsensus library. I'm currently writing a > document to complete the encapsulation of the specification of the consensus > rules. > I

Re: [bitcoin-dev] Compact Block Relay BIP

Hi Pieter, > I tried to derive what length of short ids is actually necessary (some > write-up is on > https://gist.github.com/sipa/b2eb2e486156b5509ac711edd16153ed but it's > incomplete). > > For any reasonable numbers I can come up with (in a very wide range), > the number of bits needed is ver

Re: [bitcoin-dev] Compact Block Relay BIP

Greg Maxwell wrote: > What are you talking about? You seem profoundly confused here... > > I obtain some txouts. I write a transaction spending them in malleable > form (e.g. sighash single and an op_return output).. then grind the > extra output to produce different hashes. After doing this 2^3

Re: [bitcoin-dev] Compact Block Relay BIP

new TX you randomly generate. Performing these operations can probably be reduced to N lg N complexity, which is doable for N ~2^32. In other words, I now agree that the attack is feasible. Cheers, Peter hat tip to egs > On May 9, 2016, at 4:37 PM, Peter R via bitcoin-dev >

[bitcoin-dev] Towards Massive On-Chain Scaling: Presenting Our Block Propagation Results With Xthin

Dear all, For the past two months, Andrew Clifford, Andrew Stone, @sickpig, Peter Tschipper and I have been collecting empirical data regarding block propagation with Xthin — both across the normal P2P network and over the Great Firewall of China. We have six Bitcoin Unlimited (BU) nodes runnin

[bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

Dear all, Bitcoin Unlimited’s market-based solution to the block-size limit is slowly winning support from node operators and miners. With this increased attention, many people are asking for a better explanation of how Bitcoin Unlimited actually works. The article linked below describes how

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

Great discussion, Sergio and Tom! > I now think my reasoning and conclusions are based on a false premise: that > BU block size policies for miners can be heterogeneous. Right, miners who set their block size limits (BSL) above OR below the "effective BSL" are disadvantaged. Imagine that we p

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

One of the purported benefits of a soft-forking change (a tightening of the consensus rule set) is the reduced risk of a blockchain split compared to a loosening of the consensus rule set. The way this works is that miners who fail to upgrade to the new tighter ruleset will have their non-compl

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

ower when blocks become larger, then why not change the proof-of-work? This would certainly result in a peaceful splitting, as you said you desire. Best regards, Peter R > > On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev > <mailto:bitcoin-dev@lists.linuxfounda

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

I believe nearly everyone at Bitcoin Unlimited would be supportive of a UTXO check-pointing scheme. I’d love to see this happen, as it would greatly reduce the time needed to get a new node up-and-running, for node operators who are comfortable trusting these commitments. I’m confident that

Re: [bitcoin-dev] Rolling UTXO set hashes

Hi Pieter, I wanted to say that I thought this write-up was excellent! And efficiently hashing the UTXO set in this rolling fashion is a very exciting idea!! Peter R > On May 15, 2017, at 1:01 PM, Pieter Wuille via bitcoin-dev > wrote: > > Hello all, > > I would like to discuss a way of c

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

Dear Bitcoin-Dev Mailing list, I’d like to share a research paper I’ve recently completed titled “A Transaction Fee Market Exists Without a Block Size Limit.” In addition to presenting some useful charts such as the cost to produce large spam blocks, I think the paper convincingly demonstrates

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

t regards, Peter > > On Tue, Aug 4, 2015 at 8:40 AM, Peter R via bitcoin-dev > wrote: > Dear Bitcoin-Dev Mailing list, > > I’d like to share a research paper I’ve recently completed titled “A > Transaction Fee Market Exists Without a Block Size Limit.” In addition to

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

Whether miners with larger value of h/H have a profit advantage, I'm not sure (but that was outside the scope of the paper anyways). Best regards, Peter >> On 3 Aug 2015, at 23:40, Peter R via bitcoin-dev >> wrote: >> >> Dear Bitcoin-Dev Mailing list,

Re: [bitcoin-dev] Fees and the block-finding process

> ...blocks are found at random intervals. > > Every once in a while the network will get lucky and we'll find six blocks in > ten minutes. If you are deciding what transaction fee to put on your > transaction, and you're willing to wait until that six-blocks-in-ten-minutes > once-a-week event,

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

Hello Matt and Daniele, > this seems to ignore the effects of transaction validation caches and block > compression protocols. The effect of block compression protocols is included. This is what I call the "coding gain" and use the Greek letter "gamma" to represent. As long as the block sol

[bitcoin-dev] Fwd: Your Gmaxwell exchange

Dear Greg, I am moving our conversation into public as I've recently learned that you've been forwarding our private email conversation verbatim without my permission [I received permission from dpinna to share the email that proves this fact: http://pastebin.com/jFgkk8M3]. > Greg wrote to Pete

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

Hello Matt, > It is not a purely academic scenario that blocks contain effectively no > information (that was not previously relayed). The results of my paper hold unless the information about the included transactions is identically zero. If this information is extremely small, then I agree t

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

> Of course this assumes the network does not change any as a result of > such a system. But such a system provides strong incentives for the > network to centralize in other ways (put all the mining nodes in one DC > for all miners, etc). If all the mining nodes are in one data center, and if all

Re: [bitcoin-dev] Your Gmaxwell exchange

Hi Greg, > Unfortunately, your work extensive as it was made at least two > non-disclosed or poorly-disclosed simplifying assumptions and a significant > system understanding error which, I believe, undermined it completely. > > In short these were: > > * You assume miners do not have the abilit

Re: [bitcoin-dev] Your Gmaxwell exchange

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

[bitcoin-dev] Unlimited Max Blocksize (reprise)

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

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

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

Re: [bitcoin-dev] Your Gmaxwell exchange

On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev wrote: > Even so, decentralization is a means to an end - not an end-goal. It is > essential for Bitcoin to be a useful alternative, of course. I agree. What about decentralization in development? Gavin recently said that he wants

[bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

ust with the part I know instead of > writing from scratch my own implementation. > > On 9/1/2015 2:32 AM, Peter R via bitcoin-dev wrote: > > On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev > > > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: >

Re: [bitcoin-dev] ERRATA CORRIGE + Short Theorem

On 2015-09-01, at 12:56 AM, Peter Todd via bitcoin-dev wrote > > FWIW I did a quick math proof along those lines awhile back too using > some basic first-year math, again proving that larger miners earn more > money per unit hashing power: > > http://www.mail-archive.com/bitcoin-development@lis