Re: [bitcoin-dev] difficulty adjustment (was: The Nuclear Option: BIP148 + MR POWA)
Hi, > I would also highly advise finding a simple and robust difficulty adjustment > that occurs every block instead of bitcoin/litecoin's 2016 block use. I also thought about this some time ago. But note that this implies that forks grow with the same block frequency as the main chain. Thus the longest chain rule becomes irrelevant, since all chains will have the same length (in expectancy). Rather, the chain with most work is the true one. Best Henning On Wed, Jul 05, 2017 at 02:02:08PM +, Troy Benjegerdes via bitcoin-dev wrote: > The fastest way to triple Bitcoin capacity is to split the network into > two or three different blockchains. We encourage forks of software, why > are blockchains somehow different? > > Yes, this is risky, and probably volatile. > > I honestly don't expect lots of people with large amounts of money > invested (exchanges, financial institutions, etc) to go along with > something like this, and that say 90% of the wealth with stay concentrated > in whatever chain has the majority SHA256 hashpower. > > But as a game-theory excercise to see who's theories actually work? > > I highly encourage a real-world test of all these theories. > > I would also highly advise finding a simple and robust difficulty adjustment > that occurs every block instead of bitcoin/litecoin's 2016 block use. > > On Wed, Jul 05, 2017 at 09:18:36AM +, John Hardy via bitcoin-dev wrote: > > This idea is highly contentious as it would guarantee a viable chain of > > Bitcoin with SegWit activated whether BIP148 gained sufficient support or > > not. I am not necessarily advocating it - just putting it out for > > discussion. While the downside is that it could permanently split the > > network, the upside is that it could heap additional pressure on miners to > > follow the BIP148 chain and ensure a minimally disruptive upgrade. This is > > pure game theory. > > > > > > > > MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce > > an additional proof of work to a blockchain in response to a detected > > mining behaviour. > > > > > > > > In the case of BIP148, the criteria for activation could be when the > > software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) > > ahead of a BIP148 compliant chain. > > > > > > > > At this stage the software would change its consensus rules (hard fork) to > > do two things: > > > > * Lower the difficulty for existing PoW method (SHA256). > > > > * Introduce a second POW method, such as Scrypt or Ethash, that is > > incompatible with SHA256 hardware but already has an established mining > > industry for altcoins. > > > > > > > > The difficulty should be low, and blocks will initially be found much more > > quickly than every 10 minutes until the difficulty adjusts. Each method > > would have its own difficulty. It could be a requirement that POW methods > > alternate to neutralise attacks from the other chain. > > > > > > > > This would guarantee SegWit activation. Anybody who is already running a > > BIP148 node could just as easily run a BIP148 + MR POWA node. This could > > not realistically be supported by Core and would have to be implemented in > > a grassroots movement, similar to BIP148. > > > > > > > > Ideally, it would just force the miners to follow the BIP148 chain (or risk > > the value of their hardware being hurt) and the code would never be > > activated. MR POWA would mean BIP148 miners would no longer need to ?hold > > their nerve? as they would be guaranteed a viable chain and rewarded for > > their early support. > > > > > > Regards, > > > > > > John Hardy > > > > j...@seebitcoin.com > > > > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers
itcoin-dev@lists.linuxfoundation.org> escreveu: > > > > > On Feb 24, 2017, at 7:01 PM, Peter Todd <p...@petertodd.org> wrote: > > > > > > On Fri, Feb 24, 2017 at 05:49:36PM -0600, Steve Davis via bitcoin-dev > > > wrote: > > >> If the 20 byte SHA1 is now considered insecure (with good reason), what > > >> about RIPEMD-160 which is the foundation of Bitcoin addresses? > > > > > > SHA1 is insecure because the SHA1 algorithm is insecure, not because > > > 160bits isn't enough. > > > > > > AFAIK there aren't any known weaknesses in RIPEMD160, > > > > …so far. I wonder how long that vacation will last? > > > > > but it also hasn't been > > > as closely studied as more common hash algorithms. > > > > ...but we can be sure that it will be, since the dollar value held in > > existing utxos continues to increase... > > > > > That said, Bitcoin uses > > > RIPEMD160(SHA256(msg)), which may make creating collisions harder if an > > > attack > > > is found than if it used RIPEMD160 alone. > > > > Does that offer any greater protection? That’s not so clear to me as the > > outputs (at least for p2pkh) only verify the public key against the final > > 20 byte hash. Specifically, in the first (notional) case the challenge > > would be to find a private key that has a public key that hashes to the > > final hash. In the second (realistic) case, you merely need to add the > > sha256 hash into the problem, which doesn’t seem to me to increase the > > difficulty by any significant amount? > > > > > > /s > > _______ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Currency
Hi Ben, not sure if this is the right mailing list for that. I think it rather belongs to bitcoin-discuss. And I am also not sure if I understand your question. What you may mean is the private key of a user. If you find this, you can spend his funds and also prove that you own the funds. Depending on your level of understanding of Bitcoin, this blogpost may be insightful for you: http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/ All the best Henning On Tue, Dec 13, 2016 at 11:13:24AM +, Ben West via bitcoin-dev wrote: > Hello all; > is there any number or id that determine uniquely the BTC value. > otherwise; is there any hash or address or key that when found we could say > this is my 50BTC or my 20BTC ?. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] 1 Year bitcoin-dev Moderation Review
Hi all, I totally agree with the assessment of the situation. Previously I learned a lot about bitcoin on this list. There were a lot of great ideas regarding the protocol and the surrounding ecosystem. Now there is mainly talk about code and BIPs, which is the main purpose of a developer list. I do not feel that we should clog bitcoin-dev again with non-development talk but rather find a way to get bitcoin-discuss going. My impression is that bitcoin-discuss has not reached a critical mass of contributors. The question is how we can change that. All the best Henning On Sun, Oct 09, 2016 at 12:26:07PM +0200, Jeremy via bitcoin-dev wrote: > Hi bitcoin-dev, > > I'm well aware that discussion of moderation on bitcoin-dev is > discouraged*. However, I think that we should, as a year of moderation > approaches, discuss openly as a community what the impact of such policy > has been. Making such a post now is timely given that people will have the > opportunity to discuss in-person as well as online as Scaling Bitcoin is > currently underway. On the suggestion of others, I've also CC'd > bitcoin-discuss on this message. > > Below, I'll share some of my own personal thoughts as a starter, but would > love to hear others feelings as well. > > For me, the bitcoin-dev mailing list was a place where I started > frequenting to learn a lot about bitcoin and the development process and > interact with the community. Since moderation has begun, it seems that the > messages/day has dropped drastically. This may be a nice outcome overall > for our sanity, but I think that it has on the whole made the community > less accessible. I've heard from people (a > 1 number, myself included) > that they now self-censor because they think they will put a lot of work > into their email only for it to get moderated away as trolling/spam. Thus, > while we may not observe a high rate of moderated posts, it does mean the > "chilling effect" of moderation still manifests -- I think that people not > writing emails because they think it may be moderated reduces the rate of > people writing emails which is a generally valuable thing as it offers > people a vehicle through which they try to think through and communicate > their ideas in detail. > > Overall, I think that at the time that moderation was added to the list, it > was probably the right thing to do. We're in a different place as a > community now, so I feel we should attempt to open up this valuable > communication channel once again. My sentiment is that we enacted > moderation to protect a resource that we all felt was valuable, but in the > process, the value of the list was damaged, but not irreparably so. > > Best, > > Jeremy > > > * From the email introducing the bitcoin-dev moderation policy, "Generally > discouraged: shower thoughts, wild speculation, jokes, +1s, non-technical > bitcoin issues, rehashing settled topics without new data, moderation > concerns." > > > -- > @JeremyRubin <https://twitter.com/JeremyRubin> > <https://twitter.com/JeremyRubin> > _______ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Hiding entire content of on-chain transactions
Hi Tony, > > Regarding the blinding factor, I think you could just use HMAC. > How exactly? I am not entirely sure if this works. You wrote: > There is one technical nuance that I omitted above to avoid distraction. > Unlike regular bitcoin transactions, every output in a private payment > must also include a blinding factor, which is just a random string. When > the output is spent, the corresponding spend proof will therefore depend on > this blinding factor (remember that spend proof is just a hash of the > output). Without a blinding factor, it would be feasible to pre-image the > spend proof and reveal the output being spent as the search space of all > possible outputs is rather small. Instead of a hash function you may use a keyed hash function (HMAC) where the key is just the random string. They key needs to be stored in the history of the coin to allow for verification. Best Henning On Mon, Aug 08, 2016 at 07:03:28PM +0300, Tony Churyumoff wrote: > Hi Henning, > > 1. The fees are paid by the enclosing BTC transaction. > 2. The hash is encoded into an OP_RETURN. > > > Regarding the blinding factor, I think you could just use HMAC. > How exactly? > > Tony > > > 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.k...@uni-ulm.de>: > > > Hi Tony, > > > > I see some issues in your protocol. > > > > 1. How are mining fees handled? > > > > 2. Assume Alice sends Bob some Coins together with their history and > > Bob checks that the history is correct. How does the hash of the txout > > find its way into the blockchain? > > > > Regarding the blinding factor, I think you could just use HMAC. > > > > All the best > > Henning > > > > > > On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev > > wrote: > > > This is a proposal about hiding the entire content of bitcoin > > > transactions. It goes farther than CoinJoin and ring signatures, which > > > only obfuscate the transaction graph, and Confidential Transactions, > > which > > > only hide the amounts. > > > > > > The central idea of the proposed design is to hide the entire inputs and > > > outputs, and publish only the hash of inputs and outputs in the > > > blockchain. The hash can be published as OP_RETURN. The plaintext of > > > inputs and outputs is sent directly to the payee via a private message, > > and > > > never goes into the blockchain. The payee then calculates the hash and > > > looks it up in the blockchain to verify that the hash was indeed > > published > > > by the payer. > > > > > > Since the plaintext of the transaction is not published to the public > > > blockchain, all validation work has to be done only by the user who > > > receives the payment. > > > > > > To protect against double-spends, the payer also has to publish another > > > hash, which is the hash of the output being spent. We’ll call this hash > > *spend > > > proof*. Since the spend proof depends solely on the output being spent, > > > any attempt to spend the same output again will produce exactly the same > > > spend proof, and the payee will be able to see that, and will reject the > > > payment. If there are several outputs consumed by the same transaction, > > > the payer has to publish several spend proofs. > > > > > > To prove that the outputs being spent are valid, the payer also has to > > send > > > the plaintexts of the earlier transaction(s) that produced them, then the > > > plaintexts of even earlier transactions that produced the outputs spent > > in > > > those transactions, and so on, up until the issue (similar to coinbase) > > > transactions that created the initial private coins. Each new owner of > > the > > > coin will have to store its entire history, and when he spends the coin, > > he > > > forwards the entire history to the next owner and extends it with his own > > > transaction. > > > > > > If we apply the existing bitcoin design that allows multiple inputs and > > > multiple outputs per transaction, the history of ownership transfers > > would > > > grow exponentially. Indeed, if we take any regular bitcoin output and > > try > > > to track its history back to coinbase, our history will branch every time > > > we see a transaction that has more than one input (which is not > > uncommon). > > > After such a transaction (remember, we are traveling back in time), we’ll > > > have to trac
Re: [bitcoin-dev] Hiding entire content of on-chain transactions
of the coin, not every bitcoin node. This is a fairer allocation of > costs. Regarding privacy, coin histories do expose private transactions > (or rather parts thereof, since a typical payment will likely consist of > several transactions due to one-input-per-transaction rule) of past coin > owners to the future ones, and that exposure grows linearly with time, but > it is still much much better than having every transaction immediately on > the public blockchain. Also, the value of this information for potential > adversaries arguably decreases with time. > > There is one technical nuance that I omitted above to avoid distraction. > Unlike regular bitcoin transactions, every output in a private payment > must also include a blinding factor, which is just a random string. When > the output is spent, the corresponding spend proof will therefore depend on > this blinding factor (remember that spend proof is just a hash of the > output). Without a blinding factor, it would be feasible to pre-image the > spend proof and reveal the output being spent as the search space of all > possible outputs is rather small. > > To issue the new private coin, one can burn regular BTC by sending it to > one of several unspendable bitcoin addresses, one address per denomination. > Burning BTC would entitle one to an equal amount of the new private coin, > let’s call it *black bitcoin*, or *BBC*. > > Then BBC would be transferred from user to user by: > 1. creating a private transaction, which consists of one input and several > outputs; > 2. storing the hash of the transaction and the spend proof of the consumed > output into the blockchain in an OP_RETURN (the sender pays the > corresponding fees in regular BTC) > 3. sending the transaction, together with the history leading to its input, > directly to the payee over a private communication channel. The first > entry of the history must be a bitcoin transaction that burned BTC to issue > an equal amount of BCC. > > To verify the payment, the payee: > 1. makes sure that the amount of the input matches the sum of outputs, and > all are divisible by the denomination > 2. calculates the hash of the private transaction > 3. looks up an OP_RETURN that includes this hash and is signed by the > payee. If there is more than one, the one that comes in the earlier block > prevails. > 4. calculates the spend proof and makes sure that it is included in the > same OP_RETURN > 5. makes sure the same spend proof is not included anywhere in the same or > earlier blocks (that is, the coin was not spent before). Only transactions > by the same author are searched. > 6. repeats the same steps for every entry in the history, except the first > entry, which should be a valid burning transaction. > > To facilitate exchange of private transaction data, the bitcoin network > protocol can be extended with a new message type. Unfortunately, it lacks > encryption, hence private payments are really private only when bitcoin is > used over tor. > > There are a few limitations that ought to be mentioned: > 1. After user A sends a private payment to user B, user A will know what > the spend proof is going to be when B decides to spend the coin. > Therefore, A will know when the coin was spent by B, but nothing more. > Neither the new owner of the coin, nor its future movements will be known > to A. > 2. Over time, larger outputs will likely be split into many smaller > outputs, whose amounts are not much greater than their denominations. > You’ll have to combine more inputs to send the same amount. When you want > to send a very large amount that is much greater than the highest available > denomination, you’ll have to send a lot of private transactions, your > bitcoin transaction with so many OP_RETURNs will stand out, and their > number will roughly indicate the total amount. This kind of privacy > leakage, however it applies to a small number of users, is easy to avoid by > using multiple addresses and storing a relatively small amount on each > address. > 3. Exchanges and large merchants will likely accumulate large coin > histories. Although fragmented, far from complete, and likely outdated, it > is still something to bear in mind. > > No hard or soft fork is required, BBC is just a separate privacy preserving > currency on top of bitcoin blockchain, and the same private keys and > addresses are used for both BBC and the base currency BTC. Every BCC > transaction must be enclosed into by a small BTC transaction that stores > the OP_RETURNs and pays for the fees. > > Are there any flaws in this design? > > Originally posted to BCT https://bitcointalk.org/index.php?topic=1574508.0, > but got no feedback so far, apparently everybody
Re: [bitcoin-dev] Making AsicBoost irrelevant
On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev wrote: > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > There is no way to tell from a block if it was mined with AsicBoost or > > not. So you don’t know what percentage of the hashrate uses AsicBoost at > > any point in time. How can you risk forking that percentage out? Note that > > this would be a GUARANTEED chain fork. Meaning that after you change the > > block mining algorithm some percentage of hardware will no longer be able > > to produce valid blocks. That hardware cannot “switch over” to the majority > > chain even if it wanted to. Hence you are guaranteed to have two > > co-existing bitcoin blockchains afterwards. > > > > Again: this is unlike the hypothetical persistence of two chains after a > > hardfork that is only contentious but doesn’t change the mining algorithm, > > the kind of hardfork you are proposing would guarantee the persistence of > > two chains. > > > > Assuming AsicBoost miners are in the minority, their chain will constantly > get overtaken. So it will not be one endless hard fork as you claim, but > rather AsicBoost blocks will continue to be ignored (orphaned) until they > stop making them. At least until a difficulty adjustment on the AsicBoost chain takes place. From that point on, both chains, the AsicBoost one and the forked one will grow approximately at the same speed. All the best Henning -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Hi, > However, I think it could actually increase > confidence in the system if the community is able to demonstrate a good > process for making such decisions, and show that we can separate the > meaningful underlying principles, such as the coin limit and overall > inflation rate, from what is more akin to an implementation detail, as I > consider the large-step reward reduction to be. I do not think that a line can be drawn here. As far as I understood, you think that the coin limit is a meaningful underlying principle which should not be touched, whereas the halving of mining rewards is an implementation detail. The two are very closely tied together and changes to both of them would result in a hardfork, if I am not mistaken. Regarding the effects of the mining reward halving, there is a nice paper from courtois: http://arxiv.org/abs/1405.0534 All the best Henning On Thu, Mar 03, 2016 at 10:27:35AM -0800, Corey Haddad via bitcoin-dev wrote: > Since the root cause of what you are trying to address is the reward > having, I'd suggest considering an adjustment to the having schedule. > Instead of their being a large supply shock every four years, perhaps the > reward could drop every 52,500 blocks (yearly), or even at each difficulty > adjustment, in such a way that the inflation curve is smoothed out. The > exponential decay rate would be preserved, so overall economic philosophy > would be preserved. > > I'm guessing hesitance to this approach would lie in a reluctance to tinker > with Bitcoin's 'economic contract', and slippery slope concerns about might > be the next change (21M?). However, I think it could actually increase > confidence in the system if the community is able to demonstrate a good > process for making such decisions, and show that we can separate the > meaningful underlying principles, such as the coin limit and overall > inflation rate, from what is more akin to an implementation detail, as I > consider the large-step reward reduction to be. > > I'm not too worried about the impact of the having as is, but adjusting the > economic parameter would be a safer and simpler way to address the concerns > than to tinker with the difficulty targeting mechanism, which is at the > heart of Bitcoin's security > > On Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > We are coming up on the subsidy halving this July, and there have been some > > concerns raised that a non-trivial number of miners could potentially drop > > off > > the network. This would result in a significantly longer block interval, > > which > > also means a higher per-block transaction volume, which could cause the > > block > > size limit to legitimately be hit much sooner than expected. Furthermore, > > due > > to difficulty adjustment being measured exclusively in blocks, the time > > until > > it adjusts to compensate would be prolonged. > > > > For example, if 50% of miners dropped off the network, blocks would be > > every > > 20 minutes on average and contain double the transactions they presently > > do. > > Even double would be approximately 850-900k, which potentially bumps up > > against the hard limit when empty blocks are taken into consideration. This > > situation would continue for a full month if no changes are made. If more > > miners drop off the network, most of this becomes linearly worse, but due > > to > > hitting the block size limit, the backlog would grow indefinitely until the > > adjustment occurs. > > > > To alleviate this risk, it seems reasonable to propose a hardfork to the > > difficulty adjustment algorithm so it can adapt quicker to such a > > significant > > drop in mining rate. BtcDrak tells me he has well-tested code for this in > > his > > altcoin, which has seen some roller-coaster hashrates, so it may even be > > possible to have such a proposal ready in time to be deployed alongside > > SegWit > > to take effect in time for the upcoming subsidy halving. If this slips, I > > think it may be reasonable to push for at least code-readiness before July, > > and possibly roll it into any other hardfork proposed before or around that > > time. > > > > I am unaware of any reason this would be controversial, so if anyone has a > > problem with such a change, please speak up sooner rather than later. Other > > ideas or concerns are of course welcome as well. > > > > Thanks, > > > > Luke > > _______ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.l
Re: [bitcoin-dev] Defining a min spec
Hi Jean-Paul, that's a very interesting point of view and I have never thought about it this way, since I have a totally different background. How would you go on about defining a min spec? Is this done by testing the software on different hardware configurations or are you looking at the requirements a priori? Best regards Henning On Wed, Jul 01, 2015 at 09:04:19PM -0700, Jean-Paul Kogelman wrote: Hi folks, I’m a game developer. I write time critical code for a living and have to deal with memory, CPU, GPU and I/O budgets on a daily basis. These budgets are based on what we call a minimum specification (of hardware); min spec for short. In most cases the min spec is based on entry model machines that are available during launch, and will give the user an enjoyable experience when playing our games. Obviously, we can turn on a number of bells and whistles for people with faster machines, but that’s not the point of this mail. The point is, can we define a min spec for Bitcoin Core? The number one reason for this is: if you know how your changes affect your available budgets, then the risk of breaking something due to capacity problems is reduced to practically zero. One way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level. So taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec? For example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc. Every change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade. Once we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis. Lastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup. What do you guys think? jp ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
