I don't see any point in discussing this if you are just going to keep repeating your hypothesis. P.S. You should really learn to search better. |
|
|
|
|
What do you mean by "source wallet address"?
|
|
|
|
No one holds a FOREX currency against their will.
No, they don't. But if you could buy oil in anything other than Dollars, would there be as much transactional demand for Dollars? And don't forget the black market uses. So much of the Dollar is held, used and exchanged overseas, supported largely by the petrodollar and the might of the US military, that it makes the domestic supply pale in comparison. Well, let me start by saying that people can buy oil with things other than dollars, and have been able to for about 5 years. Over that period, the dollar index has grown higher and less volatile. Next, black market uses are about as close to free market as you can get. People operating illegally are already doing so under the threat of violence, so I can't see how the US could coerce them into using the dollar against their will. I'm forced to conclude that they use dollars because dollars are the most useful to them. Your third point is just a restatement of your conclusion. You don't win arguments by repeatedly asserting what you want to be true. |
|
|
|
Where eg. is the date/time of transfers ? The "lock_time" is a different thing, mostly zero. The block creation time might be interesting for miners or other internals, not for applications. Just because you mentioned it above, lets take another example: Above you write about "BlockHeader(80)" whereas in the https://en.bitcoin.it/wiki/Protocol_specificationthe field sizes of Block Headers are 81. You know it yourself: One byte difference on this level is enough to crash a complete app. Ahh, good. Specific questions. Transactions don't have timestamps, but blocks do. The timestamp on a block is considered to be the time that all of the transactions inside it happened. Lock_time is indeed something else. A transaction is not allowed to be included in a block until the lock_time has expired. If lock_time is less than 500,000,000, it is considered to be a block index. If greater, a UNIX timestamp. The header network message is different from the header that gets hashed. The first 80 bytes get hashed. The network message includes that 80 bytes, plus a variable length integer transaction count. I think I mentioned in an earlier post that the exact spot where the block header ends and the block body begins was a bit fuzzy. P.S. Your commentary on the whitepaper is wrong, deeply wrong. You may know a bit about banking, but you don't seem to know anything about the history of cryptocurrencies. Bitcoin is the solution to problems that you don't seem to even understand as problems. |
|
|
|
To take it seriously, you have to imagine that oil producers are using dollars as garden mulch because they aren't aware that there is a global market that will instantly and for very low cost exchange them for whatever currency they actually want to be holding.
Yup, they sell those Dollars right back to the countries that just bought oil from them, and then use those currencies to buy imports, or use the Dollars directly to buy imports from the US... which of course benefits the US as well. Doesn't sound so sinister when you realize that the dollars go to some guy in Ohio selling wheat, huh? Ends don't justify the means. I agree with that. Where we disagree is that you think there is some "means" going on which needs to be justified, when clearly there is not, despite what dozens of bloggers and other quacks say. Consider bitcoin. Say you want to accept bitcoin as payment, but don't want to hold it, what happens? You sell those bitcoins on an exchange, to someone that does want to hold them. Say your buyer also just wants to use bitcoin as a payment method, but thinks it is too risky to hold. Where do they get them? They buy them on an exchange. The net effect is that all of the value of bitcoins come from people wanting to hold them. There is some friction involved, in that it takes effort and fees to move dollars (or whatever) into or out of the exchange, but FOREX has very little friction. No one holds a FOREX currency against their will. |
|
|
|
To take it seriously, you have to imagine that oil producers are using dollars as garden mulch because they aren't aware that there is a global market that will instantly and for very low cost exchange them for whatever currency they actually want to be holding.
Yup, they sell those Dollars right back to the countries that just bought oil from them, and then use those currencies to buy imports, or use the Dollars directly to buy imports from the US... which of course benefits the US as well. Doesn't sound so sinister when you realize that the dollars go to some guy in Ohio selling wheat, huh? |
|
|
|
If you want oil, you can use whatever currency you have to buy dollars on FOREX, use them to buy oil a millisecond later, and the seller can then dump them for whatever currency they want (again on FOREX) a millisecond later. Maybe you missed it before. You can't buy oil on FOREX.And since the Dollar is the only currency you can use to buy oil, and every country needs oil, every country needs Dollars. https://en.wikipedia.org/wiki/Petrodollar_warfareNo, I didn't miss it. I just don't see the point. I'm well aware of what you can and can't trade through FOREX. You can't buy food on FOREX either. So what? Just because this crank theory is popular enough to have a wikipedia page, doesn't make it true. Here is the flow: 1a. Hans has Euros and wants oil. 1b. Ivan has oil and wants Rubles. 1c. Nameless other people (aka, "the market") hold Dollars, Euros, Rubles, etc and are willing to trade. 2. Hans sells Euros (on FOREX) to the market, gets Dollars. 3. Hans buys oil ( not on FOREX), from Ivan, using Dollars. 4. Ivan sells Dollars (on FOREX) to the market, gets Rubles. 5. Everyone is happy. Net demand for Euros: down Net demand for Rubles: up Net demand for Dollars: no change The petrodollar theory pretends that step 4 never happens. To take it seriously, you have to imagine that oil producers are using dollars as garden mulch because they aren't aware that there is a global market that will instantly and for very low cost exchange them for whatever currency they actually want to be holding. |
|
|
|
Due to the special character of currency, the supply and demand curve for currency is very different than any other goods/services
The USD is supported by GOD: Guns, Oil, and Drugs. The US military (Guns) blows the shit out of any country that looks to be shifting away from the dollar for sale of Oil, and it's the currency of choice for black markets (Drugs) the world around. That creates, and maintains, an additional demand for the Dollar that keeps it's price from reflecting the supply. Sorry, but this is bullshit. The dollar has value because people want to hold it. The existence of FOREX nullifies transactional demand as a source of value. Despite the many problems with the dollar and the US economy, all of the others seem to be worse. If you want oil, you have to have Dollars first. If you have Euros, you have to buy Dollars with your Euros in order to buy oil. You can't buy oil on FOREX. If you want oil, you can use whatever currency you have to buy dollars on FOREX, use them to buy oil a millisecond later, and the seller can then dump them for whatever currency they want (again on FOREX) a millisecond later. Perhaps some tiny sliver of value comes from those two milliseconds where people are holding them against their will, but the bulk of the value of any currency comes from people wanting to hold it. No force in the universe, not guns, not oil, not drugs, can compel people to hold a currency they don't want to hold. |
|
|
|
Due to the special character of currency, the supply and demand curve for currency is very different than any other goods/services
The USD is supported by GOD: Guns, Oil, and Drugs. The US military (Guns) blows the shit out of any country that looks to be shifting away from the dollar for sale of Oil, and it's the currency of choice for black markets (Drugs) the world around. That creates, and maintains, an additional demand for the Dollar that keeps it's price from reflecting the supply. Sorry, but this is bullshit. The dollar has value because people want to hold it. The existence of FOREX nullifies transactional demand as a source of value. Despite the many problems with the dollar and the US economy, all of the others seem to be worse. ----- Notice the magnitude difference, not 4x like FED is doing now, it was 100 times to 1 million times more money printed in one or two years. And combined together with large government spending in millitary at war time, people didn't have enough time to produce so much goods to chase those money
Due to the special character of currency, the supply and demand curve for currency is very different than any other goods/services
How do you think Germany got started down that road? You think they all got together one day and said, "Fuck it, let's print a quadrillion marks"? Or do you think maybe the started smaller but it grew out of control? Money is subject to market forces, just like everything else. We tend to think of things as having a price in terms of money because it is convenient to have a universal unit of accounting, but the reverse is also true, money has a price in things. If there are too many things, no one will want to part with much money to get them. If there is too much money, no one will want to part with many things to get some. This connects with what I said to myrkul above. Comparing one currency to another shows the market forces directly and plainly. |
|
|
|
This tool is really usefull to batch create password potected and/or generate trustable vanity keys for others. I do not really see your point. Just call keyconv-command with the protkey as argument and you'll be asked for the password. so e.g. ./keyconv PsvoctFZMEVEfASHPJ2sWAr6RFgEPz55hUPNEXMz4ZjSri28iNpmFUCQgYLBLs5Jh912 gives me the private key when answered with the correct password. Why would you like to have PKCS#8 formed keys? For making a protected key out of a normal one use -e (lower case) option, as discribed in the "help" (or line 31 of the code). No I am trying to figure out how to take a protkey and convert it into a private key. Look here |
|
|
|
Basing on that, I assume that you don't use any password manager. And basing on that, I assume you heavily re-use passwords between websites, as it's impossible to remember hundreds of really different and really strong passwords (especially for websites where you log in once a month).
Actually it's perfectly possible to manage hundreds of very different strong passwords without a password manager in your computer, if you go old school. Buy yourself a hard-backed book which remains in your desk at home. Write down the passwords for every different site in that book. That way, however long and complicated the password, all you need to do is look it up in your book. They'd have to locate your house and steal your book to get at them, and yes this means you can't open your wallet in the office. And, yeah, it's really old school - paper isn't popular in the mainstream world, but isn't it interesting how it is making a comeback in the bitcoin universe? That book is still a password manager. |
|
|
|
|
I don't think that this will be as stable as you think. I'm seeing a few places where you can expect positive feedback which will amplify minor swings into huge rushes.
Your whole security model depends on backers paying more than the market rate, in hopes of being paid an even bigger premium later. Since they only profit when the value of the backing instrument rises, they would be better off just holding that instrument directly, rather than using it to go upside down in a new venture.
At least that's what I'm seeing from reading this thread. I'm not entirely sure that I understand everything as well as I should, and I'm automatically skeptical of value fixing schemes since none has ever worked in all of history, at least so far.
|
|
|
|
Ahh, ok. In that case, you need to look at the header. The exact integer amount of work that a block is "worth" is encoded in the bits field. The wiki page describes the format, and someone already posted a link into the actual source where the calculation is done. If you are looking for the math that updates the expected next target once a 2016 block window has been completed, let me know. I think it is in main.cpp, and I can find it, it is just annoying to do from this computer. It basically calculates what the difficulty in the previous window should have been to get an average of 10 minutes per block. Edit: Oh, blocks that have the wrong difficulty in the header are rejected as invalid, so there won't be any subtle disagreements, |
|
|
|
Shouldn't it be the same? I guess it doesn't matter much, since a tie isn't likely to last long. Same? Tie? Work is based on the difficulty, not the hash. |
|
|
|
|
Ahh, fuck it. I was trying to cut you some slack because I figured english wasn't your first language, but you found it out.
All of it is top secret. The published source code is fake, the extensive documentation on the wiki is all fake, even the posts on the forum and to the mailing list are fake. Blocks are really just incomprehensible blocks of random data
|
|
|
|
Etlase2 and I have a history about this kind of thing. He proposes BS,and I point out it's flaws. It drives him nuts. He's being fuzzy because he is afraid that someone is going to point out flaws.
Wouldn't we need to take him off ignore before we could do that? |
|
|
|
|
I agree. This is far too urgent to put off until people come up with their own slang terms, we must decide this now, once and for all. It is also a matter too important to let languish in any of the hundred other threads, we should each make one new thread about it.
|
|
|
|
@kjj If its really all so "simple" - why isn't it likewise simply explained? Ah! What do you mean with "bitcoin is nested"  ?? What do you mean with "a lot of the complicated bits are in the interactions" To begin with: what exactly is that "interaction"? So far I only heard from transfers/transactions. If you mean the same, what exactly do you mean with "complicated bits" (bits?)? Maybe you would be better off asking specific questions. All of the information has been provided, but we are apparently unable to translate our answers into a form that is simple enough for you.  |
|
|
|
|
Ha! Finally, a way to donate to EFF with bitcoin.
|
|
|
|
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. Of course not! I fully expect a small percentage of miners to deploy this, and that's OK! That does not mean that we should encourage this behavior as a community by building it into the main client by default, however. The some protection that you and other see is an illusion. Code-wise, it is indeed an illusion. But that doesn't automatically mean that the human element in this is also 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.
Huh? They don't even need to run this code for that to be the case right now. All you need is for a miner to restart their node and a double-spend can get through just as easily. Remember that fork we had? For the hundredth time, this has nothing to do with safety, but with playing the odds. Fast food restaurants realized that they can save several seconds per transaction by not having people sign their credit card receipt, meaning that they would automatically lose any chargeback. And yet, that savings more than made up for the additional losses that policy brought about. This issue is not just black and white, nor is it even 50 shades of grey. I guess I had thought it obvious that none of this discussion applies when a merchant is actively managing their risks through other means. I have no objection to people making the choice to be unsafe. Hell, I don't even like seatbelt laws. What I don't like is people thinking that the network is providing them some safety, when it isn't. Your quote clearly indicates that you think that the network is providing " some protection for zero-conf transactions", but the network isn't doing that. The network is providing absolutely no protection until the transaction is confirmed, because confirmation is the only protection that the network is capable of providing. If someone wants to operate on hope, they can. But we need to stop telling them that hope and safety are the same thing. |
|
|
|
|
Show Posts
