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,

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] Defending against empty or near empty blocks from malicious miner takeover?

ks 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 > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bi

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

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

[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

[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

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 > <bi

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

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

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] [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

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] 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

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

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

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

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

> On Oct 5, 2015, at 2:30 PM, Gregory Maxwell <gmaxw...@gmail.com> wrote: > > On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: >> Once again, let’s use the current gridlock > > Allow me to state uneq

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

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

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] 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

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

[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

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 ability to

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] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests

via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org 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 presenting some useful charts such as the cost

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

). Best regards, Peter On 3 Aug 2015, at 23:40, Peter R via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org 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

[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