hash - Getting Hash160 bitcoin address in python - Stack

Escrow CashScript Contract for blind escrows on Bitcoin Cash!

Thank you Michael from local.bitcoin and @LocalEthereum for the great work!
``` contract Escrow( bytes20 sellerPHK, // Hash160 of seller's public key bytes20 buyerPKH, // Hash160 of buyer's public key bytes20 arbitratorPKH // Hash160 of arbitrator's public key // bytes escrowKey // Nonce (just some unimportant random bytes unique per exchange) ) { function spend( sig spenderSig, pubkey spenderPK, bytes oracleMsg, datasig oracleSig, pubkey oraclePK, bytes actionByte ) { bytes20 verifySpenderPKH = bytes20(0); bytes20 verifyOraclePKH = bytes20(0);
if (actionByte == 0x01) { // "releaseBySeller" verifySpenderPKH = buyerPKH; verifyOraclePKH = sellerPHK; } else if (actionByte == 0x02) { // "releaseByArbitrator" verifySpenderPKH = buyerPKH; verifyOraclePKH = arbitratorPKH; } else if (actionByte == 0x03) { // "returnByBuyer" verifySpenderPKH = sellerPHK; verifyOraclePKH = buyerPKH; } else if (actionByte == 0x04) { // "returnByArbitrator" verifySpenderPKH = sellerPHK; verifyOraclePKH = arbitratorPKH; } else { // Action byte is unknown; fail. require(false); } require(hash160(oraclePK) == verifyOraclePKH); require(hash160(spenderPK) == verifySpenderPKH); // Construct message // bytes oracleMessage = escrowKey + actionByte; // Verify oracle's signature require(checkDataSig(oracleSig, oracleMsg, oraclePK)); // Verify spender's tx signature require(checkSig(spenderSig, spenderPK)); 
} } ```
Here is the typescript needed to transpile and run the contract. This works now on the testnet. Happy to answer any questions!
submitted by cgcardona to btc [link] [comments]

This is how we will recover coins sent to the wrong address or an unowned address

Don't worry, I'm NOT advocating that transactions should be reversible.
Many of us have accidentally sent coins to the wrong address or an unowned address, resulting in those coins being permanently unrecoverable and unspendable. I haven't made this mistake (yet), but damn it makes me nervous when I send larger transactions.
Unfortunately, we'll never be able to revert those past mistakes, but with a small change to the bitcoin protocol, we can make it so that we can recover the coins when we make this sort of mistake in the future.
Please let me know your thoughts about my solution below, and if something like this is already in the works.

The solution, conceptually

If everybody knew everyone else's public keys, we could prevent these permanent mistakes with multisig scripts. The change I'm proposing will make it so we can prevent the mistakes without knowing each other's public keys, but I'll explain it in terms of multisig, because the solution is conceptually the same, and easier to explain:
Instead of sending coins directly to a recipient address, send your coins to a 1-of-2 multisig account, shared by both you and the recipient.
This means that effectively, the transaction is "cancellable", but only until the recipient sends the coins to his own account. At that point the coins are irreversibly his.
The downside of this is that when receiving a payment, you must explicitly accept it before the coins are truly yours -- you should not consider the coins as yours until you do this. The upside is that it guarantees that coins are never lost at inactive addresses.

Problems that this solves

  1. Sending to an unowned address (base58Check almost always protects against this)
  2. Sending to an address that was owned, but the private keys were lost and nobody has control of the address anymore
  3. Sending to the wrong (but owned) address, unless the unintended recipient is quick to claim the coins
  4. Sending your coins to the wrong address on an exchange (i.e. an address for a forked blockchain)

Implementation and technical details

We can accomplish the above without knowledge of each others' public keys, if we use a custom pubkey script. Nodes only accept transactions with standard pubkey scripts, so we'd need to define a new standard script.
The typical P2PKH script looks like this:
scriptPubKey: OP_DUP OP_HASH160 OP_DUP  OP_EQUALVERIFY OP_CHECKSIG scriptSig:   
The new standard script I'm proposing is this:
scriptPubKey: OP_DUP OP_HASH160 OP_DUP  OP_EQUAL OP_SWAP  OP_EQUAL OP_ADD OP_VERIFY OP_CHECKSIG ( would be your address, and  would be the recipient's address) scriptSig:   
This script allows the coins to be spent by either the owner of or .
I call this new transaction type Pay To Either Public Key Hash (P2EPKH), or colloquially, "fuck-up protection".
Of course, wallets would have to be able to recognize the new transaction type, and offer controls to claim coins from incoming P2EPKH transactions or to cancel unclaimed P2EPKH transactions.

Feedback, please.

What do you all think? Is this generally a decent idea? Has this idea been floated around before? Is there another solution for this issue in the works? If this is a good idea, how do I get the attention of the devs?
submitted by ransoing to btc [link] [comments]

A reminder why CryptoNote protocol was created...

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

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

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

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]

Economic majority vote by splitting coins | Tier Nolan | Aug 20 2015

Tier Nolan on Aug 20 2015:
The economic majority is defined as the will of those who actually use
Bitcoin as a payment system.
No matter what the miners want, if users and merchants refuse to accept
their fork, then the fork loses and cannot be considered the "true" bitcoin
fork.
The problem is that it is easy to measure a miner vote. The economic
majority is not so easy.
The relative value of two forks could be compared by adding a system
similar colored coins.
These contracts could be added with a soft fork like the P2SH one.
OP_IF
 OP_DROP OP_DROP OP_HASH160 
OP_EQUAL
OP_ENDIF
OP_IF
 OP_DROP OP_HASH160 OP_EQUAL 
OP_ENDIF
This works like P2SH and is template matching. You can have as many
entries as you want.
In the example, the output can be spent on fork 1 and fork 2 by the owner
of and can be spent on fork 3 by the owner of .
Until the deadline, the value on each fork must be preserved when spending
the output. If you provide the key(s), you are allowed to consolidate
entries. You can also consolidate multiple outputs to the same key even if
you don't have the key.
This means that split outputs are a little more hassle to use and the
transactions are larger. This doesn't matter much, since measuring the
relative value of the two sub-coins only requires some of them to be traded.
If someone wants to propose a hard fork, they create a new fork id and
deadline and release software that implements the hard fork at the given
deadline (no miner vote needed).
To prevent spam, there could be a cost to create a fork-id (BTC paid to
OP_RETURN) and the deadline could have a max time in the future (say 2
years).
After the deadline, core will allow conversion of outputs that pay to the
core fork-id (probably 1) to be converted into unencumbered outputs by the
person with the core-id script. Likewise, the fork software will allow
outputs that pay to the fork id to be converted. Legacy bitcoin that
haven't been "split" will be spendable on both sides equally.
This means that users can convert x legacy bitcoin into x fork-bitcoins and
x core-bitcoins in advance of the fork.
This means that Exchanges could support trading between the two. The side
that trades with the most value is the one that is supported by the
economic majority.
As it becomes clear which side is going to win, the price of coins on the
losing side should drop. It is unlikely that the two would stay at exactly
the same value without one side winning.
Users who want to to use the losing rules are free to do so but the
economic majority will have made its decision.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/4e500973/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010501.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

[uncensored-r/BitcoinMarkets] Bitcoin Tech Rant - Happy New Year: Atomic Cross Chain Swaps

The following post by L14dy is being replicated because some comments within the post(but not the post itself) have been silently removed.
The original post can be found(in censored form) at this link:
np.reddit.com/ BitcoinMarkets/comments/7n5dwi
The original post's content was as follows:
Hola,
I didnt have much success with the last Tech Rant, so I decided to do another. Please provide feedback.
So the topic for this tech rant is Cross Chain Swaps. They’re pretty simple, but require a bit of understanding of Bitcoin Script. I will start off with on-chain swaps.
So, let’s assume I want to swap testnet BTC for mainnet BTC with you (for instance if someone wants millions of testnet coins and is willing to pay 0.01 BTC for them). How would you be able to pay me and ensure that you actually get the testnet coins? Well, the easiest way is for us to agree that u/jaderadej will be our escrow. We both trust him, so we he generates an address and provides this address to the both of us. We then each generate a new address and provide it to u/jaderadej. At this point we both send our coins to the address he generated. One tx on testnet and the other on mainnet. As soon as u/jaderadej receives the coins from both of us, he does the swap (minus his “fee”). If I send coins but you dont, then he sends them back to me. If you send coins but I dont, then he sends them back to you.
Now, this works fine as long as we both trust u/jaderadej, and we do, but what if the only person willing to do it is u/pineconecandle. Well, I dont trust u/pineconecandle ;), so why would I do this deal? I wouldn’t. Hence, we need to do it without a third party. And this is possible in Bitcoin.
The first thing you need to understand is how OP_IF works. Basically OP_IF allows you to create a conditional branch of your PubKey Script. The second thing you need to udnerstand is how OP_CLTV works: OP_CLTV stands for Check Lock-Time Verify. It is an OP_Code that accepts an integer as input, which is either interpreted as a unix timestamp or as a block number (there is a convention on when the integer is interpreted as which, you can google it if you care). So now we can create a PubKey Script on a UTXO that has one PubKeyScript branch OP_IF OP_CLTV {Script1} OP_ELSE {Script2}
Ok, so enough with the preliminaries. On to the actual protocol.
I have testnet coins and you want to buy them. So what you do is you generate a random byte string (some random sequence of bits with enough entropy to ensure I cant brute force it before the lock-time we agree upon is up. If you use a cryptographically strong random number generator that will be fine. You generate this random number and hash it, i.e. OP_SHA256 or OP_RIPEMD160, whichever of the two is fine. Usually you would SHA.
I generate an address and provide you with the hash of my public key.
You then also generate a new address and send both the hash and the new hash of the public key to me. You now spend you 0.01 BTC to an output with a PubKey Script like the one above where Script 1 is just a normal P2PKH for your new address and Script 2 is a simple pre-image check combined with a P2PKH for my address, i.e. first hash the first element in the SigScript, compare that it matches the commitment value for the hash and finally check the standard P2PKH Script, i.e. soemthing like
{Script1}: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
{Script2}: OP_SHA256 OP_EQUALVERIFY OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
Now, eventually I will see this transaction show up on the mainnet blockchain. Since you are the one looking to buy from me, you pony up the cash. Now, if I change my mind and walk away your coins are not gone. Once the lock-time is up, you can just use you knowledge of the private key to your address to create a SigScript that satisfies Script 1 above. So far no trust needed... you will NOT lose your coins.
Ok, but I want to sell my testnet coins, so I decide to Pony up the testnet coins. I spend them to an output with the same PubKeyScript, only that I reverse the roles of our public key hashes AND more importantly, I cut the lock-time in half. Since you have the hash, I want to make sure I get my coins back before you can take your BTC back, otherwise you could take both.
So now I spend to that and you see it show up on the testnet blockchain. If you decide to walk away, thats fine. I can just get my testnet coins back in half the time you can. Again, no trust needed. Why? Well, even though you know the secret random number, since you dont control the private key associated to my address, you wont be able to satisfy the pubKey Script to take your BTC back and you cant take my testnet coins without revealing the secret random number in the SigScript of the spending transaction. Since all SigScripts are public information, you cant spend my testnet coins if you want to keep the random number secret.
Let’s assume we went through all this hassle to actually do the deal. So, now you spend the testnet coins to a new address that you control (P2PKH) by revealing the random number and providing a SigScript for the address you control in the OP_ELSE branch of the PubKeyScript.
As soon as you do that, I see the random number, and I can now spend your 0.01 BTC to an address I control using the Secret Random Number You revealed to me, along with the SigScript for the P2PKH of the address I control.
And voila. We just exchanges testnet BTC for mainnet BTC in a trustless fashion with no trusted third party using some pretty simple Cryptographic primitives. Done deal.
Now, notice a few things:
  1. You need to wait a bunch of confs before this can be done, because you want to avoid double spending of your counterparty (whom you do not trust)
  2. Tetsnet is kinda a stupid example, because its pretty easy to reorg the chain. I just didn’t wanna mention another coin.
  3. In Lightning this can be done instantly. No need to wait for confs and no need to wait too long for lock-times to expire. Basically it is achieved by routing the payment to yourself on the Lightning Network. You can also combine on-chain swaps with off-chain swaps. Pretty cool stuff. This is basically how decentralized exchanges would work on Lightning.
Ok, done. Hope you like it!
submitted by censorship_notifier to noncensored_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]

Economic majority voting

In the block size fork, the proposal is to have the miners vote. However, the users of the system (merchants/exchanges/clients) are the ones who have control in the end. They choice made by them is the one that has the support of the economic majority.
One way to measure that choice is to see which fork has the coin with the highest value. If a fork is not very popular, then its coins on that fork will be less valuable.
Assuming that the XT fork activates, then the XT fork will have the support of 75% of the hashing power and the core fork will have at most 25%. If the core fork still has reasonable hashing support, then it would continue, though with around 45 mins block time.
If any of the inputs into a transaction spend a coinbase output from one of the forks (or any of its descendents) that it can only be included on that fork. This allows trading coins between the two forks.
Exchanges could add BTC-XT and BTC-core coins to allow trading between the two forks. This would clearly show which fork had the support of the economic majority. If the loser doesn't go to zero, then at least some people want to keep it going.
This trading cannot happen until the fork itself happens, so can't be used to tell in advance which side has the support of the economic majority.
This could be rectified with a soft fork. It works similar to colored coins. Outputs have information about who can spend them on each fork. Each fork has an id based on the fork deadline.
Fork-id = 0 means the core chain Fork-id = deadline means fork chain
The deadline is the unix timestamp of when the hard fork is going to happen. Each fork would have to pick their own switch moment, but that isn't that big a restriction. It is not likely we are going to have more "serious" hard fork proposals than one per second.
The soft fork allows the user to specify who owns the output in each of the potential forks.
A user can spend their money to the following output script. This is a template match like P2SH.
OP_IF   OP_DROP OP_DROP OP_HASH160  OP_EQUAL OP_ENDIF OP_IF  OP_DROP OP_HASH160  OP_EQUAL OP_ENDIF 
This spends the output to
In forks 1 and 2, the owner of script 1 owns the owner. In fork 3, the owner of script 2 owns the output.
To spend an output, you include