I understand that, but what happens when we have, say, 2000 transaction requests every 10 minutes, but the system can only process 1000 transactions every 10 minutes because of the block limitations? And say that that number of transaction requests is consistent for a week straight. Then you have tens of thousands of transactions backlogged, that may never be processed.
Am I wrong?
A few things... I believe the maximum block size can be increased, so more transactions can fit into a block. The max size is low(ish) right now to prevent malicious entities filling up people's hard disks with huge numbers of small transactions. As Bitcoin becomes more popular and there are more transactions, fees will become more prominent, so you'll have a way to prioritize your transaction if its necessary. There could be alternate block chains for more localized or specialized spending, with large processors/banks/merchants settling out via the block chain periodically. Perhaps the use of services like MyBitcoin will become more widespread. When sending transactions internally, no data is written to the block chain. They could also settle debts between each other outside of the block chain, through some other communications channel. Basically, there are lots of options for growth of network usage. |
|
|
|
Thanks Garrett.
So increases in the difficulty level also increases the amount of time it takes to compute a block? Why don't we compute blocks as quickly as possible, then use a lottery system to award the 50 BTC "prize" to the first hasher of a random block in a 10 minute time period? Seems like we're just wasting computing power that could be put to better use...
Unless the goal is to artificially limit the number of transactions that can take place in 10 minutes, to force people to eventually pay transaction fees.
But if that's the goal, what happens when adoption of bitcoins is 100x what it is at now? If there can still only be X # of transactions per block, and the difficulty adjusts itself to where only one block is computed every 10 minutes, how in the world will the system be able to handle an increase in usage? Transaction fees would have to increase to the point of fewer people wanting to use the system, which would be the opposite of what we all want, right?
The point is for a block to "equal" ~10 minutes of computing time at a power equal to the size of the network. If blocks were found more quickly, an attacker could generate more blocks quickly, but they would represent the same amount of computer power. Additionally, network propagation must be taken into account. I think 10 minutes was chosen in part because it's more time than is necessary for a message to propagate to the entire network. This helps prevent constant forking of the block chain. |
|
|
|
Is your transaction in the unconfirmed transactions list? There are currently 612 of them, which is much higher than I've seen before... http://bitcoincharts.com/bitcoin/ |
|
|
|
|
This is just AFAIK, so take it with a grain of salt...
GPG private keys are stored in the secret keyring (secring.gpg in %AppData%\GnuPG or ~/.gnupg), and are individually encrypted with a symmetric cypher, the key to which can be derived from your password. Without the password, the key is useless.
However, since it is a symmetric cipher, someone could try to break it through various means. I wouldn't leave even the encrypted key exposed to a potential attacker.
|
|
|
|
|
Also agree with Mike. Anyone who hasn't gotten this point yet, keep in mind that you can look for a solution for any and all block chains (set up as Mike specified) with one round of hashing. If this becomes popular, all miners could be computing for all parallel block chains simultaneously.
|
|
|
|
|
Cool, I appreciate the work you're doing. I'm not doing anything critical, just want to play around with some ideas for Bitcoin related projects. I figured going from C# to Java would be easier than C# to C++.
|
|
|
|
|
Ah, that makes sense. I'm newish to Java, and I've only been looking over the code the past few days, but can multiple Peers share the same BlockChain/Wallet? I was trying to figure out how one might manage multiple connections, but I wasn't sure if multiple instances of a Peer would sync on the same BlockChain.
|
|
|
|
|
Is it possible to create a Peer without a Wallet? It seems like you need a Wallet to create a BlockChain and a BlockChain to create a Peer.
|
|
|
|
|
Mike, I'm a little confused what exactly miners would be hashing that can be shared between Bitcoin and BitDNS. Is there some value they can hash that represents both Bitcoin and BitDNS?
|
|
|
|
|
Lines of code isn't a good measure of contribution. A better idea might be attaching bounties to specific bugs or features.
|
|
|
|
But fundamentally, I don't see how the "American"-libertarian tradition of the non-aggression principle and homesteading principle are necessarily supportive of landlordism and bossism, since it ultimately depends on what action and time is considered to be sufficient for homesteading and abandonment of property. For example, even the most hard-core anarcho-capitalist will admit that if you leave you home abandoned for a long enough time, that it will eventually be considered abandoned and thus homestead-able by new parties or the current renters. Emphasis mine. Very insightful, applauded. |
|
|
|
In this recent thread, Mike explains how this could work. Previously Satoshi had expressed this idea (link in thread), but had never provided implementation details. |
|
|
|
This means that the total strength of each individual network would be weaker than a single unified bitcoin network. Miners can theoretically mine toward more than one block chain simultaneously, so more block chains are a good thing IMO. Most of the long arguments take place over proposals like this one, that fundamentally alter the technicals or economics of Bitcoin. They might as well just create a fork instead of argue that their version is better. Basically, "put your money where your mouth is" - if your version is better or more useful than Bitcoin, people will use it. |
|
|
|
Do we know the details of Set the minimum posts needed to modify karma - The number of posts needed to have a "karma".
Set wait time in hours - The time between smites or applauds.
Restrict administrators to wait time - If administrators have to wait for the time above as well. Well, I know this much anyway... Sorry, you can't repeat a karma action without waiting 240 hours. |
|
|
|
Problem is, people will kill for a much lower price than I think you are anticipating. I would be shocked if the price for a head was over $50 in a free, lawless, anarchist society.
The reason it costs so much in today's society is because volume is low (no efficiencies of scale), and the risk of getting caught. If you had high volume, and much lower risks (i.e., the only risk is to the assassin if they are incompetent), then it would drive the price down to an extremely low level.
Basically, EVERYONE would have the resources to contract a murder.
Anarchism isn't what you think it is. There can be rules without rulers and laws without government. Bitcoin is proof of that, as are various legal systems throughout history such as Xeer and merchant law. Further, most schools of anarchistic thought have something like the non-aggression principle, which states that initiating the use of force (aggression) is never justified, but responding to aggression with a proportional amount of force is justified. In short, I don't think the introduction of the assassination market would have a significant impact on the number of murders of innocents, but would provide a very powerful tool for otherwise powerless people to stand up against tyranny. |
|
|
|
|
If you have sufficient resources to contract a murder, you can contract a murder - with or without an assassination market. On the other hand, if a bunch of people all want the same person killed, but nobody has sufficient resources on their own, an assassination market provides a useful tool. Think of it like crowd-sourced assassinations.
|
|
|
|
Ok, I guess we're talking about two different things then.
I was talking about an open & legal assassination market that would inevitable present itself in an anarchist society. It would be a horrible thing, for many reasons.
Why? How would an assassination market contribute to the murder of non-deserving individuals? If you're concerned about people with lots of money, they can hire assassins already. If you're concerned about individual disputes turning into murder contracts, it doesn't work unless lots of other people contribute to it as well. |
|
|
|
I'm just saying, there would be a LOT more of it happening, and it would be a LOT more common-place, if people weren't threatened with going to jail for doing it.
That's not what we're talking about. This system only makes it difficult or impossible to trace, financially, the funding for the assassination. It assumes nothing about the current legal system. There's still physical evidence of the murder itself for law enforcement to collect and courts to judge. |
|
|
|
Anyways, I'd also like to have a simple feature of "send X amount of BTC to the guy who next generates a block", as a form of donation to the "bitcoin network". Is it currently possible to have the outputs of a transaction be 0? That + using the private key to sign stuff would indeed solve my problem pretty well.
You could just do a send to an address you own and include however large a fee you desire. |
|
|
|
|
It's not really necessary, if those small amounts become the most commonly used, client software could just shift the decimal place over. So 0.00000002 BTC becomes 2 Satoshi.
|
|
|
|
|
Show Posts
