Also, if the network doesn't operate on this principle, it will be because we've implemented ways to punish those who do otherwise
Why do you keep assuming this? What's wrong with simply rejecting the block discouraging mechanism as a bad idea and keeping the situation as it is? Just because we may currently have some protection for zero-conf transactions, doesn't mean we have to add more. It's already good enough! I'm sorry dude, but you are wrong about this. Most blocks are already assembled by software other than bitcoind. Also, we have to accept that people using the stock client for mining are certainly capable of getting and applying this patch. We can discourage patches like this from the main client, but we can't keep them off the network. The some protection that you and other see is an illusion. If even a single miner is running this code, or similar code in some other block assembly software, then no transaction is safe until confirmed. The bulk of them may continue to get confirmed as everyone expects, but that is luck, not safety. |
|
|
|
Whilst I don't fully understand the concept behind this and why you're doing it, I don't see how this is going to be that worth while.. It's just going to take all legitimacy out of 0 confirmation transactions, thus making it harder for people to accept payments. As was posted in this thread: https://bitcointalk.org/index.php?topic=200090.0Sorry if I'm being ignorant, but I can't possibly see how the down sides outweigh the positives. I assume there will be possible solutions to get around these issues within the near future maybe? 0 confirmation transactions are not legitimate, never have been, never will be. People need to stop pretending that they are. |
|
|
|
I'm not intending this as a point for or against this patch, but I reading this set me wondering how many of the other assumptions we'd normally make about Bitcoin would still hold given this (fairly reasonable-sounding) idea that a majority of miners will be acting purely out of economic self-interest, regardless of damage they might do to the Bitcoin ecosystem.
I reject your premise. The health of the bitcoin ecosystem is hopelessly intertwined with the self-interests of miners. This relationship goes in both directions. Bitcoin cannot survive contrary to the self-interest of miners, and miners cannot survive without the common good of bitcoin. If it turns out that the bitcoin system does not ultimately align these two forces, it does not deserve to be continued The good news is that bitcoin does not appear to contain this flaw. The people that are damaging the ecosystem are those that are advocating and defending practices that are unsafe and cannot be made safe, such as accepting transactions secured by hope rather than work. |
|
|
|
|
No, you are still missing something important. Printing money does not create purchasing power, it merely redistributes it.
Germany and Japan were rebuilt quickly after the war because the US poured capital into them. To the locals, it may have looked like someone hacked the game and created a bunch of wealth out of thin air, but that's not what really happened. The new Europe was built in America, shipped across the ocean, and assembled by people fed by American farms.
|
|
|
|
Isn't it ironic that we have this great cryptographic system public-private keys and such and yet we still seem to need to pay through the nose for security. Could it be that BTC 'mining' is embraced not because it's really necessary but because a whole group of people make profits from it.
How terrible that people should profit from doing something useful. We need a new coin that automatically allocates profit to those that claim to represent the useless. That will keep academics and politicians busy so they don't smell their end coming. |
|
|
|
It's a game, not an accurate model.
Of course it's a game, but at a higher abstraction level, everything is a game, the solar system is also a game played under certain physical rules. Can you point out why printing money does not work by some real facts? I think basically the printing of money works, the economy developement after 1971 has proved this, but the big question is why only a selected few can print money, and how we can make sure their printed money are used on something that people really need The biggest problem is that in a simulation, no real work has to be done. In simcity, the game can turn an area into an airport or a nuclear plant just by flipping a few bits. In reality, people have to build those things (and the things they are made from, etc, etc). You can print money, but you can't print wealth. If congress had a magic wand that could create wealth, they wouldn't bother printing money. They don't have that wand, so they print money, which steals a little bit of value from all of the other money, and puts it where they want it to go. |
|
|
|
up until now, there's reasonable security in accepting unconfirmed as long as you've got a full blockchain by which to compare the transaction's inputs and outputs.
Except that there really hasn't been any security in that, just hope. People have been living on the hope that those transactions would be confirmed some block in the future. Most of them got away with it. But they never had any security, not really. |
|
|
|
So far I could not use anything in the BTC wiki. From the technical point of view we find quite a lot of more or less superficial descriptions of this and that. Still missing an equally exact description of the "surrounding" "block". I reject your claim that nothing in the wiki is usable. It really does contain everything that you need to understand a block. Just takes some getting used to...  The "surrounding block" is described exactly above. There is some confusion on exactly what parts are block and which parts are message. Most people consider the block proper to be "header + NumTx + TX 0...NumTx". In practice, you'll pretty much never find those stored or communicated without the magic number and the size, except when using the RPC calls that return block bodies. Keep in mind that bitcoin is nested, and a lot of the complicated bits are in the interactions. The block itself is very simple, a short header followed by a list of transactions. Transactions are simple too, a header (really just the version field), a list of inputs, a list of outputs, and a footer (just the locktime field). Inputs and outputs are where things start getting strange, but even those are pretty simple in representation. |
|
|
|
Other services are necessary to handle the risks that are inherent in such transactions.
That is what I suspect. Paypal/banks sponsor that change. Now they can claim that while waiting 10 minutes (or sometimes half an hour) your coffee gets cold. Better convert your Bitcoins to something else before spending it. Maybe we could store the value on little pieces of paper. Lets call it dollar. After some time when almost everyone accepts it we can get rid of that clumsy Bitcoin thing and only use this paper money. </sarcasm> You seem quite intent on clinging to the mistaken belief that zero confirmation transactions were or are safe. I guess if you aren't going to accept that work and hope-for-work are different, there isn't much point talking here. P.S. There seems to be some confusion here. The network did not previously relay double spends, but this was bad because it meant that a vendor would be unaware of attacks. That was one patch, and it was about relaying transactions. The patch mentioned in the links in the first post is to change the default behavior of the node when being used for mining. The relay patch needed broad support, the mining patch needs only one person to run it. |
|
|
|
Endlessa, with 17 posts...
post your credentials, or you are just another alt-developer or 4chan troll trying to hack a coin to make it proffitable.
If you are a proffessor, i think you need to lurk moar... i remember there's some satoshi pdf and threads explaining everything.
Search or just look at the sourcecode!
That's a bit rude, don't you think? Why do you care why he wants to learn more about the source? Did you read the sticky at the top of this board?
Yes did I miss something there? I didn't see where mining code was identified. I read the specifications, but my understanding is the literal implementation of the code is where the facts live. I'm hoping to map the facts of the code to the protocol specifications. I looked again I assume you mean the "Satoshi Client Operation: Overview", but I'm still not seeing where it references mining. let me know if I tarded out or something, as I'm a bit sleepy today and that is entirely possible As far as I know, those articles (links at the bottom to the others) are the best guide to the source that anyone has written up so far. I'm not sure if they will tell you where to look exactly, but I had hoped that they may at least get you pointed in the right direction. |
|
|
|
The only caveat is that now the blk*.dat files are padded to 16MB chunks, so the end of the files may contain lots of zeros. But this is easy to detect, because blocks are never split between files. So you only have to check for (isEndOfFile() OR magicBytes==0x00000000) to determine that there are no more blocks in the file.
Because the block files are externally indexed, I usually tell people not to make assumptions about what is in them. The -loadblocks code is a very good example of a parser that can tolerate all manners of garbage between blocks, corrupt blocks, etc. That said, when I was ripping my files for the bootstrap torrent, I found exactly zero cruft in what my node had accumulated over the last few years. |
|
|
|
I think this is a terrible idea.
If it was "higher fee with superset of outputs of first spend" then that'd be fine.
Zero-confirmation transactions will never be safe because of potential Finney attacks. But we don't need (and, in my opinion, shouldn't) make them less safe by encouraging anti-social behavior via default mining policy.
I see this by analogy to security research vulnerability disclosure. Right now, tons of people* are acting as if they were safe, when they really are not. They've been warned, over and over again. Until the tool gets posted to metasploit for one-click use, they will not really accept that they are in danger. I'm pretty sure there have been other bitcoin patches accepted or rejected on the basis of avoiding lulling users into a false sense of security. In the end, it doesn't matter. Eventually, the network will operate on the principle embodied in this patch. The miners that aren't already using their own tools for block generation can get this if they want it. That said, I'm not sure that I'd want to sign off on this either. Inevitable or not, it does kinda feel icky. * I don't believe that tons of people are actually accepting zero confirmation transactions. I suspect that there are a dozen people on these forums (incorrectly) whining about this patch making 0-conf unsafe for every person actually accepting them. |
|
|
|
I'm afraid it's not quite so simple... You see, a single bitcoin that gets seeded into the BTC-based economy has the potential to grow BTC money supply (not to be confused with BTC monetary base of 21 million bitcoins) by 100,000,000 BTC (i.e. your average satoshi, but in a consumer-friendly notation). So, assuming that the BTC-based economy will eventually flourish, can you imaging the ripple effect an act of trashing a single bitcoin could have on that economy? This is precisely what I was hoping everyone here would look into, from a technical perspective (i.e. the resilience of bitcoin protocol to withstand such threats, if there were ever to be one), rather than focus their attention on bashing my concern as being invalid. My concern is just as valid as any other concern before it, even if it came about as part of diligent economic hacking, not code hacking. So, could some of you please take a look at the technical side of this -- is there an infinite loop ( as perhaps was suggested by our very own SgtSpike) that a rouge miner would have to contend with when trying to carry out this type of an attack? Because if there is an infinite loop, then there's nothing to worry about -- bitcoin is poised to make history! I have said many times over the years that we would very likely switch to a 128 bit integer for the value field for aesthetic reasons (native word size of 128 bit CPUs) long before it became economically necessary. I doubt that even a determined attack could deplete the bitcoin supply enough to change that. The software change would be easy. Getting the network to go along with it would be hard right now because there is no need, but would be (relatively) easy if the need ever develops. P.S. Your thinking seems clouded. 1 BTC is the fundamental unit, not the satoshi. The network is currently using a representation that goes to 8 decimal places because 8 decimal places is more than enough for the foreseeable future. We call the current minimum protocol unit the satoshi because it was the first such unit, and we are sentimental creatures. That unit has no other special features. The value of 1 BTC is infinitely scalable; the software and network can be adjusted as necessary. One satoshi would be just as good for commerce as 21,000,000 BTC, it would just require a different scaling factor. |
|
|
|
|
The force behind this patch is that zero-conf transactions have never, ever, ever, ever, ever been safe in any way, shape or form. Now everyone has to accept reality.
Despite some delusions to the contrary, bitcoin can not be made suitable for instant transactions. Other services are necessary to handle the risks that are inherent in such transactions.
|
|
|
|
|
Did you read the sticky at the top of this board?
|
|
|
|
It should never allow you to reemplace a transaction, or to change outputs,
it should allow you to give more priority to a transaction that it's stuck on the limbo of 0 fee/smaller fee transactions.
Only replace the transaction if it's the same transaction with bigger fee. to the same outputs.
Any other thing is not bitcoin, btc is not reversible.
or you just killed satoshi dice.
Bitcoin is a system for deciding which of two or more transactions is the "right" one. We use a global network and consume quadrillions of hashes every few minutes not for our own amusement, but because the problem really is that hard. A transaction is exactly as secure as the quantity of work it would take to reverse it. Zero work? Zero security. STOP ACCEPTING ZERO WORK TRANSACTIONS. You've spent too long in dreamland, assuming that the intention to hash in the future was as good as hashes already done in the past. They aren't, they never were, and now everyone will be forced to accept reality as it is. But talking about improving you could also change the 10 min confirmation to 2 and slash the rewards 5 times.
then they will change to a 1or 2 confirmations .
Confirmations don't secure transactions. Hashes do. Making the blocks more frequent would mean that they have correspondingly fewer hashes of security. Changing the lump size that hashes come in won't help anyone. |
|
|
|
In reality, the words "money", "currency" and "commodity" have only very fuzzy definitions. About the only agreements you'll find are that currency circulates, commodities are more-or-less fungible, and money is whatever fills the role of money for some group of people. Some groups may have tighter definitions for some or all terms, but those are only useful for discussions within that group, not universal truths. The traits you listed are things that make it more likely for something to be used as money, but they are neither necessary (each has counterexamples) nor sufficient (other things exist with most or all of these properties, and no one uses them as money). The rest of your post is a lengthy rehash of threads that show up every week. You can read our replies in the other threads. |
|
|
|
hello.. sorry.. just one more thing.. I quote some guy - http://bitcoin.stackexchange.com/questions/876/how-much-will-transaction-fees-eventually-beI read that the market will find the equilibrium how much these transaction fees will be.
It will not. This is perhaps the biggest flaw in Bitcoin at the moment: once mining rewards end there is no direct linkage between the amount of hashpower needed to secure the network and the incentive to mine.
True, there is a limit on the blocksize, so if the transaction volume in a block window (approximately 10 minutes) exceeds the block size you can expect a miniature "auction" where transactions fight for space in the block by bidding up the minimum transaction fee needed to get in. However this isn't really a closed-loop adjustment: the maximum blocksize is an arbitrarily chosen number, and there's no reason to believe the maximum blocksize is small enough to ensure that transaction fees are high enough to incent enough miners to mine to keep the system secure. Unlike the difficulty and the USD/BTC exchange rate it does not respond to market activity. It also has the negative side effect of capping the worldwide Bitcoin transaction throughput since other parts of the protocol rely on the assumption that blocks are created -- in the long run -- no more than once every ten minutes.
As the mining reward is reduced this "direct coupling" between the network's need for security and the incentive to mine becomes progressively more diluted.
I worry a lot about what will happen to Bitcoin once we decouple those two forces. I think the developers ought to at least come up with a story on how this will be solved so people can start testing it.
I think he makes a valid point, better than I made it.. and I wanted to point out that this issue is far from clear/certain/set-in-stone to everyone. He keep using 'mining reward' wrong. What he is talking about is actually the subsidy, which will gradually taper off and end, but the subsidy is only part of the mining reward. He doesn't seem to be unaware of this distinction, but his misuse of the terms suggests muddled thinking, and he would probably benefit greatly from cleanly dividing the concepts in his mind. I'm not sure that delving deeper into this is a good use of my time. He seems to be making an awful lot of assumptions, some of which are going to be tricky to expose. The most obvious is that the competition is for block space, which is already not true today.* One more subtle is that the mining reward needs to pay for new hash power at roughly the current rate, which seems incredibly unlikely.** It looks like a very static analysis. He picked one thing that he knows is going to change, and figured out the ramifications by assuming that everything else was going to stay constant. Such thinking usually goes horribly wrong when incorrectly applied to complex systems. * The competition is for miner attention. Blocks are rarely full, and yet transactions, even some with fees, are waiting.** It didn't take many GPUs to make overtake the entire CPU network. It likewise didn't take many ASICs to overtake the entire GPU network. But ASICs are the end of that road; now all we can do is make better ASICs. There may be one or two more generational changes still coming as ASICs start to approach mass-market efficiency, but after that, improvements will be incremental rather than revolutionary. This means that the furious pace of hardware turnover will slow dramatically. Thus, mining rewards will only need to pay for operational costs and (relatively) modest upkeep and replacement, plus commodity-level profits. By contrast, prior to winning the hashpower race, the mining reward has to pay that much, plus finance very rapid growth. |
|
|
|
... words... endless, meaningless words...
Slow down there Dr. Maiden Lane - this is no FCDS. Any token of value is worth whatever you think you can trade it for. From wiki: A derivative is a financial instrument which derives its value from the value of underlying entities such as an asset, index, or interest rate.I don't see it... Just put him on ignore. His main rhetorical device is to repeat his baseless claim using lengthy posts devoid of meaning. He is indeed a philosopher, in the worst sense of the word. |
|
|
|
People want to have fast transactions. Miners want to have fees. Where these two desires interact, is where the market finds the proper transaction fee. People are not children, and thinking that they are is what has gotten this world into the state it is in. Central planning always fails. Hmm.. I mean Children in the sense that they are not informed about all the facts. Is that not a requirement for a free market to work correctly ? Total Information Transparency ? Which requires them to understand the information.. The Children don't know if they eat all those sweets they will damage their bodies, get fat, rot teeth etc etc.. If they did - they'd think twice about it. And 'happily' choose to only eat a few. They don't need "Total Information Transparency", they just need enough information to make a reasonable (not necessarily perfect) decision. The market for fees doesn't exist yet, practically speaking. We have no tools to collect and distribute the necessary information. Mostly, this is because bitcoin is still young. It wasn't born fully formed; we still have work to do. Allowing fees to float in relation to transaction value was a very wise decision. Setting a fixed percentage, even as just a floor, is impossible at best, and grotesquely disfiguring at worst. |
|
|
|
|
Show Posts
