Torrent works by breaking files up into pieces and hashing each piece. The parts that you already have will have the same hash as the hashes in the seed, with the exception of the final piece. Modern torrent clients will fetch that partial piece using the missing byte range, and then verify it with the hash. And naturally, they will also grab all of the new pieces.
Yes. I was talking about generating the file without having to download it. No point having torrents download the missing pieces when you already have them sitting in the blockchain on your hard-drive. Don't think that will work. Most bittorrent clients check the file size, etc. It would be super cool if some torrent client would be willing to serve matching chunks out of a file, even if the overall file is wrong. But none do that I'm aware of. These are specially cleaned block files. These are sequential, have no orphans, and no inter-block garbage. For virtually everyone on the planet, the first N bytes of their actual block files won't match these. jgarzik has already published his script, and I hope to publish mine soon. You can use them to recreate the file from your block database without having to download it. |
|
|
|
|
And for the record, when everyone thinks you're crazy, it isn't proof of some big conspiracy. We might have all just realized on our own that you are crazy.
|
|
|
|
Are you absolutely sure the dev team couldn't change the Bitcoin network drastically through an "urgent" protocol update that happens to be immediately accepted by most miners?
What, like in secret? Like all of the congressmen, all of the senators and the President all get together in the middle of the night, pass a law, sign it in blood, and then send out the gestapo to round up all of the devs and pool operators? Sure, I guess that could happen. But if it does, Satoshi will ride up on his unicorn to save the day. |
|
|
|
Although #bitcoin-dev supposedly is a open and transparent channel of the Bitcoind project, people were threatened for discussing a pertinent topic regarding development. Very suspicious.
Troll much? First, it wasn't an honest question, since you know the answer very well, or at least you should since it has already been answered it in a good fraction of the 94 threads you've started since you un-banning. Second, it really is off topic in that channel. Third, no one was threatened with anything more than enforcement of the channel policy. [13:23] <agent8423> when the US government needs Bitcoin to comply with antimoney laundering laws will you guys comply in your development? [13:25] <kjj_> agent8423: it has been asked and answered a million times on the forums. the government can ask us to change math, but we still can't do it[13:26] <agent8423> kjj_: you can release software that complies. you may have to fork the chain but you will have to. [13:26] <agent8423> we live in a nation of laws [13:26] <kjj_> agent8423: math is math. congress can't change math.For those of you not sure how bitcoin works, you "spend" bitcoins by giving the proof to an equation. The equation will keep working no matter what congress says or does. Worst case, everyone starts using TOR. |
|
|
|
scintill
Works like a charm. Is there any more info on how to generate a sufficient amount of entropy when generating key pairs for real world use (line 42).
Thanks!
Your best bet is probably to fopen /dev/random and read 32 bytes from it. Be warned that /dev/random will stall until it comes up with enough entropy to complete your request. Check /proc/sys/kernel/random/entropy_avail first, or use /dev/urandom (unsafe). |
|
|
|
I also have a PHP (!) script that parses the block chain and makes a clean sequential bootstrap.dat file. It is ugly and slow, but I wanted to have an independent verification. Our two scripts came up with identical files. And by ugly, I mean embarrassingly ugly, like I'd be ashamed to let anyone see it. If I have time this weekend, I'll clean it up and post it. |
|
|
|
Excellent. Though presumably it will be a slightly different length than whatever is torrented (which will be taken care of by the recheck-data option).
Why would a byte for byte copy be a "slightly different length"? How does it know the length of the torrented file? (Note that it is "identical", not a copy) Though from what jgarzick says in the post above there is some kind of checkpointing that it either knows or gets fed into it? Torrent works by breaking files up into pieces and hashing each piece. The parts that you already have will have the same hash as the hashes in the seed, with the exception of the final piece. Modern torrent clients will fetch that partial piece using the missing byte range, and then verify it with the hash. And naturally, they will also grab all of the new pieces. |
|
|
|
Roman has a "u" ?  -MarkM- Μ (μ), indeed, is commonly used alongside Latin alphabets. See this Wikipedia page. Ah, M as distinct from m? So we would write B1,30m,10M for 1.030010 BTC? I don't like it, as capitals "seem bigger than" lowercase, and having a "bigger" symbol for the "smaller" unit just seems gauche / uncouth / potentially misleading to small children / unaesthetic. Compare Lsd for pounds shillings pence vs LsD for same. Awkward. Unintuitive. Heh, no, and no. In Greek, the letter mu is written either as μ (lowercase) or M (uppercase). Since it is the first letter in the Greek word μικρός (micro) it has been adopted as the SI prefix for 10 -6. It is common to just use u instead of μ when writing with a latin character set (like ASCII). M (uppercase) is still used for Mega (10 6). And no one would ever suggest that silly notation you made up. 1.030010 BTC, or 1030.010 mBTC, or 1030010 μBTC. In metric, it is pretty much unheard of to mix powers like that. No one writes 1 Kilometer, 30 meters, 10 millimeters, they pick an appropriate scale and go with it. |
|
|
|
In IRC, we've started working on the torrent for bootstrapping. jgarzik and I each took our block databases and generated bootstrap.dat files from them, starting from the genesis block and going through (including) the last checkpointed block, 193,001 blocks in total. The bootstrap.dat has ONLY the valid blocks in it (no orphans), all blocks are in sequential order, and there are is no "extra" data in the file between any blocks. We used two totally different scripts and our own privately downloaded blockchains as the starting points. After an initial disagreement on whether to end with the checkpointed block, or the block before the checkpoint, we now have perfect agreement of size and hash. We expected this, because the bitcoin client verifies all of this data too, but it was still nice when it worked. He has created a torrent file and a magnet URL, he'll be posting it and making the announcement when everything is ready. Apparently it takes a while for the DHT system to sync up. The file size and SHA256 hash of the file are below. -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
2491771562 a3f258e7af030165360596e4cb0b9beb24b4ce97352c22e65349b89ad5fc5d3e bootstrap.dat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFQd4YcXZExftMAwEgRAthpAKC0JEiOhY3/aw06BhfLDQ2P7wdUDwCgpnQr
G+GDS3h5B+gsW81I0k2S0Ew=
=ro0i
-----END PGP SIGNATURE-----
|
|
|
|
So this:
[snip]
is more offensive than someone making fun of the entire bitcoin community by calling us idiots who use a made up currency that will fail, hacking everyone's accounts, getting a copy of everyone's passwords, stealing money from some users. You're an idiot.
Wow. You are still going on about this? Let it go and have your doctor adjust your meds. |
|
|
|
Again, relevance? Why would it be desirable to assert copyright claims to the blockchain?
Think of physical experiment, like Galileo using rolling balls on a track to invalidate the Aristotelian theory of motion. Galileo could claim copyright to his notes recording the motions, but it'd be ridiculous to claim copyright on the actual movement of the rolling balls. That's what you're trying to do with “copyright of the blockchain.” If you build a database on top of the blockchain with associated metadata, that'd be different. Blockchain.info holds copyright to their database with receiving-time and forwarded-by information on transactions. But the blockchain is not a record of physical events, it is those events. It's not copyrightable.
You point is valid, data itself is not copyrightable. That I understand. I'm trying to eliminate a layer of ambiguity for the right to modify an intangible asset using current copyright law (in the U.S. and broken as the law may be). In the model I'm trying to build, the private key is copyrighted by an individual. The "performance" of that individuals work is modifying the block chain with an entry. I believe it much easier to make this case if the property rights of the block chain are explicitly defined somewhere. My goal is to establish that private key is a "right to spend" using copyright law. Then I can defend the "right to spend" using the same law as a valuable property right regardless of the intangible nature of the assets it represents. That's the relevance. The problem with your scheme is that none of it is true. The key is not copyrighted, nor copyrightable, and there is no performance, not at signing, nor when the transaction is broadcast, nor when the transaction is packed into a block. On top of that, keyholders don't modify the block chain, miners do. Oh, and there is no block chain. |
|
|
|
|
The very question presupposes that a license is necessary. How about we think about it from the other side.
Who could make some sort of claim to the blockchain?
What sort of claim could they make?
And the third question, what would a judge think about such a claim when it was revealed that the content of the claim was intentionally uploaded, by the claimant, to a network designed with the sole function of widely distributing such things?
|
|
|
|
Sigh. I'm done with this 'discussion'. If you would like me to educate you further, send BTC to 1BQj536K9UdKexLbYvPvstc1awt8ZvJrBQ.
Meh. I've read most of your thousand or so posts; I don't think I can take any more "education" without puking. Very much looking forward to the launch of cuniculacoin though. |
|
|
|
How about the logical argument that I said, instead of the one the nonsense that you imagined me saying? I'll repeat it for you, and highlight a key point. "Proof-of-stake tends towards oligopoly/monopoly because stake has no ongoing cost and tends to accumulate."
So proof-of-work mining has capital costs and electricity costs. Proof-of-stake mining only has capital costs. Can you make a logical argument why this would matter? Hint: Consult an economics textbook. It doesn't matter. All that matters is whether returns-to-scale are decreasing, constant, or increasing. Because there is no cost. You make the investment once, and then benefit forever. Your hybrid system has this same flaw, an investment in stake multiplies your apparent work for all eternity. In POS, the returns-to-scale in stake is infinite. I note that the length of your wiki page on POS has grown rather large and convoluted as you keep trying to throw different crutches into the system to prop up first the fundamental flaws, and then the secondary flaws created by the earlier crutches, and then tertiary, etc... The source code for bitcoin is freely available, all of the functions for creating and verifying signatures exist already, there is room in the header to add a signature field, and none of your rules look particularly hard to implement. Go ahead and create your altcoin, exactly the way you want it, so that you can prove to all of us that we are wrong about your ideas. I'll bet you 1 BTC that someone like artforz will totally pwn your chain and have a near absolute, but still unstoppable, monopoly on generation within a week. |
|
|
|
P.S. Proof-of-stake tends towards oligopoly/monopoly because stake has no ongoing cost and tends to accumulate.
The system tends to oligopoly if the risk-adjusted rate of return on investment increases as more is invested. This is true in solo mining, but not in pooled mining or PPC coin's version of proof-of-stake. You are saying that if people reinvest minting earnings in minting assets, then their share in total minting assets will grow over time. Okay, but of course that is equally true in proof-of-work as well. Is there a logical argument supporting your views that I should be aware of? How about the logical argument that I said, instead of the one the nonsense that you imagined me saying? I'll repeat it for you, and highlight a key point. "Proof-of-stake tends towards oligopoly/monopoly because stake has no ongoing cost and tends to accumulate." |
|
|
|
You missed the point of this whole thread. How much Bitcoins each miner earns should be ... no, MUST be secondary to integrity of Bitcoin network.
You miss the whole point of Bitcoin. The profitability of being a miner IS integral to the security and integrity of the network. This is a severe flaw, not a feature. It can be avoided with better design. For one attempt, see PPC coin. LOL, yeah, checkpointcoin for the win. P.S. Proof-of-stake tends towards oligopoly/monopoly because stake has no ongoing cost and tends to accumulate. |
|
|
|
Just use whatever name you like for 1/1000, eventually one or more will catch on and be the de facto base unit.
At Seals we use 'chips' to mean 1/1000.
I agree with this. I do hope that we will use some other notation than mBTC and uBTC though. Putting a prefix in front of the currency code looks very akward to me. Would be much nicer to have a separate symbol for "millies" or whatever we choose to call them (like $ and ˘ for dollars and cents). This made me laugh. Cents is from the latin centi, meaning one part in 100. We just don't call them centidollars because after hundreds of years, the word has been worn down to a stub. Not sure that I get your point here. I do know that cent means one part in 100, just like milli means one part in 1000. My point was that we don't write cUSD, we write '˘'. We write 14˘ and we might write 0.14 USD if we use the currency code but we don't write 14 cUSD (I'm not american so correct me if I'm wrong). I don't think that I've ever actually used the cents symbol even once in my entire life. I rarely even write the word cents, usually opting for something more like $ 0.14. Also, keep in mind two things. First, dollars were around for hundreds of years before the concept of a "currency code" was ever imagined. And second, the world has effectively never seen a deflationary currency before, meaning that we've never ever needed more precision in a currency, always less. |
|
|
|
Solo mining is pointless because of Moore's law - if you are mining off a single GPU the rate of technological change will outstrip your ability to get the 50btc bounty even once. You can calculate it today based on the equipment you have today at the current difficultly - it will report in the next year you may get 50btc if you are lucky (based on today's values). But during the next year the difficulty will increase and processing power will increase so it will take you 3 years and then 10 and then 50 years. You may as well buy lottery tickets.
As a solo minor you will be forever chasing it, because of the increasing difficulty and the relative decreasing power of your hardware.
Wow. I'm really disappointed to see this misinformation still being promoted. It is completely untrue. It's perfectly possible to solo mine and solve a block with your very first hash operation— just unlikely. Assuming an idealized zero latency zero fee pool your expected return is the same either way. With real pools its somewhat lower compared to a well maintained local node solo mining (although that may be something of a stretch, the reference client has some scalability / stability issues that make maintaining it harder than should be, but we're working on that). I didn't read it like that at all. An "average" CPU is about 4 times as powerful today as it was 4 years ago (2 doublings), but the difficulty is 3 million times higher. That means an average of 30,000,000 minutes between blocks for a typical CPU, or about 14 years. What fraction of 14 year old CPUs do you suppose are still running today? The typical payout for CPU mining is zero, over the entire lifetime of the CPU, even though some people might get lucky. |
|
|
|
First, pools don't have much hashing power. The mining is still done by regular folks.
And? Also, the operators of the bigger pools tend to be true believers, very interested in the continued success of the bitcoin project. If that changes, the people using their services will switch.
Pool operators are humans, most with families. I hope you are aware what I'm trying to say. Second, solo mining is like buying lottery tickets. For most people, it gives no return on investment.
I don't see the investment if all it takes to start mining is to install easy to use software on a machine one is using anyway. Third, p2pool.
Does not solve anything, really. Just compromise those few hundreds which are contributing 51% or more. Fourth, that dude that was having problems with solo mining setup should have been asking for help with the specific mining software that he was using, or using different software, maybe something with a more active user community that would have been willing to help him figure it out.
What about maybe hundreds of people that found that same post and gave up themselves, seeing no answer for months? Fifth, did you even read Eleuthria's reply to your question about the minimum payout? Yes. Check my reply to his post. I'm fully aware of your paranoia, yes. Thing is, it doesn't matter how or why a pool would be compromised. Pool users would react to the compromise itself. The easy to use software is already installed. Open your bitcoin.conf and put in generate=1 (or gen=1, or whatever, been a long time) and you are solo mining. You seem to have no limit to the width of the circle of insiders that you consider to be critical to the safety of the system. You say that a dozen pool operators could be attacked, and when I point out a way to widen the circle to hundreds, you say that 51% of them could be attacked. Why not take it to the end and say that if everyone was solo mining, 51% of us could be attacked? E has good reasons for not doing dust payouts, and as someone that has been keeping track of the blockchain size for a while, I thank him, for all of us. If you, or anyone else, doesn't like his policies that he sets for his service, you can fuck off and find one more suited to your desires. |
|
|
|
About the power of end users' software:
I'm afraid it's essential that the ignorant majority of end users / miners does not end up running compromised Bitcoin software. I realize now that miners (and hence their software) have limited power (though still a bit scary), but the power of end user software could be even more: hidden code in the software could silently move control over transactions from the block chain to a centralized model. If this happens to all people simultaneously (because they use the same software) they wouldn't notice it until it's too late. This power is limited by market share of independently developed clients. Unfortunately, the Bitcoin client ecosystem isn't very diverse at the moment, and nearly all clients are derived from a single implementation.
I can't really think of any evil code that could be slipped into the software to change mathematics. Transactions are redeemed by proving that you know a secret number in a way that the whole world can verify. Adding a second path to that function to return true for any other reason would be laughably obvious, and embarrassingly visible to the few dozen people that actually read all of the pull requests, and the millions that could check them later. A variety of bitcoin clients is good for having a healthy ecosystem around the network, but the paranoia around the foundation and potential insider threats to the system are unfounded. |
|
|
|
|
Show Posts
