Since theymos made changes to support what I want to do, I paid the 20BTC bounty using the donation address for blockexplorer.com
Theymos, please support laziness by adding a link to the API description from the blockexplorer.com home page. Thanks!
Thanks for the 20 BTC! I added a link. |
|
|
|
If Debian stable release would include bitcoin after an year or so, 0.3.19 would be too old to connect to the network, wouldn't?
No. All releases are still able to connect. There is a lot of code for handling backward-compatibility. There might be some fee problems, though. Really old versions would want to run with -paytxfee=0.01. |
|
|
|
|
The only way you can enforce a resource based economy is through totalitarianism (at a degree that is probably impossible). Otherwise, people will acquire wealth, and a money will emerge spontaneously.
|
|
|
|
The Bitcoin distribution method is designed to be like mining for precious metals. The term reflects this important aspect of the system. Even when BTC distribution ends in 130 years, the hashing process will still be analogous to mining in that you search for a long time to find something very valuable. encrypting those transactions.
There is no encryption in Bitcoin. |
|
|
|
(Just realized my solution is still vulnerable: the transaction could pay you, go away, you wait n blocks, and a different transaction pays you, you recheck the balance and it looks good, but then the 2nd transaction goes away.)
Yeah, /q/getreceivedbyaddress is currently only suitable when you need just 1 confirmation. I'll add a "minconf" parameter when I get time. |
|
|
|
|
I edited betarepeating's post to remove the password.
|
|
|
|
Problem 1: In order for the network to function the way it was designed, we need as many miners as possible. If mining is controlled by a few, slarge miners, it will always be succeptible to a double-spend attack by someone with considerable resources.
Professional miners will have much more computing power than a network of volunteers. Professional miners need to compete against each other to stay in business: as soon as one of them finds a more efficient way to mine (software, hardware, or electricity), the network becomes stronger. This competition does not exist among a network of volunteers, and a large number of volunteers prevents this competitive environment from being established. I think that professional miners will eventually develop such great custom hardware that even the largest botnets will be unable to attack Bitcoin. New users pay the miners when they join (as miners are the largest sellers), but if many of them want out, there is no support there. As long as there exists miners which can crash the bitcoin market overnight (which would be very easy for some of the current large-scale miners such as ArtForz), the bitcoin economy carries with it many of the traits of a ponzi scheme (albeit a very open one) which makes MANY people very wary of investing. How is any of this specific to mining? I could also have bought 400,000 BTC in the beginning for around the same price as mining it, and many people would then buy from me now at higher prices. |
|
|
|
This CSS rule will work to show the "report to moderator" link and not the "logged" link:
td.smalltext[id^="modified_"] + td.smalltext[align="right"][valign="bottom"] {display: block !important;}
td.smalltext[id^="modified_"] + td.smalltext[align="right"][valign="bottom"] img,
td.smalltext[id^="modified_"] + td.smalltext[align="right"][valign="bottom"] .help {display: none !important;}
Thanks. I added it. |
|
|
|
I2P is a horrible network to use for something like this because every node is a relay and it makes it super vulnerable to attack since the shipper leaks geolocation when they mail. Find I2P users in shippers area, which is trivial, and then you found the shipper. Using I2P for a drug vendor would actually be worse than using no anonymity network at all. If you use no anonymity network at all law enforcement can find you, if you use I2P anyone can find you if you leak rough geolocation.
Good point. I2P is also very weak to intersection attacks for the same reason. |
|
|
|
|
Try moving all files and directories except wallet.dat somewhere else. Then allow Bitcoin to re-download the blocks.
|
|
|
|
When the transaction gets included in the miner's block, the patch suppresses adding the transaction fee to pblock->vtx[0].vout[0].nValue. So the miner doesn't claim the transaction fee - but the fee has already been taken out of his wallet. The miner ends up ripping himself off for the transaction fee!! Exactly the opposite of what was intended! Plus, it "leaks" the transaction fee out of the economy. That .05BTC is lost forever.
It doesn't do that. It just changes the limit at which a transaction would be accepted. // Transaction fee required depends on block size
bool fAllowFree = (nBlockSize + nTxSize < 4000 || dPriority > COIN * 144 / 250);
int64 nMinFee = tx.GetMinFee(nBlockSize, fAllowFree);
// If our wallet has a key for one of the outputs >= nMinFee, allow it without a fee
if (tx.IsFromMe() || tx.GetCredit() > nMinFee || mapWallet.count(tx.GetHash()))
nMinFee = 0; Notice that nMinFee can also be 0 in the first (normal) case when a larger fee is given. The fee is claimed elsewhere: Each transaction in the block is looped through, and its fee is added to nFees: if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))
continue; Even the fee-exempt transactions go through this. After all fees are tallied, the amount is added to the generation transaction: pblock->vtx[0].vout[0].nValue = GetBlockValue(pindexPrev->nHeight+1, nFees); |
|
|
|
|
Luke-jr promotes Total so heavily, I believed this for a second. LOL
|
|
|
|
You're right, Bitcoin's not proprietary, and you are free to run whatever code you want. But the problem is, the patch that Gavin submitted violates the established protocol. When you generate a transaction that, according to the established protocol would require a transaction fee, but you do not include that fee in your transaction, no other node will accept that transaction. That's why Gavin withdrew the patch. And as I said in the comments for the patch, the patch isn't necessary anyway. If you happen to generate the transaction, you get the transaction fee back and it's free (for you). If someone else generates it, they get the fee.
It's useful if you expect to generate a block in a reasonable time-frame. Unlike sending a transaction with a fee and hoping to get the fee back, sending a no-fee transaction and including it in your blocks guarantees that you will not have to pay a fee. Since there is currently no way to cancel a transaction that has been sent, and these transactions might never clear, sending one of these transactions is risky, and it shouldn't be enabled by default. It doesn't violate the protocol. Miners decide what fees to charge, so if you mine a block, you can fill it to 1MB with free transactions if you want. It doesn't look like Gavin's change even generated no-fee transactions -- it just accepted them, which is harmless. |
|
|
|
You can get a textual list with listtransactions on JSON-RPC. I think this is how you do it, though I don't have a Windows machine with a recent enough version of Bitcoin to test it on: Open a command window in the directory where bitcoin.exe is located. Run Bitcoin with RPC enabled: bitcoin -server -rpcpassword=asdf After it has started, run it again (without shutting down the first instance) with an RPC query: bitcoin -rpcpassword=asdf listtransactions * 8000 The asterisk might need to be escaped. You should get a list of all transactions. |
|
|
|
Shutup you troll, Leave
Why so hostile? |
|
|
|
Does he have account on forum?
He's MagicalTux, just above your post. |
|
|
|
Is there an easy way to track how many nodes are connected?
Look at the IRC bootstrap channel to get a rough estimate of node number. (#bitcoin on irc.lfnet.org) This doesn't reflect network hash/s, though. I have some stats related to network hash/s here: http://blockexplorer.com/q/nethash |
|
|
|
|
Show Posts
