|
Cool but I don't see any usefulness.
This did inspire me to make a vanity address that is my HAM callsign, though
|
|
|
|
|
This is interesting. Anything that reduces the amount of trust required is good IMO.
|
|
|
|
Have you seen rsnapshot? It is a super simple way to do backups. The only problem is that it doesn't have any sort of encryption. maybe if you connected it with truecrypt, that could work. In my searches, I also came across http://duplicity.nongnu.org/. I haven't used it yet, but it sounds like it would be easy to do encrypted and compressed backups. EDIT: You really do have strict firewall rules! I added some code to "tor-route-disable" to get bitcoind and namecoind to accept rpc commands. #Allow loopback connections to bitcoind and namecoind
iptables -A INPUT -i lo -p tcp --dport 8332 -j ACCEPT
iptables -A INPUT -i lo -p tcp --dport 9332 -j ACCEPT
|
|
|
|
|
Glad to see this is coming along. I guess plain sockets are okay instead of JSON since it isn't too difficult to parse.
|
|
|
|
Is there any chance you can include Truecrypt as part of the default install? That'd be awesome  The persistent storage is already encrypted. How many times do you want to encrypt your wallet? |
|
|
|
|
I've setup a bookmark on my iPhone to use your site as a quick-and-easy wallet until a native app comes out.
Any chance of implementing a mobile-friendly theme? jQuery Mobile is stable now and makes it really easy to make a pretty site for lots of smartphones.
|
|
|
|
Where are bitcoins illegal? That doesn't sound right..
They are just afraid that bitcoins will become illegal and just want to stay away. https://instawallet.org/ is an easy web based wallet. It doesn't currently have a mobile version, but that's why you have a smartphone. |
|
|
|
|
I ended up using the IMG instead of an ISO.
It took me a few steps to get it working on Mac with VirtualBox like I want it to. (I don't have a machine that I want to boot from USB)
1. Convert the IMG to a VDI: VBoxManage convertfromraw -format VDI binary.img binary.vdi
2. Go into VirtualBox and create a VM with a harddrive w/e size you want (I chose 20GB, although it doesn't seem to be using all of it)
3. Clone the data on your new hd using:
VBoxManage clonehd –existing binary.vdi newhd.vdi
4. Launch VirtualBox and boot into the VM
5. sudo apt-get install gparted (not sure if this part matters)
6. make an EXT2 partition with label "live-rw" that fills the rest of the HD (not sure if this part matters)
7. Run the "Format Storage" tool. This overrote my large image with a 1.86GB crypt-luks.
Is there anyway to make this encrypted storage larger? I am running both bitcoin and namecoin and need the storage to be larger.
How did you get bitcoin to use /storage/bitcoin instead of $HOME/.bitcoin? I can't seem to find anything that sets that path, but I want to do the same for my namecoind. EDIT: aha! I found the wrapper scripts in src/chroot_local-includes/usr/bin/storage_wrappers/
I'll have some more pull requests up soon (mostly just fixing typos in docs and comments). I really like the notification scripts when anything happens. Great work so far!
|
|
|
|
|
I liked the idea of bitbills, but their site hasn't changed in a while. I like this approach a little more since these could fit in a wallet just like paper cash.
I still don't like the idea of the manufacturer having the ability to know the private key, but there isn't a way around that.
|
|
|
|
I'm building an IMG now. Wish me luck. I noticed that tor was installing from the debian repos. The Tor Project recommends that you use their repos to be sure you get updates ASAP. https://www.torproject.org/docs/debianI changed my build system's sources.list, but I've never worked with live-build before, so I'm not quite sure if I need to make a sources.list for live-build. |
|
|
|
|
There isn't any reason why this project can't work along side GLBSE. In fact, I think that would help make it much more successful.
The genesis block for our chain could contain everything in GLBSE at whatever time we decide to launch. When the chain gets launched, a new GLBSE back-end would also be launched that would use our chain instead of w/e database it is using right now.
|
|
|
|
|
This sounds completely unnecessary. There are far too many useful projects being developed to put time into one that is literally only different in name. At least you aren't making a fork of the chain, but I'm actually not sure if that makes your client any better.
|
|
|
|
Did you build the UPNP support? I'm adding namecoin to my fork and want to keep it consistent. How do I build an ISO instead of an IMG? I thought "lb config -b iso" would do it, but that doesn't seem to work.  |
|
|
|
I like this idea of this. We should get a .bit name registered.
Or just use the Osiris client, since it's distributed and all. It's harder to visit a .bit than to use Osiris. Well the client is great for desktops, but what about mobile devices? |
|
|
|
I'm discussing the hypothetical situation where the .bit namespace is allocated by ICANN to some registrar.
While I tend to agree it 'probably' won't happen - it's not so easy to evangelize a system based on such a fuzzy 'probably'.
If ICANN ever officially allocates .bit, then the namecoin network can switch to something else like .nmc. That is why the name records are "d/blah" not "blah.bit." I'm pretty sure I read a nice explanation of this on dot-bit.org, but now I can't find it. |
|
|
|
|
I like this idea of this. We should get a .bit name registered.
|
|
|
|
|
The ability to have three party escrow would be so cool!
|
|
|
|
|
I really like the idea of green addresses. Getting multiple large sites (MtGox and Installawallet) will definitely help us get code into the main client.
Having some sort of registry would be great. Maybe we could use a variation of the namecoin personal namespace (dot-bit.org/Personal_Namespace) so that anyone can publish an address. Then there would be some third party that could collect lists of the addresses that they are willing to trust by checking the namecoin blockchain. Merchants could then get a list from a trusted third party and not have to worry about managing the list themselves.
|
|
|
|
For all of your who are uploading your own design, I'd love to see them posted here in the forum.
My design that I submitted last week. (couldn't post because of the newbie restriction): http://img7.imageshack.us/img7/9558/creditcardk.jpgThis is just an example and not the exact same as the one on the website. The QR code is a different size. The font is different aswell. But the rest is the same. That's really clean, and my favorite so far. |
|
|
|
The JSON RPC must have been designed by people who can't write software.
It's slow due to the ridiculous HTTP overhead it has and it's design looks like someone who wants to talk to a program, not provide information over an API.
Considering how simple it it to create a socket interface I wonder about the naivety of those who chose it for bitcoin.
Why does "slow" matter for an app like this? Do you need to send thousands of commands to your miners at once? JSON RPC is also incredibly easy to implement in just about every language and platform, local or remote. Socket api's are not as standardized across lots of projects. What would you propose we use instead of JSON RPC? Now would be the time considering no code has been written yet. |
|
|
|
|
Show Posts
