blockchain - Difference between Public Bitcoin Address and ...

Help with raw BCH transaction - Coinbase Multisig

Been trying to recover an old Coinbase BCH multisig wallet from back in the day and am running into errors after signing the transaction.

I followed this process to get the keys and auth script.

Now that is no longer up and running, these kinds of tools don't work like the original method -

My last attempt was to use on postman to publish the transaction.

When I decode my transaction I get this:
"payload": {
"txid": "c210d81d7421df8c29fef9d51ed4762c7c435e37e4e1f0d03da98d7a0ff53707",
"hash": "c210d81d7421df8c29fef9d51ed4762c7c435e37e4e1f0d03da98d7a0ff53707",
"size": 404,
"version": 1,
"locktime": 0,
"vin": [
"txid": "3f9c05b991e2da6a45447ad794d4a3ce83ecea4616d6865de51d823e44f6640f",
"sequence": 4294967293,
"vout": 0,
"scriptSig": {
"asm": "0 304402202c751ad9af37e4ac396e4c0517db3155996f4444912f9029c0aca48d7ebcbab102201a0b5abc1dd11377481c04f94bb61607bec3238e8efb85968fbafedf55160d09[ALL] 304502210084c5bab07dd33be1f080ff39994e42139902871d7cedbbd8aa9d1cf4b02d301f02204b275afd22b4ce3b4b60de4204aad2082ecd0bd37e1ac3c2d97dc23fc0d8d681[ALL] 5221038e0a77486457bb154806aa9696f9c09e6160961cf45978e24b3077a457c89b0a410456d2147c0ac68657840bedbc80de83ae2f3f29efb6bec8123ac5c54428e0c88f8c8c2a27fb2c32c9788e70595fc742fba6adc4dab15e8ab4a1a5d89e16025f5b4104c8b2bbb7147082f993f19a8d9641968903c9ad0be35c7e535dc307840a6af470d40eeada1ab8cffc661816423423e1cd1c867704fd436b3ebf25a330ca7eb10d53ae",
"hex": "0047304402202c751ad9af37e4ac396e4c0517db3155996f4444912f9029c0aca48d7ebcbab102201a0b5abc1dd11377481c04f94bb61607bec3238e8efb85968fbafedf55160d090148304502210084c5bab07dd33be1f080ff39994e42139902871d7cedbbd8aa9d1cf4b02d301f02204b275afd22b4ce3b4b60de4204aad2082ecd0bd37e1ac3c2d97dc23fc0d8d681014ca95221038e0a77486457bb154806aa9696f9c09e6160961cf45978e24b3077a457c89b0a410456d2147c0ac68657840bedbc80de83ae2f3f29efb6bec8123ac5c54428e0c88f8c8c2a27fb2c32c9788e70595fc742fba6adc4dab15e8ab4a1a5d89e16025f5b4104c8b2bbb7147082f993f19a8d9641968903c9ad0be35c7e535dc307840a6af470d40eeada1ab8cffc661816423423e1cd1c867704fd436b3ebf25a330ca7eb10d53ae"
"vout": [
"value": "0.21192121",
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 e6a79df19f5b69c87231e65005b3b39396368fa0 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914e6a79df19f5b69c87231e65005b3b39396368fa088ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [

But when I try to send the transaction I get this error:

"meta": {
"error": {
"code": 4003,
"message": "Cannot send transaction: mandatory-script-verify-flag-failed (Signature must use SIGHASH_FORKID) (code 16)"

I wasn't able to find much info on this error message. Any help getting this sorted out would be appreciated
submitted by Majestic-Pear-1100 to btc [link] [comments]

PSA: Guide on how to recover your lost Segwit coins using Electron Cash

How to get your recovered SegWit funds using Electron Cash


Thousands of BCH on thousands of coins that were accidentally send to Segwit 3xxx addresses were recovered by BTC.TOP in block 582705.
This was a wonderful service to the community. This had to be done quickly as the coins were anyone can spend and needed to be sent somewhere. This all had to be done before thieves could get their dirty paws on them.
So.. How were they recovered? Did BTC.TOP just take the coins for themselves? NO: They were not taken by BTC.TOP. This would be wrong (morally), and would open them up to liability and other shenanigans (legally).
Instead --BTC.TOP acted quickly and did the legally responsible thing with minimal liability. They were sent on to the intended destination address of the SegWit transaction (if translated to BCH normal address).
This means BTC.TOP did not steal your coins and/or does not have custody of your funds!
But this does mean you now need to figure out how to get the private key associated with where they were sent -- in order to unlock the funds. (Which will be covered below).
Discussions on why this was the most responsible thing to do and why it was done this way are available upon request. Or you can search this subreddit to get to them.

Ok, so BTC.TOP doesn't have them -- who does?

You do (if they were sent to you)! Or -- the person / address they were sent to does!


The Segwit transactions have a bad/crazy/messed-up format which contains an output (destination) which contains a hash of a public key inside. So they "sort of" contain a regular bitcoin address inside of them, with other Segwit garbage around them. This hash was decoded and translated to a regular BCH address, and the funds were sent there.
Again: The funds were forwarded on to a regular BCH address where they are safe. They are now guarded by a private key -- where they were not before (before they were "anyone can spend"). It can be argued this is the only reasonable thing to have done with them (legally and morally) -- continue to send them to their intended destination. This standard, if it's good enough for the US Post Office and Federal Mail, is good enough here. It's better than them being stolen.

Ok, I get it... they are on a regular BCH address now. The address of the destination of the Tx, is it?

Yes. So now a regular BCH private key (rather than anyone can spend) is needed to spend them further. Thus the Segwit destination address you sent them to initially was effectively translated to a BCH regular address. It's as if you posted a parcel with the wrong ZIP code on it -- but the USPS was nice enough to figure that out and send it to where you intended it to go.

Why do it this way and not return to sender?

Because of the ambiguity present-- it's not entirely clear which sender to return them to. There is too much ambiguity there, and would have led to many inputs not being recovered in a proper manner. More discussion on this is available upon request.

Purpose of this guide

This document explains how to:
Complications to watch out for:

Step 1: Checking where your coins went

To verify if this recovery touched one of your lost coins: look for the transaction that spent your coins and open it on explorer.

Normal aka "P2PKH"

Let’s take this one for example.
Observe the input says:
P2SH 160014d376cf1baff9eeed943d58551d53c48377adb98c 
And the output says:
P2PKH OP_DUP OP_HASH160 d376cf1baff9eeed943d58551d53c48377adb98c OP_EQUALVERIFY OP_CHECKSIG 
Notice a pattern?
The fact that these two highlighted hexadecimal strings are the same means that the funds were forwarded to the identical public key, and can be spent by the private key (corresponding to that public key) if it is imported into a Bitcoin Cash wallet.

Multisig aka "P2SH"

If the input starts with “P2SH 220020…”, as in this example, then your segwit address is a script -- probably a multisignature. While the input says “P2SH 22002019aa2610492ee2c18605597136294596d4f0f9bc6ce0974ed3a975d65da4ca1e”, the output says “P2SH OP_HASH160 21bdc73fb15b3bb7bd1be365e92447dc2a44e662 OP_EQUAL”. These two strings actually correspond to the same script, but they are different in content and length due to segwit’s design. However, you just need to RIPEMD160 hash the first string and compare to the second -- you can check this by entering the input string (after the 220020 part) into this website’s Binary Hash field and checking the resulting RIPEMD160 hash. The resulting hash is 21bdc73fb15b3bb7bd1be365e92447dc2a44e662, which corresponds to the output hex above, and this means the coins were forwarded to the same spending script but in "non-segwit form". You will need to re-assemble the same multi-signature setup and enough private keys on a Bitcoin Cash wallet. (Sorry for the succinct explanation here. Ask in the comments for more details perhaps.)

No match -- what?!

If the string does not match (identically in the Normal case above, or after properly hashing in the Multisig case above), then your coins were sent elsewhere, possibly even taken by an anonymous miner. :'(

Step 2: How To Do the Recovery

Recover "Normal" address transactions (P2PKH above)

This is for recoveries where the input string started with “160014”.
Option 1 (BIP39 seed):
Option 2 (single key):
Option 3 (xprv -- many keys):
mkey = "yprvAJ48Yvx71CKa6a6P8Sk78nkSF7iqqaRob1FN7Jxsqm3L52K8XmZ7EtEzPzTUWXAaHNfN4DFAuP4cdM38yrE6j3YifV8i954hyD5rhPyUNVP" from electroncash.bitcoin import DecodeBase58Check, EncodeBase58Check EncodeBase58Check(b'\x04\x88\xad\xe4'+DecodeBase58Check(mkey)[4:]) 
Option 4 (hardware wallet):

How to Recover Multisignature wallets (P2WSH-in-P2SH in segwit parlance)

This is for recoveries where the input string started with "220020.
Please read the above instructions for how to import single keys. You will need to do similar but taking care to reproduce the same set of multisignature keys as you had in the BTC wallet. Note that Electron Cash does not support single-key multisignature, so you need to use the BIP39 / xprv approach.
If you don’t observe the correct address in Electron Cash, then check the list of public keys by right clicking on an address, and compare it to the list seen in your BTC wallet. Also ensure that the number of required signers is identical.
submitted by NilacTheGrim to btc [link] [comments]

OP_CHECKDATASIG is copying Blockstream, and is inferior to OP_DATASIGVERIFY

Hi all,
Bitcoin-ABC's implementation of Bitcoin Cash is set to hard fork on November 18th, activating a bunch of features aimed at enhencing the usability of the currency.
One of the proposed improvements is OP_CHECKDATASIG, which can be used to run a verify operation on a (signature, message hash, pubkey) triplet. By itself, this is an extremely useful opcode to have. It allows one to embed an arbitrary message to the transaction, and these messages can then be used in applications external to the chain, or as an way to allow delegated signatures on top of the script itself that is being verified. Pretty cool.
OP_CHECKDATASIG is also exceptional for a different reason. In particular, it is an almost exact line-by-line copy of a little-known, yet fairly mature opcode called OP_CHECKSIGFROMSTACK, implemented here :
For those who haven't been following, Elements is a project created by Blockstream, and elements alpha is a sidechain where experimental features can be added and tested. This commit from October 2016 shows (among other things) the addition of OP_CHECKSIGFROMSTACK to the elements alpha chain. Compared to the recent addition of OP_CHECKDATASIG to the bitcoin-abc client, the similarity is obvious :;9ba4bfca513d6386ee3d313b15bdd4584da7633d
On the other hand, consider Bitcoin Unlimited's OP_DATASIGVERIFY :
This looks more like an independent development. It allows the same functionality as OP_CHECKDATASIG, but it does so in a way which is more transparent and also accessible for normal users. What I mean by that is, recall the verification parameters passed to OP_CHECKDATASIG, these were (signature, message hash, pubkey). For OP_DATASIGVERIFY, the parameters are slightly different: (signature, message, pubkey hash). The difference is subtle, but important. OP_DATASIGVERIFY follows the same design pattern as the widely known signmessage and verifymessage features that are implemented by various wallets (and in use by services like ). That is, a raw message is signed for and published by the user to the world, and independent verifiers are able to match the published signature and message to a specific pubkey hash - the data that makes up the user's on-chain address. If you've ever used this message signing and verifying feature of your wallet, you probably know how useful it can be. In contrast, OP_CHECKDATASIG verifies a message hash, not a plaintext message, against a pubkey, not a public address. This means that for a verifymessage-like operation, the script used in the transaction would become quite cumbersome:


  1. We want to publish a plaintext message, but we have to "feed" its hash to OP_CHECKDATASIGVERIFY, so we have to use an OP_HASH256
  2. The pubkey we provide for verification will be "used up" by OP_CHECKDATASIGVERIFY, so we must both duplicate it and keep the copy in altstack
  3. OP_CHECKDATASIGVERIFY behaves exactly like OP_CHECKDATASIG, except that it fails the entire script immediately if the signature fails to verify
  4. We have the pubkey, but we still have to check that its hash matches the address, so we use OP_HASH160 and test for equality. Note that this means that we have to publis both public key /and/ its hash in the same transaction. Almost too wasteful.

Using OP_DATASIGVERIFY instead, the script is simply:

Hashing of the plaintext message is done internally by the OP_DATASIGVERIFY operation, and the same is also true for the hashing of the resulting public key against the provided pubkey hash (the data that makes up the address). A second not-so-obvious difference is the actual content of in the two scripts. For the OP_DATASIGVERIFY script, this message is actually parsed and verified using the exact same format as verifymessage in the wallet. This means that services like blockchain explorers can then simply decode the data in such a transaction and present it to users in a manner that enables them to run local verification of the message using their own wallet, simply by copy+pasting the information! Using OP_CHECKDATASIG instead, the does not follow the same semantics and format as the one in verifymessage, and no wallet exists today which support such a verifying operation in the UI. It is also hard to expect something like verifydatasigmessage to be implemented on absolutely all wallets.
I think it benefits of OP_DATASIGVERIFY when measured against OP_CHECKDATASIG are obvious, and am curious to hear your opinions.
submitted by moosapor 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:
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:
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:
submitted by xmrhaelan to CryptoCurrency [link] [comments]

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

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

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
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:
submitted by therealtacotime to Bitcoin [link] [comments]

Inquiry on SegWit(P2SH) Address

Hi, I'm Daisy,an employee working at BaihuaBlockchian(a Chinse WeChat Official Account) . We want to help common people have a go about lightning network. So I'm searching for a wallet which supports lightning network recently. And BlueWallet is the sole one supports lightning network based on IOS. However I came across a problem about SegWit(P2SH) Address. For example, when I imported my private key 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn (don't worry, there is no bitcin in this address) and chose SegWit(P2SH) Address , I got the address
35YjHrdgaS3R3pw2KFrMyBu3e2PZN7L7kD. I guess this is how BlueWallet generates a SegWit(P2SH) Address
WIF private key:5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
HEX: 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD
uncompressed public key:04f028892bad7ed57d2fb57bf33081d5cfcf6f9ed3d3d7f159c2e2fff579dc341a07cf33da18bd734c600b96a72bbc4749d5141c90ec8ac328ae52ddfe2e505bdb
HASH160(uncompressed public key):211b74ca4686f81efda5641767fc84ef16dafe0b
Redeem script:0014211b74ca4686f81efda5641767fc84ef16dafe0b
HASH160(redeem script ):2a4f4a92750379d39fc9b73cbfb2ff2e478ff291
And when I used the private key 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn to spend bitcoin in 35YjHrdgaS3R3pw2KFrMyBu3e2PZN7L7kD, I got an alert :
Segwit supports only compressed public keys
So I think maybe the right way should be like this:
HEX: 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDDWIFC private key:KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
compressed public key:03f028892bad7ed57d2fb57bf33081d5cfcf6f9ed3d3d7f159c2e2fff579dc341a
HASH160(compressed public key):bbc1e42a39d05a4cc61752d6963b7f69d09bb27b
Redeem script:0014bbc1e42a39d05a4cc61752d6963b7f69d09bb27b
HASH160(redeem script):9ca0e746160117cc342531ab7e44d0e12961c544
Therefore, I think BlueWalllet makes a mistake when it's generating a SegWit(P2SH) Address, it doesn't convert the umcompressed key into compressed key and SegWit doese not support uncompressed key.
Yesterday, I sent several Satoshis into this address 3JyGdeQ8oth9aGZr1DAoHcGyczkkTFg3H8 which was also generated by BlueWallet. I'm not sure if they are lost forever.

submitted by Daisy2019121 to bluewallet [link] [comments]

Unconfirmed Bitcoin Problem

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

Qtum - Quantum Chain Design Document

Serialization: Qtum Foundation Design Document

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) 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 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: 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 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.


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]

Fee larger than transaction

Today I wanted to send out the bitcoins that were accumulating on one of my wallets. I was receiving there micropaymants for web ads. Unfortunately I'm not able to send any of it out (a 0.05 in total, not much but still ~50 bucks). I'm using armory and it calculated the fee of over a 1BTC for it (like 20 times greater that the transaction amount!!!). I tried to decrease the transaction but no matter what I do I end up network rejecting my transaction. All the incoming transaction are for 0.0001 or slightly more. The rejected transactions are not very huge, the average looks like thsi:
Transaction: TxHash: 025c0ffe015a8e6a35a9e7bc9018e786194ef0e3a055c7507a38f840f5938902 (BE) Version: 1 nInputs: 3 nOutputs: 2 LockTime: 0 Inputs: PyTxIn: PrevTxHash: f405598c0580cea546c73a9ed5e52347f3a07a3cb4d8b01b50a647f7438458a9 (BE) TxOutIndex: 31 Script: (4830450220019b4a6a32918f3bf72b8e67ec55cb6cd3aa97fc30dc3c8794c2be) Sender: 1AsPzC53491jKTvwrUEZnvF6cgtXDWD8mX Seq: 4294967295 PyTxIn: PrevTxHash: 86ea39dc35303a47b57689acaa8f96274ff5cc2412bc5e4c254c15ce6bfa1321 (BE) TxOutIndex: 29 Script: (483045022100b29a0b29202e19f2dc651b3ec842a8b72a3d39c3f41d14ee9445) Sender: 1AsPzC53491jKTvwrUEZnvF6cgtXDWD8mX Seq: 4294967295 PyTxIn: PrevTxHash: dd9da02bbb566681162f9956f6c2d6e47d2d0428098a2c0aba9ba4cb25ddc91e (BE) TxOutIndex: 74 Script: (483045022100aab39ac4adba537d9d441b7f92f11b66554ff2573ba3871a2285) Sender: 1AsPzC53491jKTvwrUEZnvF6cgtXDWD8mX Seq: 4294967295 Outputs: TxOut: Value: 8780 (8.78e-05) Script: OP_DUP OP_HASH160 (1Dcu2y3eefKRVkJY7JSJeaouRyEnBYaWJt) OP_EQUALVERIFY OP_CHECKSIG TxOut: Value: 53270 (0.0005327) Script: OP_DUP OP_HASH160 (1N7afkxPv9b4CRaTwecqwHisRH7yMUPQvF) OP_EQUALVERIFY OP_CHECKSIG
Does it mean that the bitcoin if fubar? is there any way to actually make any use of such dust bitcoin wallets at all?
submitted by emsiak to Bitcoin [link] [comments]

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

Qtum original design document summary (7) -- Qtum added RPC call
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.
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.
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:
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:
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:
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:
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:
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:
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": 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"}
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":, 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.
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:
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:
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
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.
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
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
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:


He calculates the corresponding address:


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

address: OP_DUP OP_HASH160
010966776006953D5567439E5E39F86A0D273BEE OP_EQUALVERIFY

The script is hashed: 36e0ea8e93eaa0285d641305f4c81e563aa570a2

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

using version byte 23:
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
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
[ LEB128-encoded] unsigned integers
representing the asset quantity of every output in order (excluding
the marker output). || Variable
! Metadata length || The
var-integer] encoded length of the metadata field. || 1-9
! 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 [ LEB128] encoding (also
used in [
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
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.
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]...
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Need help with unconfirmed transaction

Hey guys I need some help. I transferred some bitcoins ( 3 days ago) but never got any confirmations. I was using multibit 0.5.18. With a fee of 0,15 cent.
I tried the "BTC Accelerator" by and after that I got the message: "Transaction rejected by our node. Reason: Transaction was previously accepted but has been pruned from our database."
I can still see it at
raw transaction: 494ca85f66c7f857b01d5634b759db6ee21847966248874caee57d062cbfb16b: Seen by 6 peers. Pending/unconfirmed. in [3045022100fdabbdef98ff68c22aeb83ef4f185cc3768c5e1e923ef8cd3bf04d7c6bb4e70602207d142122a4ff0615b7764124bb0e587110b3fc35c80d4cd93c8c971113296b3201] [0245901fc1f018d3e76413355ebd20c18b021e36f0525b162ae7b3dfd6d55a8762] outpoint:4fdfb5aa84fd6d3c3788a77b84b8558c2458c8e3e0fc94535eeb1ed6dcf3de80:5 hash160:2e05fdf3bff6d43daf2509eb09a93a375bda2609 out DUP HASH160 [9d4fc8028865ed7a5f89ac0ddf856592d269c06d] EQUALVERIFY CHECKSIG 0.02136228 BTC
I've been searching for hours for a solution but to no avail. I'm having a really hard time understanding bitcoin. Is there anyone who can help me and guide me in the right direction? Did I lost my money, or will they come back to my wallet?
submitted by MikeldeliC to Bitcoin [link] [comments]

[BIP Proposal] Standard address format for timelocked funds | ZmnSCPxj | Jul 08 2017

ZmnSCPxj on Jul 08 2017:
BIP: ?
Title: Standard address format for timelocked funds
Author: ZmnSCPxj
Comments-Summary: ?
Comments-URI: ?
Status: ?
Type: ?
Created: 2017-07-01
License: CC0-1.0
== Abstract ==
OP_CHECKLOCKTIMEVERIFY provides a method of
locking funds until a particular time arrives.
One potential use of this opcode is for a user to precommit
himself or herself to not spend funds until a particular
date, i.e. to hold the funds until a later date.
This proposal adds a format for specifying addresses that
precommit to timelocked funds, as well as specifying a
redemption code to redeem funds after the timelock has
This allows ordinary non-technical users to make use of
== Copyright ==
This BIP is released under CC0-1.0.
== Specification ==
This proposal provides formats for specifying an
address that locks funds until a specified date,
and a redemption code that allows the funds to be
swept on or after the specified date.
At minimum, wallet software supporting this BIP must
be capable of sweeping the redemption code on or after
the specified date.
In addition, the wallet software should support sending
funds to the timelocked address specified here.
Finally, wallet software may provide a command to create
a pair of timelocked address and redemption code.
Addresses and redemption codes are encoded using
Bech32 encoding].
=== Timelocked Address Format ===
The human-readable part of the address is composed of:

The four characters hodl.

A date, in YYYYMMDD form. For example,

the date August 1, 2017 is encoded as 20170801.

A network code, either tb for testnet,

or bc for Bitcoin mainnet.
The data part of the address is composed of:

A version quintet (5 bits), which must be 0 for this


A public key hash, 32 quintets (160 bits). As is

usual for Bitcoin, this is big-endian.
This is to be interpreted as follows:

The given date is the first day that the funds in

the given address may be redeemed.

The funds are owned by whoever controls the private

key corresponding to the public key hash given.
=== Redemption Code ===
The human-readable part of the redemption code is
composed of:

The four characters hedl.

A date, in YYYYMMDD form.

A network code, either tb for testnet,

or bc for Bitcoin mainnet.
The data part of the address is composed of:

A version quintet (5 bits), which must be 0 for this


A private key, 52 quintets (260 bits). This is the

256-bit private key, prepended with 4 0
bits, in big-endian order.
This is to be interpreted as follows:

The given date is the first day that the funds in

the given address may be redeemed.

The private key unlocks the funds.

=== Lock Time Computation ===
Given a particular lock date YYYYMMDD, the
actual lock time is computed as follows:

The day before the lock date is taken. For example,

if the lock date is 20180101 or
January 1, 2018, we take the date December 31, 2017.

We take the time 1000h (10:00 AM, or 10 in the morning)

of the date from the above step.
This lock time is then translated to a
Unix epoch time, as per POSIX.1-2001 (which removes the
buggy day February 29, 2100 in previous POSIX revisions).
The translation should use, at minimum, unsigned 32-bit
numbers to represent the Unix epoch time.
The Unix epoch time shall then be interpreted as an
nLockTime value, as per standard Bitcoin.
Whether it is possible to represent dates past 2038
will depend on whether standard Bitcoin can represent
nLockTime values to represent dates past
Since nLockTime is an unsigned 32-bit
value, it should be possible to represent dates until
06:28:15 UTC+0 2106-02-07.
Future versions of Bitcoin should be able to support
nLockTime larger than unsigned 32-bit,
in order to allow even later dates.
The reason for using an earlier lock time than the
specified date is given in the Rationale section of
this BIP.
=== Payment to a Timelocked Address ===
An ordinary P2SH payment is used to provide funds to a
timelocked address.
The script below is used as the redeemScript
for the P2SH payment:
Once the redeemScript is derived, the hash is
determined, and an ordinary P2SH output with the below
scriptPubKey used:
In case of SegWit deployment, SegWit-compatible wallets
should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per
the output they would normally use in that situation.
Obviously, a timelocked address has an equivalent
Bitcoin 3 (P2SH) address.
A simple service or software that translates from a
public timelocked address to a P2SH address can be
created that makes timelocking (but not redemption)
backwards compatible with wallets that do not support
this BIP.
This proposal recommends that wallets supporting payment
to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should
reuse the same interface for paying to such addresses as
paying into timelocked addresses of this proposal.
=== Redemption of a Timelocked Redemption Code ===
To sweep a timelocked redemption code after the timelock,
one must provide the given redeemScript as
part of the scriptSig, of all unspent
outputs that pay to the given redeemScript
When sweeping a timelocked redemption code, first the
wallet must extract the private key from the redemption
code, then derive the public key, the public key hash,
the redeemScript, and finally the
redeemScript hash.
Then, the wallet must find all unspent outputs that pay
to the redeemScript hash via P2SH (and, in the
case of SegWit deployment, via P2SH-P2WSH and P2WSH).
For each such output, the wallet then generates a
transaction input with the below scriptSig, as
per usual P2SH redemptions:
The wallet then outputs to an address it can control.
As the Script involved uses OP_CHECKLOCKTIMEVERIFY,
the nSequence must be 0 and the
nLockTime must be equal to the computed
lock time.
This implies that the transaction cannot be transmitted
(and the funds cannot be sweeped)
until after the given lock time.
The above procedure is roughly identical to sweeping an
ordinary, exported private key.
This proposal recommends that wallets supporting a sweep
function should reuse the same interface for sweeping
individual private keys (wallet import format) for sweeping
timelocked redemption codes.
== Motivation ==
A key motivation for this BIP is to allow easy use of
The below are expected use cases of this proposal:

A user wants to purchase an amount of Bitcoin,

and subsequently wait for an amount of time before
cashing out.
The user fears that he or she may have "weak hands",
i.e. sell unfavorably on a temporary dip, and thus
commits the coins into a timelocked fund that can
only be opened after a specific date.

A user wants to gift an amount of Bitcoins to

an infant or minor, and wants the fund to not be spent
on ill-advised purchases until the infant or minor
reaches the age of maturity.

A user may wish to prepare some kind of monthly subsidy

or allowance to another user, and prepares a series of
timelocked addresses, redeemable at some set date on
each month, and provides the private redemption codes to
the beneficiary.

A user may fear duress or ransom for a particular

future time horizon, and voluntarily impose a lock time
during which a majority of their funds cannot be spent.
== Rationale ==
While in principle, this proposal may be implemented as a
separate service or software, we should consider the long
time horizons that may be desired by users.
A user using a particular software to timelock a fund may
have concerns, for example, of specifying a timelock
18 years in the future for a gift or inheritance to a
newborn infant.
The software or service may no longer exist after 18 years,
unless the user himself or herself takes over maintenance
of that software or service.
By having a single standard for timelocked funds that is
shared and common among multiple implementations of Bitcoin
wallets, the user has some assurance that the redemption code
for the funds is still useable after 18 years.
Further, a publicly-accessible standard specifying how the
funds can be redeemed will allow technically-capable users
or beneficiaries to create software that can redeem the
timelocked fund.
This proposal provides a timelock at the granularity of a
The expectation is that users will have long time
durations of months or years, so that the ability to
specify exact times, which would require specifying the
timezone, is unneeded.
The actual timeout used is 1000h of the day before the
human-readable date, so that timezones of UTC+14 will
definitely be able to redeem the money starting at
0000h of the human-readable date, local time (UTC+14).
Given the expectation that users will use long time
durations, the fact that timezones of UTC-12 will
actually be able to redeem the funds on 2200h UTC-12
time two days before can be considered an acceptable
The human-readable date is formatted according to
ISO standard dates], with the dashes removed.
Dashes may prevent double-click selection, making
usability of these addresses less desirable.
The bc or tb is after the
date since the date is composed of digits and the bech32
separator itself is the digit 1. One
simply needs to compare hedlbc202111211...
and hedl20211121bc1....
A version quintet is added in case of a...[message truncated here by reddit bot]...
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Proposal: Extended serialization format for BIP-32 | shiva sitamraju | Sep 09 2017

shiva sitamraju on Sep 09 2017:
I understand the motivation of adding the birthdate field. However, not
very comfortable with having this in the public key serialization. There
are privacy implication of both the birthday field and having the complete
derivation path, which takes space.
I am fine with Thomas proposal of {x,y,z}. Having additional version byte
field looks modular but since since we already have the big enough version
field in bip32, better to use that instead of adding more bytes.
Thomas, can you please explain why we require different version for P2WPKH
or P2WSH versus (P2WPKH or P2WSH) nested in P2SH. It looked to me that they
would have the same output bitcoin address and under same account.
On Fri, Sep 8, 2017 at 2:09 AM, <
bitcoin-dev-request at> wrote:
Send bitcoin-dev mailing list submissions to
bitcoin-dev at
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
bitcoin-dev-request at
You can reach the person managing the list at
bitcoin-dev-owner at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."
Today's Topics:
  1. Re: Proposal: Extended serialization format for BIP-32
    wallets (Andreas Schildbach)
  2. Re: Proposal: Extended serialization format for BIP-32
    wallets (Pavol Rusnak)
  3. Re: Fast Merkle Trees (Mark Friedenbach)
  4. Re: Proposal: Extended serialization format for BIP-32
    wallets (Thomas Voegtlin)
Message: 1
Date: Thu, 7 Sep 2017 21:35:49 +0200
From: Andreas Schildbach
To: bitcoin-dev at
Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
 BIP-32 wallets 
Content-Type: text/plain; charset=utf-8
On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote:
On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
A solution is still needed to wallets who do not wish to use BIP43
What if we added another byte field OutputType for wallets that do not
follow BIP43?
0x00 - P2PKH output type
0x01 - P2WPKH-in-P2SH output type
0x02 - native Segwit output type
Would that work for you?
I think that would work.
The question is whether this field should be present only if depth==0x00
or at all times. What is your suggestion, Thomas?
In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
we need this field. I think it should always be present if a chain is
limited to a certain script type.
There is however the case where even on one chain, script types are
mixed. In this case the field should be omitted and the wallet needs to
scan for all (known) types. Afaik Bitcoin Core is taking this path.
Message: 2
Date: Thu, 7 Sep 2017 22:00:05 +0200
From: Pavol Rusnak
To: Andreas Schildbach , Bitcoin Protocol
Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
 BIP-32 wallets 
Message-ID: <40ed03a1-915c-33b0-c4ac-e898c8c733ba at>
Content-Type: text/plain; charset=windows-1252
On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:
In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
we need this field.
But the depth of exported public key will be null. It does not make
sense to export xpub for m or m/0' for your particular case.
I think it should always be present if a chain is
limited to a certain script type.
I am fine with having the path there all the time.
There is however the case where even on one chain, script types are
mixed. In this case the field should be omitted and the wallet needs to
scan for all (known) types. Afaik Bitcoin Core is taking this path.
Is that really the case? Why come up with a hierarchy and then don't use

Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO, SatoshiLabs
Message: 3
Date: Thu, 7 Sep 2017 13:04:30 -0700
From: Mark Friedenbach
To: Russell O'Connor
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Fast Merkle Trees
Message-ID: <40D6F502-3380-4B64-BCD9-80D361EED35C at>
Content-Type: text/plain; charset="us-ascii"
TL;DR I'll be updating the fast Merkle-tree spec to use a different
 IV, using (for infrastructure compatability reasons) the scheme provided by Peter Todd. 
This is a specific instance of a general problem where you cannot
trust scripts given to you by another party. Notice that we run into
the same sort of problem when doing key aggregation, in which you must
require the other party to prove knowledge of the discrete log before
using their public key, or else key cancellation can occur.
With script it is a little bit more complicated as you might want
zero-knowledge proofs of hash pre-images for HTLCs as well as proofs
of DL knowledge (signatures), but the basic idea is the same. Multi-
party wallet level protocols for jointly constructing scriptPubKeys
should require a 'delinearization' step that proves knowledge of
information necessary to complete each part of the script, as part of
proving the safety of a construct.
I think my hangup before in understanding the attack you describe was
in actualizing it into a practical attack that actually escalates the
attacker's capabilities. If the attacker can get you to agree to a
MAST policy that is nothing more than a CHECKSIG over a key they
presumably control, then they don't need to do any complicated
grinding. The attacker in that scenario would just actually specify a
key they control and take the funds that way.
Where this presumably leads to an actual exploit is when you specify a
script that a curious counter-party actually takes the time to
investigate and believes to be secure. For example, a script that
requires a signature or pre-image revelation from that counter-party.
That would require grinding not a few bytes, but at minimum 20-33
bytes for either a HASH160 image or the counter-party's key.
If I understand the revised attack description correctly, then there
is a small window in which the attacker can create a script less than
55 bytes in length, where nearly all of the first 32 bytes are
selected by the attacker, yet nevertheless the script seems safe to
the counter-party. The smallest such script I was able to construct
was the following:
This is 56 bytes and requires only 7 bits of grinding in the fake
pubkey. But 56 bytes is too large. Switching to secp256k1 serialized
32-byte pubkeys (in a script version upgrade, for example) would
reduce this to the necessary 55 bytes with 0 bits of grinding. A
smaller variant is possible:
This is 46 bytes, but requires grinding 96 bits, which is a bit less
Belts and suspenders are not so terrible together, however, and I
think there is enough of a justification here to look into modifying
the scheme to use a different IV for hash tree updates. This would
prevent even the above implausible attacks.
On Sep 7, 2017, at 11:55 AM, Russell O'Connor
On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach
> wrote:
I've been puzzling over your email since receiving it. I'm not sure it
is possible to perform the attack you describe with the tree structure
specified in the BIP. If I may rephrase your attack, I believe you are
seeking a solution to the following:
Want: An innocuous script and a malign script for which
is equal to either
fast-SHA256(double-SHA256(malign) || r) or
fast-SHA256(r || double-SHA256(malign))
or fast-SHA256(fast-SHA256(double-SHA256(malign) || r1) || r0)
or fast-SHA256(fast-SHA256(r1 || double-SHA256(malign)) || r0)
or ...
where r is a freely chosen 32-byte nonce. This would allow the
attacker to reveal the innocuous script before funds are sent to the
MAST, then use the malign script to spend.
Because of the double-SHA256 construction I do not see how this can be
accomplished without a full break of SHA256.
The particular scenario I'm imagining is a collision between
fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2) || 
r1) || r0).
where innocuous is a Bitcoin Script that is between 32 and 55 bytes long.
Observe that when data is less than 55 bytes then double-SHA256(da...[message truncated here by reddit bot]...
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

12-03 17:43 - 'Help tracing a transaction' (self.Bitcoin) by /u/19022931 removed from /r/Bitcoin within 1942-1952min

Hey ladies and gentle men, I have read the rules, I am going to try hard to follow them and explain why I need your help.
I am pretty savvy when it comes to tech, but this ones foxed me.
Its not about a huge amount, only 0.01BTC, but not being able to figure it out is really pissing me off.
The story so far.
I tried to send 0.01BTC from a hardware wallet (Digital Bitbox) to a hot wallet (electrum in tails).
I got a receive address from Electrum, copied it and paste into the send address in the bitbox, entered the amount, hit send.
Generating Transaction, Signing, Broadcast all go smoothly but the transaction never confirms, nor shows unconfirmed in the electrum wallet. (Yes, I did have appropriate fee).
So, I start digging, the hardware wallet gave me the following TX NO - a601ea4065f36d63720eb18179fc611d3bc76408a337d9af99f8ce2a5bfce0b1
Which the block chain explorer tells me doesnt exist.
So I do a search under the receive address, this brings up some information and shows an incoming transaction for the correct amount but a balance of zero.
Can I post the receive address? Not sure, but if you want to help me, you will need it right?
And a hash 160 - b7cf7740064a5d62a7de6a449b64d9061dd8682b
both show the correct amount received but the balance is zero the button icon on bottom right shows a minus figure for the correct amount.
Both the receive address and the hash160 show unspent outputs and a negative figure/zero balance.
First time I have encountered a problem like this.
I have withdrawn all funds from the hardware wallet, a short delay but confirmed ok. Just this one has gone awol.
Can anyone help or offer a suggestion on what to do? Again, not a huge amount but you know.... I am a nerd and not being able to figure this out is pissing me off.
EDIT - I just notice at the bottom, the correct send receive information with an ID of - bcde79a8e20ce626c95c6553c3257217f8363a9d2a734435542f13aa3d828fd4
Not sure what this all means, my head hurts, trying to find out where my $100 bucks went.....
Help tracing a transaction
Go1dfish undelete link
unreddit undelete link
Author: 19022931
submitted by removalbot to removalbot [link] [comments]

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

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

Author: Peter Todd <pete at>
Status: Draft
Type: Standards Track
Created: 2014-10-01

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

Bitcoin: ScriptSig And ScriptPubKey Terminology - Part11 Unconfirmed Transactions Bitcoin (BTC) script - unofficial 10 Convert Bitcoin address to Hash160 address Blockchain  How To Find Your Block chain HASH ID  Transaction ID with Shinell Johnson Blockchain Unconfirmed Transactions Script Unlimited Earn 100% working

I'm trying to sign a coinbase transaction. I know I need to use 76 A9 14 (HASH160) 88 AC but I don't understand how to create the HASH160 (20 byte) from a bitcoin address. This bitcoin address is a 25 bytes number (usually displayed in Base58) which is linked to the hash 160 as follows: address = [Version Byte (1)][Hash 160 (20)][Checksum (4)] The version byte is simply 0x00 for the main bitcoin network and the 4 checksum bytes are simply the first 4 bytes of the double sha256 hash of the 21 bytes [Version Byte][Hash 160] I attach a java snippet to illustrate ... HASH160. Generate Armory & Electrum Chains. Generation Method. Armory Electrum . Root Key. Secure Random . Chain Code. Paper Backup. Primary Addresses. Change Addresses. Wallet Format. CSV JSON. Chain. Bitcoin Transaction Builder. Use this tool to create a new BTC transaction (tx) Build Transaction From. Private Key JSON Transaction Raw Transaction. Private Key. Source Address. BTC. Edit ... This site aims to provide the docs you need to understand Bitcoin and start building Bitcoin-based applications. It is used in the Bitcoin standard. It is a a strengthened version of the RIPEMD algorithm which produces a 128 bit hash digest while the RIPEMD-160 algorithm produces a 160-bit output. The compression function is made up of 80 stages made up of 5 blocks that run 16 times each. This pattern runs twice with the results being combined at the bottom using modulo 32 addition. Padding. The ...

[index] [7392] [37938] [48058] [34910] [2303] [24716] [33572] [14727] [37933] [40022]

Bitcoin: ScriptSig And ScriptPubKey Terminology - Part11

Convert Bitcoin address to Hash160 address Tool written in Perl: ... How to Brute Force a Bitcoin Wallet with Hashcat - Duration: 16:56. Bitcoin Daytrader 29,376 views. 16:56. Blockchain/Bitcoin ... In this video, we go over the terminology needed to understand scriptsig and scriptpubkey. We go over public key, private key, public key hash, public address, digital signature and hash160. 6. Enter your bitcoin address on alert box to change the receiver address and press ENTER. If you have further questions, We will be happy to help: [email protected] _____ #Bitcoin # ... How to find the transaction ID in your Bitcoin wallet - Duration: 2:20. Hugh Broodryk 36,896 views. 2:20. All about Blockchain. Send and receive. ⚠️ DO NOT USE PROXY WHEN YOU USE IT Download Link