Bitcoin / Address / 19h7oPeqkQeQAqKcNTGKkKr1Xd2AZ85xL2 ...

Technical: The `SIGHASH_NOINPUT` Debate! Chaperones and output tagging and signature replay oh my!

Bitcoin price isn't moving oh no!!! You know WHAT ELSE isn't moving?? SIGHASH_NOINPUT that's what!!!
Now as you should already know, Decker-Russell-Osuntokun ("eltoo") just ain't possible without SIGHASH_NOINPUT of some kind or other. And Decker-Russell-Osuntokun removes the toxic waste problem (i.e. old backups of your Poon-Dryja LN channels are actively dangerous and could lose your funds if you recover from them, or worse, your most hated enemy could acquire copies of your old state and make you lose funds). Decker-Russell-Osuntokun also allows multiparticipant offchain cryptocurrency update systems, without the drawback of a large unilateral close timeout that Decker-Wattenhofer does, making this construction better for use at the channel factory layer.
Now cdecker already wrote a some code implementing SIGHASH_NOINPUT before, which would make it work in current pre-SegWit P2PKH, P2SH, as well as SegWit v0 P2WPKH and P2WSH. He also made and published BIP 118.
But as is usual for Bitcoin Core development, this triggered debate, and thus many counterproposals were made and so on. Suffice it to say that the simple BIP 118 looks like it won't be coming into Bitcoin Core anytime soon (or possibly at all).
First things first: This link contains all that you need to know, but hey, maybe you'll find my take more amusing.
So let's start with the main issue.

Signature Replay Attack

The above is the Signature Replay Attack, and the reason why SIGHASH_NOINPUT has triggered debate as to whether it is safe at all and whether we can add enough stuff to it to ever make it safe.
Now of course you could point to SIGHASH_NONE which is even worse because all it does is say "I am authorizing the spend of this particular coin of this particular value protected by my key" without any further restrictions like which outputs it goes to. But then SIGHASH_NONE is intended to be used to sacrifice your money to the miners, for example if it's a dust attack trying to get you to spend, so you broadcast a SIGHASH_NONE signature and some enterprising miner will go get a bunch of such SIGHASH_NONE signatures and gather up the dust in a transaction that pays to nobody and gets all the funds as fees. And besides; even if we already have something you could do stupid things with, it's not a justification for adding more things you could do stupid things with.
So yes, SIGHASH_NOINPUT makes Bitcoin more powerful. Now, Bitcoin is a strong believer in "Principle of Least Power". So adding more power to Bitcoin via SIGHASH_NOINPUT is a violation of Principle of Least Power, at least to those arguing to add even more limits to SIGHASH_NOINPUT.
I believe nullc is one of those who strongly urges for adding more limits to SIGHASH_NOINPUT, because it distracts him from taking pictures of his autonomous non-human neighbor, a rather handsome gray fox, but also because it could be used as the excuse for the next MtGox, where a large exchange inadvertently pays to SIGHASH_NOINPUT-using addresses and becomes liable/loses track of their funds when signature replay happens.

Output Tagging

Making SIGHASH_NOINPUT safer by not allowing normal addresses use it.
Basically, we have 32 different SegWit versions. The current SegWit addresses are v0, the next version (v1) is likely to be the Schnorr+Taproot+MAST thing.
What output tagging proposes is to limit SegWit version ranges from 0->15 in the bech32 address scheme (instead of 0->31 it currently has). Versions 16 to 31 are then not valid bech32 SegWit addresses and exchanges shouldn't pay to it.
Then, we allow the use of SIGHASH_NOINPUT only for version 16. Version 16 might very well be Schnorr+Taproot+MAST, with a side serving of SIGHASH_NOINPUT.
This is basically output tagging. SIGHASH_NOINPUT can only be used if the output is tagged (by paying to version 16 SegWit) to allow it, and addresses do not allow outputs to be tagged as such, removing the potential liability of large custodial services like exchanges.
Now, Decker-Russell-Osuntokun channels have two options:
The tradeoffs in this case are:
The latter tradeoff is probably what would be taken (because we're willing to pay for privacy) if Bitcoin Core decides in favor of tagged outputs.
Another issue here is --- oops, P2SH-Segwit wrapped addresses. P2SH can be used to wrap any SegWit payment script, including payments to any SegWit version, including v16. So now you can sneak in a SIGHASH_NOINPUT-enabled SegWit v16 inside an ordinary P2SH that wraps a SegWit payment. One easy way to close this is just to disallow P2SH-SegWit from being valid if it's spending to SegWit version >= 16.

Chaperone Signatures

Closing the Signature Replay Attack by adding a chaperone.
Now we can observe that the Signature Replay Attack is possible because only one signature is needed, and that signature allows any coin of appropriate value to be spent.
Adding a chaperone signature simply means requiring that the SCRIPT involved have at least two OP_CHECKSIG operations. If one signature is SIGHASH_NOINPUT, then at least one other signature (the chaperone) validated by the SCRIPT should be SIGHASH_ALL.
This is not so onerous for Decker-Russell-Osuntokun. Both sides can use a MuSig of their keys, to be used for the SIGHASH_NOINPUT signature (so requires both of them to agree on a particular update), then use a shared ECDH key, to be used for the SIGHASH_ALL signature (allows either of them to publish the unilateral close once the update has been agreed upon).
Of course, the simplest thing to do would be for a BOLT spec to say "just use this spec-defined private key k so we can sidestep the Chaperone Signatures thing". That removes the need to coordinate to define a shared ECDH key during channel establishment: just use the spec-indicated key, which is shared to all LN implementations.
But now look at what we've done! We've subverted the supposed solution of Chaperone Signatures, making them effectively not there, because it's just much easier for everyone to use a standard private key for the chaperone signature than to derive a separate new keypair for the Chaperone.
So chaperone signatures aren't much better than just doing SIGHASH_NOINPUT by itself, and you might as well just use SIGHASH_NOINPUT without adding chaperones.
I believe ajtowns is the primary proponent of this proposal.

Toys for the Big Boys

The Signature Replay Attack is Not A Problem (TM).
This position is most strongly held by RustyReddit I believe (he's the Rusty Russell in the Decker-Russell-Osuntokun). As I understand it, he is more willing to not see SIGHASH_NOINPUT enabled, than to have it enabled but with restrictions like Output Tagging or Chaperone Signatures.
Basically, the idea is: don't use SIGHASH_NOINPUT for normal wallets, in much the same way you don't use SIGHASH_NONE for normal wallets. If you want to do address reuse, don't use wallet software made by luke-jr that specifically screws with your ability to do address reuse.
SIGHASH_NOINPUT is a flag for use by responsible, mutually-consenting adults who want to settle down some satoshis and form a channel together. It is not something that immature youngsters should be playing around with, not until they find a channel counterparty that will treat this responsibility properly. And if those immature youngsters playing with their SIGHASH_NOINPUT flags get into trouble and, you know, lose their funds (as fooling around with SIGHASH_NOINPUT is wont to do), well, they need counseling and advice ("not your keys not your coins", "hodl", "SIGHASH_NOINPUT is not a toy, but something special, reserved for those willing to take on the responsibility of making channels according to the words of Decker-Russell-Osuntokun"...).

Conclusion

Dunno yet. It's still being debated! So yeah. SIGHASH_NOINPUT isn't moving, just like Bitcoin's price!!! YAAAAAAAAAAAAAAAAAAA.
submitted by almkglor to Bitcoin [link] [comments]

Upcoming Updates to Bitcoin Consensus

Price and Libra posts are shit boring, so let's focus on a technical topic for a change.
Let me start by presenting a few of the upcoming Bitcoin consensus changes.
(as these are consensus changes and not P2P changes it does not include erlay or dandelion)
Let's hope the community strongly supports these upcoming updates!

Schnorr

The sexy new signing algo.

Advantages

Disadvantages

MuSig

A provably-secure way for a group of n participants to form an aggregate pubkey and signature. Creating their group pubkey does not require their coordination other than getting individual pubkeys from each participant, but creating their signature does require all participants to be online near-simultaneously.

Advantages

Disadvantages

Taproot

Hiding a Bitcoin SCRIPT inside a pubkey, letting you sign with the pubkey without revealing the SCRIPT, or reveal the SCRIPT without signing with the pubkey.

Advantages

Disadvantages

MAST

Encode each possible branch of a Bitcoin contract separately, and only require revelation of the exact branch taken, without revealing any of the other branches. One of the Taproot script versions will be used to denote a MAST construction. If the contract has only one branch then MAST does not add more overhead.

Advantages

Disadvantages

submitted by almkglor to Bitcoin [link] [comments]

Why CHECKDATASIG Does Not Matter

Why CHECKDATASIG Does Not Matter

In this post, I will prove that the two main arguments against the new CHECKDATASIG (CDS) op-codes are invalid. And I will prove that two common arguments for CDS are invalid as well. The proof requires only one assumption (which I believe will be true if we continue to reactive old op-codes and increase the limits on script and transaction sizes [something that seems to have universal support]):
ASSUMPTION 1. It is possible to emmulate CDS with a big long raw script.

Why are the arguments against CDS invalid?

Easy. Let's analyse the two arguments I hear most often against CDS:

ARG #1. CDS can be used for illegal gambling.

This is not a valid reason to oppose CDS because it is a red herring. By Assumption 1, the functionality of CDS can be emulated with a big long raw script. CDS would not then affect what is or is not possible in terms of illegal gambling.

ARG #2. CDS is a subsidy that changes the economic incentives of bitcoin.

The reasoning here is that being able to accomplish in a single op-code, what instead would require a big long raw script, makes transactions that use the new op-code unfairly cheap. We can shoot this argument down from three directions:
(A) Miners can charge any fee they want.
It is true that today miners typically charge transaction fees based on the number of bytes required to express the transaction, and it is also true that a transaction with CDS could be expressed with fewer bytes than the same transaction constructed with a big long raw script. But these two facts don't matter because every miner is free to charge any fee he wants for including a transaction in his block. If a miner wants to charge more for transactions with CDS he can (e.g., maybe the miner believes such transactions cost him more CPU cycles and so he wants to be compensated with higher fees). Similarly, if a miner wants to discount the big long raw scripts used to emmulate CDS he could do that too (e.g., maybe a group of miners have built efficient ways to propagate and process these huge scripts and now want to give a discount to encourage their use). The important point is that the existence of CDS does not impeded the free market's ability to set efficient prices for transactions in any way.
(B) Larger raw transactions do not imply increased orphaning risk.
Some people might argue that my discussion above was flawed because it didn't account for orphaning risk due to the larger transaction size when using a big long raw script compared to a single op-code. But transaction size is not what drives orphaning risk. What drives orphaning risk is the amount of information (entropy) that must be communicated to reconcile the list of transactions in the next block. If the raw-script version of CDS were popular enough to matter, then transactions containing it could be compressed as
....CDS'(signature, message, public-key)....
where CDS' is a code* that means "reconstruct this big long script operation that implements CDS." Thus there is little if any fundamental difference in terms of orphaning risk (or bandwidth) between using a big long script or a single discrete op code.
(C) More op-codes does not imply more CPU cycles.
Firstly, all op-codes are not equal. OP_1ADD (adding 1 to the input) requires vastly fewer CPU cycles than OP_CHECKSIG (checking an ECDSA signature). Secondly, if CDS were popular enough to matter, then whatever "optimized" version that could be created for the discrete CDS op-codes could be used for the big long version emmulating it in raw script. If this is not obvious, realize that all that matters is that the output of both functions (the discrete op-code and the big long script version) must be identical for all inputs, which means that is does NOT matter how the computations are done internally by the miner.

Why are (some of) the arguments for CDS invalid?

Let's go through two of the arguments:

ARG #3. It makes new useful bitcoin transactions possible (e.g., forfeit transactions).

If Assumption 1 holds, then this is false because CDS can be emmulated with a big long raw script. Nothing that isn't possible becomes possible.

ARG #4. It is more efficient to do things with a single op-code than a big long script.

This is basically Argument #2 in reverse. Argument #2 was that CDS would be too efficient and change the incentives of bitcoin. I then showed how, at least at the fundamental level, there is little difference in efficiency in terms of orphaning risk, bandwidth or CPU cycles. For the same reason that Argument #2 is invalid, Argument #4 is invalid as well. (That said, I think a weaker argument could be made that a good scripting language allows one to do the things he wants to do in the simplest and most intuitive ways and so if CDS is indeed useful then I think it makes sense to implement in compact form, but IMO this is really more of an aesthetics thing than something fundamental.)
It's interesting that both sides make the same main points, yet argue in the opposite directions.
Argument #1 and #3 can both be simplified to "CDS permits new functionality." This is transformed into an argument against CDS by extending it with "...and something bad becomes possible that wasn't possible before and so we shouldn't do it." Conversely, it is transformed to an argument for CDS by extending it with "...and something good becomes possible that was not possible before and so we should do it." But if Assumption 1 holds, then "CDS permits new functionality" is false and both arguments are invalid.
Similarly, Arguments #2 and #4 can both be simplified to "CDS is more efficient than using a big long raw script to do the same thing." This is transformed into an argument against CDS by tacking on the speculation that "...which is a subsidy for certain transactions which will throw off the delicate balance of incentives in bitcoin!!1!." It is transformed into an argument for CDS because "... heck, who doesn't want to make bitcoin more efficient!"

What do I think?

If I were the emperor of bitcoin I would probably include CDS because people are already excited to use it, the work is already done to implement it, and the plan to roll it out appears to have strong community support. The work to emulate CDS with a big long raw script is not done.
Moving forward, I think Andrew Stone's (thezerg1) approach outlined here is an excellent way to make incremental improvements to Bitcoin's scripting language. In fact, after writing this essay, I think I've sort of just expressed Andrew's idea in a different form.
* you might call it an "op code" teehee
submitted by Peter__R to btc [link] [comments]

A reminder why CryptoNote protocol was created...

CryptoNote v 2.0 Nicolas van Saberhagen October 17, 2013
1 Introduction
“Bitcoin” [1] has been a successful implementation of the concept of p2p electronic cash. Both professionals and the general public have come to appreciate the convenient combination of public transactions and proof-of-work as a trust model. Today, the user base of electronic cash is growing at a steady pace; customers are attracted to low fees and the anonymity provided by electronic cash and merchants value its predicted and decentralized emission. Bitcoin has effectively proved that electronic cash can be as simple as paper money and as convenient as credit cards.
Unfortunately, Bitcoin suffers from several deficiencies. For example, the system’s distributed nature is inflexible, preventing the implementation of new features until almost all of the net- work users update their clients. Some critical flaws that cannot be fixed rapidly deter Bitcoin’s widespread propagation. In such inflexible models, it is more efficient to roll-out a new project rather than perpetually fix the original project.
In this paper, we study and propose solutions to the main deficiencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among different electronic cash systems. We also propose our own electronic cash, “CryptoNote”, a name emphasizing the next breakthrough in electronic cash.
2 Bitcoin drawbacks and some possible solutions
2.1 Traceability of transactions
Privacy and anonymity are the most important aspects of electronic cash. Peer-to-peer payments seek to be concealed from third party’s view, a distinct difference when compared with traditional banking. In particular, T. Okamoto and K. Ohta described six criteria of ideal electronic cash, which included “privacy: relationship between the user and his purchases must be untraceable by anyone” [30]. From their description, we derived two properties which a fully anonymous electronic cash model must satisfy in order to comply with the requirements outlined by Okamoto and Ohta:
Untraceability: for each incoming transaction all possible senders are equiprobable.
Unlinkability: for any two outgoing transactions it is impossible to prove they were sent to the same person.
Unfortunately, Bitcoin does not satisfy the untraceability requirement. Since all the trans- actions that take place between the network’s participants are public, any transaction can be unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final recipient.
It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database.
Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suffers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5].
2.2 The proof-of-work function
Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “one- CPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system.
The security of this model suffers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug fixes, security fixes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7].
This permits us to conjecture the properties that must be satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more efficient on GPUs and ASIC devices when compared to high-end CPUs.
Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes.
One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat flawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains significant mining power by creating his own mining farm through the cheap hardware described previously. Suppose that the global hashrate decreases significantly, even for a moment, he can now use his mining power to fork the chain and double-spend. As we shall see later in this article, it is not unlikely for the previously described event to take place.
2.3 Irregular emission
Bitcoin has a predetermined emission rate: each solved block produces a fixed amount of coins. Approximately every four years this reward is halved. The original intention was to create a limited smooth emission with exponential decay, but in fact we have a piecewise linear emission function whose breakpoints may cause problems to the Bitcoin infrastructure.
When the breakpoint occurs, miners start to receive only half of the value of their previous reward. The absolute difference between 12.5 and 6.25 BTC (projected for the year 2020) may seem tolerable. However, when examining the 50 to 25 BTC drop that took place on November 28 2012, felt inappropriate for a significant number of members of the mining community. Figure 1 shows a dramatic decrease in the network’s hashrate in the end of November, exactly when the halving took place. This event could have been the perfect moment for the malevolent individual described in the proof-of-work function section to carry-out a double spending attack [36]. Fig. 1. Bitcoin hashrate chart (source: http://bitcoin.sipa.be)
2.4 Hardcoded constants
Bitcoin has many hard-coded limits, where some are natural elements of the original design (e.g. block frequency, maximum amount of money supply, number of confirmations) whereas other seem to be artificial constraints. It is not so much the limits, as the inability of quickly changing them if necessary that causes the main drawbacks. Unfortunately, it is hard to predict when the constants may need to be changed and replacing them may lead to terrible consequences.
A good example of a hardcoded limit change leading to disastrous consequences is the block size limit set to 250kb1. This limit was sufficient to hold about 10000 standard transactions. In early 2013, this limit had almost been reached and an agreement was reached to increase the limit. The change was implemented in wallet version 0.8 and ended with a 24-blocks chain split and a successful double-spend attack [9]. While the bug was not in the Bitcoin protocol, but rather in the database engine it could have been easily caught by a simple stress test if there was no artificially introduced block size limit.
Constants also act as a form of centralization point. Despite the peer-to-peer nature of Bitcoin, an overwhelming majority of nodes use the official reference client [10] developed by a small group of people. This group makes the decision to implement changes to the protocol and most people accept these changes irrespective of their “correctness”. Some decisions caused heated discussions and even calls for boycott [11], which indicates that the community and the developers may disagree on some important points. It therefore seems logical to have a protocol with user-configurable and self-adjusting variables as a possible way to avoid these problems.
2.5 Bulky scripts
The scripting system in Bitcoin is a heavy and complex feature. It potentially allows one to create sophisticated transactions [12], but some of its features are disabled due to security concerns and some have never even been used [13]. The script (including both senders’ and receivers’ parts) for the most popular transaction in Bitcoin looks like this: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. The script is 164 bytes long whereas its only purpose is to check if the receiver possess the secret key required to verify his signature.
Read the rest of the white paper here: https://cryptonote.org/whitepaper.pdf
submitted by xmrhaelan to CryptoCurrency [link] [comments]

The Problems with Segregated Witness

MORE: https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
... 3. The Problems with Segregated Witness
While it is true that Segregated Witness offers some improvements to the Bitcoin network, we shall now examine why these benefits are not nearly enough to outweigh the dangers of deploying SW as a soft fork.
3.1 SW creates a financial incentive for bloating witness data
SW allows for a theoretical maximum block size limit of ~4 MB. However, this is only true if the entire block was occupied with transactions of a very small ‘base size’ (e.g. P2WPKH with 1 input, 1 output). In practice, based on the average transaction size today and the types of transactions made, the block size limit is expected to have a maximum limit of ~1.7 MB post-SW (Figure 10; assuming all transactions are using SW unspent outputs — a big assumption).
However, the 4 MB theoretical limit creates a key problem. Miners and full node operators need to ensure that their systems can handle the 4 MB limit, even though at best they will only be able to support ~40% of that transaction capacity. Why? Because there exists a financial incentive for malicious actors to design transactions with a small base size but large and complex witness data. This is exacerbated by the fact that witness scripts (i.e. P2SH-P2WSH or P2SH-P2WSH) will have higher script size limits that normal P2SH redeem scripts (i.e., from 520 bytes to 3,600 bytes [policy] or 10,000 bytes [consensus]). These potential problems only worsen as the block size limit is raised in the future, for example a 2 MB maximum base size creates an 8 MB adversarial case. This problem hinders scalability and makes future capacity increases more difficult.
3.2 SW fails to sufficiently address the problems it intends to solve
If SW is activated by soft fork, Bitcoin will effectively have two classes of UTXOs (non-SW vs SW UTXOs), each with different security and economic properties. Linear signature hashing and malleability fixes will only be available to the SW UTXO. Most seriously, there are no enforceable constraints to the growth of the non-SW UTXO. This means that the network (even upgraded nodes) are still vulnerable to transaction malleability and quadratic signature hashing from non-SW outputs that existed before or created after the soft fork.
The lack of enforceability that comes with a soft fork leaves Bitcoin users and developers vulnerable to precisely the type of attacks SW is designed to prevent. While spending non-SW outputs will be comparatively more expensive than SW outputs, this remains a relatively weak disincentive for a motivated attacker.
It is also unclear what proportion of the total number of the legacy UTXO will migrate to SW outputs. Long-term holders of Bitcoin, such as Satoshi Nakamoto (presumed to be in possession of ~1 million Bitcoin), may keep their coins in non-SW outputs (although it would be a significant vote of confidence in SW by Nakamoto if they were to migrate!). This makes future soft or hard forks to Bitcoin more difficult as multiple classes of UTXOs must now be supported to prevent coins from being burned or stolen.
One key concern is that the coexistence of two UTXO types may tempt developers and miners in the future to destroy the non-SW UTXO. Some may view this as an unfounded concern, but the only reason that this is worth mentioning in this article are the comments made by influential individuals associated with Bitcoin Core: Greg Maxwell has postulated that “abandoned UTXO should be forgotten and become unspendable,” and Theymos has claimed “the very-rough consensus is that old coins should be destroyed before they are stolen to prevent disastrous monetary inflation.”
As the security properties of SW outputs are marginally better than non-SW outputs, it may serve as a sufficient rationalization for this type of punitive action.
The existence of two UTXO types with different security and economic properties also deteriorates Bitcoin’s fungibility. Miners and fully validating nodes may decide not to relay, or include in blocks, transactions that spend to one type or the other. While on one hand this is a positive step towards enforceability (i.e. soft enforceability), it is detrimental to unsophisticated Bitcoin users who have funds in old or non-upgraded wallets. Furthermore, it is completely reasonable for projects such as the lightning network to reject forming bidirectional payment channels (i.e. a multisignature P2SH address) using non-SW P2SH outputs due to the possibility of malleability. Fundamentally this means that the face-value of Bitcoin will not be economically treated the same way depending on the type of output it comes from.
It is widely understood in software development that measures which rely on the assumption of users changing their behavior to adopt better security practices are fundamentally doomed to fail; more so when the unpatched vulnerabilities are permitted to persist and grow. An example familiar to most readers would be the introduction and subsequent snail’s pace uptake of HTTPS.
3.3 SW places complex requirements on developers to comply while failing to guarantee any benefits
SW as a soft fork brings with it a mountain of irreversible technical debt, with multiple opportunities for developers to permanently cause the loss of user funds. For example, the creation of P2SH-P2WPKH or P2SH-P2WSH addresses requires the strict use of compressed pubkeys, otherwise funds can be irrevocably lost. Similarly, the use of OP_IF, OP_NOTIF, OP_CHECKSIG, and OP_CHECKMULTISIG must be carefully handled for SW transactions in order to prevent the loss of funds. It is all but certain that some future developers will cause user loss of funds due to an incomplete understanding of the intricacies of SW transaction formats.
In terms of priorities, SW is not a solution to any of the major support ticket issues that are received daily by Bitcoin businesses such as BitPay, Coinbase, Blockchain.info, etc. The activation of SW will not increase the transaction capacity of Bitcoin overnight, but only incrementally as a greater percentage of transactions spend to SW outputs. Moreover, the growing demand for on-chain transactions may very well exceed the one-off capacity increase as demonstrated by the increasing frequency of transaction backlogs.
In contrast to a basic block size increase (BBSI) from a coordinated hard fork, many wallets and SPV clients will immediately benefit from new capacity increases without the need to rewrite their own software as they must do with SW.. With a BBSI, unlike SW, there are no transaction format or signature changes required on the part of Bitcoin-using applications.
Based on previous experience with soft forks in Bitcoin, upgrades tend to roll-out within the ecosystem over some time. At the time of this writing, only 28 out of the 78 business and projects (36%) who have publicly committed to the upgrade are SW-compatible. Any capacity increase that Bitcoin businesses and users of the network desire to ease on-chain fee pressure will unlikely be felt for some time, assuming that transaction volume remains unchanged and does not continue growing. The unpredictability of this capacity increase and the growth of the non-SW UTXO are particularly troubling for Bitcoin businesses from the perspectives of user-growth and security, respectively. Conversely, a BBSI delivers an immediate and predictable capacity increase.
The voluntary nature of SW upgrades is subject to the first-mover game theory problem. With a risky upgrade that moves transaction signatures to a new witness field that is hidden to some nodes, the incentive for the rational actor is to let others take that risk first, while the rational actor sits back, waits, and watches to see if people lose funds or have problems. Moreover, the voluntary SW upgrade also suffers from the free-rider game theory problem. If others upgrade and move their data to the witness field, one can benefit even without upgrading or using SW transactions themselves. These factors further contribute to the unpredictable changes to Bitcoin’s transaction capacity and fees if SW is adopted via a soft fork.
3.4 Economic distortions and price fixing
Segregated Witness as a soft fork alters the economic incentives that regulate access to Bitcoin’s one fundamental good: block-size space. Firstly, it subsidises signature data in large/complex P2WSH transactions (i.e., at ¼ of the cost of transaction/UTXO data). However, the signatures are more expensive to validate than the UTXO, which makes this unjustifiable in terms of computational cost. The discount itself appears to have been determined arbitrarily and not for any scientific or data-backed reasoning.
Secondly, the centralized and top-down planning of one of Bitcoin’s primary economic resources, block space, further disintermediates various market forces from operating without friction. SW as a soft fork is designed to preserve the 1 MB capacity limit for on-chain transactions, which will purposely drive on-chain fees up for all users of Bitcoin. Rising transaction fees, euphemistically called a ‘fee market’, is anything but a market when one side — i.e. supply — is fixed by central economic planners (the developers) who do not pay the costs for Bitcoin’s capacity (the miners). Economic history has long taught us the results of non-market intervention in the supply of goods and services: the costs are externalised to consumers. The adoption of SW as a soft fork creates a bad precedent for further protocol changes that affirm this type of economic planning.
3.5 Soft fork risks
In this section we levy criticisms of soft forks more broadly when they affect the protocol and economic properties of Bitcoin to the extent that SW does. In this case, a soft fork reduces the security of full nodes without the consent of the node operator. The SW soft fork forces node operators either to upgrade, or to unconditionally accept the loss of security by being downgraded to a SPV node.
Non-upgraded nodes further weaken the general security of Bitcoin as a whole through the reduction of the number of fully validating nodes on the network. This is because non-upgraded nodes will only perform the initial check to see if the redeem script hash matches the pubkey script hash of the unspent output. This redeem script may contain an invalid witness program, for P2WSH transactions, that the non-upgraded node doesn’t know how to verify. This node will then blindly relay the invalid transaction across the network.
SW as a soft fork is the opposite of anti-fragile. Even if the community wants the change (i.e., an increase in transaction capacity), soft-forking to achieve these changes means that the miners become the key target of lobbying (and they already are). Soft forks are risky in this context because it becomes relatively easy to change things, which may be desirable if the feature is both minor and widely beneficial. However, it is bad in this case because the users of Bitcoin (i.e. everyone else but the miners) are not given the opportunity to consent or opt-out, despite being affected the most by such a sweeping change. This can be likened to a popular head of state who bends the rules of jurisprudence to bypass slow legal processes to “get things done.” The dangerous precedent of taking legal shortcuts is not of concern the masses until a new, less popular leader takes hold of the reigns, and by then it is too late to reverse. In contrast, activating SW via a hard fork ensures that the entire community, not just the miners, decide on changes made to the protocol. Users who unequivocally disagree with a change being made are given the clear option not to adopt the change — not so with a soft fork.
3.6 Once activated, SW cannot be undone and must remain in Bitcoin codebase forever.
If any critical bugs resulting from SW are discovered down the road, bugs serious enough to contemplate rolling it back, then anyone will be able to spend native SW outputs, leading to a catastrophic loss of funds. ...
...
Conclusion
Segregated Witness is the most radical and irresponsible protocol upgrade Bitcoin has faced in its eight year history. The push for the SW soft fork puts Bitcoin miners in a difficult and unfair position to the extent that they are pressured into enforcing a complicated and contentious change to the Bitcoin protocol, without community consensus or an honest discussion weighing the benefits against the costs. The scale of the code changes are far from trivial — nearly every part of the codebase is affected by SW.
While increasing the transaction capacity of Bitcoin has already been significantly delayed, SW represents an unprofessional and ineffective solution to both transaction malleability and scaling. As a soft fork, SW introduces more technical debt to the protocol and fundamentally fails to achieve its design purpose. As a hard fork, combined with real on-chain scaling, SW can effectively mitigate transaction malleability and quadratic signature hashing. Each of these issues are too important for the future of Bitcoin to gamble on SW as a soft fork and the permanent baggage that comes with it.
As much as the authors of this article desire transaction capacity increases, it is far better to work towards a clean technical solution to malleability and scaling than to further encumber the Bitcoin protocol with permanent technical debt. ...
MORE: https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
submitted by german_bitcoiner to btc [link] [comments]

Unconfirmed Bitcoin Problem

I posted this on another forum and was referred here to try to get a hold of a Bitcoin Developer to help solve my problem. IMO, there is a bug in the blockchain. Either the blockchain is reporting transactions to me that never existed, or I have unconfirmed transactions in my ledger that need to be confirmed and are not confirming. The transactions are from 2013 and 2014 when I first started mining.
I am running the latest version of Bitcoin Core, and have fully synced through the blockchain.
Background: Years ago I mined a little bit of BTC, and forgot about it. With the prices going astronomical I wanted to open my old wallet up and sell some. I opened it in Bitcoin Core and I can see a bunch of transactions, but they're all unconfirmed and my balance is reporting zero.
Address: 1BWCNpA3MGYHS3sbbVpGW7jY1Ean1Y3sX4
One of many transaction id's:
Status: 0/unconfirmed, not in memory pool Date: 1/23/2014 22:01 Credit: 0.10630472 BTC Net amount: +0.10630472 BTC Transaction ID: c16587ae806c2392635a20843a78f8f6a1275c6990a797f8266e3b9d8a29bd1e Transaction total size: 225 bytes Output index: 0
When I try to rebroadcast the raw transaction I get this...
Missing parents for c16587ae806c2392635a20843a78f8f6a1275c6990a797f8266e3b9d8a29bd1e while inserting: [c677f8172824b4bb761f0ce51e23235f4a6613c62e74e847936f95440fae6b6c]
If I decode it I get this...
{ "lock_time":0, "size":225, "inputs":[ { "prev_out":{ "index":0, "hash":"c677f8172824b4bb761f0ce51e23235f4a6613c62e74e847936f95440fae6b6c" }, "script":"47304402204f1602b609027990a8e17355bdb9d967882aed3ac85e06c9311d33a3228ba9d90220097941a24457d36508f8d17e94400184c849f44c48296aab09e4deb9d23e4e2f012103db4cc04dac3ee0cb4ab0afc108eb1f398ab659be127240a672b1abe139f84b60" } ], "version":1, "vin_sz":1, "hash":"c16587ae806c2392635a20843a78f8f6a1275c6990a797f8266e3b9d8a29bd1e", "vout_sz":2, "out":[ { "script_string":"OP_DUP OP_HASH160 7336d1277adaf305dddde5cedc686bb1e4988bda OP_EQUALVERIFY OP_CHECKSIG", "address":"1BWCNpA3MGYHS3sbbVpGW7jY1Ean1Y3sX4", "value":10630472, "script":"76a9147336d1277adaf305dddde5cedc686bb1e4988bda88ac" }, { "script_string":"OP_DUP OP_HASH160 95a28eec6c32896699df4ca36c880d7e42e504c5 OP_EQUALVERIFY OP_CHECKSIG", "address":"1EeCRLCksdBRJ7SUkAAFKk1TssVv62hoTQ", "value":89379528, "script":"76a91495a28eec6c32896699df4ca36c880d7e42e504c588ac" } ] }
Does this offer any more clues?
This is the raw transaction in Hex...
01000000016c6bae0f44956f9347e8742ec613664a5f23231ee50c1f76bbb4242817f877c6000000006a47304402204f1602b609027990a8e17355bdb9d967882aed3ac85e06c9311d33a3228ba9d90220097941a24457d36508f8d17e94400184c849f44c48296aab09e4deb9d23e4e2f012103db4cc04dac3ee0cb4ab0afc108eb1f398ab659be127240a672b1abe139f84b60ffffffff024835a200000000001976a9147336d1277adaf305dddde5cedc686bb1e4988bda88acc8d25305000000001976a91495a28eec6c32896699df4ca36c880d7e42e504c588ac00000000
I really need help ASAP so I can sell some coins. How do I resolve this issue, or at the bare minimum how do we correct the blockchain so this issue doesn't affect others? Any help is appreciated!
submitted by AmericasLastHope to Bitcoin [link] [comments]

Deep Analysis Of Qtum's Account Abstraction Layer (Qtum AAL)

Analysis of Qtum Account Abstraction Layer (AAL) Implementation
https://mp.weixin.qq.com/s?__biz=MzI2MzM2NDQ2NA==&mid=2247485993&idx=1&sn=57ad353fd13b10ab85b62d693f86b1f5&chksm=eabc4036ddcbc9208ea766274defc543a9238967c5d2c541e615906a25a2962d75c4c6bd2c2b&scene=21#wechat_redirect
Qtum is designed with a bitcoin UTXO-based account model and implements a smart contract that supports the EVM specification, which is done through the Account Abstract Layer (ALA). AAL adapts the UTXO account to the EVM contract account, so that the AAL can use the UTXO transaction output to create a smart contract on the chain, send the transaction to the contract account to trigger the execution of the contract, and the AAL will eventually execute after the execution. The results were processed and adapted to UTXO. Thanks to the AAL, contract developers don't need to care about the UTXO transformation details related to contract operations, they can use the features of EVM to develop and are compatible with existing Ethereum smart contracts. This paper first analyzes the working process of AAL by interpreting the implementation code from UTXO transaction to smart contract execution.
 
1. UTMO transaction added script opcode
Qtum has added three opcodes OP_CREATE, OP_CALL and OP_SPEND for UTXO trading scripts to provide operational support for conversion between UTXO and EVM account models. These opcodes are defined in the opcodetype enumeration type:
 
Enum opcodetype{
......
OP_CREATE = 0xc1,
OP_CALL = 0xc2,
OP_SPEND= 0xc3,
......
}
 
These three opcodes have the following effects:
OP_CREATE is used to create smart contracts;
OP_CALL is used for the execution of the contract;
OP_SPEND is used for the cost of the contract balance.
In order to identify and process the transactions controlled by these opcodes during the block generation process, the HasCreateOrCall() and HasOpSpend() functions are added to the class CTransaction for UTXO model transactions for use in the mempool in the new block. The transaction is processed and the corresponding processing is added to the EvalScript() function of the script opcode parsing.
 
2. Conversion of UTXO transactions to EVM model transactions
When generating new blocks, in addition to regular parameter legality, consensus rules, DDOS attack checks, etc. for UTXO transactions, it is also necessary to use the opcode check function HasCreateOrCall() to determine whether the transaction output contains OP_CREATE or OP_CALL, which respectively correspond to EVM needs to perform contract creation or contract calls. This section has the following processing:
 
2.1 Performing account parameter extraction for EVM model
The contract uses the data, gasPrice, gasLimit, and VM version parameters in the execution of the EVM. These parameters are sent by the RPC call sendtocontract. The sendtocontract generates a UTXO transaction and uses the OP_CALL opcode in the transaction output. Will be broadcast to the blockchain network. The adaptation from UTXO to EVM in AAL is implemented by the QtumTxConverter class, in which the member functions extractQtumTransactions() and parseEthTXParams() of the class complete the parameter extraction for all such UTXO transaction output. The code fragment is as follows:
 
Dev::Address receiveAddress;
Valtype vecAddr;
If (opcode == OP_CALL)
{
vecAddr = stack.back();
Stack.pop_back();
receiveAddress = dev::Address(vecAddr);
}
Valtype code(stack.back());
Stack.pop_back();
Uint64_t gasPrice = CScriptNum::vch_to_uint64(stack.back());
Stack.pop_back();
Uint64_t gasLimit = CScriptNum::vch_to_uint64(stack.back());
Stack.pop_back();
VersionVM version(CScriptNum::vch_to_uint64(stack.back()));
Stack.pop_back();
Return EthTransactionParams{version, dev::u256(gasLimit), dev::u256(gasPrice), code,
receiveAddress }
 
The above code first judges that if the opcode is OP_CALL, the contract with the address vecAddr has been created, so it is directly converted into the address of the EVM format receiveAddress, otherwise it is OP_CREATE, the corresponding contract is created, there is no such field, so no extraction is done. Next, the data, gasPrice, gasLimit, and VM version are extracted in turn, which are all essential parameters for the EVM to execute bytecode.
 
2.2 Transaction conversion of the EVM account model
Transaction conversion is done through the function createEthTX() of the QtumTxConverter class. The QtumTransaction type transaction is created using the parameters extracted in the previous step and the UTXO transaction output vout. Since QtumTransaction is derived from the dev::eth::Transaction class in EVM, the QtumTransaction class is supported by operations related to EVM execution.
 
QtumTransaction txEth;
If ( etp.receiveAddress == dev::Address() ) {
txEth = QtumTransaction(txBit.vout[nOut].nValue, etp.gasPrice, (etp.gasLimit *
Etp.gasPrice),
Etp.code, dev::u256(0));
}
Else{
txEth = QtumTransaction(txBit.vout[nOut].nValue, etp.gasPrice, (etp.gasLimit *
Etp.gasPrice),
etp.receiveAddress, etp.code, dev::u256(0));
}
Dev::Address sender(GetSenderAddress(txBit, view));
txEth.forceSender(sender);
txEth.setHashWith(uintToh256(txBit.GetHash()));
txEth.setNVout(nOut);
 
First, the code etp.receiveAddress == dev::Address() determines whether the contract is not in the EVM state and needs to be newly created or the contract already included in the EVM state. The only difference is the contract address. Then, the QtumTransaction() constructor completes some of the transaction parameter constructs, the next statement extracts the sender of the transaction, and then sets the transaction HASH. A UTXO transaction supports multiple inputs and outputs. Qtum's AAL design takes this into account, so AAL supports a transaction output containing UTXO accounts and contract accounts. The last set nOut indicates that the nOut output of the transaction is sent to the smart contract. , so this output will trigger contract execution. In this way, the transaction conversion is completed according to the EVM account model.
 
3. Contract execution and UTXO conversion of execution results
The execution of the contract changes state (managed by the QtumState class's instantiated object globalState). For the contract state, Qtum follows the EVM definition, so it is compatible with all EVM-compliant smart contracts. But the transfer of the account amount, Qtum made a UTXO conversion, which means that the smart contract and the ordinary UTXO model account can complete the interaction, which is an important part of AAL to achieve UTXO support smart contract. The following is a brief introduction to the conversion process of contract execution and status results.
 
3.1 Contract execution environment construction and contract execution
The execution of the contract is a critical step in the processing of the contract, directly affecting the state of the contract. The implementation of the EVM to the contract bytecode is implemented by the ByteCodeExec class. The main function is performByteCode(). The main process of this step is to use the transaction parameters extracted above to build the virtual machine execution environment, and then complete the execution of the contract, the code is as follows:
 
For(QtumTransaction& tx : txs){
Dev::eth::EnvInfo envInfo(BuildEVMEnvironment());
Std::unique_ptr
Se(dev::eth::ChainParams(dev::eth::genesisInfo(dev::eth::Network::HomesteadTest)).
createSealEngine());
If(!tx.isCreation() && !globalState->addressInUse(tx.receiveAddress())){
Dev::eth::ExecutionResult execRes;
execRes.excepted = dev::eth::TransactionException::Unknown;
Result.push_back(ResultExecute{execRes, dev::eth::TransactionReceipt(dev::h256(),
Dev::u256(), dev::eth::LogEntries()), CTransaction()});
Continue;
}
Result.push_back(globalState->execute(envInfo, *se.get(), tx, type, OnOpFunc()));
}
 
The first is to build a contract execution environment, which is done by BuildEVMEnvironment(). It can be seen that this execution environment is carried out for each independent transaction, so as to minimize the contract execution process of different transactions and avoid the cross-effects in the contract execution process. Then build a new sealEngine class, which is the EVM execution engine, which is done by the createSealEngine() function. In the middle, the possible state exceptions that occur are checked, and then globalState->execute() completes the execution of the contract. Here, the execution environment envInfo and the EVM execution engine se are used.
 
3.2 UTXO conversion of contract execution results
After the completion of the contract execution, the result is stored in vector result. The vector vector records the transfer relationship between EVM accounts generated by each contract execution. AAL completes the transfer from EVM account model to UTXO model by converting these transfers into UTXO transactions. Conversion of the transaction. This processing is implemented by the processingResults() function. The following is a code snippet.
 
ByteCodeExecResult resultBCE;
For(size_t i = 0; i < result.size(); i++){
If(result[i].execRes.excepted != dev::eth::TransactionException::None){
If(txs[i].value() > 0){
CMutableTransaction tx;
Tx.vin.push_back(CTxIn(h256Touint(txs[i].getHashWith()), txs[i].getNVout(), CScript() <<
OP_SPEND));
CScript script(CScript() << OP_DUP << OP_HASH160 << txs[i].sender().asBytes() <<
OP_EQUALVERIFY << OP_CHECKSIG);
Tx.vout.push_back(CTxOut(CAmount(txs[i].value()), script));
resultBCE.valueTransfers.push_back(CTransaction(tx));
}
} else {
resultBCE.usedFee += CAmount(result[i].execRes.gasUsed);
CAmount ref((txs[i].gas() - result[i].execRes.gasUsed) * txs[i].gasPrice());
If(ref > 0){
CScript script(CScript() << OP_DUP << OP_HASH160 << txs[i].sender().asBytes() <<
OP_EQUALVERIFY << OP_CHECKSIG);
resultBCE.refundOutputs.push_back(CTxOut(ref, script));
resultBCE.refundSender += ref;
}
} if(result[i].tx != CTransaction()){
resultBCE.valueTransfers.push_back(result[i].tx);
}}
 
First, the resultBCE variable of type ByteCodeExecResult is defined to save the result of the conversion. Use the opcode OP_SPEND to implement the transaction cost, because the UTXO of Bitcoin uses the private key signature to realize the balance after the transaction input is unlocked, and the EVM implementation involves the transfer between different accounts, so these need to be implemented by OP_SPEND Transfer to UTXO model trading conversion. If execRes.excepted is not None, ie the contract execution exception, the balance is returned to the contract caller. Otherwise, if there is no abnormality, the remaining gas after deducting the consumed gas is returned to the caller of the contract. For the transfer that occurs during contract execution, its UTXO transaction is stored in result[i].tx. Therefore, transactions between different UTXO accounts generated by this process of contract execution are stored in the valueTransfers vector, and eventually these transactions are included in the new block. At this point, the AAL module completes the conversion from EVM transactions to UTXO.
 
4. Summary
AAL assists in the creation, execution, and cost of contracts through the addition of UTXO script opcodes. Before the contract is created and executed, the conversion of the UTXO transaction to the EVM model transaction is required, and then the executed EVM execution environment and engine are used to complete the execution of the contract. AAL finally processed the results of the contract and adapted it from EVM to UTXO, thus implementing a UTXO-based smart contract. AAL makes Qtum compatible with EVM-compliant smart contracts, providing Dapp with a new base platform, while UTXO's advantages allow for advantages such as parallel processing and privacy.
 
Huaming
He is currently a Qtum core developer and researcher. He graduated from Huazhong University of Science and Technology and has a graduate degree from the Chinese Academy of Sciences. Prior to joining Qtum, he has been engaged in the development of algorithms and protocol stacks for many years of wireless networks (including 4G LTE and wireless ad hoc networks); since 2015, he has been in contact with blockchain technology and has participated in the first hackathon competition organized by Wanxiang Blockchain. .
submitted by thisthingismud to Qtum [link] [comments]

Qtum - Quantum Chain Design Document

Serialization: Qtum Foundation Design Document

Foreword
In this series of articles, the Qtum Quantum Chain Foundation will make public its early design documents for the first time, hoping to help the community understand the design intent of Qtum and the implementation details of key technologies. The article will be based on the original design draft in order to restore the designer's original ideas. Follow-up Qtum project team will be further collation and interpretation, to help readers understand more technical details, so stay tuned.
The topics that may be included in this series include
* Qtum account abstraction layer AAL
* Qtum distributed autonomous protocol DGP
* Qtum wallet (qt, mobile wallet, etc.) and browser
* Add RPC call
* Mutual interest consensus mechanism MPoS
* Add opcode
* Integration of EVM and Qtum blockchain
* Qtum x86 virtual machine
* Others...
The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch.
Qtum original design document summary -- Qtum new OPCODE
As we all know, Qtum uses the same UTXO model as Bitcoin. The original UTXO script was not compatible with the EVM account model, so Qtum added three OP_CREATE, OP_CALL, and OP_SPEND opcodes to the UTXO transaction script for the purpose of providing operational support for conversions between UTXO and EVM account models. The original names of the three opcodes are OP_EXEC(OP_CREATE), OP_EXEC_ASSIGN(OP_CALL) and OP_TXHASH(OP_SPEND), respectively.
The following is an excerpt of representative original documents for interested readers.
OP_CREATE (or OP_EXEC**)**
OP_CREATE (or OP_EXEC) is used to create a smart contract. The original design files (with Chinese translation) related to this opcode by the Qtum development team are as follows (ps: QTUM <#> or QTUMCORE<#> in the document numbering internal design documents. ):
QTUMCORE-3:Add EVM and OP_CREATE for contract execution Description:After this story, the EVM should be integrated and a very basic contract should be capable of being executed. There will be a new opcode, OP_CREATE (formerly OP_EXEC), which takes 4 arguments, in push order: 1. VM version (currently 1 is EVM) 2. Gas price (not yet used, anything is valid) 3. Gas limit (not yet used, assume very high limit) 4. bytecodeFor now it is OK that this script format be forced and mandatory for OP_CREATE transactions on the blockchain. (ie, only "standard" allowed on the blockchain) When OP_CREATE is encountered, it should execute the EVM and persist the contract to a database (triedb) Note: Make sure to follow policy for external code (commit vanilla unmodified code first, and then change it as needed) Make the EVM test suite functional as well (someone else can setup continuous integration changes for it though) 
The above document describes the functions required by OP_CREATE and the parameters used.

OP_CALL (or OP_EXEC_ASSIGN)

OP_CALL is used for contract execution and is one of the most commonly used opcodes. There are many descriptions in the original design document.
QTUM6: Implement calling environment info in EVM for OP_EXEC_ASSIGN 
Description: Solidity expects certain information to be pushed onto the stack as part of it's ABI. So, when data is sent into the contract using OP_EXEC_ASSIGN we need to make sure to provide this data. This data includes the Solidity "function selector" as well as ensuring the opcodes CALLER and ORIGIN function properly. This looks to be fairly easy, it should just be transferring some data from the Bitcoin stack to the EVM stack, and setting some fields for the origin info. However, this story should be split into multiple tasks and re-evaluated if it isn't easy. See also: https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI For populating the CALLER and ORIGIN value, the following should be done: OP_EXEC_ASSIGN should take 2 extra arguments, SENDER and SENDER_SIGNATURE. Sender should be a public key. Sender Signature is the signature of all the vins for the current transaction, signed of course using the SENDER value.On the EVM side, CALLER's value will be a public key hash, ie, a hash of the SENDER public key. This public key hash should be compatible with Bitcoin's public key hash for it's standard version 1 addresses. IF the given SENDER_SIGNATURE does not match successfully, then the transaction should be considered invalid. If the SENDER public key is 0, then SENDER_SIGNATURE must also be 0, and the given CALLER opcode etc should just return 0.
The above document describes the OP_EXEC_ASSIGN calling environment information that needs to be implemented in the EVM.
QTUM8: Implement OP_EXEC_ASSIGN for sending money to contracts 
Description: A new opcode should be added, OP_EXEC_ASSIGN. This opcode should take these arguments in push order: # version number (VM version to use, currently just 1)

gas price (can be ignored for now)

gas refund script (can be ignored for now)

data (The data to hand to the smart contract. This will include things like the Solidity ABI Function Selector and other data that will later be available using the CALLERDATA EVM opcode) # smart contract address (txid + vout number)

It should return two values right now, 0 and 0. These are for spendable and out of gas, respectively. Making them spendable and dealing with out of gas will be in a future storyFor this story, the EVM contract does not actually need to be executed. This opcode should only be a placeholder so that the accounting system can determine how much money a contract has control of
The above document describes the OP_EXEC_ASSIGN implementation details.
QTUM15: Execute the relevant contract during OP_EXEC_ASSIGN 
Description: After this story is complete, when OP_EXEC_ASSIGN is reached, it should actually execute the contract whose address was given to it, passing the relevant data from the bitcoin script stack with it. Other data such as the caller and sender can be left for a later story. Making the CALLER, ORIGIN etc opcodes work properly will be fixed with a later story
The above document describes OP_EXEC_ASSIGN how the script runs the relevant contract code.
QTUM40: Allow contracts to send money to pubkeyhash addresses Description: We need to allow contracts to send money back to pubkeyhash addresses, so that people can withdraw their coins from contracts when allowed, etc. This should work similar to how version 0 contract sends work. Instead of using an OP_EXEC_ASSIGN vout though, we need to instead use a standard pubkeyhash script. So, upon spending to a pubkeyhash, the following transaction should be placed on the blockchain: vin: [standard contract OP_EXEC_ASSIGN inputs] ... vout: OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG change output - version 0 OP_EXEC_ASSIGN back to spending contract These outputs should be directly spendable in the wallet with no changes to the wallet code itself 
The above document describes how to allow contracts to send QTUM to pubkeyhash addresses.
QTUMCORE-10:Add ability for contracts to call other deployed contracts Description:Contracts should be capable of calling other contracts using a new opcode, OP_CALL. Arguments in push order:version (32 bit integer) gas price (64 bit integer) gas limit (64 bit integer) contract address (160 bits) data (any length) OP_CALL should ways return false for now. OP_CALL only results in contract execution when used in a vout; Similar to OP_CREATE, it uses the special rule to process the script during vout processing (rather than when spent as is normal in Bitcoin). Contract execution should only be triggered when the transaction script is in this standard format and has no extra opcodes. If OP_CALL is created that uses an invalid contract address, then no contract execution should take place. The transaction should still be valid in the blockchain however. If money was sent with OP_CALL, then that money (minus the gas fees) should result in a refund transaction to send the funds back to vin[0]'s vout script. The "sender" exposed to EVM should be the pubkeyhash spent by vin[0]. If the vout spent by vin[0] is not a pubkeyhash, then the sender should be 0.Funds can be sent to the contract using an OP_CALL vout. These funds will be handled by the account abstraciton layer in a different story, to expose this to the EVM. Multiple OP_CALLS can be used in a single transaction. However, before contract execution, the gas price and gas limit of each OP_CALL vout should be checked to ensure that the transaction provides enough transaction fees to cover the gas. Additionally, this should be verified even when the contract is not executed, such as when it is accepted in the mempool. 
The above document describes how the contract calls other contracts via OP_CALL.

OP_SPEND (or OP_TXHASH, OP_EXEC_SPEND)

OP_SPEND is used for the cost of the contract balance. Because the contract address is a special address, in order to ensure consensus, the UTXO needs to be specially processed. Therefore, there are more descriptions of the OP_SPEND operation code in the original design document.
QTUM20: Create OP_EXEC_SPEND transaction when a contract spends money 
Description: When a CALL opcode or similar to used from an EVM contract to send another contract money, this should be shown on the blockchain as a new transaction. When a money transfer is done in the contract, the miner should add a new transaction exactly after the currently processing transaction in the block. This transaction should spend an input owned by the contract by using EXEC_SPEND in it's redeemScript. For the purposes of this story, assume change is not something to be worried about and consume as many inputs are needed. Properly picking effecient coins and sending back money to the originating contract will come in a later story. Edge cases to watch for: The transaction for sending money to the contract must come directly after the executing transaction. The outputs should use a version-0 OP_EXEC_ASSIGN vout, so that if the transaction were received out of context, it would still mean to not execute the contract.
The above document describes the timing of creating a OP_SPEND transaction.
QTUM21: Create consensus-critical change and coin-picking algorithm for OP_EXEC_SPEND transactions Description: Building on #20, now a consensus-critical algorithm must be made that picks the most optimal outputs belonging to the contract, and spends them, and also makes a change output that returns the "change" from the transaction back to the contract. All outputs in this case should be using a version-0 OP_EXEC_ASSIGN, to avoid running into the limitation that prevents more than one (version 1) OP_EXEC_ASSIGN transaction from being in a single transaction. The transaction should have as many vins as needed, and exactly 2 vouts. The first vout to go to the target contract, and the second vout to send change back to the source contract. 
QTUM22: Disallow more than one EVM execution per transaction
Description: In order to avoid significant edge cases, for now, disallow more than one EVM execution to take place in a single transaction. This includes both deployment and fund assignment vouts. Instead, such things should be split into multiple transactions If two EVM executions are encountered, the transaction should be treated as completely invalid and not suitable for broadcast nor putting into a block
QTUM23: Add "version 0" OP_EXEC_ASSIGN, which does not execute EVM Description: To counteract problems from #22, we should allow OP_EXEC_ASSIGN to be used to fund a contract without the contract actually being executed. This will be used later for "change" outputs to (multiple) contracts. If the version number passed in for OP_EXEC_ASSIGN is 0, then the contract is not executed. Also, this is only valid if the data provided to OP_EXEC_ASSIGN is just a single byte "0". Multiple version-0 OP_EXEC_ASSIGN vouts should be valid in a transaction, or 1 non-version-0 OP_EXEC_ASSIGN (or an OP_EXEC deployment) and multiple version-0 OP_EXEC_ASSIGN vouts. This will be used for all money spending that is sent from a contract to another contract
The above three documents describe that if the consensus-associated coin-picking algorithm guarantees that the OP_SPEND opcode does not cause a consensus error, the correctness of the change is ensured. At the same time, it describes the situation where the contract does not need to be run and how it is handled.
QTUM34: Disallow OP_EXEC and OP_EXEC_ASSIGN from coinbase transactions Description: Because of problems with coinbase maturity and potential side effects from ordering of gas-refund scripts, it should not be legal for coinbase outputs to be anything which results in EVM execution or directly changing EVM account balances. This includes version 0 OP_EXEC_ASSIGN outputs. 
The above document stipulates that coinbase transactions should not include contract-related scripts.

Other related documents

In addition, there are some documents describing the infrastructure needed for the new operation code.
QTUMCORE-51:Formalize the version field for OP_CREATE and OP_CALL Description:In order to sustain future extensions to the protocol, we need to set some rules for how we will later upgrade and add new VMs by changing the "version" argument to OP_CREATE and OP_CALL. We need a definitive VM version format beyond our current "just increment when doing upgrades". This would allow us to more easily plan upgrades and soft-forks. Proposed fields: 
  1. VM Format (can be increased from 0 to extend this format in the future): 2 bits2. Root VM - The actual VM to use, such as EVM, Lua, JVM, etc: 6 bits
  2. VM Version - The version of the Root VM to use (for upgrading the root VM with backwards compatibility) - 8 bits
  3. Flag options - For flags to the VM execution and AAL: 16 bits Total: 32 bits (4 bytes). Size is important since it will be in every EXEC transaction Flag option bits that control contract creation: (only apply to OP_CREATE) • 0 (reserve) Fixed gas schedule - if true, then this contract chooses to opt-out of allowing different gas schedules. Using OP_CALL with a gas schedule other than the one specified in it's creation will result in an immediate exception and result in an out of gas refund condition • 1 (reserve) Enable contract admin interface (reserve only, this will be implemented later. Will allow contracts to control for themselves what VM versions and such they allow, and allows the values to be changed over the lifecycle of the contract) • 2 (reserve) Disallow version 0 funding - If true, this contract is not capable of receiving money through version 0 OP_CALL, other than as required for the account abstraction layer. • bits 3-15 available for future extensions Flag options that control contract calls: (only apply to OP_CALL) • (none yet) Flag options that control both contract calls and creation: • (none yet) These flags will be implemented in a later story Note that the version field now MUST be a 4 byte push. A standard EVM contract would now use the version number (in hex) "01 00 00 00" Consensus behavior: VM Format must be 0 to be valid in a block Root VM can be any value. 1 is EVM, 0 is no-exec. All other values result in no-exec (allowed, but the no execution, for easier soft-forks later) VM Version can be any value (soft-fork compatibility). If a new version is used than 0 (0 is initial release version), then it will execute using version 0 and ignore the value Flag options can be any value (soft-fork compatibility). (inactive flag fields are ignored) Standard mempool behavior: VM Format must be 0Root VM must be 0 or 1VM Version must be 0Flag options - all valid fields can be set. All fields that are not assigned must be set to 0Defaults for EVM: VM Format: 0Root VM: 1VM Version: 0Flags: 0
The above documents formally identified OP_CREATE and OP_CALL needed version information, paving the way for subsequent multi-virtual machine support for Qtum.
QTUMCORE-52:Contract Admin Interface Description:(note, this isn't a goal for mainnet, though it would be a nice feature to include) It should be possible to manage the lifecycle of a contract internally within the contract itself. Such variables and configuration values that might need to be changed over the course of a contract's lifecycle: • Allowable gas schedules 
• Allowable VM versions (ie, if a future VM version breaks this contract, don't allow it to be used, as well as deprecating past VM versions from being used to interact with this contract) • Creation flags (the version flags in OP_CREATE) All of these variables must be able to be controlled within the contract itself, using decentralized code. For instance, in a DAO scenario, it might be something that participants can vote on within the contract, and then the contract triggers the code that changes these parameters. In addition, a contract should be capable of detecting it's own settings throughout it's execution as well as when it is initially created. I propose implementing this interface as a special pre-compiled contract. For a contract ot interact with it, it would call it using the Solidity ABI like any other contract. Proposed ABI for the contract: • bytes[2048] GasSchedule(int n) • int GasScheduleCount() • int AddGasSchedule(bytes[2048] • bytes[32] AllowedVMVersions() • void SetAllowedVMVersions(bytes[32]) Alternative implementations: There could be a specific Solidity function which is called in order to validate that the contract should allow itself to be called in a particular manner: pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; } } In this way a contract is responsible for managing it's own state. The basic way it would work is that when a you use OP_CALL to call a contract, it would first execute these two functions (and their execution would be included in gas costs). If either function returns false, then it immediately triggers an out of gas condition and cancels execution. It's slightly complicated to manage the "ValidateVMVersion" callback however, because we must decide which VM version to use. A bad one could cause this function itself to misbeha`ve.```````
pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; }
} 
The above document describes the management interface of the contract, and yes the contract can manage its own status.
QTUMCORE-53:Add opt-out flags to contracts for version 0 sends Description:Some contracts may wish to opt-out of certain features in Qtum that are not present in Ethereum. This way more Ethereum contracts can be ported to Qtum without worrying about new features in the Qtum blockchain Two flag options should be added to the Version field, which only have an effect in OP_CREATE for creating the contract: 2. (1st bit) Disallow "version 0" OP_CALLs to this contract outside of the AAL. (DisallowVersion0)  If this is enabled, then an OP_CALL using "root VM 0" (which causes no execution) is not allowed to be sent to this contract. If money is attempted to be sent to this contract using "version 0" OP_CALL, then it will result in an out of gas exception and the funds should be refunded. Version 0 payments made internally within the Account Abstraction Layer should not be affected by this flag. Along with these new consensus rules, there should also be some standard mempool checks: 
  1. If an OP_CALL tx uses a different gas schedule than the contract creation, and the disallow dynamic gas flag is set, then the transaction should be rejected from the mempool as a non-standard transaction (version 0 payments should not be allowed as standard transactions in the mempool anyway)
The above document describes how to get better EVM compatibility by ignoring certain Qtum specific features in order to port Ethereum contract code. This makes smart contracts in the Ethereum ecosystem more easily compatible with Qtum.

summary

The Qtum original design document presented above describes Qtu's increased opcode associated with the contract run, laying the groundwork for subsequent Qtum's EVM VMs that are compatible with the account model on top of the UTXO model, and also making the account abstraction layer AAL possible. The subsequent Qtum project team will further interpret the key documents. If you have any questions, readers can post comments in the comments area or contact the Qtum project team .
The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch .
Please note that based on Patrick Dai's translation request, the content in this material is translated to English and published on Reddit.
OP's Qtum Address: QMmYAMEFgvPJGwK9nrwqYw1DHhBkiuEi78
submitted by szhman to Qtum [link] [comments]

Proposal: Invalidate bitcoin balances which haven't been spent in multiple years.

There are currently a lot of bitcoin balances which haven't moved for many years. Those pose a risk to the bitcoin market because some are very large, and if they were to be sold on an exchange, they could cause bitcoin prices to crash to zero.
There is speculation that many of these coins are no longer looked after by their owners, who might have lost them, moved on from bitcoin, or died.
I propose that all these balances be zeroed after an inactivity timeout of 4 years (210,000 blocks), and the "freed" coins added to mining rewards.
This would be achieved by making CHECKSIG operations always pass after 4 years, such that a miner may direct the coins to himself.
Thoughts?
submitted by londons_explorer to Bitcoin [link] [comments]

The Problems with Segregated Witness

MORE: https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
... 3. The Problems with Segregated Witness
While it is true that Segregated Witness offers some improvements to the Bitcoin network, we shall now examine why these benefits are not nearly enough to outweigh the dangers of deploying SW as a soft fork.
3.1 SW creates a financial incentive for bloating witness data
SW allows for a theoretical maximum block size limit of ~4 MB. However, this is only true if the entire block was occupied with transactions of a very small ‘base size’ (e.g. P2WPKH with 1 input, 1 output). In practice, based on the average transaction size today and the types of transactions made, the block size limit is expected to have a maximum limit of ~1.7 MB post-SW (Figure 10; assuming all transactions are using SW unspent outputs — a big assumption).
However, the 4 MB theoretical limit creates a key problem. Miners and full node operators need to ensure that their systems can handle the 4 MB limit, even though at best they will only be able to support ~40% of that transaction capacity. Why? Because there exists a financial incentive for malicious actors to design transactions with a small base size but large and complex witness data. This is exacerbated by the fact that witness scripts (i.e. P2SH-P2WSH or P2SH-P2WSH) will have higher script size limits that normal P2SH redeem scripts (i.e., from 520 bytes to 3,600 bytes [policy] or 10,000 bytes [consensus]). These potential problems only worsen as the block size limit is raised in the future, for example a 2 MB maximum base size creates an 8 MB adversarial case. This problem hinders scalability and makes future capacity increases more difficult.
3.2 SW fails to sufficiently address the problems it intends to solve
If SW is activated by soft fork, Bitcoin will effectively have two classes of UTXOs (non-SW vs SW UTXOs), each with different security and economic properties. Linear signature hashing and malleability fixes will only be available to the SW UTXO. Most seriously, there are no enforceable constraints to the growth of the non-SW UTXO. This means that the network (even upgraded nodes) are still vulnerable to transaction malleability and quadratic signature hashing from non-SW outputs that existed before or created after the soft fork.
The lack of enforceability that comes with a soft fork leaves Bitcoin users and developers vulnerable to precisely the type of attacks SW is designed to prevent. While spending non-SW outputs will be comparatively more expensive than SW outputs, this remains a relatively weak disincentive for a motivated attacker.
It is also unclear what proportion of the total number of the legacy UTXO will migrate to SW outputs. Long-term holders of Bitcoin, such as Satoshi Nakamoto (presumed to be in possession of ~1 million Bitcoin), may keep their coins in non-SW outputs (although it would be a significant vote of confidence in SW by Nakamoto if they were to migrate!). This makes future soft or hard forks to Bitcoin more difficult as multiple classes of UTXOs must now be supported to prevent coins from being burned or stolen.
One key concern is that the coexistence of two UTXO types may tempt developers and miners in the future to destroy the non-SW UTXO. Some may view this as an unfounded concern, but the only reason that this is worth mentioning in this article are the comments made by influential individuals associated with Bitcoin Core: Greg Maxwell has postulated that “abandoned UTXO should be forgotten and become unspendable,” and Theymos has claimed “the very-rough consensus is that old coins should be destroyed before they are stolen to prevent disastrous monetary inflation.”
As the security properties of SW outputs are marginally better than non-SW outputs, it may serve as a sufficient rationalization for this type of punitive action.
The existence of two UTXO types with different security and economic properties also deteriorates Bitcoin’s fungibility. Miners and fully validating nodes may decide not to relay, or include in blocks, transactions that spend to one type or the other. While on one hand this is a positive step towards enforceability (i.e. soft enforceability), it is detrimental to unsophisticated Bitcoin users who have funds in old or non-upgraded wallets. Furthermore, it is completely reasonable for projects such as the lightning network to reject forming bidirectional payment channels (i.e. a multisignature P2SH address) using non-SW P2SH outputs due to the possibility of malleability. Fundamentally this means that the face-value of Bitcoin will not be economically treated the same way depending on the type of output it comes from.
It is widely understood in software development that measures which rely on the assumption of users changing their behavior to adopt better security practices are fundamentally doomed to fail; more so when the unpatched vulnerabilities are permitted to persist and grow. An example familiar to most readers would be the introduction and subsequent snail’s pace uptake of HTTPS.
3.3 SW places complex requirements on developers to comply while failing to guarantee any benefits
SW as a soft fork brings with it a mountain of irreversible technical debt, with multiple opportunities for developers to permanently cause the loss of user funds. For example, the creation of P2SH-P2WPKH or P2SH-P2WSH addresses requires the strict use of compressed pubkeys, otherwise funds can be irrevocably lost. Similarly, the use of OP_IF, OP_NOTIF, OP_CHECKSIG, and OP_CHECKMULTISIG must be carefully handled for SW transactions in order to prevent the loss of funds. It is all but certain that some future developers will cause user loss of funds due to an incomplete understanding of the intricacies of SW transaction formats.
In terms of priorities, SW is not a solution to any of the major support ticket issues that are received daily by Bitcoin businesses such as BitPay, Coinbase, Blockchain.info, etc. The activation of SW will not increase the transaction capacity of Bitcoin overnight, but only incrementally as a greater percentage of transactions spend to SW outputs. Moreover, the growing demand for on-chain transactions may very well exceed the one-off capacity increase as demonstrated by the increasing frequency of transaction backlogs.
In contrast to a basic block size increase (BBSI) from a coordinated hard fork, many wallets and SPV clients will immediately benefit from new capacity increases without the need to rewrite their own software as they must do with SW.. With a BBSI, unlike SW, there are no transaction format or signature changes required on the part of Bitcoin-using applications.
Based on previous experience with soft forks in Bitcoin, upgrades tend to roll-out within the ecosystem over some time. At the time of this writing, only 28 out of the 78 business and projects (36%) who have publicly committed to the upgrade are SW-compatible. Any capacity increase that Bitcoin businesses and users of the network desire to ease on-chain fee pressure will unlikely be felt for some time, assuming that transaction volume remains unchanged and does not continue growing. The unpredictability of this capacity increase and the growth of the non-SW UTXO are particularly troubling for Bitcoin businesses from the perspectives of user-growth and security, respectively. Conversely, a BBSI delivers an immediate and predictable capacity increase.
The voluntary nature of SW upgrades is subject to the first-mover game theory problem. With a risky upgrade that moves transaction signatures to a new witness field that is hidden to some nodes, the incentive for the rational actor is to let others take that risk first, while the rational actor sits back, waits, and watches to see if people lose funds or have problems. Moreover, the voluntary SW upgrade also suffers from the free-rider game theory problem. If others upgrade and move their data to the witness field, one can benefit even without upgrading or using SW transactions themselves. These factors further contribute to the unpredictable changes to Bitcoin’s transaction capacity and fees if SW is adopted via a soft fork.
3.4 Economic distortions and price fixing
Segregated Witness as a soft fork alters the economic incentives that regulate access to Bitcoin’s one fundamental good: block-size space. Firstly, it subsidises signature data in large/complex P2WSH transactions (i.e., at ¼ of the cost of transaction/UTXO data). However, the signatures are more expensive to validate than the UTXO, which makes this unjustifiable in terms of computational cost. The discount itself appears to have been determined arbitrarily and not for any scientific or data-backed reasoning.
Secondly, the centralized and top-down planning of one of Bitcoin’s primary economic resources, block space, further disintermediates various market forces from operating without friction. SW as a soft fork is designed to preserve the 1 MB capacity limit for on-chain transactions, which will purposely drive on-chain fees up for all users of Bitcoin. Rising transaction fees, euphemistically called a ‘fee market’, is anything but a market when one side — i.e. supply — is fixed by central economic planners (the developers) who do not pay the costs for Bitcoin’s capacity (the miners). Economic history has long taught us the results of non-market intervention in the supply of goods and services: the costs are externalised to consumers. The adoption of SW as a soft fork creates a bad precedent for further protocol changes that affirm this type of economic planning.
3.5 Soft fork risks
In this section we levy criticisms of soft forks more broadly when they affect the protocol and economic properties of Bitcoin to the extent that SW does. In this case, a soft fork reduces the security of full nodes without the consent of the node operator. The SW soft fork forces node operators either to upgrade, or to unconditionally accept the loss of security by being downgraded to a SPV node.
Non-upgraded nodes further weaken the general security of Bitcoin as a whole through the reduction of the number of fully validating nodes on the network. This is because non-upgraded nodes will only perform the initial check to see if the redeem script hash matches the pubkey script hash of the unspent output. This redeem script may contain an invalid witness program, for P2WSH transactions, that the non-upgraded node doesn’t know how to verify. This node will then blindly relay the invalid transaction across the network.
SW as a soft fork is the opposite of anti-fragile. Even if the community wants the change (i.e., an increase in transaction capacity), soft-forking to achieve these changes means that the miners become the key target of lobbying (and they already are). Soft forks are risky in this context because it becomes relatively easy to change things, which may be desirable if the feature is both minor and widely beneficial. However, it is bad in this case because the users of Bitcoin (i.e. everyone else but the miners) are not given the opportunity to consent or opt-out, despite being affected the most by such a sweeping change. This can be likened to a popular head of state who bends the rules of jurisprudence to bypass slow legal processes to “get things done.” The dangerous precedent of taking legal shortcuts is not of concern the masses until a new, less popular leader takes hold of the reigns, and by then it is too late to reverse. In contrast, activating SW via a hard fork ensures that the entire community, not just the miners, decide on changes made to the protocol. Users who unequivocally disagree with a change being made are given the clear option not to adopt the change — not so with a soft fork.
3.6 Once activated, SW cannot be undone and must remain in Bitcoin codebase forever.
If any critical bugs resulting from SW are discovered down the road, bugs serious enough to contemplate rolling it back, then anyone will be able to spend native SW outputs, leading to a catastrophic loss of funds. ...
...
Conclusion
Segregated Witness is the most radical and irresponsible protocol upgrade Bitcoin has faced in its eight year history. The push for the SW soft fork puts Bitcoin miners in a difficult and unfair position to the extent that they are pressured into enforcing a complicated and contentious change to the Bitcoin protocol, without community consensus or an honest discussion weighing the benefits against the costs. The scale of the code changes are far from trivial — nearly every part of the codebase is affected by SW.
While increasing the transaction capacity of Bitcoin has already been significantly delayed, SW represents an unprofessional and ineffective solution to both transaction malleability and scaling. As a soft fork, SW introduces more technical debt to the protocol and fundamentally fails to achieve its design purpose. As a hard fork, combined with real on-chain scaling, SW can effectively mitigate transaction malleability and quadratic signature hashing. Each of these issues are too important for the future of Bitcoin to gamble on SW as a soft fork and the permanent baggage that comes with it.
As much as the authors of this article desire transaction capacity increases, it is far better to work towards a clean technical solution to malleability and scaling than to further encumber the Bitcoin protocol with permanent technical debt. ...
MORE: https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
submitted by german_bitcoiner to bitcoin_offical [link] [comments]

ConceptCoin

ConceptCoin is a proof-of-concept crypto-currency. The idea is to create a currency which can be used to test out some new ideas.
The first idea is to test out an improved version of proof-of-stake which uses a trusted source of randomness to select which coin holder is able to create new blocks. The first implementation will use NIST's randomness beacon as a source of randomness.
We also want to test out ideas to stabilise the price of the crypto-currency via a blockchain based voting system and methods of monetary base inflation/deflation.
Join the team @http://www.reddit.com/Conceptcoin/
Contact me to speak about donations/funding. Would like feedback on the Protocol below.
Protocol V0.1 Draft (as drafted by telepatheic)
Introduction
To aid interoperability, development speed and to prevent programmer confusion, ConceptCoin will be based on the existing Bitcoin protocol in v0.1, subsequent versions will implement changes to increase efficiency (such as using a faster ECDSA curve) and make the protocol more consistent. The specification is based upon https://en.bitcoin.it/wiki/Protocol_specification and v0.9.1 of the bitcoin core code. Where the two are not in agreement the v0.9.1 bitcoin core code takes priority.
There will be some small changes as follows:
The magic value is F3 B2 BA D1 The relay field is removed from the version message filterload, filteradd, filterclear, merkleblock, and alert messages are not supported
There will be three major changes which will be explained in greater depth:
Scripting will be simplified Blocks will have a different structure to support proof of stake mining Beacon blocks are introduced
Scripting simplifications
The only valid scripts are those of the following form:
scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG scriptSig:
Blocks
Blocks are where the most significant changes are. Blocks must be signed by the block creator. To help detect double signing of blocks in future versions, the signature is of the block hash concatenated with the magic value and the timestamp. This makes sure that signing other pieces of data can't be used as evidence of signing ConceptCoin blocks.
Block header:
Version uint32_t: as in Bitcoin = 1
Timestamp uint32_t: must be greater than the last beacon block timestamp and less than the last beacon block timestamp + 60. Default is beacon block timestamp + 30
Block creator pubKey char[33]: the block creator's public key in compressed form given as where is 0x02 if y is even and 0x03 if y is odd. (see section below)
Previous block hash char[32]: the hash of the previous valid block
Merkle tree hash char[32]: As in Bitcoin
Block hash char[32]: The SHA256 hash of the previous fields
Block hash signature char[64]: The signature for the block hash concatenated with the magic value and the timestamp.
Block body:
Number of transactions uint16_t: The number of transactions which follows (note: slight difference to Bitcoin, uses fixed length integer)
Transactions starting with the coinbase transaction (same as Bitcoin)
Creating a block
Block creators are selected by the random seed in the previous beacon block. The selection is weighted by the amount of unspent output such that it becomes proof of stake based.
All pubKeyHashes from unspent outputs (except those created in the previous block) are ordered in a database by pubKeyHash from smallest to largest alongside the cumulative (starting from the smallest pubKeyHash) amount of unspent output. We take the 512 bit random seed and find the (mod total unspent output) of this number to get a random selector. The pubKeyHash selected is the one which has the smallest cumulative value next to it where the cumulative value is greater than the random selector. Here is a simplified example:
pubKeyHash Unspent output 12 30 17 4 32 5 21 12 19 9 24 16
pubKeyHash Cumulative Value of selector required 12 30 0-29 17 34 30-33 19 43 34-42 21 55 43-54 24 71 55-70 32 76 71-75
If the random output from the beacon was 412: 412 (mod 76) = 32 so pubKeyHash 17 is selected
Because not all key holders are likely to be online, blocks will not be created every minute in v0.1 (this will be modified in subsequent versions). Also in v0.1 double signing of different blocks is technically possible creating forks. Double block signing detection will be added in subsequent versions.
Beacon block
Version uint32_t: the version of the beacon block (can be used to change to different beacon specifications) = 1
Timestamp uint32_t: must match the NIST beacon timestamp
NIST version var_str: must match the NIST beacon version string
NIST frequency uint32_t: must match the NIST beacon frequency (normally 60)
NIST seed value char[64]: must match the NIST beacon seed value
NIST status uint32_t: must match the NIST beacon status code
NIST signature char[256]: must match the NIST beacon signature
NIST output value char[64]: must match the NIST beacon output value
A beacon block is a new message with command = "beacon". It allows everyone to be aware of the last random number generated without overloading the NIST randomness beacon server. The signature signs the previous output value to link the beacon blocks together.
More details will be provided on how to verify that beacon blocks are genuine.
Transaction fees
By default transaction fees are 0.
Block rewards
Block rewards are 100 base (indivisible) units. This is an arbitrary choice and there will be no economic mechanism in v0.1
The maturation period for coinbase transactions is 10 blocks but they contribute to the pubKeyHash selection algorithm in the same way as all other transactions.
Edited to update beacon block data types.
submitted by Mox16 to altcoin [link] [comments]

Feedback on ConceptCoin?

ConceptCoin is a proof-of-concept crypto-currency. The idea is to create a currency which can be used to test out some new ideas.
The first idea is to test out an improved version of proof-of-stake which uses a trusted source of randomness to select which coin holder is able to create new blocks. The first implementation will use NIST's randomness beacon as a source of randomness.
We also want to test out ideas to stabilise the price of the crypto-currency via a blockchain based voting system and methods of monetary base inflation/deflation.
Join the team @http://www.reddit.com/Conceptcoin/
Contact me to speak about donations/funding. Would like feedback on the Protocol below.
Protocol V0.1 Draft (as drafted by telepatheic)
Introduction
To aid interoperability, development speed and to prevent programmer confusion, ConceptCoin will be based on the existing Bitcoin protocol in v0.1, subsequent versions will implement changes to increase efficiency (such as using a faster ECDSA curve) and make the protocol more consistent. The specification is based upon https://en.bitcoin.it/wiki/Protocol_specification and v0.9.1 of the bitcoin core code. Where the two are not in agreement the v0.9.1 bitcoin core code takes priority.
There will be some small changes as follows:
The magic value is F3 B2 BA D1 The relay field is removed from the version message filterload, filteradd, filterclear, merkleblock, and alert messages are not supported 
There will be three major changes which will be explained in greater depth:
Scripting will be simplified Blocks will have a different structure to support proof of stake mining Beacon blocks are introduced 
Scripting simplifications
The only valid scripts are those of the following form:
scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG scriptSig:
Blocks
Blocks are where the most significant changes are. Blocks must be signed by the block creator. To help detect double signing of blocks in future versions, the signature is of the block hash concatenated with the magic value and the timestamp. This makes sure that signing other pieces of data can't be used as evidence of signing ConceptCoin blocks.
Block header:
Version uint32_t: as in Bitcoin = 1
Timestamp uint32_t: must be greater than the last beacon block timestamp and less than the last beacon block timestamp + 60. Default is beacon block timestamp + 30
Block creator pubKey char[33]: the block creator's public key in compressed form given as where is 0x02 if y is even and 0x03 if y is odd. (see section below)
Previous block hash char[32]: the hash of the previous valid block
Merkle tree hash char[32]: As in Bitcoin
Block hash char[32]: The SHA256 hash of the previous fields
Block hash signature char[64]: The signature for the block hash concatenated with the magic value and the timestamp.
Block body:
Number of transactions uint16_t: The number of transactions which follows (note: slight difference to Bitcoin, uses fixed length integer)
Transactions starting with the coinbase transaction (same as Bitcoin)
Creating a block
Block creators are selected by the random seed in the previous beacon block. The selection is weighted by the amount of unspent output such that it becomes proof of stake based.
All pubKeyHashes from unspent outputs (except those created in the previous block) are ordered in a database by pubKeyHash from smallest to largest alongside the cumulative (starting from the smallest pubKeyHash) amount of unspent output. We take the 512 bit random seed and find the (mod total unspent output) of this number to get a random selector. The pubKeyHash selected is the one which has the smallest cumulative value next to it where the cumulative value is greater than the random selector. Here is a simplified example:
pubKeyHash Unspent output 12 30 17 4 32 5 21 12 19 9 24 16
pubKeyHash Cumulative Value of selector required 12 30 0-29 17 34 30-33 19 43 34-42 21 55 43-54 24 71 55-70 32 76 71-75
If the random output from the beacon was 412: 412 (mod 76) = 32 so pubKeyHash 17 is selected
Because not all key holders are likely to be online, blocks will not be created every minute in v0.1 (this will be modified in subsequent versions). Also in v0.1 double signing of different blocks is technically possible creating forks. Double block signing detection will be added in subsequent versions.
Beacon block
Version uint32_t: the version of the beacon block (can be used to change to different beacon specifications) = 1
Timestamp uint32_t: must match the NIST beacon timestamp
NIST version var_str: must match the NIST beacon version string
NIST frequency uint32_t: must match the NIST beacon frequency (normally 60)
NIST seed value char[64]: must match the NIST beacon seed value
NIST status uint32_t: must match the NIST beacon status code
NIST signature char[256]: must match the NIST beacon signature
NIST output value char[64]: must match the NIST beacon output value
A beacon block is a new message with command = "beacon". It allows everyone to be aware of the last random number generated without overloading the NIST randomness beacon server. The signature signs the previous output value to link the beacon blocks together.
More details will be provided on how to verify that beacon blocks are genuine.
Transaction fees
By default transaction fees are 0.
Block rewards
Block rewards are 100 base (indivisible) units. This is an arbitrary choice and there will be no economic mechanism in v0.1
The maturation period for coinbase transactions is 10 blocks but they contribute to the pubKeyHash selection algorithm in the same way as all other transactions.
Edited to update beacon block data types.
submitted by Mox16 to Bitcoin [link] [comments]

ConceptCoin

ConceptCoin (to be renamed) is a proof-of-concept crypto-currency. The idea is to create a currency which can be used to test out some new ideas. If successful they will be carried out into the final released version of the coin.
The first idea is to test out an improved version of proof-of-stake which uses a trusted source of randomness to select which coin holder is able to create new blocks. The first implementation will use NIST's randomness beacon as a source of randomness.
We also want to test out ideas to stabilise the price of the crypto-currency via a blockchain based voting system and methods of monetary base inflation/deflation.
Join the team @http://www.reddit.com/Conceptcoin/ Grin Kiss Smiley
Contact me to speak about donations/funding.
Protocol V0.1 Draft (as drafted by telepatheic)
Introduction
To aid interoperability, development speed and to prevent programmer confusion, ConceptCoin will be based on the existing Bitcoin protocol in v0.1, subsequent versions will implement changes to increase efficiency (such as using a faster ECDSA curve) and make the protocol more consistent. The specification is based upon https://en.bitcoin.it/wiki/Protocol_specification and v0.9.1 of the bitcoin core code. Where the two are not in agreement the v0.9.1 bitcoin core code takes priority.
There will be some small changes as follows:
The magic value is F3 B2 BA D1 The relay field is removed from the version message filterload, filteradd, filterclear, merkleblock, and alert messages are not supported 
There will be three major changes which will be explained in greater depth:
Scripting will be simplified Blocks will have a different structure to support proof of stake mining Beacon blocks are introduced 
Scripting simplifications
The only valid scripts are those of the following form:
scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG scriptSig:
Blocks
Blocks are where the most significant changes are. Blocks must be signed by the block creator. To help detect double signing of blocks in future versions, the signature is of the block hash concatenated with the magic value and the timestamp. This makes sure that signing other pieces of data can't be used as evidence of signing ConceptCoin blocks.
Block header:
Version uint32_t: as in Bitcoin = 1
Timestamp uint32_t: must be greater than the last beacon block timestamp and less than the last beacon block timestamp + 60. Default is beacon block timestamp + 30
Block creator pubKey char[33]: the block creator's public key in compressed form given as where is 0x02 if y is even and 0x03 if y is odd. (see section below)
Previous block hash char[32]: the hash of the previous valid block
Merkle tree hash char[32]: As in Bitcoin
Block hash char[32]: The SHA256 hash of the previous fields
Block hash signature char[64]: The signature for the block hash concatenated with the magic value and the timestamp.
Block body:
Number of transactions uint16_t: The number of transactions which follows (note: slight difference to Bitcoin, uses fixed length integer)
Transactions starting with the coinbase transaction (same as Bitcoin)
Creating a block
Block creators are selected by the random seed in the previous beacon block. The selection is weighted by the amount of unspent output such that it becomes proof of stake based.
All pubKeyHashes from unspent outputs (except those created in the previous block) are ordered in a database by pubKeyHash from smallest to largest alongside the cumulative (starting from the smallest pubKeyHash) amount of unspent output. We take the 512 bit random seed and find the (mod total unspent output) of this number to get a random selector. The pubKeyHash selected is the one which has the smallest cumulative value next to it where the cumulative value is greater than the random selector. Here is a simplified example:
pubKeyHash Unspent output 12 30 17 4 32 5 21 12 19 9 24 16
pubKeyHash Cumulative Value of selector required 12 30 0-29 17 34 30-33 19 43 34-42 21 55 43-54 24 71 55-70 32 76 71-75
If the random output from the beacon was 412: 412 (mod 76) = 32 so pubKeyHash 17 is selected
Because not all key holders are likely to be online, blocks will not be created every minute in v0.1 (this will be modified in subsequent versions). Also in v0.1 double signing of different blocks is technically possible creating forks. Double block signing detection will be added in subsequent versions.
Beacon block
Version uint32_t: the version of the beacon block (can be used to change to different beacon specifications) = 1
Timestamp uint32_t: must match the NIST beacon timestamp
NIST version var_str: must match the NIST beacon version string
NIST frequency uint32_t: must match the NIST beacon frequency (normally 60)
NIST seed value char[64]: must match the NIST beacon seed value
NIST status uint32_t: must match the NIST beacon status code
NIST signature char[256]: must match the NIST beacon signature
NIST output value char[64]: must match the NIST beacon output value
A beacon block is a new message with command = "beacon". It allows everyone to be aware of the last random number generated without overloading the NIST randomness beacon server. The signature signs the previous output value to link the beacon blocks together.
More details will be provided on how to verify that beacon blocks are genuine.
Transaction fees
By default transaction fees are 0.
Block rewards
Block rewards are 100 base (indivisible) units. This is an arbitrary choice and there will be no economic mechanism in v0.1
The maturation period for coinbase transactions is 10 blocks but they contribute to the pubKeyHash selection algorithm in the same way as all other transactions.
Edited to update beacon block data types.
submitted by Mox16 to CryptoCurrency [link] [comments]

BTCIOT Tutorial - LED Matrix bitcoin price checker Check BTC Balance Crypto-Currency: How to check the balance of any address ... Bitcoin Price Rises to $9,500  BTC Meets Banking As US ... Bitcoin price drop - Bitcoin btc price analysis  check live price chart  march 28th 2020

Check Bitcoin (BTC) address 1K4XxLfByfWXCqc8EfJYEwMT1aU3eMpq5Z balance and its transactions Update: The article has been updated to reflect the new 4769 all time high and take the November 2x fork into consideration (thank you Bitcoin&Robin!Come talk to us at WhaleClub!).. Update 2: It looks like 5000 it is.. All time high again, again. This time the price hit 4769 USD. We had some crazy movements that affected even the 1 week chart, so let’s analyse it. 8 Countries Stricken With Rampant Inflation See Bitcoin Prices Touch All-Time Highs. The price of bitcoin touched new highs in 2020 and a number of supporters are optimistic that the crypto asset ... Bitcoin Price 1. Bitcoin Price Today. Bitcoin is now trading from $11,056(+1,16 %) – Bitcoin Price Today: Bitcoin is climbing and has already passed the $ 11k resistance level, where is it going?. The cost of Bitcoin has broken beyond the $11,000 mark only one day after payments business Square revealed it’d decided to buy fifty dolars million of digital currency. Bitcoin price is entirely determined, at that exact moment, by what somebody is willing to pay for a bitcoin. This means that while you can get a general idea of pricing, just how much you pay for a bitcoin varies depending on who you’re talking to, which leaves a lot of room to haggle if you’re buying. As a result, different exchanges will have different numbers. There Is Lots of ...

[index] [7391] [7941] [10245] [29545] [35840] [35336] [13149] [6094] [22578] [44930]

BTCIOT Tutorial - LED Matrix bitcoin price checker

Bitcoin price is up on news of Deutsche Bank starting lay offs, Singapore looks set to welcome crypto for retail, and South Korean crypto craze continues! GR... ️ Tap into OPM (Other People's Money): http://opm.cryptonewsalerts.net Bitcoin price broke out from a tightening range to rally above $9,500 but will BTC ho... Close. This video is unavailable. We aim to understand how bitcoin nodes validate a bitcoin transaction by concatenation of output and input scripts . Therefor we analyze the format of Bitcoin transaction. This is needed to ... Today we use an LED matrix and ESP32 to make a bitcoin price checker. The module also outputs Hal Finney quotes, between checking the price - all for under $...

#