What type of device will be needed to "listen" the BitSat broadcast?
I mean, normal computers/smartphones would be able to recieve BitSat blocks and transactions?
You will need some sort of satellite receiver. The exact specifications are being hammered out right now. At worst, you will need some sort of dish + equipment. At best, you will need a simple radio attached via USB dongle. Read the system specification PDFs on http://www.dunveganspace.com/goals/bitsat |
|
|
|
|
The BitSat project would like to thank Mohit Kalra for a 2 BTC donation, plus discussions of additional funding. Mohit is a bitcoin enthusiast and angel investor. Mohit currently runs a Zip Fastener Manufacturing Unit in New Delhi , India, and also a medium sized Data Centre. Mohit has been investing in Bitcoin Businesses for over a year now.
The BitSat project would also like to thank an unknown party for donating 1 BTC.
Project update #2 coming very soon.
|
|
|
|
|
Expect an extensive project update in the next day or two.
|
|
|
|
|
Because of stupid node selection, it takes a while to cycle through dead addresses passed to your node from other nodes. You can use addnode etc.
|
|
|
|
Holy crap! It's the fastest torrent I never downloaded
hehe, good! The idea is to get many long-term seeders. If we have enough, most downloaders will see an immediate, fast download. The torrent remains idle the rest of the time. |
|
|
|
Could someone explain why it is preferable to seed a torrent of the blockchain rather than just run a bitcoin full node? I run a full node and it sends between 500GB to 1TB a month of data to at least 70-95 connected clients. Yes, I opened port 8333 on the firewall/router.
It is preferable to run a full node. The torrent is a workaround until "headers first sync" is implemented, at which point, it will be faster to download from the P2P network. Today, the torrent makes some client syncs faster, and also lessens the load on the P2P network. It is more useful for the P2P network to be used for distributing recent information. |
|
|
|
|
The new torrent is now ready for public release.
Read the updated OP, and seed away!
Remember to reuse your old bootstrap.dat, which will start the new torrent at 81% (14G) of the new 17G torrent.
|
|
|
|
Do you have any pictures of these properties. The link below is not working anymore
The link in the OP is working: |
|
|
|
Hi, i pulled down and tried to compile picocoin on my system. Linux XXXXXXXXXXX 2.6.32-431.5.1.el6.i686 #1 SMP Tue Feb 11 21:56:33 UTC 2014 i686 i686 i386 GNU/Linux ( centos 6.5 final) now with the latest and greatest i found the following small mistakes: 1. in brd.c you need to include socket.h and netinet/in.h in order to successfuly compile. 2. in blkscan.c and most probably in many other places you create a dependency on glib 2.28 to 2.30. if i might suggest: in blkscan.c "print_txout(bool show_from, unsigned int i, struct bp_txout *txout)" you can do the following: #if GLIB_CHECK_VERSION (2, 28, 0)
g_list_free_full(addrs.pub, g_buffer_free);
g_list_free_full(addrs.pubhash, g_buffer_free);
#else
//addrs.pub cleanup
g_list_foreach (addrs.pub, (GFunc) g_buffer_free, NULL);
g_list_free (addrs.pub);
//addrs.pubhash cleanup
g_list_foreach (addrs.pubhash, (GFunc) g_buffer_free, NULL);
g_list_free (addrs.pubhash);
#endif
3. similar as above in txmod.c "mutate_outputs(void)" you can: if (!tx.vout){
#if GLIB_CHECK_VERSION (2, 30, 0)
tx.vout = g_ptr_array_new_full(8, g_bp_txout_free);
#else
tx.vout = g_ptr_array_sized_new (8);
g_ptr_array_set_free_func (tx.vout, (GDestroyNotify)g_bp_txout_free);
#endif
}
Thanks for pointing out several locations incompatible with older GLib versions. In general, #ifdefs directly placed in the library code are to be avoided. The pattern to follow is updating compat.h with #if VERSION < X
provide wrapper or full implementation of missing function
#endif
If there is a missing function, add the function to compat.h, inside a version check. |
|
|
|
|
Lot #5 is under contract (alas, not for bitcoin).
Lot #11 is still available.
|
|
|
|
I always figured that - Agents would act as competitive peers in a market.
- User software would communicate with multiple agents, and replicate accordingly.
Of course it need not be this way. RE chains: A chain produces a time-ordered sequence of events. That's not storage and typically you don't need to store actual data in a chain, even if you do need time ordering. You just store a hash, then the data may be stored and proven as needed in any fashion. One might imagine software and agents competing to determine the best replication methods at the lowest cost. |
|
|
|
No, sorry, I don't buy that.
You don't even really need a P2P network except for very basic things like publishing adverts. You just need servers that can sell their disk space and bandwidth in return for money. I prototyped the start of this some time ago with PayFile. Then they need to learn how to run themselves and manage their own resources, pay their own hosting bills, and advertise their existence.
But at no point do you need a new currency or new block chain, not even for funding development.
I don't know where the DRM mention came from. That's random. StorJ nodes are supposed to store encrypted data, are they not? I mean, they're untrusted.
Ah! I understand where the confusion is. Let me clarify. So what your describing is closer to gmaxwell's original spec where an agent is a temporary file store. That is a user wants to store a file for 24 hours on a server and pays for that. In that case you don't need a blockchain. Like I noted in private email, I like this project and hope it succeeds... but calling it "Storj" just generates confusion whenever it differs from the original gmaxwell design. You really want your own project name, and just give a shout-out to the project genesis: "Automaton, inspired by StorJ" |
|
|
|
|
Exciting new news coming mid-April.
|
|
|
|
../include/ccoin/compat.h:26: error: static declaration of 'g_list_free_full' follows non-static declaration
/usr/local/include/glib-2.0/glib/glist.h:53: note: previous declaration of 'g_list_free_full' was here
Diagnosis: Typically a system either (a) needs compat.h help due to older GLib, or (b) does not need such help. All systems should be either "a" or "b". Your system configured as both "a" and "b". The most likely fix is to make sure you have GLib > 2.30, properly installed with pkg-config support. Alternately, you may try manually editing compat.h to comment out the offending lines, and see if that works for you. #if ((GLIB_MAJOR_VERSION == 2) && (GLIB_MINOR_VERSION < 30))
...
#endif /* GLIB_VERSION < 2.30 */
|
|
|
|
Yes. bitcoin.org will be the new official site. It was "soft launched" (without announcement) as I was travelling and did not have time to adequately test, and then make updates. It is also about time to roll another torrent. I've also been considering adding a second torrent, which contains blocks/blk*.dat as you might find created by Bitcoin Core. New installations could download this blk*.dat torrent, restart with "-reindex" option. This will perform a zero-trust revalidation of all data, while eliminating the redundant copy of the bitcoin data (vs. bootstrap.dat). |
|
|
|
So... an engineering flaw that impacts everyone in bitcoin -- not just counterparty -- is exposed on this thread. The response... add an even worse method for storing data? This is childish, not professional. |
|
|
|
|
Show Posts
