rescanning is what the final argument of importaddress is for:


if you look at my first post you will see i used the linux "time" command - it took 41 minutes and 59 seconds to import this watch-only address and still failed.

i just read an article by mike hearn (https://medium.com/@octskyward/the-resolution-of-the-bitcoin-experiment-dabb30201f7#.vdzy3oei0) where he says that miners in china don't want the block size to grow because they cannot get the transactions into china fast enough to build blocks to mine:


and then later


this "problem" seems to have a very simple solution to me, and i haven't seen anybody else talk about it, so i thought i'd share it here. basically the transactions should be assembled outsize of the great firewall of china - somewhere with fast internet - then only the block header need be transmitted into china for mining. infact the block header need only be transmitted once per mined block, and the 32 byte merkle root can be updated and transmitted more frequently to the miners in china as new transactions are added to the block (prior to the mining operation being completed of course).

then, once the miner discovers the nonce that mines the block they can transmit this back out and broadcast the block to the network. transmitting 32 bytes past the great firewall has to be easy. and of course it never changes regardless of block size.

has anybody else considered this already? is there any reason this is not already happening?

should i submit a bug report? i wish my knowledge of c++ was better - i could investigate by actually stepping through the code

i just want to see transaction hashes for account "1GkktBuJ6Pr51WEJe5ZzyNvMYaMDFjwyDk". but like i said at the start, its not working:

right, but it still doesn't show me the transactions for that watch-only address:


ie the output is blank. i'm fairly certain it is watching this address though:

have you tried running this? when i run it i get the following:

i know that - that's why i made an account with the name of an address:


i could just as well have done:


and it would be the same. also note that the results of listaddressgroupings confirm this:

i'm having no luck getting bitcoin-cli listtransactions to work for a watch-only address:


its only producing an empty list, but blockchain.info shows 6 transactions for this address. is it broken or am i doing something wrong?

That makes sense. I guess allowing OP_CHECKLOCKTIMEVERIFY to be bypassed by the signer using sequence=maxint would make OP_CHECKLOCKTIMEVERIFY no more useful than the locktime field that already exists in the transaction, so I can see why its set up that way. Its just not at all obvious from the comments that this is the intended functionality.

I think I understand why only the sequence number for the txin containing OP_CHECKLOCKTIMEVERIFY is tested, but it does have weird implications when considered in combination with IsFinalTx(). Like a transaction could be "not final" (other txin sequence nums < maxint, and a locktime in the future), yet this script would still validate so long as this txin sequence = maxint. I can't think of any circumstances where that would be a problem, since the transaction would not make it into the blockchain due to failing the IsFinalTx() constraint, but still... the logic is weird.

from src/interpreter.cpp - I'm seeking clarification on why OP_CHECKLOCKTIMEVERIFY will fail if the current txin sequence number is set to maxint. The code comments say it will be "bypassed", but it is my understanding that if the script fails to validate with SCRIPT_ERR_UNSATISFIED_LOCKTIME then the transaction will not go into the mempool, and thus will not be selected for mining into a block.


For starters I don't understand why only the current txin is tested. And secondly, I would have thought that if all txin sequence numbers were set to maxint then it should return true, not false. Maybe the if statement has a bug and should be negated there?

Can someone explain this code to me please.

exactly what i wanted to know! thanks a million

that explains a lot! are there any checks at all though? for example what if i literally did OP_PUSHDATA0(10 bytes) <abab> - ie only providing 2 bytes to push, even though i claim to be pushing 10 bytes. would that still make its way into the live blockchain?

right you are (again). updated...

one more thing - doesn't this 1443 byte stack element violate the MAX_SCRIPT_ELEMENT_SIZE criteria? shouldn't this mean that the script would fail and so should not be included in the blockchain?

you're right, my bad. its been a while since i looked at the raw bytes for this script - i was investigating the mysterious contents i got confused and thought that the output on blockexplorer.com was complete (forgetting they don't show the pushdata's)

for my own satisfaction and for anybody else reading this: the start of the script in hex is:

63ff054effffffff4da30546726f6d...

decoding:

0x63 = OP_IF
0xff = OP_INVALIDOPCODE
0x05 = OP_PUSHDATA0 (5 bytes)
push <4effffffff> onto the stack
0x4d = OP_PUSHDATA2 (use the next 2 bytes little endian to determine how many bytes to push onto the stack)
0xa305 = push 0x05a3 (=1443) bytes onto the stack
push <46726f6d...> onto the stack

i have found a transaction in the live blockchain (http://blockexplorer.com/tx/77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69) which claims to push 0xffffffff bytes onto the stack, but infact only pushes 1443 bytes. the relevant txout script is:

OP_IF OP_INVALIDOPCODE 4effffffff 46726f6d20...2e340a0a OP_ENDIF

could someone explain how fewer than 0xffffffff bytes are pushed here? i actually don't even understand how the parser can identify the OP_ENDIF at all - it should see that as part of the 0xfffffff bytes i would have thought.

links to the satoshi source code are welcome but i don't understand much c++ so i might need a walkthrough.

domob, your discussion in the namecoin forum is very similar to this thread. i can see deciding where to put the root-hash of this bitcoin address-lookup thing, even if people think it is a good/efficient way of solving the spv problem, is going to be a task in and of itself.

as you say, each miner/pool-manager will have to have a full bitcoin node, or at the very least a steady flow of the latest bitcoin blocks built on top of an existing address book from some point in the past - just to be able to keep the address book up to date.

my original thinking for suggesting namecoin was that namecoin is intended as a distributed database, whereas bitcoin is more associated with currency. i was also thinking that getting changes made to bitcoin will be slower, and namecoin is maybe easier? however the proposal would mean that namecoin miners would have to run a bitcoin full node as part of their protocol, and it this would both require a lot more resources for namecoin miners, as well as breaking the "separation of concerns" between bitcoin and namecoin (although merged mining has already done that to some degree).

so maybe it would be best to keep the address book entirely on the bitcoin side of things.

this leaves the tx scripts (probably the coinbase txin) and the block header for storing the root-hash of the address book. the coinbase txin seems like a far better candidate, since it would not require changes to the bitcoin protocol. but i also realize that this is valuable space and there are a potentially infinite number of things people might want to store in the coinbase txin.

yeah that's very similar - albeit a bit more generic (which is probably a good thing).

as an aside, i also noticed that bip33 proposes a method to "discover the history of a bitcoin address without needing direct access to the blockchain", but it still relies on some degree of trust. if the client can be cut off from all reliable nodes then it really makes no difference what percentage of the contacted nodes are in agreement - agreement among malicious nodes offers no security. i know such a thing would be hard to pull off, but when the stakes are high the likelihood increases. for example if an isp were to simply block off access to ip addresses of trustworthy full-nodes, and only allow access to malicious nodes. or to redirect requests aimed at trustworthy nodes all to a single malicious node, the client could be fooled into thinking it had never received certain funds.

hi all, i'm new here and i'm not sure if i'm posting in the right place. feel free to move this post to somewhere appropriate.

i was thinking it would be nice to have a trustless way of looking up address balances without having to download the entire blockchain. i read in bip37 that there is a problem where a malicious remote node can omit transactions and there is no way for the thin client to know this has happened:


currently i'm not aware if this problem has been solved. i have googled for it and found nothing, so for the remainder of this post i will assume not...

one way around this might be to look up the address on blockchain.info or blockexplorer.com and verify that one's balance is correct, and therefore that no transactions are missing in the client. however this is not practical for a large e-commerce website which generates a lot of addresses automatically. i guess api calls can be used but still... i dislike the idea of trusting a third party when money is at stake.

and you could say that an e-commerce website should be downloading a full version of the blockchain - that would solve the problem. yet somehow it seems a bit of a wasteful requirement to me - particularly if other options are available.

i had an idea and i thought i'd see what people think of it. firstly, security is paramount, so it is vital that blanaces be validated by the client using the blockchain and not by some "trusted" third party. so i think that if a thin client wants to establish its balance, it should download the relevant transactions, pruned merkle tree for the block, and all block headers. i think this is already how all thin clients work - so no problems there.

but the problem lies in determining which transactions and pruned merkle trees to download - and specifically in ensuring that a full list of this data is provided. so my thinking was that an address book could be constructed using a merkle tree of addresses and their corrsponding lookup data, and then the root of that address book tree could be included in the blockchain somewhere - say the coinbase txin,  elsewhere in the bitcoin header, or even in a merge-mined blockchain like namecoin (this would avoid changes to the bitcoin protocol and clients could easily download all namecoin headers in addition to bitcoin headers as these are small). since this last option - using the namecoin blockchain - is the most likely solution of those 3, i will assume it for the remainder of this post.

full namecoin nodes would be able to verify this "address book merkle root" by reconstructing it for themselves, and maybe it could even be part of the namecoin protocol to reject blocks which contained incorrect "bitcoin address book merkle roots". the precise details of this address book are unknown to me, but a simplified example would look like this:


this way whenever a thin client wanted to download transactions for a specific address it could do a request to the address book (contained on many namecoin full nodes i envisage) to retrieve the specific blocks where its transactions are, then request the specified blocks the regular way through the network. really only specific txs in that block are required, but for simplicity's sake lets assume its the whole block at this stage.

namecoin miners could calculate the merkle root of all addresses by appending the latest bitcoin block's addresses into the merkle tree and keeping as many address branches pruned as possible from the previous instance of the database to reduce hashing (since the list of bitcoin addresses is huge).

and to ensure that remote nodes are not lying by omission when the thin clients request their address list, the minimal verification branches of the address merkle tree could be supplied to the thin client so that it can calculate the address-merkle-root by itself and compare it to the value in the block header.

friendly comments welcome. maybe this problem has already been solved in some other way that i'm not aware of, and the above is an inferior solution? let me know...

i think i have come up with a way to prevent dos attacks on a fawkescoin network. the private key in the txout being spent must consist of two components which are then hashed separately and concatenated. then one of these can be revealed when broadcasting the transaction hash to the network, while keeping the other secret for the transaction validation after the safe number of blocks.

so the new steps are:

1) i generate some private keys (just large random alphanumeric strings)
2) each address is derived from two private keys, like so: addr = base58(hash(pk1) + hash(pk2)) where "+" is just concatenation.
3) i create a transaction string (tx1) which has:
- input scripts consisting of private keys (pk1 only) which evaluates to the first half of the previous transaction's output addresses
- hashes and indexes for each txin to locate the previous txouts
- output elements containing bitcoin values and recipient addresses
4) i hash tx1 to get tx1hash. now create tx2 = tx1. replace all private keys (pk1) in the input scripts of tx2 with pk2, place tx1hash at some known location in tx2 - probably using opcodes to specify it within the first input script.
5) i broadcast tx2 to the network. miners confirm that it is valid because the now fully visible private keys (pk2) in the input scripts of this transaction each reveal half of every output address in the specified txouts from past transactions. so this transaction gets added to the blockchain.
6) i wait for a safe number of blocks to be confirmed on top of tx2 then broadcast tx1 with the private keys (pk1) fully visible to all.
7) miners confirm that the hash of tx1 indeed evaluates to the input script of the first input of tx2 and so they include tx1 in the blockchain aswell
as per standard bitcoin procedure, the recipient(s) of the funds from this transaction should wait a safe number of blocks before spending to ensure their received funds exist on the main blockchain