So the more MicroCash you have the higher the percentage of the fees you get. It doesn't necessarily reward early adopters, it rewards people who have MicroCash.
MicroCash: Taking from the poor and giving to the rich. Interesting. If I understand correctly, if an address has a greater-than-average amount of currency then it will get interest. Paid for by all the accounts with a less-than-average amount of currency. So there's an incentive for everybody to (try to) be above the average. That seems like a recipe for a lot of disappointed people, especially since a graph of size-of-account will have a long tail with of lots of little accounts. Making a half-thought-out-prediction, I'd say the end result would likely be one big centralized account controlled by the largest exchange with over 50% of the currency in it, because there would be a natural incentive to store your money in the biggest account so you get the most interest... |
|
|
|
Bitcoin version 0.6.1rc2 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.1/test/This is a bug-fix and code-cleanup release, with no major new features. NOTABLE CHANGES =============== Much faster shutdowns. However, the blkindex.dat file is no longer portable to different data directories by default. If you need a portable blkindex.dat file then run with the new -detachdb=1 option or the "Detach databases at shutdown" GUI preference. Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux binaries are dynamically linked to the version of OpenSSL on the system). CHANGE SUMMARY ============== Use 'git shortlog --no-merges v0.6.0..' for a summary of this release. Source codebase changes: - Many source code cleanups and warnings fixes. Close to building with -Wall - Locking overhaul, and several minor locking fixes - Several source code portability fixes, e.g. FreeBSD JSON-RPC interface changes: - addmultisigaddress enabled for mainnet (previously only enabled for testnet) Network protocol changes: - protocol version 60001 - added nonce value to "ping" message (BIP 31) - added new "pong" message (BIP 31) Backend storage changes: - Less redundant database flushing, especially during initial block download - Shutdown improvements (see above) Qt user interface: - minor URI handling improvements - progressbar improvements - error handling improvements (show message box rather than console exception, etc.) - by popular request, make 4th bar of connection icon green Thanks to everybody who contributed to this release: Chris Moore Dwayne C. Litzenberger Gavin Andresen Jeff Garzik Luke Dashjr Matt Corallo Philip Kaufmann Pieter Wuille R E Broadley Timothy Redaelli Wladimir J. van der Laan cardpuncher freewil graingert sje397 |
|
|
|
I guess my question is, what makes Bitcoin better than Litecoin other than being the first of the two to get acceptance?
Network effect. More developers are working on Bitcoin, there are more interesting projects, more useful tools, more documentation at places like bitcoin.stackexchange.com, etc. And that all builds on itself. |
|
|
|
Did a post disappear from here? Was it too off-topic?
Yes. And yes. |
|
|
|
|
If a 51% attacker stopped including all broadcast transactions in blocks "we" would quickly figure out a rule or rules to reject their blocks.
Something like "ignore a longer chain orphaning the current best chain if the sum(priorities of transactions included in new chain) is much less than sum(priorities of transactions in the part of the current best chain that would be orphaned)" would mean a 51% attacker would have to have both lots of hashing power AND lots of old, high-priority bitcoins to keep up a transaction-denial-of-service attack. And they'd pretty quickly run out of old, high-priority bitcoins and would be forced to either include other people's transactions or have their chain rejected.
I'm tempted to code that up and run some tests on a testnet-in-a-box, but there are much higher priority things on my TODO list; I don't think a 51% attack is likely. You'd spend a lot of time and money on an attack that "we" would neuter within a day or two.
|
|
|
|
Let me try to further explain why I want this feature (and I really don't care exactly what form or exactly which RPC command is modified to support it) - I am wanting to use the blockchain as a "true" ledger for a specific address (i.e. that can be publicly audited without having to try and chase up "change" addresses and without using inputs from any other address).
I am so far surprised that no-one seems to be interested in this (for things such as Bitcoin100) and (if the feature actually does get added) will be creating a "project management" package for the CIYAM software platform that will integrate with bitcoind to work with such "non-anonymous" addresses.
I have a -noprivacy patch that I use for the Faucet that accomplishes what you want, sending any change back to the funding address. It isn't part of the core code because it doesn't play nicely with other features (accounts and listtransactions, for example). See https://github.com/gavinandresen/bitcoin-git/tree/noprivacy |
|
|
|
|
I pinky-swear on a stack of bibles I haven't heard a peep from Satoshi.
Whatever he/she/they have been busy doing, I guess he/she/they're still busy doing it. Or maybe doobadoo is Satoshi and is trying to misdirect us....
|
|
|
|
Unless you want to argue that fungibility is not related to anonymity of digital tokens, or that fungibility is not an important property of money.
Of course fungibility is important. But fungibility isn't all-or-nothing, and, in my humble opinion, it isn't all-important. Refusing to accept dollar bills or bitcoins that you believe were obtained illegally makes them less fungible, but so what? It's the right thing to do. |
|
|
|
Cross-posted from the Alternative Clients sub-forum, since it looks like the alternative client folks are more interested in adding new features than figuring out exactly how the features we already have work: Better testing, both for the Satoshi code and across different implementations, is right at the top of my priority list. So I wrote some code to make it easier to exercise edge cases in Script evaluation: https://github.com/bitcoin/bitcoin/pull/1121/filesThe unit tests are data-driven by two files: script_valid.json contains pairs of (scriptSig,scriptPubKey) that, when used in a transaction, should evaluate to true. script_invalid.json contains pairs that are invalid for some reason. I'm looking for help to expand those to cover all the quirky edge cases that might trip up alternative "fully validating" implementations (excluding OP_CHECKSIG/OP_CHECKMULTISIG, I'm still thinking about how best to write test cases for those). If you can help, please jump in and write some more. Assuming you've got the bitcoin source tree cloned the process for adding new tests is easy: 1. Edit src/test/data/script*.json 2. From the src/ directory run: make -f makefile.unix test_bitcoin 3. Run the unit tests with: ./test_bitcoin Or if you've already got Script test cases in some other human-readable form please point me to them. I'm planning on resetting the testnet with a new genesis block and a chain that contains all of the valid tests as spent transactions (and a checkpoint so all those nice test cases aren't overwritten). It would be really nifty to have a 'bad chain' node running; -connect to it and it would send you otherwise-valid blocks that contained one or more of the invalid transactions from script_invalid.json. Does that sound like a project any of you would like to tackle? |
|
|
|
No, you should not
I agree with Andrew. Building a website that handles money is a terrible first project. |
|
|
|
I have a question
Why we have "block/transaction versions" if we don't use it? There was a good moment to increment version number and later use it in such way: if Miner gets a "strange" block with increased version number -- it is a signal for him to check for new soft. We could have avoided many of lost orphaned blocks
We should have, but "we" didn't think of that in time. I've been working on a "how to do it better next time" document: https://gist.github.com/2355445 |
|
|
|
Better testing, both for the Satoshi code and across different implementations, is right at the top of my priority list. So I wrote some code to make it easier to exercise edge cases in Script evaluation: https://github.com/bitcoin/bitcoin/pull/1121/filesThe unit tests are data-driven by two files: script_valid.json contains pairs of (scriptSig,scriptPubKey) that, when used in a transaction, should evaluate to true. script_invalid.json contains pairs that are invalid for some reason. I'm looking for help to expand those to cover all the quirky edge cases that might trip up alternative "fully validating" implementations (excluding OP_CHECKSIG/OP_CHECKMULTISIG, I'm still thinking about how best to write test cases for those). If you can help, please jump in and write some more. Assuming you've got the bitcoin source tree cloned the process for adding new tests is easy: 1. Edit src/test/data/script*.json 2. From the src/ directory run: make -f makefile.unix test_bitcoin 3. Run the unit tests with: ./test_bitcoin Or if you've already got Script test cases in some other human-readable form please point me to them. I'm planning on resetting the testnet with a new genesis block and a chain that contains all of the valid tests as spent transactions (and a checkpoint so all those nice test cases aren't overwritten). It would be really nifty to have a 'bad chain' node running; -connect to it and it would send you otherwise-valid blocks that contained one or more of the invalid transactions from script_invalid.json. Does that sound like a project any of you would like to tackle? |
|
|
|
If for example my chip has been loaded with double-spent Dollars without my knowledge, would I be denied that money at the next reset or not?
Good question. They're the Mint, so I bet they'll handle that the same way they handle somebody showing up at a bank with a bunch of counterfeit $100 bills: they'll ask you where you got them, and either throw you in jail (if they don't like your story) or tell you to be more careful about who you deal with and maybe direct you to some technology to help detect counterfeits in the future. But they won't let you deposit them or trade your bad money for good. |
|
|
|
|
RE: $100 per-transaction, $500 balance limit:
That makes perfect sense; they probably figured out about how much it will cost to hack a MintChip to get it's private key (dissolve case in acid, put it under an electron microscope, attach electrodes at exactly the right spots, etc...). Do a little calculation involving the cost of hacking one chip, the number of times you can double-spend before you're likely to get caught and the maximum amount per transaction and I bet they figure it doesn't pay.
Especially if online transactions "phone home" to detect double-spends. If you have to physically walk to 500 different not-online merchants to get away with $50,000 worth of double-spends that's just like counterfeiting $100 bills, and that's an attack Mints have been pretty successfully dealing with for hundreds of years.
RE: anonymity: the anonymity model is similar to Bitcoin. Each physical MintChip is like a Bitcoin keypair, if you can easily buy/load a bunch of them anonymously then it will be hard for Them to track your purchases.
If MintChip fails I bet it is not due to hacking or lack of anonymity, but just due to the inconvenience of needing Yet Another Physical Doohickey. Paper money fits nicely into the wallet I already have, I don't want Yet Another Dongle on my keychain, and I bet before the end of the year either Apple will finally approve a Bitcoin app or there will be a nifty HTML5-based web wallet I can use on my iPhone...
|
|
|
|
Suppose there's a transaction for 100,000BTC and several blocks later a double spend with 50,000BTC fee...
Maybe there should be a maximum fee per transaction.
Or maybe you should wait 60 blocks before considering a half-a-million-dollar transaction final if you think there is any possibility of a mining cabal trying to do this. All of this reminds me, I need to clean up my user-defined-checkpoints code for the 0.7 release, so a cabal of merchants and exchanges can get together and decide they will "lock in" an agreed-upon blockchain after 6 (or 60 or whatever) confirmations. I think that would go a long way towards infrastructure for injecting real-world knowledge about who is trustworthy into the block-chain. |
|
|
|
Split from the press hits topic: The only "skeleton key" I have is the private key for alert messages, that lets me sign messages that are broadcast and then displayed in the client (see https://en.bitcoin.it/wiki/Alerts for details, and the alerts that have been sent). MAYBE he is saying that the core developers could slip in a change to the source code without anybody else noticing... but we've worked hard to make that impossible (with things like the gitian reproducible build system so people can verify that we are creating executables from the source code that anybody can look at). Smells like plain-old FUD to me. |
|
|
|
A Bitcoin in which miners can and do vote on how much inflation they'd like to award themselves is not a Bitcoin I'd feel like participating in. But it's the logical outcome of assuming miners are a perfectly informed conspiracy of entirely selfish actors.
The Bitcoin ecosystem consists of more that just miners, and even if miners decided to try to form a cabal to increase inflation merchants, users, and exchanges could all veto their block-chain by simply refusing to recognize it. I think the policy of which transactions to keep in the memory pool is fundamentally different, because miners can do whatever they like and there's not a whole lot merchants/users/exchanges or other miners can do about it. There's no way to enforce a "first broadcast version of a transaction must be mined" rule, if there was then we wouldn't need the block chain at all. As for re-writing the blockchain if an after-the-fact, large-fee double-spend is broadcast: I think that's covered by this case: Should a miner put Transaction 1 into the block they're mining and take the smaller fee now, or not include it, hoping that nobody else mines Transaction 1 in the next 3 days so maybe they can mine Transaction 2 and get the bigger fee?
I'm not an expert in game theory, but I believe the winning strategy in the above situation, assuming everybody knows about both transactions, is to mine Transaction 1 right away (any economists reading who know a lot more about game theory than I do?).
Or, in other words, you'd need to be pretty sure that you've got a majority of miners who will cooperate with you to rewrite the block chain. The longer the chain, the harder that will be (because it becomes increasingly likely that one of your co-conspirators mined one of the blocks you want to overwrite). |
|
|
|
Please let's just try and use the tools Satoshi left us with rather than constantly trying to change them. I'm strongly against trying to "improve" parts of the protocol that we've barely even begun to understand yet, like nLockTime and tx replacement.
Some of the big mining pool operators are already going their own way, experimenting with new types of transactions (e.g. deepbit and eligius), so I suspect the answer to your question "Can 'we' please hold off..." is "No." Discussions like this one are how I start to understand parts of the protocol like nLockTime and transaction replacement better. As for BIP 16 draining effort away from making the standard client scale: I've been saying for a year that my top priorities are network stability and wallet security. Making the standard client scale is, in my opinion, a lower priority; I don't want a super-scalable client with a 4-minute blockchain initial block sync time if it is vulnerable to the user clicking one wrong link and getting infected by a trojan wallet stealer. |
|
|
|
|
Show Posts
