Please post the output from: And let's verify if you have the core version 0.16.2 As requested: 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. |
|
|
|
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: 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? |
|
|
|
I ran into a transaction which I can't decode properly using bitcoin-cli decoderawtransaction: 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. |
|
|
|
It returned this, I'm not entirely sure why 1
2
5KfbGQiriNxxwMKgdpwmu5ZsYyXBuBaCg7es9z5xznAnCEHzy51: True
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
Looking at the code: it uses an invalid wif(5KgbGQiriNxxwMKgdpwmu5ZsYyXBuBaCg7es9z5xznAnCEHzy51) and then replaces a character with every possible value. So every time this leads to a different wif to check. The result you see counting from 1..50 is the position where it tries the different possible values. A success was found by replacing the third character from a "g" to "f" leading to a valid wif. Incorrect wif at start: 5K gbGQiriNxxwMKgdpwmu5ZsYyXBuBaCg7es9z5xznAnCEHzy51 Corrected to: 5K fbGQiriNxxwMKgdpwmu5ZsYyXBuBaCg7es9z5xznAnCEHzy51 All the other substitutions didn't lead to a valid wif, that's why you see the counter go up to 50 without any other success messages. Disclaimer: I'm not the author of the code just explaining the code  |
|
|
|
I suppose, op is asking about a hypothetical improvement and not the current bitcoin. And my answer is yes!
I think it is totally possible to have a data structure with parallel blocks allowed the only restriction I can imagine is for the blocks not to have competing transactions (different transactions trying to spend same outpoints) or to share a same transaction.
In my opinion parallel means for instance two blocks get added at the same time so neither of these blocks know of the existence of the other. So how exactly would you prevent competing transactions between those two blocks if there is no knowledge about the other block? As soon as a single competing transaction is in these blocks the whole chain gets corrupted. |
|
|
|
At the original block reward you got 7200 coins a day.
In the beginning the average time for finding a block was over 10 minutes. Since the difficulty was it 1 it couldn't be dialed back. Your calculation of early April is about 6 weeks off since block 14400 (6*24*100) was mined on May 14 2009. But I agree it's still a lot of coins |
|
|
|
Each party application sends a signed message and public key to the network to initiate the process.
So in your example Party A has the Private key for address A And in your example Party B has the Private key for address B Party “A” receives the private key to party “B”s wallet from the network.
Party “B” receives the private key to party “A”s wallet from the network.
So in your example Party A has the Private key for address A and B now also knows the Private Key for address A And in your example Party B has the Private key for address B and A now also knows the Private Key for address B Sharing Private Keys seems like a bad choice! Party A still has control over address A after it has been "handed over" to B so A could just clear the address after a successful wallet swap. |
|
|
|
this bastard wanna steal my idea right now
Calling people bastards, morons, ignoring review comments and on top of all think you are entitled to donations because of this simple idea you had doesn't really help your case! |
|
|
|
If you want to play around with this using Python you can check: https://github.com/mcdallas/cryptotoolsExample: >>> from ECDSA.secp256k1 import CURVE, PrivateKey
>>> private = PrivateKey.random()
>>> private.int()
8034465994996476238286561766373949549982328752707977290709076444881813294372
>>> public = private.to_public()
>>> public
PublicKey(102868560361119050321154887315228169307787313299675114268359376451780341556078, 83001804479408277471207716276761041184203185393579361784723900699449806360826)
>>> public.point in CURVE
True
>>> public.to_address('P2WPKH')
'bc1qh2egksgfejqpktc3kkdtuqqrukrpzzp9lr0phn'
|
|
|
|
Do any of you guys use Python, and what do you think of it?
I do. I personally like that a lot of things are intuitive in Python. There's also a ton of libraries available so a lot of times you can use one of them and don't have to reinvent the wheel Keep in mind Python is a scripting language which means you won't have to compile your code before it can run. This also means when you are looking for cutting-edge performance it might not be the best choice. So it all depends on what you want to accomplish with your upcoming projects if Python is a viable option. |
|
|
|
Funny to see the address "1s2iywx94HudryMHsU2g1K9x8DB1cahGc" pop up here. I had it already flagged since my block parser choked on the coinbase transaction where this address is used. These two transactions were the only cases where I saw the OP_RETURN in the output before the actual payout. So I already figured this was some custom made script for the coinbase transaction. A message in the coinbase refers to "MiningCore". Reading the entire topic: this seems to be an expensive mistake! OP: Were you using this: https://github.com/coinfoundry/miningcore ? |
|
|
|
I still think #1 is correct, the function will return true if the hash is lower than or equal to the target  We came to the same conclusion I mixed up by claiming #2 was right while delivering proof #1 was right (just as you did). I edited my post to match the right number. End conclusion: We agree #1 is the correct one. We even both delivered examples as proof |
|
|
|
If the hash is bigger than the target, return false.. So if the hash is smaller than OR EQUAL TO the target, true is returned... #1 is correct (if i'm not mistaking)
Let's break this down to a simple example: Target = 10
Scenario A: Check value 9
Scenario B: Check value 10
Scenario C: Check value 11
Code:
return = true;
#Scenario A:
if (9 > 10 )
return false;
#Scenario A: returns ->true
#Scenario B:
if (10 > 10 )
return false;
#Scenario B: returns -> true
#Scenario C:
if (11 > 10)
return false;
#Scenario C: returns -> false
Conclusion: EQAUL TO (as in scenario B) returns true, meaning it is accepted. In other words: #1 is the correct one. |
|
|
|
bool CheckProofOfWork(uint256 hash, unsigned int nBits, const Consensus::Params& params)
{
bool fNegative;
bool fOverflow;
arith_uint256 bnTarget;
bnTarget.SetCompact(nBits, &fNegative, &fOverflow);
// Check range
if (fNegative || bnTarget == 0 || fOverflow || bnTarget > UintToArith256(params.powLimit))
return false;
// Check proof of work matches claimed amount
if (UintToArith256(hash) > bnTarget)
return false;
return true;
}
Code doesn't lie So I agree it should be #1 then. Another case where the (official) documentation doesn't project the reality then! Anyhow, learned something again |
|
|
|
The second one is correct. Each block header must hash to a value below the target threshold. For more in-depth documentation you can check the developers guide on proof of work here: https://bitcoin.org/en/developer-guide#proof-of-workUpdate: see below for proof my linked documentation does not match the reality. #1 is correct. |
|
|
|
"txid": "c7da009b85f48502023e5be467bef367092ed7d3ce25ce0b3b13f9a4945d932a",
"hash": "7f8e80ea576384721538ead7ef47a3e6004171dbfb3b8e29cf191c39be5b8e51", another thing that I notice on a segwit transaction is its txid differs from its (tx)hash @TheArchaeologist you've done the "blockhash as private key" experiment on the other thread while you're compiling data on segwit vs non-segwit txs in all blocks, you should also do "private key" experiment on segwit txhashes too  segwit tx has 2 possible hex numbers (txid and hash) that can be used as private keys Good idea. I will add it to my list of things-to-do. I'm currently working on adding extra data to my database so it might be a while when I get to this. I will update in the other thread when I performed the experiment. |
|
|
|
In that case, start from block cluster ( blk.dat files) blk00971.dat onwards. Check for the dates, since SegWit was started on August 24, 2017, you might save some time by skipping the older blocks. Thanks, I'm aware of when Segwit activated I already marked all transactions from blocks prior to 481,824 being "Non segwit". |
|
|
|
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.
Thanks for your input! Good to know I didn't make a false assumption. BTW: I will use this to check the number transactions containing Segwit data vs number of transactions without Segwit data in a block. |
|
|
|
|
Show Posts
