|
When did it happen: I made time to fix it a few days ago.
|
|
|
|
Please don't spread misinformation. I agreed to join TruCoin a couple of months ago, because I knew Eric (chaord) and Chris (cbrunner) through these forums and I think their vision and experience give TruCoin a really good chance of being an important company in the bitcoin economy. And they hired me because TruCoin won't go anywhere if core bitcoin falls apart. I will (and have) mostly be working on core bitcoin issues, jumping in and writing code that I think is critically needed that nobody else is stepping up to write and working to make bitcoin as stable and secure as possible. If Eric and Chris tell me to do something that is bad for bitcoin, I'll let them know what I think. If they suddenly lose their minds and stop listening, then I'll quit. If I lose my mind and start doing things that are bad for bitcoin as a whole (or if I start trying to do things to bitcoin-core that benefit TruCoin over everybody else), then you-all should fire me. |
|
|
|
|
A Radeon 6990 has 4 gigabytes of ram.
If the task is "find a number that bcrypts/scrypts to less than a given hash target," I don't see anything that would stop a GPU programmer from implementing bcrypt/scrypt on the CPU and parallelizing at the try-different-nonces level.
Maybe I'm missing something; I'm probably biased because I worked at SGI from 1988 to 1996 and saw first-hand the evolution of GPUs from very-special-purpose chips with very limited memory to very-general-purpose vector-processing pipelines with very fast access to lots of memory.
|
|
|
|
|
I think it would be wise for any alternative block-chain to discourage creation of exchanges for at least a month or three to get the bugs out.
That should also help build trust that the alternative chain developers/promoters aren't just trying to make some quick BTC.
|
|
|
|
I disagree with your comment about the miners though. As seeing as it was mined into the test chain I would assumed it would be mined into the prod one too? Especially if you put a big fee on it!
Non-standard transactions are allowed-by-default on the test network. So people can test things out. They are "discouraged-by-default" on the main network (discouraged means not relayed to peers, and not included in blocks by the default mining code). I think etotheipi is right: last I heard, Eligius was the only mining pool with different rules for non-standard transactions. |
|
|
|
RE: where in the code: script.cpp static const size_t nMaxNumSize = 4;
CBigNum CastToBigNum(const valtype& vch)
{
if (vch.size() > nMaxNumSize)
throw runtime_error("CastToBigNum() : overflow");
// Get rid of extra leading zeros
return CBigNum(CBigNum(vch).getvch());
}
... and all of the arithmetic binary ops do a CastToBigNum() nMaxNumSize = 4 means numbers added must be 32-bits or less. RE: simpler version being redeemed by anybody by rewriting: D'oh! Right, definitely need a signature so the transaction can't be modified between being broadcast and being included in a block. I'll remove it from the wiki page. |
|
|
|
|
RE: hidden recipient address:
I dug deeper into the Script OPs when working on the multisig proposal, and OP_ADD can't add bignums, so the 'hidden recipient' script won't work.
A simpler version would, though; I'll update the wiki.
|
|
|
|
The testnet has suffered rewrite-the-block-chain-with-more-hashing-power attacks. It does bad things to your wallet, if your wallet contains transactions that depend on previously mined but now-no-longer-valid blocks. I suspect it will cause lots of heartburn for exchanges; this patch from sipa (which hasn't been extensively tested because long block-chain re-orgs on the main chain are not an issue) might help: https://github.com/bitcoin/bitcoin/pull/195Alternatively, removing all the wtx wallet transactions stored in the wallet and then running with -rescan should get back to a sane state. Although an exchange may very well find customers end up with negative balances after doing that, and customers will likely be upset that their balances are likely to change from what they think they have if they've deposited invalid-under-the-new-chain transactions. Successfully bootstrapping an alternative chain starting from a low difficulty, given that there are people with lots of potential hashing power and the willingness to mess around with the chain "just because they can," seems like a hard problem to me, although if people were willing to accept some centralization until hashing power got to a "safe" level it could be solved by a central authority publishing block-chain checkpoints every X blocks. |
|
|
|
As an experiment, I've uploaded a Mac .dmg disk image with 0.4rc2 binaries to: https://github.com/downloads/bitcoin/bitcoin/I'd like to switch from sourceforge to github for binary release downloads, because sourceforge doesn't support https for downloads. Help improving the script I used to create the .dmg file would be most appreciated; see this branch for what I done did: https://github.com/gavinandresen/bitcoin-git/commits/osx_dmgFor some reason setting the "Drag and drop to install" background image isn't working...
shasum checksum is:
6621bdb82fd4520f6efcb87f489e47a587d8915f Bitcoin.dmg
Fixed. New shasum checksum is: c86229b4c973da2207f516962804958424e94e08 Bitcoin.dmg |
|
|
|
|
They won't lose any money to fees, because they won't broadcast their transactions-to-self, they'll just include them in blocks that they create.
So, evil miner does:
Gets some myselfcoins.
Creates transactions that pays themselves the myselfcoins, and pays BIG fees.
Does NOT broadcast those transactions.
... eventually mines a block that contains those transactions (they're a miner, they can put whatever transactions they like in their blocks).
Then does that again and again, re-using the same coins, getting richer and richer from the FEES+10%
|
|
|
|
|
I haven't seen anybody post about what would be my biggest worry if I were trying out alternative block chains. I realize this may be perceived as "Gavin is FUD'ding anything that isn't bitcoin!" (FUD == Fear, Uncertainty and Doubt) But I think some of you might be forgetting some basic computer security fundamentals in the excitement to be early adopters.
When I first heard about bitcoin, my questions were:
1) Can it possibly work (do the ideas for how it works make sense)?
2) Is it a scam?
3) If it is not a scam, could it open my computer up to viruses/trojans if I run it?
I answered those questions by:
1) Reading and understanding Satoshi's whitepaper. Then thinking about it for a day or two and reading it again.
2) Finding out everything I could about the project. I read every forum thread here (there were probably under a hundred threads back then) and read Satoshi's initial postings on the crypto mailing list.
3) Downloaded and skimmed the source code to see if it looked vulnerable to buffer overflow or other remotely exploitable attacks.
If I were going to experiment with an alternative block-chain, I'd go through the same process again. But I'm an old conservative fuddy-duddy.
If you want to take a risk on a brand-new alternative block-chain, I'd strongly suggest that you:
1) Run the software in a virtual machine or on a machine that doesn't contain anything valuable.
2) Don't invest more money or time than you can afford to lose.
3) Use a different passphrase at every exchange site.
|
|
|
|
|
0.3.24 Linux/Windows releases weren't built on EC2, but was built on 'gitian' virtual machines (lookup trusted build process here for more info, or get in touch with devrandom).
|
|
|
|
Thanks; we really ought to do a parallel release of binaries with 0.4.0, and maybe keep it up until the core dev team finally merges it.
I think everybody would like to merge bitcoin-qt as soon as the 0.4 release is shipped (see the bitcoin-dev mailing list for the current known bugs). Closing the dozens of wxWidgets-related GUI bugs in the issues list will give me great pleasure... |
|
|
|
Y'all probably want this: https://github.com/bitcoin/bitcoin/pull/491However, I don't think you can fix all the problems that a fixed transaction fee cause; the real problem is that basic economics says that you need to let the price of a scare resource change, ideally in a market, to match the underlying real costs. (bitcoin's fee structure isn't right either, and fixing it to create a market between miners and clients is high on the TODO list) |
|
|
|
Good idea. The developers listed on bitcoin.org are the people who have 'push' rights to the github source tree, but I like the git approach. Who wants to volunteer to make it happen? |
|
|
|
|
Optimizing the accounts code to add a berkeley db index table that indexed wallet transactions by account, and that cached account balances (and invalidated or updated the cache on receive/send) shouldn't be terribly hard for somebody who already knows c++ and berkeley db.
It is not on my short-term TODO list because there are too many other higher priority things on my TODO list, but a nice clean well-tested upward-compatible patch would be most welcome.
PS: for ClearCoin, I used the "bitcoind keeps track of the bitcoins" architecture, and I never regretted it-- no problems with synchronization, less possibility for MtGox-like hacks that create mythical bitcoin balances out of thin air by adding an entry to a database.
|
|
|
|
|
Show Posts
