Natural gas venting: How Bitcoin solved a 160 year old problem

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]

As part of my ongoing effort to develop stupid shit for Garlicoin, I present you: W-addresses!

“Wait, what?!” I hear you asking? Well…(buckle up, this is another one of my technical posts that goes on, and on…)
For some time now, I have been using native SegWit (Pay-to-Witness-Public-Key-Hash, P2WPKH) transactions for myself. Mostly because they have a 75% fee subsidy on signature data (which comes out on ~50% fee subsidy on the entire transaction, depending on the type of transaction) and I am dutch after all ;-)
It turns out that Garlicoin Core kind of supports them and kind of does not. If you manually register the transaction redeem script to your wallet (using the addwitnessaddress command) it will start recognizing them on the blockchain but gets kind of confused on how to deal with them, so it registers them all as ‘change’ transactions. Still, this means you can receive coins using these types of transactions and pay with them in all ways you can with regular Garlicoins, except your transactions are cheaper.
However, sending coins using native SegWit is quite a hassle. You can basically only do it by creating your own raw transactions (createrawtransaction, edit it to make it native SegWit, fundrawtransaction, signrawtransaction, sendrawtransaction). On top of this, any change address the wallet creates are still legacy/normal Garlicoin addresses, so you will end up with a bunch of unspent transaction outputs (UTXOs) for which you have to pay full fee anyway. I decided we (I) could do better than this.
But first a few steps back. What is this native SegWit anyway and weren’t people already using SegWit? Wasn’t there a user that just after mainnet launched accidentally made a SegWit transaction? So what the hell am I talking about?
To understand this, you will need to know a few things about what SegWit is and how Bitcoin Garlicoin transactions work in general. Note that this bit gets really technical, so if you are not interested, you might want to skip ahead. A lot.
First thing to understand is that addresses are not really a thing if you look at the blockchain. While nodes and explorers will interpret parts of a transaction as addresses, in reality addresses are just an abstraction around Bitcoin Script and an easy way send coins instead of asking people “hey, can you send some coins to the network in such a way that only the private key that corresponds to public key XYZ can unlock them?”. Let’s look at an example: say I ask you to send coins to my address GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxC. What ends up happening is that you send coins out a transaction where you say that the coin are locked in the blockchain and can only be unlocked by successfully executing the following script:
OP_DUP OP_HASH160 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050 OP_EQUALVERIFY OP_CHECKSIG
Now, without getting too technical, this means something like this:
As you can see, the address actually represents a well-known piece of script. This start making sense if you look at the decoded address:
26 4E9856671C3ABB2F03B7D80B9238E8F5ECD9F050 F8F1F945
The first byte (0x26, or 38) is the version byte. This tells the clients how the interpret the rest of the script. In our case 38 means Pay-to-Public-Key-Hash (P2PKH), or in other words the script mentioned above. The part after that is just the SHA1 hash of the public key and the final 4 bytes are a checksum to verify you did not make a typo when entering the address.
Enter SegWit. What SegWit exactly is depends on who you are talking to, however it mostly is a different transaction format/protocol. The main change of SegWit is that signature data is not longer included in the transaction (fixing transaction malleability). Instead transaction data is sent separate from the transaction itself and outside of the (main) blocks.
This is not really that much of an issue, except for the fact that people wanted to enable SegWit as a soft-fork instead of a hard-fork. This means that somehow unupgraded nodes needed a way to deal with these new transaction types without being able to verify them.
The solution turned out to be to make use of an implementation detail of Bitcoin Script: if a piece of script executes without any errors, the last bit of data determines whether the transaction is valid (non-zero) or invalid (zero). This is what they used to implement SegWit.
So what does this look like? Well, you might be surprised how simple a P2WPKH (the SegWit way of doing a P2PKH transaction) script looks:
00 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050
Yes. That’s it.
The first byte is the Witness program version byte. I.e. it tells you how the other data should be interpreted (very similar to how addresses work). Then there is the hash of the public key. As you can see, SegWit does not actually use Bitcoin Script. Mostly because it needs old nodes to ‘just accept’ its transactions. However interestingly enough, while the transaction format changed, the transaction data is pretty much the same:
This means that these kind of SegWit transactions need a new way of addressing them. Now, you might think that this is where the ‘3’ addresses on Bitcoin or the ‘M’ addresses on Garlicoin come in. However, that is not the case.
These addresses are what are called Pay-to-Script-Hash (P2SH) addresses. There scrypt is like this:
OP_HASH160 35521b9e015240942ad6b0735c6e7365354b0794 OP_EQUAL
Huh? Yeah, these are a very special type of transactions, that kind of go back to the “hey, can you send some coins to the network in such a way that only the private key that corresponds to public key XYZ can unlock them?” issue.
These transactions are a way to have arbitrary smart contracts (within the limits of Bitcoin Script) to determine whether a transaction output can be spend or not without the sender of the coins having to deal with your scripts. Basically they use a hash of the “real” script, which whoever owns the coins has to provide when they want to spend them, as well as the specific inputs required for a script. This functionality is for example used in multi-signature (MultiSig) wallets, without requiring someone sending money to these wallets having to deal with random bits of information like how many signatures are required, how many private keys belong to the wallet, etc.
This same method is used for so called P2SH-wrapped SegWit transactions (or P2SH-P2WPKH). Consider our earlier SegWit transaction output script:
00 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050
Or 00144e9856671c3abb2f03b7d80b9238e8f5ecd9f050 in low-level hex. The P2SH script for this would be:
OP_HASH160 a059c8385124aa273dd3feaf52f4d94d42f01796 OP_EQUAL
Which would give us address MNX1uHyAQMXsGiGt5wACiyMUgjHn1qk1Kw. This is what is now widely known and used as SegWit. But this is P2SH-wrapper SegWit, not native or "real" SegWit. Native would be using the data-only SegWit script directly.
The reason for using the P2SH variant is mostly about compatibility. While SegWit nodes understand these newer transactions, they were never officially assigned a way to convert them to addresses. Hence, they will show up in blockchain explorers as Unparsed address [0] or something similar. Then there is also the whole thing about old nodes and relaying non-standard transactions, but I will skip that bit for now.
Bitcoin is using/going to use new BECH32 addresses for native SegWit transactions, which looks completely different from the old Base-58 encoded addresses. However, right now, especially on Garlicoin, you cannot really use them and have to use the P2SH variant. But why not use these new cool transaction types without having to deal with all that useless and complex P2SH wrapping, right? Right? …
Well, I went ahead and gave them their (unofficial) address space.
So last thursday I made some changes to Garlicoin Core, to make dealing with these native SegWit transaction a lot easier. In short, the changes consist of:
  • Assigning address version byte 73 to them, in other words addresses starting with a ‘W’ (for ‘witness’).
  • Allowing the use of ‘W’ addresses when sending coins.
  • Make the wallet automatically recognize the SegWit transaction type for any newly generated address.
  • Add the getwitnessaddress command, which decodes a version 38 ‘G’ address and re-encodes the same data as a version 73 ‘W’ address (unfortunately it is not as simple as just changing the first letter). Note that this can be any address, not just your own. (That said, you should not send SegWit transactions to people not expecting them, always use the address given to you.)
  • Added the usewitnesschangeaddress configuration setting, to automatically use the cheaper SegWit transaction outputs for transaction change outputs.
  • (Since using the 'W' address only changes the way coins are sent to you and the private key used for both transaction types is the same:) When receiving coins they show all up under the original ‘G’ address, whether a SegWit or legacy/normal transaction type was used. The idea behind this is that both are actually the same "physical" (?) address, just to the way to coins to it differs. Address book entries are also merged and default to the ‘G’ address type.
Anyway, I don’t expect people to actually use this or it getting merged into mainline or anything. I actually mostly made this for myself, but thought I should share anyway. I guess it was also a nice opportunity to talk a bit about transactions and SegWit. :-)
Btw, I also changed my pool to allow mining to ‘W’ addresses, to make coin consolidation cheaper (due to the SegWit fee subsidy). Right now this is only for instant payout though (as I would have to update the wallet node the pool is using for daily payout, which I haven’t done yet).
Also note that you can actually mine to a ‘W’ address (and therefore use cheaper transactions) even if you are running the official, non-patched version of Garlicoin Core, however:
  • You need to manually convert your ‘G’ address to a ‘W’ address.
  • You need to run the addwitnessaddress command (Help -> Debug Window -> Console) to make the wallet recognize SegWit transactions (you can ignore the ‘M’ address it produces).
  • The wallet might get a bit confused as it does not really understand how it got the coins. This is mostly notable in the ‘Coin Control’ window if you have it enabled. Apart from that everything should still work though.
submitted by nuc1e4r5n4k3 to garlicoin [link] [comments]

VGO will be launched on LOEX Global at 20:00 on July 2.

Dear LOEX users: Loex Global will soon launch VGO (VirtualGoodsToken) and open VGO/USDT trading pairs. The specific time is as follows: Loex Global will provide VGO charging service at 14:00 Singapore time on July 2.VGO/USDT trading market will be opened at 20:00 on July 2.
Token Introduction Token Name:VirtualGoodsToken Abbreviation:VGO Issue Supply:2.1 billion Website:http://vgo.life Official Website:http://vgo.life/vgo_white_paper.pdf Project Introduction:VGO (VirtualGoodsToken, Chinese for Virtual Goods Pass) addresses many of the limitations of the Bitcoin system as a transactional, everyday currency designed to provide a scalable and sustainable alternative to Bitcoin. VGO is a bitcoin spread project. The algorithm mainly includes SHA256 and RIPEMD160. Bitcoin combines the application of these two hash algorithms into two functions: hash256(d)=sha256(sha256(d)) and hash160(d)= Ripemd160(sha256(d)), where d is the byte array to be hashed, and the two generate hexadecimal values ​​of 256 bits (32 bytes) and 160 bits (20 bytes), respectively. Hash256 is mainly used to generate identifiers, such as block ID, transaction ID, etc., and hash160 is mainly used to generate VGO addresses. The above algorithm can be developed on any computer and never requires specialized mining equipment. VGO enables efficient transaction confirmation. And through the VVM (VGO Virtual Machine) smart contract virtual machine to carry out smart contract encoding operation, providing a faster, more scalable blockchain platform, more suitable for daily trading use.
Risk Reminder Investing in digital assets comes with high risks due to huge price fluctuations. Before investing, please have a full understanding of all the risks of investing in digital assets and be prudent of your own investment decisions.
Enjoy your trading on Loex Global! Follow us on: www.loex.io
Loex Global Related Community
Official reddit:https://www.reddit.com/useLOEXCHANGE
Official Twitter:https://twitter.com/LoexGlobal
Official telegraph group:http://t.me/loexmember
Official BQI community:https://t.bqi.com/exchange/loex.html
Official Weibo :https://weibo.com/6870211274/profile?rightmod=1&wvr=6&mod=personnumber
Loex Global June 28, 2019
submitted by LOEXCHANGE to u/LOEXCHANGE [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]

Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) | Matt Corallo | Mar 16 2015

Matt Corallo on Mar 16 2015:
In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
stack element, adds the height of the output being spent and then has
identical semantics to CLTV.
A slightly different API (and different name) was described by maaku at
http://www.reddit.com/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154
which does a better job of saving softfork-available opcode space.
There are two major drawbacks to adding such an operation, however.
1) More transaction information is exposed inside the script (prior to
CLTV we only had the sigchecking operation exposed, with a CLTV and
RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions).
2) Bitcoin Core's mempool invariant of "all transactions in the mempool
could be thrown into one overside block and aside from block size, it
would be valid" becomes harder to enforce. Currently, during reorgs,
coinbase spends need checked (specifically, anything spending THE
coinbase 100 blocks ago needs checked) and locktime transactions need
checked. With such a new operation, any script which used this new
opcode during its execution would need to be re-evaluated during reorgs.
I think both of these requirements are reasonable and not particularly
cumbersome, and the value of such an operation is quite nice for some
protocols (including settings setting up a contest interval in a
sidechain data validation operation).
Thoughts?
Matt
On 10/01/14 13:08, Peter Todd wrote:
I've written a reference implementation and BIP draft for a new opcode,
CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at:
https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki
The reference implementation, including a full-set of unittests for the
opcode semantics can be found at:
https://github.com/petertodd/bitcoin/compare/checklocktimeverify

BIP:
Title: OP_CHECKLOCKTIMEVERIFY
Author: Peter Todd <pete at petertodd.org>
Status: Draft
Type: Standards Track
Created: 2014-10-01

==Abstract==
This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin
scripting system that allows a transaction output to be made unspendable until
some point in the future.
==Summary==
CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it
compares the top item on the stack to the nLockTime field of the transaction
containing the scriptSig. If that top stack item is greater than the transation
nLockTime the script fails immediately, otherwise script evaluation continues
as though a NOP was executed.
The nLockTime field in a transaction prevents the transaction from being mined
until either a certain block height, or block time, has been reached. By
comparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we
indirectly verify that the desired block height or block time has been reached;
until that block height or block time has been reached the transaction output
remains unspendable.
==Motivation==
The nLockTime field in transactions makes it possible to prove that a
transaction output can be spent in the future: a valid signature for a
transaction with the desired nLockTime can be constructed, proving that it is
possible to spend the output with that signature when the nLockTime is reached.
An example where this technique is used is in micro-payment channels, where the
nLockTime field proves that should the receiver vanish the sender is guaranteed
to get all their escrowed funds back when the nLockTime is reached.
However the nLockTime field is insufficient if you wish to prove that
transaction output ''can-not'' be spent until some time in the future, as there
is no way to prove that the secret keys corresponding to the pubkeys controling
the funds have not been used to create a valid signature.
===Escrow===
If Alice and Bob jointly operate a business they may want to
ensure that all funds are kept in 2-of-2 multisig transaction outputs that
require the co-operation of both parties to spend. However, they recognise that
in exceptional circumstances such as either party getting "hit by a bus" they
need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny,
to act as a third-party.
With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with
either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer
not to have immediate access to the funds to discourage bad actors from
attempting to get the secret keys from him by force.
However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
the form:
IF  CHECKLOCKTIMEVERIFY DROP  CHECKSIGVERIFY 1 ELSE 2 ENDIF   2 CHECKMULTISIG 
At any time the funds can be spent with the following scriptSig:
  0 
After 3 months have passed Lenny and one of either Alice or Bob can spend the
funds with the following scriptSig:
  1 
===Non-interactive time-locked refunds===
There exist a number of protocols where a transaction output is created that
the co-operation of both parties to spend the output. To ensure the failure of
one party does not result in the funds becoming lost refund transactions are
setup in advance using nLockTime. These refund transactions need to be created
interactively, and additionaly, are currently vulnerable to transaction
mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the
interactive setup with a non-interactive setup, and additionally, making
transaction mutability a non-issue.
====Two-factor wallets====
Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's
such that one keypair is controlled by the user, and the other keypair is
controlled by the service. To spend funds the user uses locally installed
wallet software that generates one of the required signatures, and then uses a
2nd-factor authentication method to authorize the service to create the second
SIGHASH_NONE signature that is locked until some time in the future and sends
the user that signature for storage. If the user needs to spend their funds and
the service is not available, they wait until the nLockTime expires.
The problem is there exist numerous occasions the user will not have a valid
signature for some or all of their transaction outputs. With
CHECKLOCKTIMEVERIFY rather than creating refund signatures on demand
scriptPubKeys of the following form are used instead:
IF  CHECKSIGVERIFY ELSE  CHECKLOCKTIMEVERIFY DROP ENDIF  CHECKSIG 
Now the user is always able to spend their funds without the co-operation of
the service by waiting for the expiry time to be reached.
====Micropayment Channels====
Jeremy Spilman style micropayment channels first setup a deposit controlled by
2-of-2 multisig, tx1, and then adjust a second transaction, tx2, that spends
the output of tx1 to payor and payee. Prior to publishing tx1 a refund
transaction is created, tx3, to ensure that should the payee vanish the payor
can get their deposit back. The process by which the refund transaction is
created is currently vulnerable to transaction mutability attacks, and
additionally, requires the payor to store the refund. Using the same
scriptPubKey from as in the Two-factor wallets example solves both these issues.
===Trustless Payments for Publishing Data===
The PayPub protocol makes it possible to pay for information in a trustless way
by first proving that an encrypted file contains the desired data, and secondly
crafting scriptPubKeys used for payment such that spending them reveals the
encryption keys to the data. However the existing implementation has a
significant flaw: the publisher can delay the release of the keys indefinitely.
This problem can be solved interactively with the refund transaction technique;
with CHECKLOCKTIMEVERIFY the problem can be non-interactively solved using
scriptPubKeys of the following form:
IF HASH160  EQUALVERIFY  CHECKSIG ELSE  CHECKLOCKTIMEVERIFY DROP  CHECKSIG ENDIF 
The buyer of the data is now making a secure offer with an expiry time. If the
publisher fails to accept the offer before the expiry time is reached the buyer
can cancel the offer by spending the output.
===Proving sacrifice to miners' fees===
Proving the sacrifice of some limited resource is a common technique in a
variety of cryptographic protocols. Proving sacrifices of coins to mining fees
has been proposed as a ''universal public good'' to which the sacrifice could
be directed, rather than simply destroying the coins. However doing so is
non-trivial, and even the best existing technqiue - announce-commit sacrifices
create outputs that are provably spendable by anyone (thus to mining fees
assuming miners behave optimally and rationally) but only at a time
sufficiently far into the future that large miners profitably can't sell the
sacrifices at a discount.
===Replacing the nLockTime field entirely===
As an aside, note how if the SignatureHash() algorithm could optionally cover
part of the scriptSig the signature could require that the scriptSig contain
CHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed.
(the CODESEPARATOR opcode came very close to making this possible in v0.1 of
Bitcoin) This per-signature capability could replace the per-transaction
nLockTime field entirely as a valid signature would now be the proof that a
transaction output ''can'' be spent.
==Detailed Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP2: { // CHECKLOCKTIMEVERIFY // // (nLockTime -- nLockTime ) if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY)) break; // not enabled; treat as a NOP if (stack.size() < 1) return false; // Note that elsewhere numeric opcodes are limited to // operands in the range -2**31+1 to 2**31-1, however it is // legal for opcodes to produce results exceeding that // range. This limitation is implemented by CScriptNum's // default 4-byte limit. // // If we kept to that limit we'd have a year 2038 problem, // even though the nLockTime field in transactions // themselves is uint32 which only becomes meaningless // after the year 2106. // // Thus as a special case we tell CScriptNum to accept up // to 5-byte bignums, which are good until 2**32-1, the // same limit as the nLockTime field itself. const CScriptNum nLockTime(stacktop(-1), 5); // In the rare event that the argument may be < 0 due to // some arithmetic being done first, you can always use // 0 MAX CHECKLOCKTIMEVERIFY. if (nLockTime < 0) return false; // There are two times of nLockTime: lock-by-blockheight // and lock-by-blocktime, distinguished by whether // nLockTime < LOCKTIME_THRESHOLD. // // We want to compare apples to apples, so fail the script // unless the type of nLockTime being tested is the same as // the nLockTime in the transaction. if (!( (txTo.nLockTime < LOCKTIME_THRESHOLD && nLockTime < LOCKTIME_THRESHOLD) || (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD) )) return false; // Now that we know we're comparing apples-to-apples, the // comparison is a simple numeric one. if (nLockTime > (int64_t)txTo.nLockTime) return false; // Finally the nLockTime feature can be disabled and thus // CHECKLOCKTIMEVERIFY bypassed if every txin has been // finalized by setting nSequence to maxint. The // transaction would be allowed into the blockchain, making // the opcode ineffective. // // Testing if this vin is not final is sufficient to // prevent this condition. Alternatively we could test all // inputs, but testing just this input minimizes the data // required to prove correct CHECKLOCKTIMEVERIFY execution. if (txTo.vin[nIn].IsFinal()) return false; break; } 
https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4
==Upgrade and Testing Plan==
TBD
==Credits==
Thanks goes to Gregory Maxwell for suggesting that the argument be compared
against the per-transaction nLockTime, rather than the current block height and
time.
==References==
PayPub - https://github.com/unsystem/paypub
Jeremy Spilman Micropayment Channels - http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02028.html
==Copyright==
This document is placed in the public domain.
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-March/007714.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Proposal: We should vote on the blocksize limit with proof-of-stake voting

This is an automatic summary, original reduced by 97%.
OP HASH160 H(OP RETURN magic vote id txid vout vote) OP EQUAL. vote id is the ID of the specific vote being made, and magic is included toallow UTXO proof implementations a as yet unspecified way of identifying votesand including the weighted median as part of the UTXO tree sums.
In any case, of course the majority of miners can ignore a vote to increase the blocksize, what they can't do is ignore a vote to keep it steady or decrease it.
Could you think of any voting system where a miner can vote individually, using his small 300Mh/s miner?Something that would still allow him to cast a vote of his choice, yet without a need for him to give up his mining pool? Why do we even want to involve mining pools into politics? I am sure none of them wants that - they are not like the elite of bitcoin But anyway, it's the people who mine that should decide - just let them to do it, but without forcing mining pools to choose a camp.
Frankly what are you guys worried about? Losing? If Bitcoin users really want a large blocksize they'll vote, and it'll be easy to convince them to vote if they see fees going up and want fees to be lower.
The problem with your proposal is that it counts anyone creating transactions on clients that don't have this voting feature as voting for the permanent 1 MB block size limit, which is a very controversial departure for the original plan to eventually replace what was meant to be a temporary 1 MB block size limit with another solution that allows high bandwidth nodes.
There's a big difference between miners voting once to change the protocol, and a protocol change that allows miners to actively control the block size limit through regular voting.
Summary Source | FAQ | Theory | Feedback | Top five keywords: vote#1 mine#2 Bitcoin#3 block#4 limit#5
Post found in /BitcoinAll, /Bitcoin and /Bitcoin.
NOTICE: This thread is for discussing the submission topic. Please do not discuss the concept of the autotldr bot here.
submitted by autotldr to autotldr [link] [comments]

[Informational] [CC0] Forks In Simple Terms

Forks

Hard Fork

Any change to the Bitcoin protocol that means the existing nodes would reject blocks and transactions as invalid is called a hard forking change.
Since the Bitcoin protocol is strict about setting limits in a wide variety of areas, most notably the coin limit and block size limit, there are a wide number of changes that may appear to be simple, but from from a protocol perspective are equivalent to completely changing the entire system.
Not all clients of the Bitcoin protocol work the same way. It's possible to change the limits, and so for some types of clients, a hard fork would not be a hard fork at all. Because this is confusing, generally only the broad consensus of the Bitcoin rules is considered when referring to a hard fork.

Proposed Hard Forks

It's generally understood that should there be an obvious issue or critical problem with the Blockchain, any issue including a deliberate attack on the network, this problem can be solved with a rapid, dynamically chosen or custom developed hard fork.
Satoshi Nakamoto once proposed that in the future a possible hard fork to increase the block size limit be implemented by using a far future flag day, a day after which the old ruleset is no longer used and a new ruleset is switched to.
One Bitcoin protocol change that has been long discussed is the reversal of how Bitcoin transactions are confirmed. In the existing protocol, miners sweep unconfirmed transactions into their blocks. In a theorized change, miners would win a temporary period of time in which they could simply directly add transactions to the Blockchain.
Every Bitcoin can be subdivided into one hundred million Satoshis, however this may not always be enough. A hard fork could increase the divisibility without increasing the coin limit, should the value of a Satoshi grow by enough to justify the change.

Accidental Hard Forks

Sometimes a hard fork happens in an unplanned way, where miners simply make invalid blocks for accidental reasons.
In July of 2015, this happened on two separate occasions. The first fork produced a series of six invalid blocks, starting with an invalid block from the small mining pool BTC Nuggets, and then followed by a series of five blocks produced by the Chinese mining pools AntPool and F2Pool. The next day, a similar fork occurred, initiated by a block created by the miner MegaBigPower. The block was followed by two invalid blocks created by unknown miners.
The reason for this fork is that from the point of view of the network, some miners attempted to reverse the rules set up in the BIP 66 soft fork upgrade. This split the network into two: Bitcoin nodes that used the consensus rule set defined in Bitcoin version 0.9.4 and Bitcoin nodes that used the consensus rule set defined in Bitcoin version 0.9.5.

Soft Fork

Any change to the Bitcoin protocol's consensus rules that is more restrictive than the existing set of rules is called a soft fork. Generally soft forks are considered backwards-compatible because nodes on both sides of the consensus fork may remain interoperable. The standard rollout of a soft fork involves a majority of mining hashing power updating node software to only mine transactions that comply with soft fork rules, and deliberately avoid building on blocks who do not do the same.
Reversing a soft fork would be changing the limits to something that existing nodes would reject, and is thus a hard fork. The hard fork would be from the point of view of the updated nodes only, older nodes would not notice the reversal. This means that even a majority of miners enforcing a soft fork at one point in time do not provide an assurance that the soft fork will remain or be constantly enforced. The assurance derives from the rest of the network's acceptance of the soft fork code, which provides the hard fork cost to the miner of rolling back the soft fork.
Soft fork rollbacks may be accidental, shepherding the miners and the network to a new set of consensus rules can be a perilous process and has led to multiple historical accidents. To safeguard against this, steps have been taken to encourage miners to accurately signal their soft fork consensus rules in BIP 9, and the common process for miners coming to agreement on a soft fork is to signal for three to four weeks that the soft fork has at least ninety-five percent consensus and will be enforced permanently. A soft fork increases the risk to an out of date node that they will no longer be following consensus, so they are encouraged to either update their node to the soft fork or reduce their payment receipt risk by waiting for more confirmations.

Adding Features

The primary method of adding major features to the Bitcoin protocol is to use a soft fork to enforce new rules about a transaction. For example: adding a new transaction type that appeared to spend funds that anyone might be able to spend but also included a script that others would validate as only being spendable under arbitrary conditions. This transaction would pass muster both to nodes that could not validate the new unknown conditions and to nodes that could validate the script's additional requirements. In this way, miners introduce new spending types by enforcing new rules on apparently less-restricted transactions.
In the case of the P2SH soft fork which enabled new transaction types such as multi signature transactions, the signature requirement to spend funds locked in a P2SH address simply changed to be more restrictive. Before P2SH, anyone could spend funds sent to an output script that matched the pattern OP_HASH160 $value OP_EQUAL as long as they provided an input that matched the hash value. After P2SH only the value that matched a working script could be used to spend funds.
Many transaction operation codes or opcodes have been with Bitcoin since the early days of the protocol. This set of codes also includes codes that do nothing and always validate, so that in the future they may be used to include new features as they are conceived and agreed upon, without the need to hard fork.
submitted by pb1x to writingforbitcoin [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]

ConceptCoin protocol v0.1 Draft 1

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:
There will be three major changes which will be explained in greater depth:
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 telepatheic to Conceptcoin [link] [comments]

$160 Every Day. Alternative Cloud Mining to HashFlare ? Earn 2.5 BTC Weekly (SHA-256)Generator finder private key bitcoin wallet tool full version 2018 Bitcoin Lesson  Keys & Addresses HashFlare Ethereum mining 2016 365 mh/s Ethereum mining rig  Best price per hash  MineBox12 mining case!?

Bitcoin mining is hand's down the most competitive business on the planet. It is designed to be very easy to get into - literally just download some software and you are mining. This ease of entry is exactly what makes it so difficult to do profitably. Therefore miners are always looking to find the cheapest energy sources to stay profitable. What source is cheaper than wasted natural gas that ... Pay-to-PubKey-Hash (Pay-to-Public-Key-Hash, P2PKH) is the basic form of making a transaction and is the most common form of transaction on the Bitcoin network.Transactions that pay to a Bitcoin address contain P2PKH scripts that are resolved by sending the public key and a digital signature created by the corresponding private key.. The ScriptPubKey and ScriptSig for a transaction is shown below: Invest in Cryptocurrency Bitcoin Mining & Easy Way to Trade Bitcoin. Bitcoin Transaction. We make cryptocurrency investments easier through the use of our automated machines. Safe And Secure . We use one of the most professional and trusted DDoS protection and mitigation provider. Personal support. We give instant support by our professional support team, knock us on live chat and get help ... Accurate Bitcoin mining calculator trusted by millions of cryptocurrency miners since May 2013 - developed by an OG Bitcoin miner looking to maximize on mining profits and calculate ROI for new ASIC miners. Updated in 2020, the newest version of the Bitcoin mining calculator makes it simple and easy to quickly calculate mining profitability for your Bitcoin mining hardware. It is used in the Bitcoin standard. It is a a strengthened version of the RIPEMD algorithm which produces a 128 bit hash digest while the RIPEMD-160 algorithm produces a 160-bit output. The compression function is made up of 80 stages made up of 5 blocks that run 16 times each. This pattern runs twice with the results being combined at the bottom using modulo 32 addition. Padding. The ...

[index] [33919] [17305] [43809] [20357] [20992] [12213] [43580] [6727] [5208] [29165]

$160 Every Day. Alternative Cloud Mining to HashFlare ?

HashFlare es una pagina de minería en la nube que tiene muy buena reputación en foros oficiales del Bitcoin como BitcoinTalk y los foros de Bitcoin.org. Esta oferta de Pre lanzamiento (Pre-Order ... CCG Mining - The Most Transparent Open-Ended Bitcoin Cloud Mining Company - Duration: 55:34. CryptoRobert 37,207 views. 55:34. USB Bitcoin Miner - The Power of 1000's Computers - Duration: 15:24. How Much? 335,179 views. 15:24. HASHRATE of the 8 x 480 8GB Mining Rig! - Duration: 12:15. Red Panda Mining 128,145 views. 12 ... Max Keiser: China secretly hoarding gold and will unleash crypto backed by metal and destroy USD - Duration: 16:16. Kitco NEWS 219,343 views Start Mining BTCV (Bitcoin Vault) With Mining City: minimum investment is $300 Sign up here to mine BTCV: https://bit.ly/3cY3rBN 4. You can also buy BTCV via Coineal: https://bit.ly/2LVfgfW 5 ...

#