 Show Posts
|
|
Pages: [1]
|
|
Thanks for the explanation. Very clear.
It's going to be interesting to see how many of these "not to address" txs there are in the blockchain. I knew about multisig addresses before but not this anyone can spend and nobody can spend, and there seems to be a few more when looking at the core cpp code.
|
|
|
|
What happened to the tx input in this transaction? The output says "nulldata". What does that mean? C:\Program Files\Bitcoin\daemon>bitcoin-cli.exe getrawtransaction db3cc99eb91533
bf0973b62c572589925df8e1f1501678d54034261b5a4ccfbf 1
{
"hex" : "010000000151693cb178b2d7396532865aaa35d054be0db6aaf2ca3b5adbf90bcf7
28eaabb3a0000008a47304402202b0c035d0075adae560688dae0fcf78142e96bcaf9fafd510940c
76c5629936d0220037e006368f3fc09af40f862df4bcc10cf0f239a40364cffcd1fabb0904f5f830
14104bd184b34e4e20698a7670854e16f68c4ca2f9326572342998bdf1b1c4685644c2374e40c19c
a20eeb3439e3255d468d3e92aa32f577df99bdb409c8f064462f7ffffffff0100000000000000002
a6a28444f4350524f4f46f303df84d32e8c5c3433a807d4b6da36f782bc4e03c6cf41a907ea2193a
0e16b00000000",
"txid" : "db3cc99eb91533bf0973b62c572589925df8e1f1501678d54034261b5a4ccfbf",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "bbaa8e72cf0bf9db5a3bcaf2aab60dbe54d035aa5a86326539d7b278b1
3c6951",
"vout" : 58,
"scriptSig" : {
"asm" : "304402202b0c035d0075adae560688dae0fcf78142e96bcaf9fafd5
10940c76c5629936d0220037e006368f3fc09af40f862df4bcc10cf0f239a40364cffcd1fabb0904
f5f8301 04bd184b34e4e20698a7670854e16f68c4ca2f9326572342998bdf1b1c4685644c2374e4
0c19ca20eeb3439e3255d468d3e92aa32f577df99bdb409c8f064462f7",
"hex" : "47304402202b0c035d0075adae560688dae0fcf78142e96bcaf9faf
d510940c76c5629936d0220037e006368f3fc09af40f862df4bcc10cf0f239a40364cffcd1fabb09
04f5f83014104bd184b34e4e20698a7670854e16f68c4ca2f9326572342998bdf1b1c4685644c237
4e40c19ca20eeb3439e3255d468d3e92aa32f577df99bdb409c8f064462f7"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_RETURN 444f4350524f4f46f303df84d32e8c5c3433a807d4b6d
a36f782bc4e03c6cf41a907ea2193a0e16b",
"hex" : "6a28444f4350524f4f46f303df84d32e8c5c3433a807d4b6da36f78
2bc4e03c6cf41a907ea2193a0e16b",
"type" : "nulldata"
}
}
],
"blockhash" : "0000000000000000000119f88871f8a3c3b7be053c98b31e9c4676df30243
cfe",
"confirmations" : 7913,
"time" : 1418331464,
"blocktime" : 1418331464
}
Blockchain.info also has trouble showing this transaction. I.e. it doesn't have an output address? https://blockchain.info/tx/db3cc99eb91533bf0973b62c572589925df8e1f1501678d54034261b5a4ccfbf?show_adv=trueThere is btc input, but there doesn't seem to be any output address. How does that work? |
|
|
|
Consider that a transaction that exists only in orphaned blocks, but not in the main chain, is an unconfirmed transaction. If it never makes its' way into the main chain, it 'didn't happen', as far as the canonical state is concerned.
This is a nice explanation. Thanks. |
|
|
|
Nope. A transaction from an orphaned block usually gets rebroadcasted by the client or directly included in the competing block by the other miner.
Oooooh. This puts things in a new perspective. It makes orphans much less important than I thought. Their transactions will (well, there's no guarantee but mostly) end up in other blocks. Now the rpc api makes more sense. Thanks. |
|
|
|
I'm trying to iterate over all blocks, incl orphans, via the rpc api. First, these are my assumptions. Please tell if these are correct: - Orphaned blocks are valid blocks.
- Orphaned blocks contains valid transactions.
- The transactions in an orphaned blocks can only be found in that orphaned block.
In order to iterate over all blocks in the longest chain you could use these commands: getblockcount
getblockhash <index>
getblock <hash> But what about all the orphans? They are not part of the longest chain, right? You can get any block if you know the hash with "getblock". But how do you discover the hash of the orphans in the first place? Is there a way to discover the orphans via rpc? |
|
|
|
|
It seems that blocks are written to disk in the WriteBlockToDisk function in main.cpp. But I haven't found where they are deleted. Maybe they don't ever get deleted from disk? Once written they are always valid?
|
|
|
|
|
Interesting. How to you set those verification levels?
|
|
|
|
I only connect to a known host so I trust everything that comes from it. What can I remove in order to speed up the initial sync with the blockchain? I have already commented out a few things in CheckBlock (main.cpp). My version looks like this now: bool CheckBlock(const CBlock& block, CValidationState& state, bool fCheckPOW, bool fCheckMerkleRoot)
{
// These are checks that are independent of context
// that can be verified before saving an orphan block.
/*
// Size limits
if (block.vtx.empty() || block.vtx.size() > MAX_BLOCK_SIZE || ::GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION) > MAX_BLOCK_SIZE)
return state.DoS(100, error("CheckBlock() : size limits failed"),
REJECT_INVALID, "bad-blk-length");
// Check proof of work matches claimed amount
if (fCheckPOW && !CheckProofOfWork(block.GetHash(), block.nBits))
return state.DoS(50, error("CheckBlock() : proof of work failed"),
REJECT_INVALID, "high-hash");
*/
// Check timestamp
if (block.GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return state.Invalid(error("CheckBlock() : block timestamp too far in the future"),
REJECT_INVALID, "time-too-new");
/*
// First transaction must be coinbase, the rest must not be
if (block.vtx.empty() || !block.vtx[0].IsCoinBase())
return state.DoS(100, error("CheckBlock() : first tx is not coinbase"),
REJECT_INVALID, "bad-cb-missing");
for (unsigned int i = 1; i < block.vtx.size(); i++)
if (block.vtx[i].IsCoinBase())
return state.DoS(100, error("CheckBlock() : more than one coinbase"),
REJECT_INVALID, "bad-cb-multiple");
*/
/*
// Check transactions
BOOST_FOREACH(const CTransaction& tx, block.vtx)
if (!CheckTransaction(tx, state))
return error("CheckBlock() : CheckTransaction failed");
*/
// Build the merkle tree already. We need it anyway later, and it makes the
// block cache the transaction hashes, which means they don't need to be
// recalculated many times during this block's validation.
block.BuildMerkleTree();
// Check for duplicate txids. This is caught by ConnectInputs(),
// but catching it earlier avoids a potential DoS attack:
set<uint256> uniqueTx;
for (unsigned int i = 0; i < block.vtx.size(); i++) {
uniqueTx.insert(block.GetTxHash(i));
}
if (uniqueTx.size() != block.vtx.size())
return state.DoS(100, error("CheckBlock() : duplicate transaction"),
REJECT_INVALID, "bad-txns-duplicate", true);
/*
unsigned int nSigOps = 0;
BOOST_FOREACH(const CTransaction& tx, block.vtx)
{
nSigOps += GetLegacySigOpCount(tx);
}
if (nSigOps > MAX_BLOCK_SIGOPS)
return state.DoS(100, error("CheckBlock() : out-of-bounds SigOpCount"),
REJECT_INVALID, "bad-blk-sigops", true);
// Check merkle root
if (fCheckMerkleRoot && block.hashMerkleRoot != block.vMerkleTree.back())
return state.DoS(100, error("CheckBlock() : hashMerkleRoot mismatch"),
REJECT_INVALID, "bad-txnmrklroot", true);
*/
return true;
} What other changes can I do to speed it up? |
|
|
|
|
I have set up Abe and it's now indexing all the transactions into a PostgreSQL database. Would it be easy to query the database for e.g. the top 10 largest unspent outputs?
I know SQL but I don't know the details of the Abe schema yet, that's where I'm looking for some guidance.
|
|
|
|
|
