Bitcoin Forum
September 25, 2018, 09:57:43 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 »
1  Bitcoin / Development & Technical Discussion / Re: Manually convert a Binary or HEX private key to WIF, then find the Public Key on: Today at 10:44:53 AM
whereas Andrew has provided an extensive answer, I thought I'd add two and a half more things.
I had this confusion with keys in hex and WIF, and then how to come to bitcoin addresses. So I made a small picture, which
I posted on a thread in bitcoin.SE.

Do you have or know of an updated picture including bech32 addresses from Public Key?
2  Bitcoin / Bitcoin Technical Support / Re: I Want To Learn Exact Formula To Get Block's Hash on: Today at 09:53:00 AM
You are a legend dude. I would give merit if I had but where is the nonce?
This is the nonce in the example provided by seoincorporation: 42a14695

Code:
version        = "01000000"
hashPrevBlock  = "81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000"
hashMerkleRoot = "e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b"
Time       = "c7f5d74d"
Bits       = "f2b9441a"
Nonce       = "42a14695"


3  Bitcoin / Bitcoin Technical Support / Re: Possible bug in decoderawtransaction in 16.02? on: September 24, 2018, 06:17:08 AM
Quote
Nice to see this get fixed, as you commented before, no one talk about that second parameter for decoderawtransaction, the true at end makes the difference. avoiding the problem. Maybe you can change the topic to Fixed and close the thread now.  Wink

The problem itself isn't fixed in my opinion since the heuristic part still can result in bogus output for decoderawtransaction. The given workaround will only be usable if you can reference a transaction-id. That will not be the case if I constructed a raw transaction which I want to check with decoderawtransaction. Thread should only be closed when this is no longer the case.

This should produce the same outcome (as mentioned before and as a test):

Code:
bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4
bitcoin-cli decoderawtransaction <output from previous getrawtransaction>

VERSUS

bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 true
Note the first approach gives the bogus output with a value of -49104543721.81252095. The second output will produce the correct output.

4  Economy / Investor-based games / Re: BTC2double.com - Double your BTC in 6 hours - Trusted Bitcoin Doubler ||OFFICIAL on: September 20, 2018, 07:48:53 AM
Thread updated - Btc2Double still scamming
5  Bitcoin / Bitcoin Technical Support / Re: Segwit and decoderawtransaction on: September 14, 2018, 11:58:24 AM
That is a fairly safe assumption.

If there are no "txinwitness" blocks, then none of the inputs being used are "SegWit" inputs... therefore, it isn't a SegWit "transaction"... or more correctly, it doesn't contain any SegWit data.
I am currently doing some more research into this and maybe there is at least one other scenario where a transaction is a "Segwit transaction" without a single "txwitness" block. That scenario is  when the coinbase reward is collected by a native Segwit address (bc1...).

An example:
Code:
bitcoin-cli getrawtransaction 2d531f2d4bf1227a6492656b4b340d36c810d313d94a413a965524ae71086bb9 1

Returns:
{
  "txid": "2d531f2d4bf1227a6492656b4b340d36c810d313d94a413a965524ae71086bb9",
  "hash": "157d1c3bf4860855a6f98792d459f83ad3bd8844cf729c8d9a6ec3accc5e2d7f",
  "version": 2,
  "size": 290,
  "vsize": 263,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "039b4208045c2b9b5b642f4254432e434f4d2ffabe6d6d91102119a0522dda683a998f05620ba4beb1f5372a04689d07d47a291dbd25c20100000000000000653f93327a0200fd00000000",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 12.50253935,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 97cfc76442fe717f2a3f0cc9c175f7561b661997",
        "hex": "001497cfc76442fe717f2a3f0cc9c175f7561b661997",
        "reqSigs": 1,
        "type": "witness_v0_keyhash",
        "addresses": [
          "bc1qjl8uwezzlech723lpnyuza0h2cdkvxvh54v3dn"
        ]
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN aa21a9ed1892392fc479aa2479df651f83a83c625ae23d35876a9fac6d9c617c8d602d9f",
        "hex": "6a24aa21a9ed1892392fc479aa2479df651f83a83c625ae23d35876a9fac6d9c617c8d602d9f",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000000,
      "n": 2,
      "scriptPubKey": {
        "asm": "2 3 [error]",
        "hex": "52534b424c4f434b3ad1087f5ba5c0e6d2c0ebe90d2ef35033860dfa99aec1afe04dfd11fa70ebd1a2",
        "type": "nonstandard"
      }
    }
  ],
  "hex": "020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff4b039b4208045c2b9b5b642f4254432e434f4d2ffabe6d6d91102119a0522dda683a998f05620ba4beb1f5372a04689d07d47a291dbd25c20100000000000000653f93327a0200fd00000000ffffffff036f5c854a0000000016001497cfc76442fe717f2a3f0cc9c175f7561b6619970000000000000000266a24aa21a9ed1892392fc479aa2479df651f83a83c625ae23d35876a9fac6d9c617c8d602d9f00000000000000002952534b424c4f434b3ad1087f5ba5c0e6d2c0ebe90d2ef35033860dfa99aec1afe04dfd11fa70ebd1a20120000000000000000000000000000000000000000000000000000000000000000000000000",
  "blockhash": "0000000000000000000b616cd42f140420d47544464ea9e59f72ff4d124f903a",
  "confirmations": 48,
  "time": 1536895846,
  "blocktime": 1536895846
}

Note: the vout-part mentions a type of "witness_v0_keyhash".

I'm not sure if this should be counted as a "Segwit transaction" or not. I guess it all comes down to the question if a coinbase transaction always counts as a non-segwit input or not.

Any feedback is welcome!
6  Bitcoin / Project Development / Re: Help me DESTROY Bitcoin! on: September 11, 2018, 01:02:54 PM
What you are describing has been done before. You might want to lookup the story of Counterparty who was responsible for trading a new currency "XCP" for people who were willing to burn bitcoin in exchange. Over 2,100 BTC's were burned this way.But some smaller startups have done it as well in the past.

7  Bitcoin / Project Development / Re: Help me DESTROY Bitcoin! on: September 11, 2018, 12:17:00 PM
Burning Bitcoin offline is easy. Transfer to a Drive and destroy the drive. Same with paper wallet, there you will actually get the satisfaction of burning it.
OP asked for a way to to track it and verifiable prove it.

Also: Burning a paper wallet or destroying a drive is not burning a coin, it's still registered in the utxo.
8  Bitcoin / Bitcoin Technical Support / Re: strange bitcoind reindex and txindex on: September 11, 2018, 09:14:33 AM
Code:
example:bitcoin-cli getrawtransaction 2157b554dcfda405233906e461ee593875ae4b1b97615872db6a25130ecc1dd6 1
error code: -5
error message:
No such mempool transaction. Use -txindex to enable blockchain transaction queries. Use gettransaction for wallet transactions.
With txindex enabled the error message should be slightly different:

"No such mempool or blockchain transaction. Use gettransaction for wallet transactions."
9  Bitcoin / Bitcoin Technical Support / Re: strange bitcoind reindex and txindex on: September 11, 2018, 09:10:53 AM
Is your node fully synced? What do you get from the getblockchaininfo command?
Both transactions seem to be from the same block with height 500000.

I personally have no problem getting the right response for both transactions though with bitcoin-cli so I'm not sure what is going on.
10  Bitcoin / Project Development / Re: Help me DESTROY Bitcoin! on: September 11, 2018, 07:46:27 AM
I am not looking to destroy Bitcoin but rather a way to effectively send a deposit to a wallet and then destroy the wallet along with the Bitcoins.
I'd want to be able to do this with any cryptocoin. And I want to be able to track it and verifiably prove it.
Why exactly do you want to send to a wallet? Do you by any chance mean an address? Because otherwise I could be holding a wallet with some addresses in them having a huge balance and then they all get destroyed because you deposit some satoshi's in an address from that wallet?

Essentially setting up an off-chain burning tool / service.
What's the off-chain aspect of this? How will coins get deposited into this wallet if it's not on-chain?

In general the preferred way in Bitcoin to burn coins is to include an OP_RETURN in a transaction with a value > 0.00. That way it is verifiable because it's registered in the blockchain but it cannot be spent afterwards. This is a better way than using fake addresses like the Bitcoineater one since the will be unspendable but it will also be included in the utxo-database.
11  Bitcoin / Development & Technical Discussion / Re: Blockchain based online portal on: September 10, 2018, 02:21:05 PM
But instead of saving users information in a usual database what I want to do is; I want to store them in blockchain.
Can you explain why you want to store them in a blockchain? Because I would expect you first wite down your requirements and then try to find a technical solution which best fits those requirements. It looks like you did it the other way around: Starting with a technical solution (blockchain) which then should accomplish whatever requirement you came up with.

I register on a website and then I create a book and start writing the first page.
once the first page is finished click on save button.
Now, this information should create a block and could be only opened by its author.
The very idea of a blockchain is that all information stored in there is publicly available. So once again: why do you think blockchain is the best option for your idea?

So everytime i add another page it should create a block and add to the blockchain.
What will happen if I decide to change some text on my first page already saved? How is a page (which is a single block in your solution) linked to another page in your solution? So will it be linked to a random page from another user or only to my own pages?

my query is where will this blockchain saved? in database? or its a raw file which user could download on their own computer?
Well the entire idea of a (public) blockchain is that all the information will be stored on every node (every computer which is part of the network). What would be the incentive in your solution for people to keep a copy of all these pages they can't even read themselves?


I personally would expect for your idea to just have a regular server-based solution with a database to store the pages. Users can then lookup previous saved pages of themselves and if needed alter them. All of this based on authentication (user credentials given in the webpage).

To make a long story short: Blockchain is a great solution for some problems, but relational databases are way better solutions for others!
12  Bitcoin / Bitcoin Technical Support / Re: Btcrecover for cracking sentences on: September 07, 2018, 10:47:19 AM
Code:
./btcrecover.py --wallet wallet.dat --tokenlist tokens.txt --utf8 --min-tokens 18
it ends with the following error message: "at least 3,800,000 passwords to try, ETA > --max-eta option (168 hours), exiting"

The default maximum runtime is 168 hours you can override this with a higher value by adding a --max-eta parameter to your call. Something like this:
Code:
./btcrecover.py --wallet wallet.dat --tokenlist tokens.txt --utf8 --min-tokens 18 --max-eta=100000000
Just be prepared the script can run for a very long time now! But at least the script won't stop and throw that message anymore.
13  Bitcoin / Bitcoin Technical Support / Re: Possible bug in decoderawtransaction in 16.02? on: September 06, 2018, 05:03:34 PM
This is a known issue and unfortunately it cannot be fixed without a fork. The issue lies with the format of a segwit transaction itself. A segwit transaction, under some circumstances, can be interpreted as either a 0 input, 1 output transaction, or as a witness transaction. Since getrawtransaction fetches transactions from blocks themselves or from the mempool, the transaction must be a valid network transaction and thus witness serialization can be attempted safely as a first step and only deserializing as non-witness if the witness deserialization fails.

However, decoderawtransaction behaves differently as it is intended to be used during the transaction creation steps. This means that it must be able to handle 0-input, 1 output transactions (which are inherently non-witness) as users may create a 0-input, 1 output transaction, decode it, and then pass it to fundrawtransaction to get inputs. But because some 0-input, 1 output transactions can be interpreted as witness transactions, and some witness transactions can be interpreted as 0-input, 1 output transactions, decoderawtransaction does not always succeed to decoding a transaction correctly. It uses some heuristics in order to decrease the number of false decodings, but sometimes, as you can clearly see, it's wrong.
Thanks, very informative. I didn't know decoderawtranscaction was intended to be used during transaction creation steps.

Fortunately, if you know that a transaction is witness you can set the iswitness argument (added in 0.16) to true to tell it explicitly to decode the transaction as witness. You can set it to false for non-witness decoding. Not setting it uses the heuristics.

So your command will be something like:
Code:
bitcoin-cli decoderawtransaction <tx> true
Yes, this does indeed work! The documentation found at https://bitcoin.org/en/developer-reference#decoderawtransaction doesn't list the second parameter. According to the documentation decoderawtransaction only takes a single parameter. Guess the documentation isn't up to date here.

One last question about the heuristic in this specific case: It's pretty clear the assumption made this was a transaction without witness data is wrong based on the fact it's reporting a negative value as an amount. So shouldn't the "heuristic algoritm" reassess itself when the output generated was clearly wrong:

Code:
Input -> Trying as non witness -> Output is valid -> Done
Input -> Trying as non witness -> Output is invalid -> Trying as witness ->Output is valid -> Done

I might be oversimplifying things here but it seems to me this would lead to a lot less incorrect assumptions from heuristics.
14  Bitcoin / Bitcoin Technical Support / Re: Possible bug in decoderawtransaction in 16.02? on: September 06, 2018, 12:22:15 PM
Just to add another piece to the puzzle: I do get the right response when overriding the second parameter of getrawtransaction to "true", as stated in the  documentation https://bitcoin.org/en/developer-reference#getrawtransaction

Quote
bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 true

Results in:
{
   "result": {
      "txid": "00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4",
      "hash": "68749aae9aeb5d1a6971ed16e0244f648aadcffbfe8ff6c6eec6fbeb1e43e1c7",
      "version": 1,
      "size": 249,
      "vsize": 168,
      "locktime": 0,
      "vin": [
         {
            "txid": "d77c1bc59aea11eff5a289d8e79b92d7c19a06e993eeb44be6bbda8fc3e45f68",
            "vout": 0,
            "scriptSig": {
               "asm": "001422234e073571fde8414ae49a8fb294c712a96c88",
               "hex": "16001422234e073571fde8414ae49a8fb294c712a96c88"
            },
            "txinwitness": [
               "30440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e7 74304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff87901",
               "02355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e"
            ],
            "sequence": 4294967295
         }
      ],
      "vout": [
         {
            "value": 2.57409060,
            "n": 0,
            "scriptPubKey": {
               "asm": "OP_HASH160 85fdf348463ede1237e06e471cce02746b9220fd OP_EQUAL",
               "hex": "a91485fdf348463ede1237e06e471cce02746b9220fd87",
               "reqSigs": 1,
               "type": "scripthash",
               "addresses": [
                  "3DuW1qNmzF3BtrbVSornifUb9EseA8KAGE"
               ]
            }
         },
         {
            "value": 0.20000000,
            "n": 1,
            "scriptPubKey": {
               "asm": "OP_DUP OP_HASH160 eee47d625f1e4a72e579ca884363ebda0f11f4b1 OP_EQUALVERIFY OP_CHECKSIG",
               "hex": "76a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac",
               "reqSigs": 1,
               "type": "pubkeyhash",
               "addresses": [
                  "1Nn9YQSAkLXU1d51fnkxmXSbB8DXePWnMh"
               ]
            }
         }
      ],
      "hex": "01000000000101685fe4c38fdabbe64bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd70 00000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f000000 0017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47 d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e 69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd 9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279 cd76255a4e643b9e00000000",
      "blockhash": "0000000000000000013aa3efc9b6e19ec6b43f55596a5e7246de92e881537297",
      "confirmations": 57144,
      "time": 1504306950,
      "blocktime": 1504306950
   },
   "error": null,
   "id": null
}

Summing up my experience:
Works:
bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 true

Fails:
bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4
Followed by using the  output from this step as input to decoderawtransaction
bitcoin-cli decoderawtransaction <output from getrawtransaction above>

Expected:
bitcoin-cli getrawtransaction <txid> true
is equal to
bitcoin-cli getrawtransaction <txid> ->rawtransaction
bitcoin-cli decoderawtransaction <rawtransaction>
15  Bitcoin / Bitcoin Technical Support / Re: Possible bug in decoderawtransaction in 16.02? on: September 06, 2018, 12:08:08 PM
Interesting found, i checked this possible bug/problem with Bitcoin Core 0.16.2 (txindex disabled, so i just try decoderawtransaction) and few explorer/services with getrawtransaction/decoderawtransaction show different result.
Did you get the same results as I did?

Gonna try it after reindexing is done.
Thanks a lot! Keep us posted Smiley

16  Other / Serious discussion / Re: Should I teach myself Python on: September 06, 2018, 06:37:59 AM
And are the books PDFs? Are they legit copies, or scanned from a textbook? If not, why would the publisher let them give it away for free. Just my skeptical mind.
They are in multiple formats including PDF, EPUB, MOBI  and online reading. They also include zip-files with all code examples. This is a legit site/service. In the end they try to sell you books ofcourse, these free books are meant to lure you in. But you can still claim a book every day without having to buy anything.
17  Bitcoin / Bitcoin Technical Support / Re: What's going on with this transaction-id? on: September 06, 2018, 06:32:26 AM
Ok, i found some one with the same problem and the explanation:

Quote
That transaction is a witness transaction, but 0.14.2 is interpreting it as non-witness, which is why the hash is the same as the txid and there are no inputs. 0.15.0 interprets it fine.

Please take a look to https://github.com/bitcoin/bitcoin/issues/11157 'Fail to decode transaction correctly.'
That's referring to bitcoin core before 0.15.0. As I've posted multiple times now that's not the case for me. So the original question remains why this is (still) happening with 0.16.02?

Anyone who can do this simple test with running the latest version of bitcoin core (0.16.02) and list their result:
Code:
bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4

And then:
bitcoin-cli decoderawtransaction <output from previous getrawtransaction>
18  Bitcoin / Bitcoin Technical Support / Re: What's going on with this transaction-id? on: September 05, 2018, 08:54:12 PM
Please post the output from:
Code:
bitcoin-cli getinfo
And let's verify if you have the core version 0.16.2

As requested:
Code:
bitcoin-cli -getinfo

{
  "version": 160200,
  "protocolversion": 70015,
  "walletversion": 130000,
  "balance": 0.00000000,
  "blocks": 540088,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 6727225469722.534,
  "testnet": false,
  "keypoololdest": 1504256530,
  "keypoolsize": 1000,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "warnings": ""
}

And to be complete the output i get when using bitcoin-cli getinfo (so not -getinfo) as you requested):
error code: -32601
error message:
getinfo

This call was removed in version 0.16.0. Use the appropriate fields from:
- getblockchaininfo: blocks, difficulty, chain
- getnetworkinfo: version, protocolversion, timeoffset, connections, proxy, relayfee, warnings
- getwalletinfo: balance, keypoololdest, keypoolsize, paytxfee, unlocked_until, walletversion

bitcoin-cli has the option -getinfo to collect and format these in the old format.
About the same as I posted before with the now used getnetworkinfo. So I am running the latest version.

Can anyone repeat the steps I did with bitcoin core 16.02 running and tx-index enabled since it looks like a bug to me.
19  Bitcoin / Bitcoin Technical Support / Re: What's going on with this transaction-id? on: September 05, 2018, 07:13:13 PM
What version of bitcoin core are you running? That might be the issue here, as it is probably(?) not recognizing the payment script.


I'm running latest version of core with -txindex enabled and fully synced:
Code:
bitcoin-cli getnetworkinfo

Returns:
  "version": 160200,
  "subversion": "/Satoshi:0.16.2/",
  "protocolversion": 70015,
  "localservices": "000000000000040d",
  "localrelay": true,
  "timeoffset": 0,
  "networkactive": true,
   ......
Anyone with a full node runnig who can try the same as I did?
20  Bitcoin / Bitcoin Technical Support / Possible bug in decoderawtransaction in 16.02? on: September 05, 2018, 06:11:58 PM
I ran into a transaction which I can't decode properly using bitcoin-cli decoderawtransaction:

Code:
bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4

Returns this raw transaction:
01000000000101685fe4c38fdabbe64bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e00000000

Decode by:
bitcoin-cli decoderawtransaction 01000000000101685fe4c38fdabbe64bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e00000000

Returns:
{
  "txid": "68749aae9aeb5d1a6971ed16e0244f648aadcffbfe8ff6c6eec6fbeb1e43e1c7",
  "hash": "68749aae9aeb5d1a6971ed16e0244f648aadcffbfe8ff6c6eec6fbeb1e43e1c7",
  "version": 1,
  "size": 249,
  "vsize": 249,
  "locktime": 0,
  "vin": [
  ],
  "vout": [
    {
      "value": -49104543721.81252095,
      "n": 0,
      "scriptPubKey": {
        "asm": "b4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede12 e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93 OP_RIPEMD160 9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402 3e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879 33 23605 OP_OR 796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b OP_NUMNOTEQUAL",
        "hex": "4bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e",
        "type": "nonstandard"
      }
    }
  ]
}

So no inputs, and a negative output value without any address. Does anyone have an idea what's going on here?

I thought maybe somehow my local files got corrupted but I did the same thing at http://chainquery.com/bitcoin-api/decoderawtransaction and got the exact same result.

Edit: This is running the latest version (16.02) of bitcoind with tx-index enabled.
Pages: [1] 2 3 4 5 6 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!