|
Actually, there are two command line switches -blocknotify and -walletnotify which will call a command when a block is found and when transactions arrive.
Honestly, I would avoid using listsinceblock, it doesn't behave as you'd expect and it'll come back to bite you.
|
|
|
|
Where is that pool? Disk? Not RAM I suppose...
LevelDB (it's what the chainstate directory is for). It's partially cached in RAM though. |
|
|
|
There is a pool of unspent outputs.
a pool of ALL unspent outputs ? Yes, you can see its size with the command 'gettxoutsetinfo'. Yeah. ALL unspent outputs. I'm not sure how to query it.
You don't, at least not without modifying the client to add a new RPC command. |
|
|
|
Satoshi-dice is based on BitcoinJ. One of the example projects is called PingService which listens for incoming transactions and then sends them back where they came which is pretty much the entire functionality of Satoshi-dice. |
|
|
|
|
There was no fee, so you're only chance is to get in by priority. You tried to spend an output which was only 2 days old and only 1BTC. Priority is calculated as age*amount, so there's going to be lots more transactions with higher priority which come before yours. So your only chance is to get lucky where a couple of quick blocks in a row flush out all the waiting transactions, or you have to wait for your inputs to get older so your priority increases sufficiently.
|
|
|
|
You could view source and copy the javascript data. series: [{
name: 'MB',
data: [[1231006505000, 2.71E-4],[1231092905000, 0.0],[1231179305000, 0.0], ... ],
showInLegend: false
}]
The data is averaged over the day though, so maybe you need more detail. |
|
|
|
about 200 transactions, each transaction has no tx and is signed by the last transaction, will Alice have to wait for a long period to receive the funds? Can Alice speed it up?
 I believe he meant "no transfer fee". Ahh - not sure why I couldn't work that out myself! Anyway, the answers are that it will indeed take a long time to receive the funds (you're extremely unlikely to get more than one transaction into each block at a time), and currently the way the transactions are selected into a block in the reference client means there is no way to speed it up if miners are running unmodified clients. This thread is relevant. Someone is doing the exact thing you describe. |
|
|
|
about 200 transactions, each transaction has no tx and is signed by the last transaction, will Alice have to wait for a long period to receive the funds? Can Alice speed it up?
|
|
|
|
|
Your transaction is large and your inputs are young and small, so the transaction has very low priority, so it's unlikely to get selected for the free part of the block. And your fee/kB is also tiny, so it won't get selected based on that either.
|
|
|
|
Well thats a HUGE issue, if the change generated by your tx is going to get flagged as dust and thus your tx will never confirm.
How could no one have thought of or picked up on that!?
This will only be a problem if the mining pools all switch to 0.8.2 and you use a client version (< 0.8.2) which generates dust change outputs. |
|
|
|
|
Sorry, talking crap - had it in my head that the new dust checks were already included in 0.8.1, so most nodes would reject the tx.
|
|
|
|
|
Your second output is considered 'dust', so your transaction won't get relayed.
|
|
|
|
Looking at multiple sites that exchange Bitcoin, I noticed that a number of them offer a way to deposit Bitcoin in your account by sending it to some personalized Bitcoin address.
The method in which these are generated makes me think that there must be one or more such addresses for each account.
Are there any estimates as to how many accounts on these sites need to be created to consume any appreciable portion of the total number of addresses available?
2 160 possible address hashes, 2 32 people on the planet. So each person could have 2 128 addresses each. That's 100,000,000,000,000,000,000,000,000,000,000,000,000 addresses each. So even if you sign up to 1000's of these sites, you'll never make a dent. |
|
|
|
Again: this wastes a hell lot of bandwidth, generating lots of traffic in the network each time a new block is mined.
No. That's not how it works. I believe that I understand the purpose of the locators very well - and that is why my implementation always sends only one locator
If you do this after the last checkpoint, you're in for a surprise. Good luck. |
|
|
|
Actually, if you look at this article it even clearly advises: To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop Yeah, you are only at block 236k+, so just keep pushing all the hashes, starting from the top, until you reach the genesis block - a brilliant idea  What's wrong with this? It sounds to me like you don't understand the purpose of the locators. |
|
|
|
|
Hang on - why are you trying to put the blockchain in a leveldb database?
|
|
|
|
|
Show Posts
