Script. All about cryptocurrency - BitcoinWiki

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]

BIP 199 HTLC initial stack state

Hey fellow bitcoiners and redditors

I'm trying to understand how HTLCs (Hashed Time-Locked Contracts) can be implemented in Bitcoin and BIP-199 turned out to be the best resource for that purpose.

TL;DR
Question answered!
  1. Does the stack need to feature the secret/image twice in the OP_IF case? => call the script with [pubKey, signature, 1]
  2. How can the OP_ELSE flow ever be executed successfully (since this requires the stack to be empty, but [pubKey, signature] are required for OP_CHECKSIG at the very end of the script )? => call the script with [pubKey, signature, 0]

Full story
This is the example HTLC script I copied from BIP-199:
OP_IF
[HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160
OP_ELSE
[TIMEOUTOP] OP_DROP OP_DUP OP_HASH160
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

IF-Case (seller can claim the buyers deposited BTCs)
TL;DR: detailed debug log of this path. Question: Can I avoid providing the preimage twice?

Before running this script, the preimage should be known and the stack should looks:
preimage
preimage
pubKey
signature

  • So since the stack is not empty, it will jump into the OP_IF clause.
    • the OP_IF will pop the top value => stack is now: [preimage, pubKey, signature]
  • [HASHOP] will hash the preimage
    • the preimage on the stack will, be replaced by the image => stack: [image, pubKey, signature]
  • digest (a synonym for image) will be pushed
    • => stack: [image, image pubKey, signature]
  • OP_EQUALVERIFY checks the two top items for equality: image == image => true
    • ...and removes them, if they are equal => stack: [pubKey, signature]
  • OP_DUP will duplicate the pubKey, => stack: [pubKey, pubKey, signature]
  • OP_HASH160 will double-hash the pubKey => stack: [p2pkhAddress, pubKey, signature]
  • represents the p2pkhAddress => stack: [p2pkhAddress, p2pkhAddress, pubKey, signature]
  • OP_EQUALVERIFY checks the two top items for equality: p2pkhAddress == p2pkhAddress => true
    • ...and removes them, if they are equal => stack: [pubKey, signature]
  • OP_CHECKSIG checks the signature
  • Done, all fine!
  • Question: This flow requires the secret to be on the stack twice before starting the script; Can I avoid that somehow?

ELSE-Case (buyer claims refund of his/her deposited BTCs)
Since the script runs an OP_CHECKSIG at the very end. This means the stack has to contain at least [pubKey, signature] before the execution pointer moves to OP_IF. However, OP_IF returns true "If the top stack value is not False". So how can the script possibly ever execute the OP_ELSE flow?

Disclaimer
  • My mother tongue is not English, please forgive me any mistakes. :)
  • I'm just getting started with BTC scripting, please forgive me any noob mistakes.
  • I also searched the whole stackexchange/search engine/reddit/github universum for this issue, obivously without success.
PS - buy Bitcoin :)
submitted by redditeraya to Bitcoin [link] [comments]

Please Protect Consumers by Using Stealth Addressing

It's recently been brought to attention that various companies have been heavy handed in their restrictions of how one may spend their purchased coins. I'm writing this up so that people can have a basic understanding of stealth addressing and how it works. If you'd like more details on the cryptography behind stealth addresses, please refer yourself to 13.4.3 of Wiley's Understanding Bitcoin: Cryptography, Engineering and Economics.
A stealth address looks like this: vJmwY32eS5VDC2C4GaZyXt7i4iCjzSMZ1XSd6KbkA7QbGE492akT2eZZMjCwWDqKRSYhnSA8Bgp78KeAYFVCi8ke5mELdoYMBNep7L
When you send funds to a stealth address, you create a data containing (OP_RETURN) output and a normal output to a one-time use Bitcoin address. The latter output contains the money you actually wish to send, while the former output contains some data which looks, to observers of the blockchain, like a bunch of indecipherable garbage.
Here's an example:
Tx hash 6ea5c6f1a97f382f87523d13ef9f2ef17b828607107efdbba42a80b8a6555356 https://blockchain.info/tx/6ea5c6f1a97f382f87523d13ef9f2ef17b828607107efdbba42a80b8a6555356
So, when you send money from Bob to Alice using a stealth address, what's basically going on from a privacy perspective?
To everyone else observing, it's impossible to tell that Alice was sent money. The only thing that they can tell is that Bob sent money to a stealth output, and that's if Bob himself didn't receive his funds as the result of stealth output and his address is somehow already known.
Using stealth addresses, it will be impossible for someone to tell where your money is being sent. The only thing obviously visible is the amount sent. In the future, a Bitcoin sidechain, such as that proposed by andytoshi and gmaxwell, may have mandatory stealth addressing as found in altcoins such as Monero; however, the technology is currently available for use in Bitcoin using simple OP_RETURN scripts.
There is a downside to this technology: to receive coins, you need to scan every incoming Bitcoin transaction to see if it might have an output belonging to you. However, I'm sure if you care about the privacy of your customers and their ability to be able to send funds to you in the future, the benefits more than outweigh the costs!
Current software/clients supporting stealth transactions include:
Hopefully, more soon!
Additional, for free references if you don't want have access to the Wiley book:
https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth
http://sx.dyne.org/stealth.html
submitted by therealtacotime to Bitcoin [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]

Qtum Quantum Chain Design Document -- Add RPC Calls (Seven)

Qtum original design document summary (7) -- Qtum added RPC call
https://mp.weixin.qq.com/s/JdJLxEIBjD255qey6ITO_g
Qtum's core program, qtumd, runs all core logic including validation and creation of blocks. However, to achieve interaction with qtumd, you need to rely on RPC (Remote Procedure Call). Through RPC, you can interact with qtumd from the outside to implement basic functions such as sending and receiving QTUM and obtaining blockchain information.
The initial version of the Qtum RPC call is compatible with Bitcoin. On this basis, because the Qtum blockchain is different from Bitcoin, and Qtum supports the smart contract function that Bitcoin does not have, it is necessary to add a new RPC or improve the existing RPC to achieve Qtum. Full interaction of nodes.
The following section captures the relevant original design documents (with Chinese translation) for the Qtum RPC call from the early Qtum development team (ps: QTUM<#> or QTUMCORE<#> in the document is the internal design document number):
 
QTUM-35: Add RPC call for off-chain contract execution
Description: In Ethereum there are some contract's that can be executed without needing to be on the blockchain. This is useful especially for retrieving the status and results from a contract, and will make no changes to the on-chain storage or state. We should Add an RPC call to cover this functionality
 
Callcontract [address] [data]
Returns/prints hex encoded return data
 
Task: Add an RPC (Remote Procedure Call) call to run under the chain Description: It is useful to have some contracts in Ethereum that are not working on the blockchain, especially when retrieving the status and results of contracts, and not changing the storage and status of the chain. We should add an RPC call to implement this functionality. Callcontract [address] [data] Return / print hexadecimal encoded return data
 
QTUMCORE-14: Add "callcontract" RPC call for off-chain computations
Description: There should be an RPC call that executes a contract without requiring interaction with the blockchain network, and thus without gas or other fees. Callcontract contract-address data (sender) This should execute the contract locally, and if the contract function returns data, it should be returned/printed by the RPC call. Sender is optional and does not require an owned vout (it can be any valid address)
Task: Add a "callcontract" RPC call for the calculation of the chain Description: There should be an RPC call that does not require interaction with the blockchain network to run the contract, so it does not require gas or other fees. The format is as follows: Callcontract contract-address data (sender) It can run the contract locally, and if the contract function returns data, the RPC call can return/print the data. The sender is optional and does not need to have vout (it can be any valid address).
The above two tasks add a callcontract RPC call interface to implement a local chain call contract, which is convenient for viewing contract status or obtaining contract results without changing any information on the chain.
 
QTUMCORE-7: Add "createcontract" RPC call
 
Description: A new RPC call should be added call "deploycontract" "createcontract". This RPC call will be used to deploy a new smart contract to the Qtum blockchain.
Syntax:
Deploycontract createcontract gas-price gas-limit bytecode [sender-address] [txfee] [broadcast]
If no address is specified, then it should be picked randomly from the wallet. If no outputs exist to spend using that sender-address, then an error should be shown and no transaction created.
Tsfee is optional and if not specified should use the same auto txfee as the rest of the wallet (for example sendtoaddress uses an auto txfee)
Broadcast should default to true. If broadcast is false, then the transaction is created and signed, and then printed to the screen in hex rather than broadcast to the network.
If the sender-address does have an output, but it is not enough to cover the gas costs and tx fees, then any UTXO owned by the wallet should be used by the transaction to cover those fees. (not all funds must come from sender -address, but the sender-address must be vin[0])
After execution, if broadcast is true, it should print the txid and the new contract address.
Task: Add "createcontract" RPC call
Description: Add a "createcontract" RPC call that will be used to deploy a new smart contract on the Qtum blockchain.
grammar:
Createcontract gas-price gas-limit bytecode [sender-address] [txfee] [broadcast]
Among them, sender-address (sender address) is optional. If no address is specified, an address will be randomly selected from the wallet. If there is no output available in the sender-address, an error will be displayed and the transaction will not be created.
Txfee (transaction fee) is optional. If not specified, it should use the same automatic txfee as the rest of the wallet (for example, the automatic txfee used by sendtoaddress)
Broadcast should be true by default. If broadcast is false, the transaction is created and signed, and will be printed to the screen in hexadecimal format instead of being broadcast to the network.
If the sender-address does have an output, but it does not cover the gas charges and transaction fees, then any UTXO owned by the wallet can be used by the transaction to pay for these charges. (Not all funds must come from sender-address, but sender-address must be vin[0])
After running, if broadcast is true, the transaction id and the new contract address are printed.
The above task adds the RPC call createcontract for creating and deploying new smart contracts, and describes the specific meaning of the parameters and their corresponding behavior.
 
QTUMCORE-13: Add "sendtocontract" RPC call
Description: An rpc call should be adding for sending data and (optionally) money to a contract that has been deployed on the blockchain.
The format should be:
Sendtocontract contract-address data (value gaslimit gasprice sender broadcast)
This should create a contract call transaction using OP_CALL.
Value defaults to 0.
If no address is specified, then it should be picked randomly from the wallet. If no outputs exist to spend using that sender-address, then an error should be shown and no transaction created.
Broadcast should default to true. If broadcast is false, then the transaction is created and signed, and then printed to the screen in hex rather than broadcast to the network.
If the sender-address does have an output, but it is not enough to cover the gas costs, tx fees, and value, then any UTXO owned by the wallet should be used by the transaction to cover the remainder. (not all funds must Come from sender-address, but the sender-address must be vin[0])
After execution, if broadcast is true, it should print the txid and the new contract address.
Task: Add "sendtocontract" RPC call
Description: In order to send data or funds to a contract already deployed on the blockchain, an RPC call should be added.
The format should be:
Sendtocontract contract-address data (value gaslimit gasprice sender broadcast)
You can use OP_CALL to create a contract call transaction.
Value defaults to 0.
The sender-address is optional. If no address is specified, an address will be randomly selected from the wallet. If there are no outputs available in the sender-address, an error will be displayed and no transaction will be created.
Broadcast is default to true. If broadcast is false, then the transaction is created and signed and then printed to the screen in hexadecimal format instead of being broadcast to the network.
If the sender-address does have an output, but the output is not sufficient to cover the gas fee, transaction cost, and value, then any UTXO owned by the wallet can be traded to pay the remaining fee. (Not all funds must come from sender-address, but sender-address must be vin[0])
After running, if broadcast is true, the transaction id and the new contract address should be printed.
In order to implement the contract on the chain, the above task adds a sendtocontract RPC call. Its functionality is similar to callcontract and can be used to run contracts. The biggest difference is that sendtocontract implements the chain call, which requires the cost of the Gas, and the running result needs to be verified by the entire network node, and will change the storage state on the contract chain.
 
QTUMCORE-81:create getTransactionReceipt rpc call
Description: We need to create getTransactionReceipt rpc call that returns the same values ​​as here:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgettransactionreceipt
Most important part is the logs. they can either be stored into a separate db or use one of the existing tx or eth related db.
Task: Create getTransactionReceipt RPC call
Description: We need to create a getTransactionReceipt RPC call that returns the same value as in the following link:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgettransactionreceipt
The most important part is the log. They can be stored in a separate database, or they can use existing transactions or Ethereum-related databases.
The above task adds a gettransactionreceipt RPC call to the smart contract log to get the contract transaction related logs, which is very useful for understanding the status of smart contracts.
 
QTUMCORE-90: add searchlogs rpc call
Description: we need to add an rpc call to allow us to search the eth event logs, we need to support similar parameters as eth:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethfilter
So it would be: searchlogs(fromBlock, toBlock, address, topics)
fromBlock, toBlock should support latest keyword
Adderss: optional should be an array of one or more addresses
Topics: optional (check the link above)
Unlike eth where you have to call watch, this method should just output the filtered logs
Task: Add searchlogs RPC call
Description: We need to add a PRC call that allows searching for smart contract event logs, and we need to support parameters similar to Ethereum:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethfilter
So its form is as follows: searchlogs(fromBlock, toBlock, address, topics)
fromBlock: toBlock should support the latest keywords
Address: an optional array of one or more addresses
Topics: optional (refer to the link above)
Unlike the Ethereum, which needs to call watch, this method only outputs the filtered log.
The above task adds an RPC for retrieving the smart contract event log to facilitate screening of event logs that satisfy the condition. Users can quickly get the contract status they care about.
 
QTUMCORE-92: add getcode and getstorageat rpc calls
Description: We need to implement Qtum equivalent of these 2 rpc calls:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgetcode
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgetstorageat
No need to implement callback function for now.
For the default block, we can use block number, or keyword "latest" (default)
Task: Add getcode and getstorageat RPC calls
Description: We need to implement the QTP version of the RPC call equivalent to the following two RPCs:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgetcode
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgetstorageat
There is currently no need to implement a callback function.
For the default block, we can use the block number, or the keyword "latest" (default)
The above task implements an equivalent RPC similar to Ethereum for obtaining contract code and storing information.
 
QTUMCORE-97: Change validation of contract rpc calls inputs
Description: Change validation of contract rpc calls inputs to accept only hex
Task: Modify the verification of the input value of the contract RPC call
Description: Modify the validation of the input value of the contract RPC call to accept only hexadecimal.
The above task stipulates that the RPC of the verification contract only accepts the hexadecimal data parameters, so that the rpc interface is as consistent as possible.
 
QTUMCORE-123: Add "excepted": to gettransactionreceipt
Description: We need to add the "excepted": field to gettransactionreceipt rpc call which lists "None" if no exception occured, or lists the actual exception that happened.
The same lessons is in callcontract call.
We need the change to be backward compatible, which means it should not break the current logs db, but people who want to see exceptions would have to recreate/reindex the logs db
Task: Add "excepted": field in gettransactionreceipt
Description: We need to add the "excepted": field to the gettransactionreceipt RPC call. If no exception occurs, it will display "None", otherwise it will list the actual exception.
The same is true for Callcontract calls.
We need to modify it to be forward compatible, which means it can't break the current log database, but if you want to see these exceptions, you must rebuild/reindex the log database.
The above tasks enable a number of RPCs associated with smart contracts to throw exceptions that are convenient for the user to understand the wrong running state of the contract and also help developers debug the code.
 
QTUMCORE-124:Add "changeToSender" to sendtoaddress and make sure the "Don't use change address" option also affects sendtoaddress
Description: We need to add "changeToSender" parameter to sendtoaddress rpc call, same as we did for sendtocontract.
Also we need to make sure the "Don't use change address" also affects sendtoaddress
Task: Add "changeToSender" to sendtoaddress and make sure the "Don't use change address" option is also valid for sendtoaddress
Description: We need to add the "changeToSender" parameter to the sendtoaddress RPC call, which is also added to the sendtocontract.
We also need to make sure that the "Don't use change address" option is also valid for sendtoaddress.
Due to the UTXO model, the change of the contract call is easy to confuse the user. Therefore, the above task adds the option of "do not use the change address" for the sendtoaddressRPC, from which the user can choose to return to the original address.
 
QTUMCORE-125: Add callcontract support to "createrawtransaction" rpc call
Description: As requested by some exchanges, which use "createrawtransaction" to create raw transactions before signing on a cold wallet, we need to add
1- raw contract data support to "createrawtransaction" rpc call.
Currently "createrawtransaction" supports two types of outputs in the outputs arguments:
First is "address": x.xxx which created a standard P2PKH output
The second is "data": "hex" which creates an OP_RETURN output
We need to add:
1- "callcontract":
{contractAddress:"address", data:"data", amount:"amount", gasLimit:"gaslimit", gasPrice:"gasPrice"}
Where:
contractAddress: a valid contract address (valid hash160 hex data)
Data: the hex data to add in the OP_CALL output (should validate it's hex data, you can check the validation done in sendtocontract)
Amount (optional): the value of the output (value in QTUM to send with the call), should be a valid amount, default 0
gasLimit (optional): the gas limit for the transaction (same as in sendtocontract), defaults to the default/DGP value
GasPrice (optional): the gas price for the transaction (same as in sendtocontract), defaults to the default/DGP value
After parsing and validation all the values ​​an OP_CALL output should be constructed
Similar to this:
CScript scriptPubKey = CScript() << CScriptNum(VersionVM::GetEVMDefault().toRaw()) << CScriptNum(nGasLimit) << CScriptNum(nGasPrice) << ParseHex(datahex) << ParseHex(contractaddress) << OP_CALL;
Task: Make the "createrawtransaction" RPC call support callcontract
Description: Before some transactions are signed on the cold wallet, use "createrawtransaction" to create the original transaction. At the request of these exchanges, we should add:
1 -- original contract data support for "createrawtransaction" RPC calls
Currently, for the outputs parameter, "createrawtransaction" supports two types of outputs:
The first type is "address": x.xxx, which creates a standard P2PKH output
The second type is "data": "hexadecimal", creating an OP_RETURN output
We need to add:
1 -- "callcontract":
{contractAddress:"address", data:"data", amount:"amount", gasLimit:"gaslimit", gasPrice:"gasPrice"}
among them,
contractAddress: a valid contract address (valid hash 160 hex data)
Data: hexadecimal data added in OP_CALL output (should be verified as hexadecimal data, you can check if it is verified in sendtocontract)
Amount (optional): The value of output (the value in QTUM, sent with this call), should be a valid value, the default is 0
gasLimit (optional): the gas limit of the transaction (same as sendtocontract), the default is the default/DGP value
gasPrice (optional): the gas price of the transaction (same as sendtocontract), defaults to the default/DGP value
After parsing and verifying all the values, you should build an OP_CALL output.
The build method is similar to the following:
CScript scriptPubKey = CScript() << CScriptNum(VersionVM::GetEVMDefault().toRaw()) << CScriptNum(nGasLimit) << CScriptNum(nGasPrice) << ParseHex(datahex) << ParseHex(contractaddress) << OP_CALL;
Prior to the above task, the createrawtransaction RPC call was consistent with Bitcoin and could only be used to send standard transactions. Qtum extends it to compatible contract transactions. From then on, the RPC can be used to create original contract transactions for developers or exchanges.
Summary
The RPC call is the most important way to interact with the qtumd core program. It provides a call interface for getting all kinds of information on the blockchain and local. It is the basis for many applications such as wallets, browsers, and exchanges. A good RPC interface design enables developers to get more accurate information and develop more feature-rich applications. Qtum provides developers with sophisticated RPC calls, making it possible for many third-party applications, such as predicting market projects, Bodhi.
submitted by thisthingismud to Qtum [link] [comments]

BIP Number Request: Open Asset | Nicolas Dorier | May 26 2016

Nicolas Dorier on May 26 2016:
Open Asset is a simple and well known colored coin protocol made by Flavien
Charlon, which has been around for more than two years ago.
Open Asset is OP_RETURN to store coin's color. Since then, the only
modification to the protocol has been for allowing OA data to be into any
push into an OP_RETURN.
The protocol is here:
https://github.com/OpenAssets/open-assets-protocol/blob/mastespecification.mediawiki
I asked to Flavien Charlon if he was OK if I submit the protocol to the
mailing list before posting.
Additional BIP number might be required to cover for example the "colored
address" format:
https://github.com/OpenAssets/open-assets-protocol/blob/masteaddress-format.mediawiki
But I will do it in a separate request.
Here is the core of the Open Asset specification:
Title: Open Assets Protocol (OAP/1.0)
Author: Flavien Charlon
Created: 2013-12-12
==Abstract==
This document describes a protocol used for storing and transferring
custom, non-native assets on the Blockchain. Assets are represented by
tokens called colored coins.
An issuer would first issue colored coins and associate them with a
formal or informal promise that he will redeem the coins according to
terms he has defined. Colored coins can then be transferred using
transactions that preserve the quantity of every asset.
==Motivation==
In the current Bitcoin implementation, outputs represent a quantity of
Bitcoin, secured by an output script. With the Open Assets Protocol,
outputs can encapsulate a quantity of a user-defined asset on top of
that Bitcoin amount.
There are many applications:
could then be traded frictionlessly through the Bitcoin
infrastructure.
could withdraw and deposit money in colored coins, and trade those, or
use them to pay for goods and services. The Blockchain becomes a
system allowing to transact not only in Bitcoin, but in any currency.
of colored coins. The door would only open when presented with a
wallet containing that specific coin.
==Protocol Overview==
Outputs using the Open Assets Protocol to store an asset have two new
characteristics:
asset stored on the output.
many units of that asset are stored on the output.
This document describes how the asset ID and asset quantity of an
output are calculated.
Each output in the Blockchain can be either colored or uncolored:
both undefined).
non-null asset ID.
The ID of an asset is the RIPEMD-160 hash of the SHA-256 hash of the
output script referenced by the first input of the transaction that
initially issued that asset (script_hash =
RIPEMD160(SHA256(script))). An issuer can reissue more of an
already existing asset as long as they retain the private key for that
asset ID. Assets on two different outputs can only be mixed together
if they have the same asset ID.
Like addresses, asset IDs can be represented in base 58. They must use
version byte 23 (115 in TestNet3) when represented in base 58. The
base 58 representation of an asset ID therefore starts with the
character 'A' in MainNet.
The process to generate an asset ID and the matching private key is
described in the following example:

The issuer first generates a private key:

18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725.

He calculates the corresponding address:

16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM.

Next, he builds the Pay-to-PubKey-Hash script associated to that

address: OP_DUP OP_HASH160
010966776006953D5567439E5E39F86A0D273BEE OP_EQUALVERIFY
OP_CHECKSIG.

The script is hashed: 36e0ea8e93eaa0285d641305f4c81e563aa570a2

Finally, the hash is converted to a base 58 string with checksum

using version byte 23:
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC.
The private key from the first step is required to issue assets
identified by the asset ID
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC. This acts as a
digital signature, and gives the guarantee that nobody else but the
original issuer is able to issue assets identified by this specific
asset ID.
==Open Assets Transactions==
Transactions relevant to the Open Assets Protocol must have a special
output called the marker output. This allows clients to recognize such
transactions. Open Assets transactions can be used to issue new
assets, or transfer ownership of assets.
Transactions that are not recognized as an Open Assets transaction are
considered as having all their outputs uncolored.
===Marker output===
The marker output can have a zero or non-zero value. The marker output
starts with the OP_RETURN opcode, and can be followed by any sequence
of opcodes, but it must contain a PUSHDATA opcode containing a
parsable Open Assets marker payload. If multiple parsable PUSHDATA
opcodes exist in the same output, the first one is used, and the other
ones are ignored.
If multiple valid marker outputs exist in the same transaction, the
first one is used and the other ones are considered as regular
outputs. If no valid marker output exists in the transaction, all
outputs are considered uncolored.
The payload as defined by the Open Assets protocol has the following format:
{|
! Field !! Description !! Size
|-
! OAP Marker || A tag indicating that this transaction is an
Open Assets transaction. It is always 0x4f41. || 2 bytes
|-
! Version number || The major revision number of the Open Assets
Protocol. For this version, it is 1 (0x0100). || 2 bytes
|-
! Asset quantity count || A
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] representing the number of items in the asset
quantity list field. || 1-9 bytes
|-
! Asset quantity list || A list of zero or more
[http://en.wikipedia.org/wiki/LEB128 LEB128-encoded] unsigned integers
representing the asset quantity of every output in order (excluding
the marker output). || Variable
|-
! Metadata length || The
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] encoded length of the metadata field. || 1-9
bytes
|-
! Metadata || Arbitrary metadata to be associated with
this transaction. This can be empty. || Variable
|}
Possible formats for the metadata field are outside of
scope of this protocol, and may be described in separate protocol
specifications building on top of this one.
The asset quantity list field is used to determine the
asset quantity of each output. Each integer is encoded using variable
length [http://en.wikipedia.org/wiki/LEB128 LEB128] encoding (also
used in [https://developers.google.com/protocol-buffers/docs/encoding#varints
Google Protocol Buffers]). If the LEB128-encoded asset quantity of any
output exceeds 9 bytes, the marker output is deemed invalid. The
maximum valid asset quantity for an output is 263 - 1
units.
If the marker output is malformed, it is considered non-parsable.
Coinbase transactions and transactions with zero inputs cannot have a
valid marker output, even if it would be otherwise considered valid.
If there are less items in the asset quantity list than
the number of colorable outputs (all the outputs except the marker
output), the outputs in excess receive an asset quantity of zero. If
there are more items in the asset quantity list than the
number of colorable outputs, the marker output is deemed invalid. The
marker output is always uncolored.
After the asset quantity list has been used to assign an
asset quantity to every output, asset IDs are assigned to outputs.
Outputs before the marker output are used for asset issuance, and
outputs after the marker output are used for asset transfer.
====Example====
This example illustrates how a marker output is decoded. Assuming the
marker output is output 1:
Data in the marker output Description ----------------------------- 
0x6a The OP_RETURN opcode. 0x10 The PUSHDATA opcode for a 16 bytes payload. 0x4f 0x41 The Open Assets Protocol tag. 0x01 0x00 Version 1 of the protocol. 0x03 There are 3 items in the asset quantity list. 0xac 0x02 0x00 0xe5 0x8e 0x26 The asset quantity list: - '0xac 0x02' means output 0 has an 
asset quantity of 300.
 - Output 1 is skipped and has an 
asset quantity of 0
 because it is the marker output. - '0x00' means output 2 has an 
asset quantity of 0.
 - '0xe5 0x8e 0x26' means output 3 
has an asset quantity of 624,485.
 - Outputs after output 3 (if any) 
have an asset quantity of 0.
0x04 The metadata is 4 bytes long. 0x12 0x34 0x56 0x78 Some arbitrary metadata. 
===Asset issuance outputs===
All the outputs before the marker output are used for asset issuance.
All outputs preceding the marker output and with a non-zero asset ...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012741.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

What would happen if you told your boss that you "pretended" to do half your work, then forged the proof of your work through some elaborate scheme and took your entire paycheck? Maybe it's time to do to Bitmain what your boss would do to you......its time to fire them.

Now that proof is coming out by the community on asic boost being used, we know antpool is guilty.
This post details the forgery
*You need to do 32 bits of work to find a 64 bit collision. That's deceptively little. For ASICBOOST you only need a very small partial collision. https://en.wikipedia.org/wiki/Birthday_attack There's even a tool to do massive collisions using this property on bitcoin addresses. https://github.com/basil00/pairgen
shared = 20chars hash160[1] = 53e1f4f491509f9012bd901be5147447f770018b hash160[2] = 53e1f4f491509f9012bd825ce1e9599b253188ef
shared = 15chars addr[1] = 18eXmgR5Svoqqa6PaYVrKvbH6hvrp5xe3A addr[2] = 18eXmgR5Svoqqa6JXSMmbNaD4Cs5ThcV1P That's a 80 bit collision, doing only 40 bits of work.
submitted by Cryptolution to Bitcoin [link] [comments]

The ultimate back-up plan: Your private key, stored in the block chain, encrypted

[edit: It is the ultimate back-up, but it doesn't mean it is the safest. I'm too tired to figure that out. I'm just explaining how to store a private key in the block chain, in case it is useful or can be made useful.]
I had that idea if someone is interested, though I guess people won't like it. It's a bit wild. We encrypt the key and put it in the block chain with a trick.
I'm not saying everyone should do this, but it could be useful to know it can be done.
If you trust encryption and your password more than back-ups or a third-party, then it could be nice. I'm no encryption expert but it should be strong enough.
"Instead of taking 1.3 quadrillion years, our magical cracking supercomputer would only need 328 trillion years." http://www.kotfu.net/2011/08/what-does-it-take-to-hack-aes/
If it's flawed or gets cracked after a billion years, I decline all responsibility. But you can be sneaky about it. I propose a sneaky trick at the end. It's a bit rough on the edges and crazy but I'll put it out there. If people like it, there are always ways to streamline.
Anyway, you can't memorize the key as you can memorize a password. It's true you can put it on paper; then lose the paper. You can encrypt it and keep it on hard drive, then lose the hard drive. Or on a service, and lose the service. The block chain though, is going to stay around as long as you need the key. So I suggest this whole alternative.
You can still put the information on paper if you want. But now, just your memory is enough. Just the password.
The drawback is the infinitesimal odd of someone finding out and spending a lot of years and resources on brute-forcing. I'm not sure what would be the odds of success. Just make it so decades of computing resource cost more than what's inside.
Now I'll explain how to do it from A to Z, for the few interested.
Plan: 0) Vanity 1) Get the key 2) Encrypt the key 3) Put the key in the block chain 4) Retrieval 5) Conclusion
0) Optional: Vanity I recommend a vanity address (choosing the first part of the address). So if worst comes to worst, you find it from memory in the block chain. And also, it's kinda neato. How-to: first, download VanityGen, direct/wiki. Extract it, then Open a console window at the location with shift-right click in the folder, if you have vista/7/8. Then type "vanitygen 1something" in it. It has to start with 1. If it's too long it'll take a lot of time. Ctrl-C to cancel if it's too long. Faster with GPU: oclvanitygen -D 0:0 1something (maybe broken atm) When you have the key, type "importprivkey mykey" in Help->Debug->Console of bitcoin-qt, to add it. Result of this optional step: A beautiful address which can be retrieved from memory if needed (after it has been seen in the block chain with a transaction)
1) Get the key - Download open source Pywallet: direct/profile - Extract pywallet.py somewhere. Shift-right click in the folder and "open a console window" - In the console, type: pywallet --dumpwallet dump.txt If your wallet is encrypted, then add --passphrase=PASSPHRASE Now you find the key in dump.txt. (note: it reads the wallet at C:\Users\x\Bitcoin) Result of this step: the private key; it looks like 51 characters starting with the number 5. (To delete dump.txt, you can use a software so it can't be recovered from HDD, like Recuva it seems)
2) Encrypt the key - Choose an algorithm. Personally, I pick AES-256. - Download a trustworthy program to encrypt text with the algorithm. Here are two with GUI I found. It's open source but I didn't check it, so it's not 100% safe: http://sourceforge.net/projects/textcrypt/ https://code.google.com/p/immediatecrypt/downloads/list They're both jar files. Maybe you can click them. Personally I have to go in the console; I'm so tired of that coffee cup. "C:\Program Files (x86)\Java\jre7\bin\java.exe" -jar ImmediateCrypt.jar. It gave me an error though. Not the other. Maybe someone can suggest better. - Choose a good password. It's all about the password (and the software). AES is weak with weak password. And crazy strong with a good password. This is not like websites with protection against brute-force. People can brute-force fully if they find out. I like psycho-pass method which is about a pattern on the keyboard instead of semantics. Side Info: http://www.jmir.org/2012/1/e10/ http://www.jmir.org/2013/8/e161/ Or a passphrase if you want. Here is a nice table with password entropy: http://en.wikipedia.org/wiki/Password_strength#Random_passwords Below 64 bits of entropy, it's too unsafe, it's too weak. We need 128 bits or above, as far as I know. That is 25 random alphanumeric. If you're feeling paranoid, 256 bits. You can check entropy of password roughly here: http://rumkin.com/tools/password/passchk.php Remember it is not like websites. There is no "Forgot password?" button. Memorize it permanently; and maybe write it down in your favorite book just in case, I don't know. Result of this step: the encrypted key. It doesn't matter what it looks like as long as it takes you back to the key when you click "Decrypt". (on a different software, preferably)
3) Put the key in the block chain It works by sending some minimum amount to fake addresses, with data encoded in the addresses. Can't try this part because I don't have bitcoins. :[ Only a wallet! If some liked the guide particularly: 1thxd4KJLhBMcfCYaVKYMA8Atv3Dfx9hb :3 I'll follow the method of this great article: http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html (the blog is remarkable!) - We're supposed to split the encrypted key in chunks of 20 characters. Then convert from ASCII to hex. Last chunk we fill with extra zeros. I wrote a little javascript to do it all automatically! If you don't like it, find a software, or do it manually. Not tested much but seems to work for my test. I'll say how to know if it worked. Copy that: encrypted='';har=(encrypted.split ('').map(function(c){return c.charCodeAt(0).toString(16); }));ek="";har.forEach(function(c){ek+=c;});while(ek.length%40!=0)ek+='0';iEK=0;ek2='';while(ek.length>0){ek2+=ek.substr(iEK,iEK+40) + "\n";if(ek.length>=40)ek=ek.substr(40,ek.length-40);else ek='';};ek2;
Check eventual comments to know if it's a hack/broken mess.
I don't do much Javascript, or much anything. Paste the whole thing in the javascript console. To open the console: Chrome, Ctrl-Shift-J. Firefox, Ctrl-Shift-K. IE9, F12. Put your encrypted key between the '' right at the beginning, then enter.
This should display rows of 40-characters chunks of the encrypted key in hex format (numbers, and a to f). I have 6 chunks but it depends on encryption. It should give twice as much characters as the input except for last zeros, and follow this conversion table from Char to Hx column. If it doesn't, call the police. Or use some Ascii to Hex service.
Now we take these chunks one by one and use https://blockchain.info/q/hashtoaddress/the_hex_chunk to convert to BTC addresses.
Send spare money to each one (the strict minimum is suspect and it'd get found easily) in the right order (wait for 1 or 2 confirmations each time to be sure).
And we're done! The information is safe and cozy, in the block chain. Not safe from brute-forcing, but safe from ourselves; and that's safer, isn't it?
4) Retrieval
Alright, how do we go back from the addresses to the encrypted key? I can't try it myself, but apparently, according to the article: 1) Get the transaction ID on blockchain.info, by going to the wallet's profile 2) Go to http://blockexplorer.com/rawtx/your_transaction_id 3) There will be something like that: "out":[ { "value":"25.08603421", "scriptPubKey":"OP_DUP OP_HASH160 27a1f12771de5cc3b73941664b2537c15316be43 OP_EQUALVERIFY OP_CHECKSIG" } ]
And you need to translate the "27a1f12771de5cc3b73941664b2537c15316be43" part from hex to Unicode. The result should be the chunk of encrypted key, written in hex again. You put all the parts together in order, remove extra zeros. Then use a program to go back from hex bytes to ASCII. Maybe someone can do it or I'll put the javascript one of these days if people are interested; I don't think they'll be. Usually I'm serious and extensive but you can't imagine how tired I am these days, of everything. Anyway, you put that ASCII in the AES program with your password, you click Decrypt.
Then you have your private key.
If you do this, don't lose other back-ups until you have successfully retrieved the key, to know it works.
5) Conclusion I understand that there's a small chance that someone figures the transactions are data, reassembles the parts, has massive luck and breaks the crazy strong encryption with supercomputers and botnets in less than decades, or aliens hack your bitcoins with quantum computers, ect... But I don't know, that seems very unlikely to me; more unlikely than losing personal back-ups or third-parties being untrustworthy.
More importantly, it gives peace of mind of not having to manage back-up stuff. You can format your hard drive and burn your house down if you want without worrying about losing stuff; well, except the house. And maybe the wife. Or you go to prison 20 years, and it'll still be there. If some of you want to go to prison. I know of one.
Here's a complicated idea for the extra-extra-paranoid: You send just one letter by one letter of the encrypted key, into dozens of fake addresses, to which you send bitcoins you got from an exchange and not from the main wallet, and only you know the correct addresses/order with the data, because of a pattern in the other letters. For example, the 2nd letter of the 1st data part is the 1st letter of your password when it's hashed. The 3rd letter of the 2nd data part is the 2nd letter of your hashed password. Ect... And it's not true for the other parts. So you know the order, but not someone without the password. It can go like this for many parts, then maybe if you run out of letters you send through a different wallet. All other characters are misleading except the 1st one, or last one, being the key character. And you also send money to other fake wallets which are purely misleading. Even if a flaw in AES was found and it could be broken instantly, an attacker would have to find the correct combination even before the strong encryption brute-forcing, he can't even know if he has the right combination, and that can be a big number of combinations. You can do the math. It's exponential stuff, I think. That's something I just thought of quickly, and I don't know much about any of that. Someone can find better. (Maybe, or maybe not, there's something about the encryption output which makes it so we can find the order back without password, then we'd need some kind of trick to obfuscate the position or nature of key characters but I won't spend any more time on something likely to be wrong/uninteresting).
tl;dr: "It works by sending some minimum amount to fake addresses, with data encoded in the addresses. "
Point is, once we know we can store data in the block chain, there are plenty of ways to make it so we're never locked out from the main address.
Well, if you can remember the password.
I hope this was useful to someone!
Goodbye
submitted by yemethzi to Bitcoin [link] [comments]

How does the range of valid ECDSA private keys work?

"Nearly every 256-bit number is a valid ECDSA private key. Specifically, any 256-bit number from 0x1 to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 is a valid private key." - https://en.bitcoin.it/wiki/Private_key
How come I can generate a private key with the secret exponent of all 256 bits set and use it? I.E
input : L5oLkpV3aqBjhki6LmvChTCq73v9gyymzzMpBbhDLjDpKCuAXpsi network : Bitcoin mainnet netcode : BTC secret exponent : 115792089237316195423570985008687907853269984665640564039457584007913129639935 hex : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF <- is higher than FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 wif : L5oLkpV3aqBjhki6LmvChTCq73v9gyymzzMpBbhDLjDpKCuAXpsi uncompressed : 5Km2kuu7vtFDPpxywn4u3NLu8iSdrqhxWT8tUKjeEXs2f9yxoWz public pair x : 65766924097070208376629306902125118242069746467871217785643147593192657258159 public pair y : 109236945745669593534474897756172178689381177381602435107906663179476813370855 x as hex : 9166c289b9f905e55f9e3df9f69d7f356b4a22095f894f4715714aa4b56606af y as hex : f181eb966be4acb5cff9e16b66d809be94e214f06c93fd091099af98499255e7 y parity : odd key pair as sec : 039166c289b9f905e55f9e3df9f69d7f356b4a22095f894f4715714aa4b56606af uncompressed : 049166c289b9f905e55f9e3df9f69d7f356b4a22095f894f4715714aa4b56606af\ f181eb966be4acb5cff9e16b66d809be94e214f06c93fd091099af98499255e7 hash160 : f5f5c490b6d86d83fda2143ebfab443f51bd3ebd uncompressed : 0ec34b6ec2038fbdfbb04ff481fb82f0e3b86f99 Bitcoin address : 1PRWyFKTsQSJaUdX9VKgQNw8JERPw2kMFm Bitcoin address uncompressed : 12M4QznuNZH2BRVbLK8SKvNqGTPJpCpST7 
https://blockchain.info/address/12M4QznuNZH2BRVbLK8SKvNqGTPJpCpST7
submitted by SoldToChina to Bitcoin [link] [comments]

Some Questions about bitcoin transactions (specifically - the contents of ScriptSig and ScriptPubKey)

I'm using these pages on the bitcoin wiki to help me understand bitcoin transactions, but I need some clarification: https://en.bitcoin.it/wiki/Transactions https://en.bitcoin.it/wiki/Script
If we look at a Standard Transaction to Bitcoin address (pay-to-pubkey-hash), the ScriptSig and ScriptPubKey will contain the following:
My understanding is that this script describes what the "receiver" must do to perform the next transaction with the bitcoins included in this transaction. and refer to the public key of this "receiver".
Q1 - and both refer to the "receiver's" public key. So why does OP_CHECKSIG require as an input? Wouldn't be enough?
Q2 - According to the Script wiki page, the signature is a hash on "the entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end)". When and how is this OP_CODESEPARATOR run?
Q3 - When the signature is computed, it is computed on a "simplified version of the transaction". The parameter must be missing for obvious reasons, but what other parameters are excluded from this "simplified version"?
Thanks in advance. And for those who haven't yet dug into how transactions are formed - it is well worth checking out.
submitted by molodets to Bitcoin [link] [comments]

Blockchain scripting contest, second stage

This blockchain scripting contest is a way to raise awareness about the possibilities and powers of the scripting mechanism integrated in the bitcoin protocol.
Every stage will be about a non-standard transaction output (scriptPubKey) broadcast by me and funded with a given amount. Objective of the stage is to find an appropriate script (scriptSig) that will succesfully resolve the stacked scripts, as requested by the bitcoin protocol. The amount in the tx output is the award of the stage and can be claimed at will.
The difficulty of the stages will increase in each step.
Link to 1st stage and solution
2nd stage
Funding transaction/output: 948aeca2003bf0bdc4f0dc7d61615d05010da8bca744dd9cfa12fb57e2540a2d, n=0
Claimable amount: 5 mBTC !!remember to reserve at least 0.1mBTC for transaction fees!!
scriptPubKey to solve:
OP_DEPTH OP_1 OP_NUMEQUAL OP_IF 6e616d65206f66206e616b616b616d6f746f OP_DROP OP_RIPEMD160 OP_RIPEMD160 9c864b8bb110c05cb9c77381ad5d6868f0fd9f9f OP_EQUAL OP_ELSE OP_DUP OP_HASH160 897b934876ff50bfebe218e30382d7eaa6559a12 OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF 
Difficulty level: medium
State: Unclaimed!
Recommended Toolchain:
Documentation: Transactions, Raw Transactions API, Scripts and OPcodes reference.
Have fun!
PS: Any amount sent to the address 1JHCn9wLLXHc4yfo968FrT259Um2hzeUpy will be used to fund the next stages.
submitted by tartare4562 to Bitcoin [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]

NOOO!!! IT'S MUCH WORSE THAN EVERYONE THINKS!! HERE IS BITCOIN's NEXT MOVE!!! w. DavinciJ15 What is Bitcoin Cash? Frag den Trainer! 48  BITCOIN - Wie funktioniert die Blockchain? What is Bitcoin? Bitcoin Explained Simply for Dummies ... Dissecting a P2PKH Bitcoin Transaction down to the last Byte

Aus Bitcoin Wiki. Wechseln zu: Navigation, Suche. Ein Hash-Algorithmus wandelt Daten beliebiger Länge in einen Datensatz fester Länge um, den Hash. Gleiche Daten führen immer zum gleichen Hash. Wird aber auch nur ein einzelnes Bit der Daten geändert sieht der Hash komplett anders aus. Wie alle Daten im Computer bestehen Hashes aus langen Zahlenketten und werden für gewöhnlich in ... Bitcoin uses a scripting system for transactions. Script. From BitcoinWiki. This is the approved revision of this page, as well as being the most recent. Jump to: navigation, search. Enjoyed the article? Share: Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops. A ... HAS-160 is a cryptographic hash function designed for use with the Korean KCDSA digital signature algorithm. It is derived from SHA-1, with assorted changes intended to increase its security.It produces a 160-bit output. HAS-160 is used in the same way as SHA-1. First it divides input in blocks of 512 bits each and pads the final block. From Bitcoin Wiki. Jump to: navigation, search. RIPEMD-160 is a cryptographic hash function based upon the Merkle–Damgård construction. 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 ... Hashrate (Hash per second, h/s) is an SI-derived unit representing the number of double SHA-256 computations performed in one second in the bitcoin network for cryptocurrency mining. Hashrate is also called as hashing power. It is usually symbolized as h/s (with an appropriate SI prefix).

[index] [15464] [30647] [15982] [25913] [47860] [26853] [42619] [38363] [40389] [16783]

NOOO!!! IT'S MUCH WORSE THAN EVERYONE THINKS!! HERE IS BITCOIN's NEXT MOVE!!! w. DavinciJ15

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. Gossip Room est une communauté sur les réseaux sociaux, créée il y a 7 ans, qui regroupe aujourd’hui des millions de passionnés d’actualité TV, people, série... Hallo zusammen, in der heutigen Folge erkläre ich euch wie Bitcoin technisch funktioniert und welche Unterschiede es bei den Nodes und Wallets gibt. Viel Spaß! Bitwala - JETZT 35€ sichern! Nur ... 3 Fundamental Reason Why Bitcoin Will Rally Again! 3 DIFFERENT Reasons Trump Is Good For Bitcoin! 👍 Like. Comment. Subscribe. Follow us on Twitter: https://t... Bitcoin Cash is peer to peer electronic cash. Visit https://bitcoincash.org for more information on Bitcoin Cash (BCH)

#