I'm trying to get a transaction info using
bitcoind gettransaction \
9962d5c704ec27243364cbe9d384808feeac1c15c35ac790dffd1e929829b271
but I'm receiving
error: {"code":-5,"message":"Invalid or non-wallet transaction id"}
How to see a transaction using bitcoin API?
You can view foreign transactions using bitcoind.
Set txindex=1 in your bitcoin.conf file.
restart bitcoind with -reindex (you need to re-build your entire index)
After you've indexed a few blocks you can use something like this:
$ bitcoind getblockcount
122735
$ bitcoind getblockhash 67543
0000000004e213266ccd388df12896412c1a70e647b48004f7d6894b9d6f63b9
$ bitcoind getblock 0000000004e213266ccd388df12896412c1a70e647b48004f7d6894b9d6f63b9
// JSON containing tx "a93a668d9332e21d51380c7251bbf5ad47295ca9795e0ad6f2fe8d63b76af9aa"
$ bitcoind getrawtransaction a93a668d9332e21d51380c7251bbf5ad47295ca9795e0ad6f2fe8d63b76af9aa 1
// json of transaction - note that "1" at the end tells bitcoind to decode into json
See this for more.
getrawtransaction <txid> command gets any transaction even from Bitcoin-qt client
Raw Transactions
The "raw transaction API" was introduced with Bitcoin-Qt/bitcoind version 0.7. It gives developers or very sophisticated end-users low-level access to transaction creation and broadcast.
This will return hexadecimal string of bytes, which is not very useful. But if you type
getrawtransaction <txid> 1
you'll get nicely formatted JSON representation
znort987's blockparser program looks promising. i haven't had a chance to play with it yet so i'm not sure if it has native support for specifying an individual transaction to inspect, but the doco says that if you know the receiving address then you can get all transaction details for that address like so:
./parser transactions the_receiving_address
As the error said, you are trying to see a transaction which is not part of your wallet. Bitcoind only allows you to explore transactions that are related to your wallet.
If you want to explore "foreign" transactions, you should use other tools like http://blockexplorer.com/
Related
We are trying to replicate data from AlloyDB to Bigquery using Datastream.
We Get "An unknown error occurred. Please try again. If the error persists, contact Google support."
In the Datastream console --> objects list, we see all source tables with Object Status "Failed" and Backfill status "Completed".
In Bigquery we see only a subset of the tables (not all the "Completed" objects were synced).
In the Logs Explorer I can see this error on BQ:
I also see this error: error: {
code: 11
message: "Unsupported primary key column either does not exist or is a pseudocolumn at [1:401]"
}
The column referred in the error is of type enum.
The desired situation is having all the AlloyDB tables replicated into Bigquery.
The error message is not very informative...
What does it mean?
What would be the best way to go about troubleshooting this?
We're actively working on making these error messages be more informative, and improvements are continuously being rolled out as we identify more edge cases. Assuming you followed all the steps in the documentation, then you may need to open a ticket with support for further investigation. If a support ticket isn't an option, you can still report the issue using the public issue tracker
I just had this same issue but connecting to a PostgreSQL in AWS RDS:
Beginning with Postgres 10, passwords are encrypted using SCRAM-SHA-256 in PostgreSQL. Google DataStream still expects MD5 password encryption, or it will generate an "unknown error" in the logs and fail the backfills.
You'll need to update your postgresql.conf (or RDS Cluster Parameter Group if you're using AWS like me):
password_encryption = 'MD5'
Restart the database and make sure the parameter has changed with:
SHOW password_encryption;
Reset the password of your users:
ALTER USER "{username}" with password '{password}';
More info from the PostgreSQL docs: https://www.postgresql.org/docs/current/auth-password.html
What's the best way to get the revert reason for a historical failed transaction using Web3.py and an Erigon archive node? The method shown in a recent article doesn't seem to work reliably.
So for example transaction 0x2b6e98bbecaf182c47ab21db7d379e216c3431c8e4ef5d13d9f6e390f1cc6e89 on Etherscan failed with reason "Fail with error 'Transaction too old'". But when I try replaying the transaction myself, I get the following:
{'code': -32000, 'message': 'insufficient funds for gas * price + value: address 0x3Ebf59161F2e3344d22FA9aE19aBE087AC11c6C1 have 4799611000000000 want 767628934000000000'}
It looks like perhaps it's replaying the transaction against the current state rather than the correct block height (12955068). I've tried supplying the correct block height both as a positional parameter (as in the example given in the article) and by using block_identifier as a keyword argument, but I get the same result. What's going on here?
I've got problem with printing transactions received on address.
On my machine I've got full sync node
but still cannot get transactions on address. Command which I use:
bitcoin-cli getreceivedbyaddress ADDRESS
Result:
error code: -4
error message:
Address not found in wallet
Is there anything more that I should do?
getreceivedbyaddress is a wallet RPC query. It queries your own wallet.
Bitcoind does not maintain a full per-address index of the blockchain.
To query any address you should use importaddress RPC call
importaddress "address" ( "label" rescan p2sh ) Adds an address or
script (in hex) that can be watched as if it were in your wallet but
cannot be used to spend. Requires a new wallet backup.
rescan is on by default and rescanning can take some time.
If it’s impossible to get public address from bitcoin address. How can a full node performing the transaction verify that the transaction is coming from authorised user.
The core of bitcoin is he language, Bitcoin Script, this is a language not Turing complete because is without loop.
The node bitcoin doesn't need the public key for spending the bitcoin, but a transaction input have an unlocked script (known as ScriptSig) this transaction can unlock a previous output transaction with have a locked script(Know as Script pubkey), for unlocked the node executed in the stack the ScriptSig + ScrptPubKey, if return true the transaction is spendable otherwise no.
an example
if you have two transaction
Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501
Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG
How bitcoin execute the script
Complete script
304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10 OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG
if you push the script inside this ide and run it you can see how bitcoin run the script.
In this example the ide returned false because the transaction output cannot be sent with her input
The ScriptPubKey(most of the time) contains the pubKey
The ScriptSing contains the Signature of the private key
This are all informations for work the simple node bitcoin.
Now I have and question for you.
You say
impossible to get public address from bitcoin address.
what does it mean?
I am trying to understand, how pipe lining in redis works? According to one blog I read, For this code
Pipeline pipeline = jedis.pipelined();
long start = System.currentTimeMillis();
for (int i = 0; i < 100000; i++) {
pipeline.set("" + i, "" + i);
}
List<Object> results = pipeline.execute();
Every call to pipeline.set() effectively sends the SET command to Redis (you can easily see this by setting a breakpoint inside the loop and querying Redis with redis-cli). The call to pipeline.execute() is when the reading of all the pending responses happens.
So basically, when we use pipe-lining, when we execute any command like set above, the command gets executed on the server but we don't collect the response until we executed, pipeline.execute().
However, according to the documentation of pyredis,
Pipelines are a subclass of the base Redis class that provide support for buffering multiple commands to the server in a single request.
I think, this implies that, we use pipelining, all the commands are buffered and are sent to the server, when we execute pipe.execute(), so this behaviour is different from the behaviour described above.
Could someone please tell me what is the right behaviour when using pyreids?
This is not just a redis-py thing. In Redis, pipelining always means buffering a set of commands and then sending them to the server all at once. The main point of pipelining is to avoid extraneous network back-and-forths-- frequently the bottleneck when running commands against Redis. If each command were sent to Redis before the pipeline was run, this would not be the case.
You can test this in practice. Open up python and:
import redis
r = redis.Redis()
p = r.pipeline()
p.set('blah', 'foo') # this buffers the command. it is not yet run.
r.get('blah') # pipeline hasn't been run, so this returns nothing.
p.execute()
r.get('blah') # now that we've run the pipeline, this returns "foo".
I did run the test that you described from the blog, and I could not reproduce the behaviour.
Setting breakpoints in the for loop, and running
redis-cli info | grep keys
does not show the size increasing after every set command.
Speaking of which, the code you pasted seems to be Java using Jedis (which I also used).
And in the test I ran, and according to the documentation, there is no method execute() in jedis but an exec() and sync() one.
I did see the values being set in redis after the sync() command.
Besides, this question seems to go with the pyredis documentation.
Finally, the redis documentation itself focuses on networking optimization (Quoting the example)
This time we are not paying the cost of RTT for every call, but just one time for the three commands.
P.S. Could you get the link to the blog you read?