Pieter,
I am trying to make my blockparser utility work with your changes ...
In particular, it looks like blkXXXX.dat files do not obey the same structure as the
original blkXXX.dat files of the previous version (e..g sometimes the block magic
is not what I expect it to be).
They should be exactly the same as <= 0.7.1: 4-byte pchMessageStart, 4-byte size, data. If that is not the case, there is a bug that should be fixed. They block magic is not always pchMessageStart. It's very often zero, but looking at things closer, it looks like it's always close to the end of the blkXXXX.dat, and therefore, I suspect it's an EOF mark. The older blkXXX.dat did end exactly on the last byte of the last block. The parser in the reference client is extremely tolerant of extra cruft in the block files. Of course, it is only used to load extra block files and bootstrap files, but still. Since the real block files are never parsed sequentially in normal operation, they are allowed to be a little odd. Take a look at the reference implementation for a solid, robust block file parser. |
|
|
|
P.S. NTP has been around since 1985, if someone doesn't know if their clock is right or not, they deserve what they get.
I'm fully with you on the use of ISO format for dates, but I disagree on the NTP for autoconfiguration. NTP abuse is so rampant that it now has its own notable Wikipedia article: http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuseAnd thats just a tip of iceberg. In many locales servers like "time.windows.com" are unreachable because of the rampant abuse by the various software licensing/subscription enforcement schemes. McAfee private-label products were implicated in DDoS-ing Swiss government NTP servers, if I recall correctly. And apparently the situation is slowly getting worse, not better. Yeah, I know. On the other hand, DHCP can provide local NTP servers. Timekeeping is one of the things that really pisses me off. There is absolutely no excuse for any network operator to fail to provide and advertise local NTP servers. GPS receivers with PPS interfaces have been dirt cheap and quite common for 10 or 15 years now, and ntpd supports them all. Doing it right is well within the technical and financial means of any network provider. Hell, within the means of most college students. And device makers suck. It isn't hard at all to implement NTP properly, but no one seems to until they end up on slashdot. And times are changing; even the dinosaurs that have kept PBX systems in the dark ages have started to catch on. |
|
|
|
The clock might be wrong... but it's not gonna days or weeks wrong.
Hardcore Americanism detected!  The month-day-year versus day-month-year ambiguity with dates is an endless source of the errors that stick is thinking about. People in USA don't see is as often because most of the BIOSes and other low-level tools use the American layout. But it trips over many Europeans. Wait till Americans start importing Czech-made wallets that use day-month-year order... I personally hate the American system. It doesn't make any sense. Though, I'm not sure how relevant it is here: UTC unix time is the "path of least resistance" for storing timestamps in binary files, and thus wouldn't have that problem. Part of the reason I avoided this is because there's a lot that can go wrong with offline computers. The clocks could be totally wrong with no access to the internet, and thus they don't know the block height at birth, either. I could insert special cases where I know one or the other based on what information is available at the time it was recorded in the log file. But then I have to treat all conditions of {have/donthave} {block/time}. And as I said... I think getting it wrong and silently missing parts of the user's wallet could be a disaster -- those could literally be lost forever, because no program that ever reads the file would check before the recorded time. The end result is that users would just want to scan everything anyway, just to be sure. The european system is just as stupid, just incompatibly so. ISO8601 puts magnitude in the proper order on all scales, and there hasn't been a valid excuse for using anything else in a long, long time (when you need actual dates, not seconds-from-epoch). If you don't know the proper birthdate of a key or wallet, set it to zero so you get a full rescan. Key birthdates is something I wish for about twice a week. I do a lot of private key importing because I work with offline key generation. The raw transaction API lets me bypass a lot of that, but not all. If you don't think that key birthdays are important, just give it a few more years. If bitcoin is going to take off, transaction volume (and thus scan complexity) is going to grow much faster than Moore's law, and the rescan that you think is just fine now will be downright painful soon. P.S. NTP has been around since 1985, if someone doesn't know if their clock is right or not, they deserve what they get. |
|
|
|
Then maybe it's time to revisit. Anyone care to read this thread and summarize.
Summary: puppet said Usagi falsified navs, conveniently forgetting to mention that the spreadsheets in question explicitly state that all numbers are approximations. Then usagi redoes the spreadsheets to pull data directly off the GLBSE, and puppet/EB/etc cry foul again stating that usagi is using an unfair/biased formula. So usagi redoes the spreadsheets a third time, backed by shareholder motions, using both formulas and allowing investors to make their own decision about how to value the shares. The trolls go bananas and everyone starts to realize no, usagi is not a scammer, and the trolls are just dicks. Then GLBSE shuts down and "therefore usagi is a scammer". Unfortunately there are some people here who think they can say anything they want and that being anonymous on the internet will protect them. You just have to put up with their shit, I guess. This. The numbers weren't so much "approximations" as they were "pure fantasy" or "blatant falsehoods". I have no idea if you were doing mark-to-fantasy with the intention of defrauding your customers, or if you just really thought that your assets were worth that much. I will say that you were very inconsistent about how you did your accounting, which suggests, but does not prove, that you knew something wasn't right. Many people were pointing out the widening gulf between your numbers and the mark-to-market numbers, which should have made you sit down and take a hard, honest look at everything. Instead, you doubled down and got defensive about your bullshit valuations. I haven't seen any conclusive proof of malice, so I don't think a scammer tag is justified. But I sure won't ever invest in anything that you are involved with. |
|
|
|
|
Set up a RAM disk, copy your current blockchain files to that, start bitcoin using that for the data directory. Wait for it to catch up, then shut down. Copy the blockchain files back to your USB stick, start bitcoin from the normal data directory.
Starting from absolutely nothing, you can get the full chain in a few hours using tmpfs, assuming you can connect to a decent node for the IBD.
|
|
|
|
This whole argument seems a bit absurd since bitcoin the blockchain is itself in effect created credit and bitcoin the free open source software is a free to use credit-creation system. Take a good look at http://galaxies.mygamesonline.org/digitalisassets.htmlI think maybe no one has yet. The figures there continue to amaze me. Something somehow does seem to have been massively suppressing bitcoin exchange rates but fortunately it maybe also has diverted attention from some of its spin-offs. If there are not enough bitcoins to go around, or, as seems to have been the case for a year or more, bitcoin is somehow failing to represent enough value to serve as a useful unit of account, make more spin-offs. -MarkM- Dude. You keep posting that link like it means something to us. It does not. None of us have any idea what those numbers mean. |
|
|
|
I already closed this port on my Firewall.
The point is that in the german wiki, there is still stated that Bitcoin communicates over port 8333 and 6667, if it still does, I leave that entry, if not then I remove it.
So is port 6667 still used?
It can be used, but is disabled by default now. Also, it is outgoing only, it doesn't ever need to accept incoming connections on port 6667. |
|
|
|
|
The step about copying the chaining cert to the client is very important. Without that step, an attacker can man-in-the-middle you.
|
|
|
|
0.00095 BTC is worth about one US cent. Are you sure it is worth your time to try to get that penny back?
I really hope we don't end up with a large amount of perpetual txout bloat because that kind of thinking. Perhaps there should be some kind of "send all my private keys to charity" button that sends them to someone who can sweep them up. Wouldn't leaving it behind and never spending it be the opposite of bloat? If it is never spent, then there are no further transactions added to the blockchain that use that value, and the overall value of the rest of the bitcoin in use increases, right? On the other hand, if it gets spent, then that creates a new transaction that has to be added to the blockchain, which allows it to be used in another transaction that must be added to the blockchain, and so on indefinitely. So, abandoning it means no more transactions using it, and not abandoning it means potentially millions (billions? trillions?) of transactions using that value in the future, right? Due to people losing their wallets/private keys and people abandoning bitcoin that they find to be of insufficient value, it is expected that there will be a continuously growing number of txout that will never be spent. This would be the reason people refer to bitcoin as eventually being "deflationary". On the other hand, there certainly is reasonable argument that bitcoin is still very young, and that 0.00095 BTC that is worth less than a penny today could be worth $100 in several years. How much effort would you be willing to put in today if you believed that the effort would result in an additional $100 in your pocket a few years from now? Think in terms of stock and flow. The block chain is a permanent record of flow, but stock is what each client has to check every time a new block or transaction comes in. Flow (blocks) is easy, just a matter of storage. Stock (unspent transaction outputs) is what is going to hurt in a few years if we aren't careful. Losing a key and abandoning transactions creates permanent clutter in the stock that each node has to keep track of. Spending the transaction just creates one more entry in cheap storage. |
|
|
|
We should not be talking about cracking passwords on a BTC forum. If it is for "self security reasons" that will be ok, but the second people find out the new ASICs are really going to be used for password cracking...goodbye BTC.
Can't all cracking hardware be reversed to help secure rather than destroy? I'm not pointing any fingers, perhaps I misread the post. Password cracking is usually a red flag for me; never done it, never will.
 |
|
|
|
P2Pool release 9.0 tag: 9.0 hash: 2cb4d8381e179f71ea2075cdce948ea83cf0dc55 HARDFORK: Upgrade is required! Hardfork will happen after 95% of the pool's hash rate has upgraded. Everybody having not upgraded will be split off into a tiny P2Pool. Windows binary: http://u.forre.st/u/urxoztyg/p2pool_win32_9.0.zipSource zipball: https://github.com/forrestv/p2pool/zipball/9.0Source tarball: https://github.com/forrestv/p2pool/tarball/9.0Changes: * Transaction preforwarding Transactions that you're mining are sent to peers before you get a share, so any block solution you find can be broadcast virtually instantaneously. This could theoretically get our invalid block rate below any other pool's thanks to our large network of nodes. This was implemented in v8, but was prevented from taking effect due to a bug being discovered.* Stratum support in the P2Pool protocol. Stratum mining will be enabled in a future patch to v9. Any chance that you could put a list of supported block versions on the main status page? |
|
|
|
Currently there is no full client support. The reference client supports multi-sig but it requires ALL (in this case 3) keys to the in the SAME wallet.
The "missing link" is support in clients/protocol to support partial signing. i.e. deal goes good so A partially signs and passes it to B who partially signs and submits it to the network. Until that is implemented making a third party service is unlikely to be user friendly. So complete the transaction one or more parties would need to extract their private keys and send them to you so you can combine them into a single wallet and sign the multi-sig tx. I don't think anyone is going to do that.
The raw transaction API will be able to do this soon. The pull for it ( #1818) was merged into master, but I don't think it made it into the 0.7.1 release. You can use it now if you apply the pull and compile your own bitcoind. Or, wait until 0.8.0 is released Soon TM. If you are going to start doing this, take a look at BIP 10. It was made for something else, but I think it should work just fine here for passing the stuff around, perhaps with a few changes. Also see this thread for more information on using it. In particular, read Gavin's notes. When you create a multisig address using the API, you get a script, a hash, and the address. You need the script and the hash when you go to redeem transactions sent to that address. You can recreate them if necessary, but the keys have to be in the same order when you do. |
|
|
|
|
What is the situation here? Are you trying to shut down a wallet that has 0.00095 BTC in it? Or are you trying to pay someone $ 0.01 ?
If you are trying to pay someone a penny, you are probably stuck unless you do solo mining.
If you want to empty out a wallet, just send 1 BTC to it, wait a day or so, and then send the new total balance out.
|
|
|
|
To answer your question, laws limit the amount of deposited money that a bank can loan. The limit depend on the quality and size of the deposits. It is called the "reserve requirement" and it is set by the Fed in the U.S.
Fractional reserve banking (FRB) works whether or not the currency is backed by anything. In a nutshell, it works like this: I deposit $100 cash in a bank. The bank loans $90 of that to someone else. I believe that I have $100 in the bank, and someone else has $90. The perceived amount of money is now $190, although the actual amount is still $100. That's how FRB works. There is no reason why bitcoin can't have fractional reserve banking.
You have it backwards. Or rather the banks do it backwards. What really happens is that the bank makes a $100 loan first, and then seeks $10 in reserves. To the bank the order does not matter, as long as the reserve is in place before the regulators take a look at their balance sheet. I would say that it matters a whole lot. If you think that your deposit is enabling loans, and that banks can't make loans without them, you'll never understand how the system really works. Banks don't give a fuck about your deposit. 40 years ago, if you owned the steel mill in town, sure, your small town bank might care. That world is dead and buried. Banks accept deposits partly out of inertia, and partly out of hope that you'll bounce a check and pay them $35 for the privilege. Also, once upon a time, there was a meaningful difference in regulation between a deposit account and a demand account, but now through the magic of imagination they are effectively the same thing. They call this imagination a "sweep". In the modern world, banks just sweep up all of their deposits at the end of the day, and if they are under their reserve requirement their computer asks a computer in their local Federal Reserve district for an instant overnight loan and they pay a few millionths of a percent. If they do that too often, or for too much, the regulators start asking questions. Since the Fed has been bouncing on the zero-rate bound (for a while now), there isn't much point in even using the inter-bank lending process any more. Why borrow from another bank at a few thousandths of a point interest when the fed will do it for a few millionths? And those idiots making deposits will give it up for a few billionths, so they aren't entirely useless, but you have to wait for them to come to you, so the discount window keeps a thriving business. * parts of this post are exaggerated or otherwise inaccurate, but it is closer to modern reality than what you remember from It's a Wonderful Life. |
|
|
|
What we have nowadays, though, is a bit different, right? Fiat currency isn't backed by gold and can be created at commercial banks by a magical process called credit creation (or "credit expansion"?): the bank puts a new loan into its books as an asset and at the same time increases the balance of the customers account who took the loan by the amount of the loan. New money has been created. The bank cannot do this indefinitely, though, it need some "other assets" to back up the loans. Is that correct? How exactly does this work?
To answer your question, laws limit the amount of deposited money that a bank can loan. The limit depend on the quality and size of the deposits. It is called the "reserve requirement" and it is set by the Fed in the U.S. Fractional reserve banking (FRB) works whether or not the currency is backed by anything. In a nutshell, it works like this: I deposit $100 cash in a bank. The bank loans $90 of that to someone else. I believe that I have $100 in the bank, and someone else has $90. The perceived amount of money is now $190, although the actual amount is still $100. That's how FRB works. There is no reason why bitcoin can't have fractional reserve banking. You have it backwards. Or rather the banks do it backwards. What really happens is that the bank makes a $100 loan first, and then seeks $10 in reserves. |
|
|
|
. . .So the depositor isn't expected to use the IOU as money and it's usually not transferrable to a third part, it's just his account balance at the bank? He is still told he can withdraw all his funds at any time?. . .
Sounds like you are finally starting to understand what some people here are talking about when they mention fractional reserve. Pretending I run a bank as an example: Over time 3,000 customers have all deposited money with my bank. For the sake of this example lets assume that each customer has 100 BTC on deposit. My bank has in cold storage a total of 300,000 BTC set aside "reserved" for the purposes of honoring withdrawn funds or other debits against customer accounts. When one of my customers makes a payment to another of my customers, I don't even have to create a blockchain transaction for the transfer. I simply update the two accounts in my bank database. I only have to pull from the reserve and send across the blockchain if one of my customers is transferring value to somewhere outside my bank. Now, I come to realize that with some customers making deposits while other customers are witdrawing, my cold storage never seems to drop below 100,000 BTC. So I loan out 10,000 BTC from my reserve to someone I have determined has a high likelihood of repaying the loan. I still have 290,000 BTC in reserve today, and am confident that my reserve won't drop below 90,000 BTC through normal business. I now only have a fraction of my depositors funds in reserve. Any one customer could close out his account at any time and still be paid his full 100 BTC at any time. For that matter, most of my customers could withdraw all their bitcoin at any time, and I'd still have enough in reserve to honor those debits. So long as I continued to provid value to my customers and thereby gain additional customers to replace the ones who have left, there won't be a problem. Of course if too many of my customers loose faith in my bank and all try to withdraw all their funds at once, I will obviously eventually run in to a problem where I can't honor the last 10,000 BTC of debits. If my bank is insured by someone else who is willing to take on that risk for a small fee, then the insurer will have to pay off the last 10,000 BTC to my customers and take the loss against all the fees from all the banks they insure. Most likely, the insurer will at that time also take ownership of the loan and become the payee, further reducing their losses as the debtor continues to pay back the 10,000 BTC plus interest. As you can see, the person receiving the loan from the bank gets "actual" BTC. The account holders at the bank receive (or send) "actual" BTC whenever they make transfers out of the bank. The "IOU" is shared among all the accounts on a fractional basis that increases as money leaves the bank, and decreases as the bank takes in more funds. Ultimately the insurer pays off the IOU from the profits they acquire from the insurance premiums collected from banks that have not failed across the entire banking industry. Regardless, while there is still only a total of 300,000 "actual" BTC in existence withing my banking system at the time of the loan, an additional 10,000 BTC has entered circulation "out of thin air". As all my customers still have their full balances showing in their accounts totaling 300,000, but 10,000 of it has re-entered circulation in the hands of my debtor. The smaller the fraction of account balances that I hold in reserve, the higher the chance that customers will loose faith in my bank and I'll have to turn to my insurer to make my customers whole. This is an excellent description of banking. If someone wants to understand modern dollar banking, this is a good starting point, just replace BTC with USD in your head as you read it, and that brings you up to around 1913. There have been two "innovations" since then that work as a team to entirely eradicate bank runs. The first is the Federal Reserve System which can create money at will, in any quantity whatsoever, and lend it to a bank facing a run. The second is FDIC. Since money is imaginary anyway, there is no reason to allow a depositor to lose any because of bank mismanagement or whatever. |
|
|
|
I don't think so, because: BTC Banks cannot borrow Bitcoin from a central bank to buy more time.
True, no last lender means they have a bankrun risk, so that they should treat each loan much more carefully. This is by design Exactly. If loans can still theoretically be made and fractional reserve banking and interest can still be part of the loaning process, the fact that there is no last lender and the fact that it is a well know fact that there is a known total maximum amount of coins make banks run risks very high. It makes them higher than what you're used to, that does not make such risk "high". A bitcoin bank that fractionally loans out twice as much as it keeps in reserves can crediblely do so, so long as it's open and up front abou it's methods and long term CD's are it's primary method of raising capital (or some other not-on-demand deposit system). Except that the bank can't lend out bitcoins, but only something that can be redeemed for bitcoins. Would you accept a piece of paper that says: "can be redeemed for 1 Bitcoin at the first international bank of bitcoin at any time" instead of 1 Bitcoin? You've got it backwards. The borrower gets actual real bitcoins. It is the depositor that gets the IOU. |
|
|
|
Suppose you create an 8 of 10 multisig address and send a coin to it.
Can you now:
With any 8 of the 10 private keys digitally sign some text as proof of ownership?
What public key(s) need to be made public to do so?
Can you prove you have just one of these 10 keys?
OK leaving the current BIP as I understand it for now, is there some way a number of keys (say 20) could go into a signature in such a way that the 20 key holders do not know if theirs was one of the 8 ones which make the signature valid for the ownership of the coin?
There are two ways to do multisig right now, Conventional and P2SH. In a conventional multisig, you provide a list of public keys and a count of how many signatures are required for the transaction. As soon as you transmit that transaction, the entire network knows the list of public keys. In P2SH, you create that list, but you don't send it to the network. You hash it, and send that hash instead. Now the entire network knows that there is a transaction, and they will be able to verify that the right keys are signing it later, but until that transaction is redeemed, they won't know what any of the keys are. All of the public keys are revealed at the same time. If you want to prove ownership of a P2SH transaction without redeeming it, you can provide the script and people can verify the hash. Obviously, you'd need to provide the whole script for that, and that would have all of the public keys in it. You can sign arbitrary messages using any/all of the private keys, and people would be able to confirm that you did indeed possess whichever keys you used in this way. How many of them you'd need to use to convince them is up to them. 1 would prove that you are involved. 8 would prove capability of spending. 10 should strongly suggest that you created it in the first place. |
|
|
|
No, I meant exactly what I said, "no one else". Would you use bitcoin if, for example, the Federal Reserve Bank was the only miner? Exactly, kjj. This is not only the critical part but the final part because this will be the end of bitcoin. Attackers achieve their goal - bitcoin is crashed and current monetary monopoly stays intact! Again, there are easier was to do that, and cheaper too. That's why I say it is uninteresting, and why I had assumed that we were talking about something entirely different. |
|
|
|
at least until the point that everyone stops using the system entirely, at which point the only person left mining is the subsidizer, and he can set the difficulty to whatever low value he wants, but, and this part is critical, but no one cares because no one else is using it.
By everyone and no one you probably mean everyone and no one among miners?! No, I meant exactly what I said, "no one else". Would you use bitcoin if, for example, the Federal Reserve Bank was the only miner? |
|
|
|
|
Show Posts
