|
Note: For a minority of users, the bootstrap.dat "one huge 20GB file" import method does not work beyond 4GB of data. This is due to some limitations with large files on some 32-bit operating systems. It is planned to move away from a single bootstrap.dat file to a directory full of blkNNNNN.dat files that may be imported directly into bitcoind via "-reindex". The bootstrap.dat file also causes a 2x disk space increase over the "-reindex" method, which occasionally triggers complaints from users on low disk space cloud servers.
For these reasons, bootstrap.dat import method is being deprecated (at least with regards to this torrent). Today's torrent update will be the last bootstrap.dat torrent.
Future torrents will include the block chain split into multiple files, never exceeding 1GB in size.
|
|
|
|
|
Torrent officially updated! See OP. New height: 317,000 @ 22.5 GB
|
|
|
|
|
Just held an 8-hour Preliminary Design Review (PDR) with Deep Space Industries, covering all major subsystems, ground station details, power/link/etc. budgets.
Lots going on behind the scenes, as this contract with Deep Space Industries proceeds.
|
|
|
|
What about other trackers? Open, less politicized, trackers, that aren't associated with thepiratebay.se? Or maybe differently politicized trackers associated with other organizations? While those 4 trackers are reliable and well defended against DDoS, they are also the ones that are most commonly blocked/censored/filtered by various software nannies.
I don't pretend to be a tracker expert, and actively solicit suggestions. I would certainly bias towards less politicized + more reliable trackers. Please post your tracker suggestions. |
|
|
|
Beta-testing and pre-seeding a new torrent at http://gtf.org/garzik/bitcoin/bootstrap.dat.torrentPlease only join if you already have an old bootstrap.dat file, or you built the new one yourself using linearize.py and bitcoind.magnet link:
magnet:?xt=urn:btih:682759b001fac5d3b0d8517d2a179af2e65ebed6&dn=bootstrap.dat&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.ccc.de%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A80
|
|
|
|
Jgarzik, how does that design enforce two-way pegging?
There's no two-way pegging, which increases complexity. It gives what a sidechain needs at a minimum: Regularized block production, consensus on SidechainCoin's transaction timeline. |
|
|
|
|
Here's one side chain design that requires zero changes to bitcoin, and zero external parties such as oracles:
1. Put a block header for your side chain into an OP_RETURN output.
2. Core consensus rule: Only one sidechain block header per bitcoin block. If multiple sidechain TXs exist in a single bitcoin block, the winner is chosen based on highest transaction fees.
For any bitcoin miner, the transaction fee is returned to yourself, making it a very low cost proposition to mine this side chain. Akin to merge mining, adding such side chains should be cheap and easy.
If you are not a bitcoin miner, mining involves competing with random other parties to see who will burn the most money. A decidedly non-optimal scenario, particularly if bootstrapping without miners initially. But it does produce an easily provable consensus, and it could be mitigated with further rules (complexity++).
Obviously, this is very miner centric.
This is not as efficient as some scheme to stuff N chains into a merge-mined merkle root in the coinbase. It is also not a complete solution for the folks who want confirmations faster than once-per-bitcoin-block.
It does work within the current bitcoin ecosystem with zero changes, and at very low cost to existing miners. Possibly lower setup & maintenance cost than some merged mining setups. "Permission-less innovation" It could be deployed today.
|
|
|
|
It has taken a bit longer to put together the project update, but many things are happening behind the scenes. We continue to have regular design meetings with Deep Space Industries, designing the cubesat spacecraft and constellation. Big update coming at the Bitcoin in the Beltway conference on Sunday. |
|
|
|
|
Thinking that there must be only One Blessed P2Pool Chain is linear thinking.
|
|
|
|
That is a good option. I would love a dumptxoutset RPC command. Still if was an interesting project and I learned a couple things so that is always good. I never considered that for uncompressed keys in the output set you don't need to record all 65 bytes. could just record the x and recompute the y as it is done for compressed keys. I new tx version could save 32 bytes per input (Pay2PubKeyHash) or 32 bytes in the output (Pay2PubKey) by recording the PubKey in compressed format while still supporting uncompressed PubKeys.
There is gettxout, which could be expanded if it's missing some info. I doubt you will see a dump1gigabytedataset RPC added, though.  |
|
|
|
Yes, the WoT is a common solution. In order to scale well, WoT usually requires one or several centralizing entities that act as large signature hubs.
And even so, you still need a useful rendezvous mechanism.
LOL, a common solution? in what exactly? -bm Commonly proposed as a solution, to be specific. |
|
|
|
|
Yes, the WoT is a common solution. In order to scale well, WoT usually requires one or several centralizing entities that act as large signature hubs.
And even so, you still need a useful rendezvous mechanism.
|
|
|
|
|
Tangible progress is being made.
Disable-wallet support is rolled out in 0.9. This is the first step towards a public daemon being a separate process from the wallet. This mode permits disabling of wallet at compile time (no BDB or wallet code) or runtime.
Headers-first sync is the next step. This will enable a faster, more secure chain sync... and also enable a further wallet split.
At that point, the wallet may run as a separate client, talking to the public blockchain engine.
|
|
|
|
|
Fundamentally, two big problems to solve are rendezvous and communication, both user/agent and agent/agent. BitMessage attempts to solve these problems, but BitMessage has its own scaling and other code problems.
Users need to be able to find agents (oracles) in a vendor-neutral, open market manner, where one vendor may not DoS other vendors off the market. (vendor == agent's owner/operator)
And agents need to communicate with other agents in the market.
Once we have a good, decentralized chat room for market players to congregate and communicate, it is trivial to implement M-of-N oracles.
|
|
|
|
In light of the current "51% attack" brouhaha raging on Reddit, how difficult would it be to add some p2pool mining functionality to the picocoin library?
It would take several days of work, but it's not complicated. Basically, as you probably have guessed, P2Pool chain is simply another chain to manage. |
|
|
|
|
This fulfills the bounty conditions IMO.
|
|
|
|
If picocoin (or more specifically brd) is lightweight enough it could be built as a DD-WRT and/or OpenWRT package. We would then potentially have tens if not hundreds of thousands routers in peoples homes working as bitcoin relays.
It is more a question of whether or not a platform is heavyweight enough to support a full node. At first blush, you need enough data storage to store the entire blockchain (though perhaps mount over NFS), enough CPU to verify incoming data, and enough bandwidth to send and receive data. |
|
|
|
Hi Jeff, I'm trying to get my head around the brd.c code with a view to introducing LMDB to the picocoin project. There's a few things I don't yet get. It seems that brd no longer stores blocks in brd.blkdb (it's commented out in code) but uses brd.blocks instead. But, there are still attempts to write to brd.blkdb, like calling blkdb_add(), which I think will always fail. So, can the blkdb.c code be removed or does it just need a tidy-up? blkdb is required and is always used. It is the block header database. It is kept in RAM, as bitcoind does. It is optionally stored in a file, in addition to RAM. It is optionally regenerated from the 17+GB blockchain file, if blkdb is missing. |
|
|
|
|
Show Posts
