Re: [bitcoin-dev] [bitcoin-discuss] Checkpoints in the Blockchain.

Our wetware memory is faulty at details, but a rendering that provides features at which it isn't faulty makes it a decent backup in situations where technology has been used to hide important differences from us. Some of us may recall being in a situation where something seems off, and we start t

[bitcoin-dev] Proposal to replace full blockchain with recent history plus UTXO Set

I've been working on an idea that relieves full nodes of storing the entire blockchain. Open source software generally relies on the fact that "enough" people agree that it's secure. Bitcoin software works that way too. So if you understand enough to see that a UTXO set is valid at a certain block

Re: [bitcoin-dev] Proposal to replace full blockchain with recent history plus UTXO Set

The image at imgur and the pastebin both reference block 542324 but the correct block is 542322. As the pastebin shows, the decimal and hex representations I gave for the block height did not match, and this is why. If you use the Merkle root for block 542322 instead of 542324, you'll be able to

[bitcoin-dev] How much is too much time between difficulty changes?

The last difficulty change took about 20% longer than expected. How large does the time between difficulty changes have to get for us to make changes? In other words, if, at some point, block confirmation times are averaging, say, hours or days, will we hardfork to speed things up? One option is

Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC

I think EXACTLY ONE YEAR is the perfect time. Well, a year and a day for me because I'm on the wrong side of the date line, apparently. On Sun, Mar 31, 2019 at 6:04 PM Ricardo Filipe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > one year seems too long. i think with the BIP-1

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

Every block's hash is smaller than the difficulty at that time. Block 569927's hash was VERY small (started with 21 zeros). The ratio of block hash to difficulty requirement (0x - difficulty, I think) could be used to identify blocks as "special," thus providing the opportunity to popular

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

On Sat, Apr 13, 2019 at 12:09 PM Peter Todd wrote: > On Wed, Apr 03, 2019 at 02:39:32PM -0700, Dave Scotese via bitcoin-dev > wrote: > > Every block's hash is smaller than the difficulty at that time. Block > > 569927's hash was VERY small (started with 21 zer

[bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain.

Currently, bitcoin must be redeemed by providing input to a script which results in the required output. This causes the attached amount of bitcoin to become available for use in the outputs of a transaction. Is there any work on creating a shorter "transaction" which, instead of creating a new o

[bitcoin-dev] Block solving slowdown question/poll

It seems that many on this list think deeply enough to imagine the scenario where we have few days left before a difficulty adjustment comes up but we also see mining power dropping off at a rate that suggests the few days might become a few weeks, and then, possibly, a few months or even the unth

Re: [bitcoin-dev] Block solving slowdown question/poll

t:* Sunday, 22 March 2020 6:54 PM > *To:* Dave Scotese ; Bitcoin Protocol Discussion > > *Subject:* Re: [bitcoin-dev] Block solving slowdown question/poll > > On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev > wrote: > > [Imagine] we also see mining power

Re: [bitcoin-dev] Block solving slowdown question/poll

I believe this isn't something we need to address. The fact is that every byte stored in the blockchain is already valuable to everyone who downloads the blockchain because of what it allows them to prove - by adding more bytes to it. Over time, the value per byte will increase. Perhaps there wi

[bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

Rather than (promising to, and when they don't actually, at least pretending to) use the first-seen block, I propose that a more sophisticated method of choosing which of two block solutions to accept. Essentially, a miner receiving two solutions at the same height would compute a weighted sum of b

Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

> > issue. > > How do you know which of 2 blocks with the same height is "newer"? > > > On 11 September 2015 at 12:32, Jorge Timón > > wrote: > > > > > > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev" > > > wrote:

Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic

> > From the Bitcoin wiki page on transaction fees > : > > Transaction priority is calculated as a value-weighted sum of input age, > divided by transaction size in bytes: priority = > sum(input_value_in_base_units * input_age)/size_in_byt

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

"But if a metric were chosen that addressed my concerns (worst case propagation and validation time), then I could be in favor of an initial bump that allowed a larger number of typical transactions in a block." +1. A ratio is much more valuable than a simple metric. It seems clearly difficult t

Re: [bitcoin-dev] Weekly development meetings on IRC

I am in a timezone that uses DST (currently PDT), but I would like us to use a timezone that does NOT use DST. It will be nice to have something that reflects the seasonal patterns like my own body does. I hate the time change in both ways. On Fri, Sep 18, 2015 at 2:50 PM, Luke Dashjr via bitcoi

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

It seems there should be a practical limit to the size of a re-org - I mean a practical limit that is smaller than the current height. Vincent's proposal suggests that a year's worth of blocks is such a practical limit. I agree. There are probably lower limits that are practical too, but I like a

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

phm got most of this, but... On Sat, Sep 19, 2015 at 2:53 PM, phm via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Mike Hearn via bitcoin-dev wrote: > > > > > * Most governments can easily spend enough money to do a 51% attack, > > especially if they can compel chip fabs to

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

Mike wrote: ... Obama would like to restrict guns, but can't, because they are too popular (in the USA). ... Governments tolerate this sort of abuse [black markets] only because they believe, I think correctly, that Bitcoin can have great benefits for their ordinary voters and for now are willing t

Re: [bitcoin-dev] libconsensus and bitcoin development process

If I'm reading this situation correctly, Jeff is basically pointing out that developers need more links (hooks, rungs, handholds, data points, whatever you want to call them) so that they can see all the things his email insinuated are missing (a plan, order, sense, etc.). He didn't say these thin

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Why are they called soft forks when they are really hidden forks? Isn't the point of a soft fork to prevent old clients from rejecting what they don't have the code to validate? That seems dangerous. notplato On Mon, Sep 28, 2015 at 2:12 PM, odinn via bitcoin-dev < bitcoin-dev@lists.linuxfounda

Re: [bitcoin-dev] Design Competition

I am waiting for the bitcoin (not bitcoin-dev) mailing list so that anyone who writes "That's off-topic" can also include a link to it. Someone else mentioned that they read all these emails in about 15 minutes. I'm a bit slower than that, but I'm reading the vitcoin-xt stuff too. It isn't too m

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

If the PoW function is changed, it ought to change slowly so as not to drop a brick wall in front of the miners speeding toward the ever-receding goal of protecting the blockchain. Who's going to get on that path if the bitcoin community does that? But it can be done slowly. If most of the entri

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

I prefer the hard fork because the complexity introduced by soft forks scares me. At http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011309.html Gregory wrote: "Security requires a bit of vigilance, inherently." and [A non-upgraded miner will end up] "*> producing invalid blo

[bitcoin-dev] Masked bits and isStandard

Thanks again. The description of bits 16..29 as "can take any value" suggests to me an improvement for isStandard: if any bits "can take any value" without affecting the script then they must be off for the script to pass isStandard. If I understand it correctly, this requirement will serve as a

Re: [bitcoin-dev] Memory leaks?

{ "size" : 1085, "bytes" : 16151768 } It has been running about a day. I'll report tomorrow too. This is a Windows 8.1 box. 16 million divided by 1085 transactions is almost 15Kb per transaction = unlikely, right? On Tue, Oct 13, 2015 at 4:14 PM, Jonathan Toomim (Toomim Bros) wrote: > > On O

Re: [bitcoin-dev] Memory leaks?

as the > main determinant of memory usage scaling. Can you tell me how much memory > Task Manager is reporting your bitcoin process as using both today and > tomorrow? > > On Oct 13, 2015, at 4:52 PM, Dave Scotese via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote:

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

What is required to spend bitcoin is that input be provided to the UTXO script that causes it to return true. What Chris is proposing breaks the programmatic nature of the requirement, replacing it with a requirement that the secret be known. Granted, the secret is the only requirement in most ca

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

gt; >> On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" < > >> bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > >>>> This idea could be applied by having the wildcard signature apply to > >>>> all > >>>&g

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

I was curious about there being only 10 single-byte opcodes left. There are ten single-byte OP_NOPx opcodes defined, but there are 15 opcodes that "simply *do not exist anymore* in the protocol" because they are scary (had bugs that "could crash any Bitcoin node if exploited" or "allowed anyone to

Re: [bitcoin-dev] [BIP Draft] Datastream compression of Blocks and Transactions

Emin's email presents to me the idea of dictionaries that already contain the data we'd want to compress. With 8 bytes of indexing data, we can refer to a TxID or a Public Key or any existing part of the blockchain. There are also data sequences like scripts that contain a few variable chunks and

Re: [bitcoin-dev] Scaling by Partitioning

If we partition the work using bits from the TxID (once it is no longer malleable) or even bits from whatever definition we use for "coin," then every transaction may have to use all the other partitions to verify that the incoming coin is good. If all partitions are involved in validating and sto

Re: [bitcoin-dev] Scaling by Partitioning

Edit: "... as well as those blocks with hashes for which the last B bits match any of the next N bit patterns where *N is largest* integer for which the claimed output is not *greater* than (subsidy+fees)*(N/(2^B)). On Wed, Dec 9, 2015 at 8:08 PM, Dave Scotese wrote: > If we partition the work u

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I indeed think we can communicate much better that deciding consensus > rules is not within our power. I'm not a core dev, so maybe I have the power to change the consensus rules. No o

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

I've already publicly declared that I offer one bitcoin to "those who suffer from a May 5, 2016 hardfork to 2MB blocks" but that's probably way too sloppy. Here's a better idea that transmits the economic power of merchants and customers (well, anyone with bitcoin) to the miners on whom they must

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

A couple observations: - The consensus block limit is different than the disk space required to do validation. Some participants are worried about one and some about the other, and sometimes they feel what amounts to an imaginary contention because they perceive these two different th

Re: [bitcoin-dev] We need to fix the block withholding attack

There have been no decent objections to altering the block-selection mechanism (when two block solutions appear at nearly the same time) as described at http://bitcoin.stackexchange.com/questions/39226 Key components are: - Compute BitcoinDaysDestroyed using only transactions that have been i

Re: [bitcoin-dev] We need to fix the block withholding attack

ld this possibly be enforced? > > On Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> There have been no decent objections to altering the block-selection >> mechanism (when two block solutions appear at ne

Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?

Maybe I'm being dense, but I don't see why 2**80 storage is required for this attack. Also, I don't see why the attacker ever needs to get the victim to accept "arbitrary_data". Perhaps I'm wrong about how the collision attack works: 1. Create a script which is perfectly acceptable and would

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

This seems like a good place to point out that attempts to identify individuals (either by name or simply as an individual human being) are futile as well as destructive. "1%" usually means "one out of every 100 people" but this requires identification of individuals as individuals. One person can

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

I agree with the prohibition of +1s. The core competency of those who provide this list are moderation and technology, not managing a process through which "involved people [indicate] whether they're for or against it." That is certainly an excellent function, but it can be offered by anyone who

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

+1 The distinction we are making importantly requires that contributors provide readers with another thing to say in favor of something - another thing which is different than "X people support this instead of only X-1 people." Evidence trumps votes. On Sat, Jan 23, 2016 at 1:38 PM, Gavin via bit

Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses

The section that starts "Should two software projects need to release" addresses issues that are difficult to ascertain from what is written there. I'll take a stab at what it means: Would bitcoin be better off if multiple applications provided their own implementations of API/RPC and correspondi

Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses

On Mon, Feb 1, 2016 at 11:54 PM, Luke Dashjr wrote: > On Tuesday, February 02, 2016 5:50:29 AM Dave Scotese wrote: > > The section that starts "Should two software projects need to release" > > addresses issues that are difficult to ascertain from what is written > > there. I'll take a stab at w

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

It makes sense to me that there might be objective conditions under which we would want to use a number smaller than 2016. A good example would be a mean time between blocks of more than 20 minutes over the last 144 blocks (one - two days). If such an occurrence ever happened, and the software t

Re: [bitcoin-dev] consensus rule change for TX fee safety

It would be a shame to prohibit someone from rewarding whoever mines their transaction. A good example would be a transaction designed to record some information which is damning to powerful authorities, sort of like the service cryptograffiti offers. When we try to protect others by prohibiting

Re: [bitcoin-dev] Services bit for xthin blocks

I think a BIP is a good idea, but rather than making such a specific proposal as "Let's use bit 4 to indicate communication of thin blocks," how about a more general one like "Let's use bit(s?) 4(-5?) as user-agent specific service bits so that if you customize your user-agent string, you can use t

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

If Alice knows enough to see that she needs CHECKBLOCKATHEIGHT to avoid paying Bob twice, then she also knows that Fred owes her 4BTC. If Bob complains about getting paid faster, Alice can let him know that Fred essentially stole his coins and that when she is certain he (and she) can't get them b

Re: [bitcoin-dev] 1 Year bitcoin-dev Moderation Review

I sent my previous email ONLY to bitcoin-disc...@lists.linuxfoundation.org and it waited in the moderation queue. I don't know when moderation was added to this list, but it seems to me that it's a misstep. On Mon, Oct 10, 2016 at 12:38 AM, Henning Kopp via bitcoin-dev < bitcoin-dev@lists.linuxfo

Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System

There are two ideas here for "on-chain" voting, both of which require changes to the software. I agree with David that on-chain solutions complicate things. Both proposals can be effected without any software changes: Those who wish to use proof of stake can provide a service for making vanity a

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

I was under the impression that RIPEMD160(SHA256(msg)) is used to turn a PUBLIC key (msg) into a bitcoin address, so yeah, you could identify ANOTHER (or the same, I guess - how would you know?) public key that has the same bitcoin address if RIPEMD-160 collisions are easy, but I don't see how that

[bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

I used Google to establish that there is not already a post from 2015 that mentions "roadmap" in the subject line. Such would be a good skeleton for anyone new to the list (like me). 1. Increase the 7 Tx per second - by increasing block size. 2. Do something about the trend toward centralization

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

On Fri, Jul 24, 2015 at 4:38 AM, Mike Hearn wrote: > It's worth noting that even massive companies with $30M USD of funding >> don't run a single Bitcoin Core node > > > This has nothing to do with block sizes, and everything to do with Core > not directly providing the services businesses actual

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 2, Issue 95

> Alternatively I think instead of displaying a meaningless number we ought > to go by a percentage (the double spend improbability) and go by > 'confidence'. That is a great idea, and not too hard to implement. A bit of code can determine over the last N blocks, how many blocks that were at the

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

Incentivize investigations for public consumption. The people on this list are the ones who probably care the most. When I looked up that IP address, the Whois info names "OVH" and "Octave Klaba" (who founded OVH, according to Wikipedia) as the owner. " blockchain.info" appears in the HTML heade

Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal

Here are some books that will help more people understand why Adam's concern is important: Kicking the Dragon (by Larken Rose) The State (by Franz Oppenheimer) Like he said, it isn't much about bitcoin. Our crypto is just one of the defenses we've created, and understanding what it defends will h

Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal

It will help to assume that there is at least one group of evil people who are investing in Bitcon's demise. Not because there are, but because there might be. So let's assume they are making a set of a billion transactions, or a trillion, and maintaining currently-being-legitimately-used hashing

[bitcoin-dev] Wrapping up the block size debate with voting

"Miners can do this unilaterally" maybe, if they are a closed group, based on the 51% rule. But aren't they using full nodes for propagation? In this sense, anyone can vote by coding. If and when we need to vote, a pair-wise runoff ("condorcet method") will find an option that is championed by a

Re: [bitcoin-dev] Fwd: Block size following technological growth

Bitcoin is an irreversible payment system. When you pay someone using its main selling point, which is removing the need for physical presence, you are trusting that person. Bitcoin doesn't obviate trust. It obviates authority. Centralization of trust is what creates the authority that we all r

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

I see value in lowering the block size or leaving it where it is. We expect to run out of space, and I think it's a good idea to prepare for that, rather than avoid it. When we run out of space and the block size is low, we will see problems. If we raise the block size, we will NOT see these prob

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

On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote: > > Someone mentioned that when the backlog grows faster than it shrinks, > that > > is

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

Three things: 1) Hostility is generally the result of perceived hostility. If you assume the best intentions of another person, you will eventually find yourself in one of two places. Either you will find truth with that person (becuase they are also seeking it), or you will drive them away (bec

Re: [bitcoin-dev] Bitcoin XT Fork

At http://media.scmagazine.com/documents/127/virtual_currency_rules_31557.pdf, section 200.3(c)(2) lists "consumers that utilize Virtual Currency solely for the purchase or sale of goods or services or for investment purposes" as "Persons [who] are exempt from the licensing requirements". Who else

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

On Mon, Aug 17, 2015 at 10:13 PM, GC wrote: > Dave, > > “ … highly skilled psychological warfare agents ..” > > Paranoia, much? > > Well, I respect your characterization of it as paranoia, sure. If you check out the #1 podcast in higher education on podomatic.com, you may find that it's more awa

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

I guess every mailing list should have its own internal SNR discussions. My answer is to respond when something is off-topic and offer a different place for the topic. I haven't been doing that, partly because no one else has, but mostly because I figured I don't have a strong handle on what is o

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

Prabhat, You write about OFAC, KYC, and AML. The *Office of Foreign Assets Control* (*OFAC*) is a financial intelligence and enforcement agency of the U.S. government charged with planning and execution of economic and trade sanctions

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

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

Re: [bitcoin-dev] BIP 100 specification

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I suggest revising these items for clarity (and I'm guessing on the first one) Calculate hardLimit by examining the coinbase scriptSig votes of the previous 12,000 blocks, and taking the 20th percentile. A new hardLimit may not increase or dec

Re: [bitcoin-dev] BIP 100 specification

I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and 1,024,000 bytes. I believe the best policy is to use "megabyte" to mean 2^20 (1,048,576) bytes. Kb always means 1024 bytes, even when a lot people round it, so I like the K spec best. I also see value in having human readable da

[bitcoin-dev] Fee estimation requirements

At https://github.com/bitcoin/bitcoin/issues/22404#issuecomment-874168305 no explanation is given for a peculiar rule about estimating fees, that "you have to wait around for a couple of blocks *after* being synced before fee estimation will work." The rule is true, but it needn't be true, and the

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

I believe it's foolish to attempt objective definitions of things that we define collectively, like "Bitcoin." The best any one of us can do is to be consistent with a subjective personal definition. I believe most people do that with the term "Bitcoin" and that the capped supply is intrinsic to