So the EFF not only uses Tor despite the 'legal uncertainties' - and that 'no court has ever considered any case involving the Tor technology' but, they give detailed instructions on how Tor works and how to use it on their 'Surveillance Self-Defense' site: https://ssd.eff.org/tech/torThis is true, but from a practical perspective, the US government itself recommends Tor, and according to one analysis provides over 80% of the Tor project funding. Tor Project itself claims "militaries use Tor" and I have heard similar claims. There is plenty of precedent that EFF will not get in trouble for using and recommending Tor. Once that CIA starts paying clandestine agents with bitcoin, the EFF will start accepting bitcoin donations again, one presumes  |
|
|
|
As for BitcoinJ, I thought I read somewhere that it wasn't a full node at this time but might become one in the future. Can't find that post right now, though...
Correct. BitcoinJ is primarily focused on lightweight client mode, but BlueMatt has been working on adding the necessary verification code. Not there yet, though. |
|
|
|
Proprietary, closed source applications using cbitcoin library are permitted.
That is what I was saying and I thought (I shouldn't have said "derivative"). I don't want proprietary applications using my library but I do not mind if they are closed-source. I do not consider closed source applications as necessarily proprietary. I consider them to be free software as long as they allow for free distribution, reverse-engineering and modification. Open-source is just an option. The rest of the world does not consider that free software. Closed source does not permit easy reverse engineering or modification, by its very nature. |
|
|
|
Their code doesn't depend on bitcoind in the classical sense, but as far as I know, they do still depend on
it because they are not full-verifying nodes, so a network without bitcoind nodes to connect to can't operate properly (correct me if I'm wrong).
pynode and ufasoft-coin are full, verifying nodes. purecoin is too, I think, as is mtve's Perl bitcoin implementation. The full nodes actually on the network are still 98% reference client (bitcoind). |
|
|
|
What about linking to the library which is what I really mean to say. That's a different story isn't it?
LGPL:Proprietary, closed source versions of the library are NOT permitted. Proprietary, closed source applications using cbitcoin library are permitted. GPL:Proprietary, closed source versions of the library are NOT permitted. Proprietary, closed source applications using cbitcoin library are NOT permitted. In either case, LGPL or GPL, your cbitcoin code remains free software. Nobody is permitted to modify and distribute cbitcoin without also providing source code. |
|
|
|
RE: one vote per bitcoin: there seems to be some notion that Foundation member will be voting on things like "should a change to the core protocol be rolled out to support XYZ."
Umm, no. [...]
Technical changes will happen as they have for the last couple of years-- get rough consensus in the developer community then convince miners and merchants and users to upgrade.
+1 Quoted for emphasis. There should not be any major revamp in how development decisions are made. |
|
|
|
Correct me if I'm wrong but I believe all clients still depend on bitcoind. That is, the essential part of verifying and storing the blockchain and communicating with other clients is still handled in all clients by this one backend codebase. I may be wrong here as I have not checked all the clients myself.
This is incorrect. BitcoinJ, pynode and ufasoft-coin do not depend at all on bitcoind. Other alternate implementations also exist, in varying states of completion (bitcoin-alt, purecoin, ...) |
|
|
|
What I'm thinking about is a new license that aims to satisfy these two things:
1. Does not require source distribution alongside binary distribution of derivative works.
2. Places restriction on the license of derivative works but is more compatible with other licenses for linking purposes.
The second is the most awkward. It would need to be some sort of compromise between the GPL and LGPL to allow for compatibility but at the same time prevent proprietary derivative works.
LGPL prevents distribution of proprietary copies of the library. |
|
|
|
|
On a practical level, it is doubtful that the user community would trust a closed source implementation with their money, when so many open source implementations exist.
|
|
|
|
Well grondilu pointed out the linux kernel. That's not exactly "small, niche and useless to a vast portion of the community that would use it".
Irrelevant example, comparing apples and oranges. The Linux kernel is not a library. Applications do not link directly with the Linux kernel, therefore applications (obviously!) may be any license. I'm must say I'm quite surprised by this GPL hate. Where is the hate, in my message? I am simply stating facts. Linux kernel developers have been deeply involved in the arcane legal issues of licenses and linking for well over a decade. And even excluding my kernel work, you will see that many of my projects are GPL license: https://github.com/jgarzik (basically all the non-python projects are GPL'd) The Linux kernel example is simply not applicable to the cbitcoin licensing situation, because it is not a library against which people directly link their end user applications. The facts are: 1) If cbitcoin is LGPL, an application using cbitcoin may be any license. 2) If cbitcoin is GPL, an application using cbitcoin must be GPL. 3) Linux kernel is not a library against which user applications directly link. The kernel is GPL, but applications using the kernel's system call interface may be any license. |
|
|
|
Well grondilu pointed out the linux kernel. That's not exactly "small, niche and useless to a vast portion of the community that would use it".
Irrelevant example, comparing apples and oranges. The Linux kernel is not a library. Applications do not link directly with the Linux kernel, therefore applications (obviously!) may be any license. Not so, with cbitcoin. |
|
|
|
That is why many library developers chose to go with LGPL. It allows you to link to the open source code and protect your source code. If we changed or improved upon cbitcoin in any way, those changes would still have to be made public.
+1 Most libraries are LGPL'd or similar. A GPL'd library requires that all users be GPL'd. |
|
|
|
I'm confused! "Networks" cannot store data, they're networks. So someone somewhere on some storage media has the actual block data, right? I assumed it was everyone and that the most logical storage method would be a database and not a flat file. I get the indexing part, whether it's were to be in a database with the blocks as a separate table or not, since it allows you to find a block super quickly. But, if everyone deleted blk*.dat then who on the network are they going to download the new version from? Nobody would have it, lol. Unless it's generated by reindexing their local copy of the block chain that you're saying they don't have.
The entire network does not upgrade at the exact same moment. There will be many not-yet-upgraded nodes that will serve blockchain data to those upgrading to a new database index. 3GB is kinda big for an index file though, so aren't all the blk.dat files the chain data itself?
3GB chain data 1GB index is what I have here. |
|
|
|
OK. I see. I just didn't think the older versions of the Satoshi client would accept version 2 blocks, but I guess that's the case.
Over the P2P network, the Satoshi client will accept and relay nVersion=1 blocks until a super-majority of the network has upgraded to nVersion=2. Locally, if you are mining, the Satoshi client provides nVersion=2 blocks via 'getwork' or 'getblocktemplate' RPCs. |
|
|
|
I hope that miners some day will reward transactions that allow significant pruning aka merge many addresses. Why should I pay for a transaction of 50kB if after this transaction the blockchain shrinks by 49kB?
Yes, there are ongoing discussions about choosing metrics which encourage shrinking the UTXO (unspent output) set. |
|
|
|
In the next release, they will most likely make the switch to levelDB, which will be significantly faster in disk I/O. How would that possibly work? Everyone would download a new version of the blockchain database...from each other? When nobody has it? Lol, so the original releaser of the fully converted database would be able to put whatever the hell they wanted in it  So it'd have to be a very lengthy and difficult conversion process or a flat switch over supporting two databases, which is also not ideal. The block format used on the network has not changed. It is underlying database index on-disk that is changing. It is trivial to rebuild the database index: just delete blk*.dat, and download fresh from the network. The blockchain data itself has not changed, and continues to be self-verifying (integrity protected by hash). |
|
|
|
Jeff probably skims this sub forum for the same reasons I do-- entertainment, to keep my mind open to new ideas, and the chance that there will actually be some good ideas.
Yep. Open competition means there is always a chance somebody will create a better-than-bitcoin alternative currency. It is refreshing to see people trying new ideas beyond "change block #0 and call it jgarzik-coin" |
|
|
|
|
P.S. Note the color attached to smoothie's "ignore" link. This indicates that a profile is a frequently-ignored profile, usually for trolling reasons.
|
|
|
|
|
Show Posts
