|
Is ? a valid means of passing arguments to PHP on the command line? I've never tried it. I always use argc/argv, but my quick google search suggests that you can also use CGI style arguments:
/path/to/php /path/to/script.php trxhash=%s
and trxhash will be populated in $_GET, etc.
|
|
|
|
With 120Gh -> 0-3 shares a day, one orphan means 30-50% off.
No, it really doesn't. Everyone on p2pool has orphans. That's the nature of a block chain with a 30 second target, and is unavoidable. The p2pool shares are just used to divide up the bitcoins (as with other pools). As long as your orphan rate isn't higher than others', you get your fair share of the bitcoins. Yes there is variance. You might get an orphan, which makes your earnings go down in the short run. But others are also constantly getting orphans, which makes your earnings go up. With a little patiences it balances out and ends up in your favor. If you want immediate gratification, yes go ahead look elsewhere. If you want better returns over time, stay with p2pool. Sounds like youre washed your brain with this, open your eyes. This topic is repeated every 10 pages or so. Please go back and read about it over and over and over and over again. You fail at math and reading. |
|
|
|
I was under the impression that pseudo shares are not included in the share chain, only shares with diff above the p2pool diff are included.
Another question. Let's pretend for a moment the p2pool share difficulty is at 10. A miner submits a share with difficulty 20 and the share goes into the share chain. During payout, is the value of the share capped to the share difficulty at the time of submission (10)?
I'm trying to build a proxy pool that'd would be able to payout to miners on a pseudo share basis (much less variance for miners at higher risk to pool operator). And perhaps have a vardiff system based on the pseudo shares. Has anything like this been attempted before?
Miners can intentionally pick a higher difficulty for themselves. These higher difficulty shares give a higher payout and free up space in the share window. This was discussed to death a few pages back. |
|
|
|
|
Rather than adding more steps and layers to the system, I propose ignoring the chance of the joiner operator skimming merges.
If it bothers anyone, they can send their donation to a new address in their own wallet, then send that to the donation address in the normal way. This operation could even be scripted. (Your wallet searches google for your payment address. If there are no results, it is more or less impossible for another coin join user to be sending to that address. If there are results for it outside of the explorer sites, it automatically switches into 2-stage mode.)
|
|
|
|
The validity of the working key can be confirmed in a single decryption step.
No Yes. The cypher is well known (always), the plaintext and the cyphertext have been published (unusual in cryptography, but necessary in this system). The key is the unknown. When found, it is trivial to verify that the key is valid (meaning that it really does decrypt the cyphertext into the plaintext). |
|
|
|
|
You could just use a 256 bit block cypher and use exactly the system described in the PDF. The validity of the working key can be confirmed in a single decryption step.
But a hashing system for proof of work needs more properties than just an asymmetry of solve/verify work. For one thing, the "difficulty" of that system must be set in advance, and while the validity of the solution is easy to verify, verification of the difficulty requires difficulty work to be done.
Also keep in mind that in a system like this, the fastest computer solves all of the puzzles, and everyone else solves none.
|
|
|
|
|
The satoshi is not a fundamental unit of bitcoin. It is just the current scaling factor used by the protocol, an accident of history.
The fundamental unit of bitcoin is 1 bitcoin.
|
|
|
|
|
There is no way to prove that you have forgotten the private key.
|
|
|
|
From another thread... Wow, thanks! but that is WAY over my head. I'd better go watch the Khan Academy videos. . .
People will come up with pretty tools to make it easier as we go. But for now, the guts are certainly here and do work. This really can be done by hand though, if you have an urgent need to do it. Decoding a transaction in hex by hand is pretty easy. Just follow the docs and remember that each byte is 2 chars, and that you are counting in hex (in my example below, the pkscript length 19 is in hex and means 16+9=25). And double check everything before you send anything.
01000000 - version
01 - vin count
2084ba9f2f0f98bb - prevout hash
1cf0320ee1c486b5
9b6b79e243de7596
d3e44fa087b597aa
01000000 - prevout index
00 - signature script length
ffffffff - sequence
01 - vout count
00e1f50500000000 - value
19 - pkscript length
76a91428f60d621b - pkscript
5d07b9c2820c11cc
c6d41146b53a3e88
ac
00000000 - locktime
A transaction is final when: the sequences are no longer incrementable or the locktime is in the past A transaction that is not final will not be accepted for relay. The brute force method of transaction replacement, which works with all software on all networks, is to not broadcast the transaction (sendrawtransaction) until it is ready. Most uses don't actually need any sort of replacement mechanism. |
|
|
|
|
First, you need some high quality pure sand...
|
|
|
|
What is the difference between "hoarding" and "saving?"
I thought saving was important.
Saving is something we are all suposed to do. If we don't do it then we get slapped. If we actually find a way to save it is called hoarding. If we hoard then we get slapped. Saving propably means save(?) in a Bank, where that capital is recycled in the economy. while hoarding means save under the mattress, or in a chest or in a hole in the ground, where that capital is retracted by the economy. Money is an abstraction of barter. You trade wealth you have for wealth you want, but the two halves of the trade don't have to happen at once, they can be spread across time and space, and with different people. If you are holding money (saving, hoarding, whatever you want to call it), it means that you have given wealth to the world to use, but have not claimed wealth back to complete your trade. The difference between saving and hoarding is the difference between understanding this and not understanding it. |
|
|
|
|
It has the disadvantage that anyone can spam the network by creating blocks from an easier point in the past.
|
|
|
|
|
You seem to have a peculiar amount of faith in the guesses that blockchain.info posts on their site. Go look up some of your own past transactions and see how well they do at figuring out which outputs are the value and which outputs are the change.
Go on. We'll wait for you.
|
|
|
|
Now on to your question:
Let's say I have a vigin block of 50 BTC that was mined in January of 2009.
At some point in January 2010 I sent 1 BTC to a buddy, sending the change to a new address
Now Yesterday I wanted to spend 95 BTC to buy a new Tesla S from a car dealer
The transaction is as follow:
49 BTC from the change from the 2010 transaction
25 BTC from a brand new freshly minted block
25 BTC from a block that was minted in 2013
Outputs:
95 BTC to the dealer for the car
4 BTC to a change address
Now you want to kill the BTC from from the Jany 2009 block. How would you do it?
Ok What would the effect be is suddendly everyone decided that the genesis block is one past the one of Jan 2009 you mined Just in case anyone has any remaining doubts about your complete and total lack of understanding of what bitcoin is and how it works, can you please post some more? With a moving genesis block, you have total chaos. New nodes would not sync to the rest of the network because they would quickly find transactions that refer to past transactions that no longer exist. They would see everything as invalid: transactions, blocks, everything. You can't, in general, undo the start of a linked list without throwing the whole thing out. Now if you kept the old chain, but decided that transactions that referenced it were merely invalid in the future, you end up with the situation that BurtW is trying to ask you about. That you can't see it is, uh, informative. Keep in mind that we do not trace transactions backwards. When a new transaction comes in (by message or by block), we validate it against our current set, and if we accept it, we update that set to reflect the new information. We could trace backwards, if there was some need, at a considerable cost. I look forward to hearing how you solve that problem in your VanishCoin alt. |
|
|
|
|
Grep is the index. The files have names, use those as your table of contents.
You can often use known text strings (rpc commands, log messages, errors, etc) to get into the right ballpark. From there, grep function names forward and backward to find what you are looking for. Be careful of namespaces when grepping.
|
|
|
|
Blockchain.info is connected to every major pool, so they will see much more than half of all orphans.
I can say with considerable confidence that you are not in possession of data supporting that claim. |
|
|
|
Does anyone know a web page which shows a live statistic of the number of orphans created in a day ?
Is there any paper that presents this information?
Have anyone computed the average orphan rate during last year and previous years?
Best regards,
Sergio.
There is not, and such a thing is not possible. The concept of orphanhood is purely local. Some sites have lists of orphans as seen by their node. Blockchain.info has already been mentioned, block explorer has another. There are probably others too. A while back I estimated the global race/fork rate to be in the neighborhood of 1 in 300. My method was not very special, merely counting the orphans seen by a node and dividing by the number of blocks over the same span and multiplying by two (because I figure on average a given node will land on the winning side first about half the time). I have vague memories of other people arriving at similar figures, but I doubt that I could find any references. |
|
|
|
USB drives also tend to suffer random bricking events.
I've only had one USB drive suffer from what I'd call a "random" bricking event, and this was a drive that was physically damaged and still managed to work perfectly for at least 3 more years of moderate to heavy use before finally dying on me. More likely, USB drives that are heavily used (a lot of read/write cycles) will tend to suffer from bad sectors or file corruption over time. I've never had a drive that wasn't damaged or heavily used just "randomly" go bad on me while it was sitting in a drawer. I get about one per year in my small-ish organization. Amusingly, the people that are the most physically abusive of them* have yet to lose one, even to physical damage. I don't allow any data storage leave my organization without physical destruction.** There is a lot of variation between different manufacturers in their willingness to tolerate my requirements in their RMA procedures. Imation has never had a problem sending me a new drive to replace a baggie of thumb drive parts including a PCB with a half inch drill hole where the flash used to be. * Patrol officers will stir their coffee with the first roughly plank-shaped object they see.** I prefer to raise the temperature of magnetic media above the curie temperature with thermite, but shredding is quicker. |
|
|
|
|
Show Posts
