Along these lines I've been working on bringing namecoin to its full potential, that is, acting as a modern day digital equivalent role to a legal Registrar. Open-Registrar is looking towards a user-friendly, cross-platform application of the peer-to-peer namecoin registration system. https://github.com/randy-waterhouse/Open-Registrarcomments, inputs welcomed. The idea is that anybody wishing to store hashes of important electronic documents, contracts, cryptographic keys, dot-bit names or whatever can. The incorruptibility of that publicly visible (registered) data being backed by the merged-mining power from the bitcoin-namecoin network ... and obviously your own resources to keep your private keys secure. Ever felt the ground shifting under you when you couldn't remember if that was exactly what you wrote in a document? Wondered if someone or something might have changed (hacked) your files? |
|
|
|
So I notice there are currently 6 servers the Electrum client is aware of ... just wondering if the servers can be made aware of other servers in the same way that the client is?
I didn't take a closer look to the source but i think electrum uses irc to find servers, so yeah it wouldn't be a problem for the server to be aware of other servers. But why would you need that? It makes possible the linking of servers into groups for auditing, cross-checking, etc. It offers other possibilities like a stratum network on top of bitcoin, a server-to-server network, or even just groupings of servers that electrum clients could log into and be ambivalent about which precise server they are referencing just that it is one of a trusted group, etc ... it may be easier for electrum servers to get blockchain update information directly from other electrum servers (in addition to the bitcoin network) since they share db architecture ... ... and lots of other reasons  Basically a network of servers is stronger and less centralised than nodes of lone, isolated servers. |
|
|
|
|
So I notice there are currently 6 servers the Electrum client is aware of ... just wondering if the servers can be made aware of other servers in the same way that the client is?
|
|
|
|
We are experiencing some issues with our tor server at the moment. Its not responding to its public IP address. There has been some rough weather in the area and a power outage. We believe that the UPS on the server may have ran dead before the power came back. One of us has to physically drive out to where the server is located and check on/reset it. Please give us a couple hours to get this resolved. Do not worry about your funds, we will be back.
Probably not the best idea publishing time and cause of outage on a public forum. You just narrowed down the possible physical locations of your "hidden" server somewhat. |
|
|
|
I just remember it being a chore... having to teach them about counting back change, waiting for it at the counter and making sure it was right instead of getting ripped off.
now they just expect to see their balance go up every saturday morning when I pay their allowance and regretfully go down when they want something. it's a million times easier now with bitcoin because exchange rates and change are calculated for you. it's just a number to them now.
I rant about the government printing money to pay the bills and comment that it's not fair I dont get to do the same thing, but I don't think they are up to that level of conception yet. I'm expecting that to kick in in about 5 years when they start studying civics in school and hopefully we'll have another full libtard in our family by then.
Another advantage of system like this is to avoid having the kids every transactional move analysed by predators looking to mine information on the habits of our most vulnerable. Keeping the kids out of the banking system, as it it stands, is an excellent idea, in fact it is probably a moral duty of an self-respecting parent. The kind of data that can be gleaned from the developing financial habits of the kids is probably a goldmine for the psycho-analysts ... and will probably live with the person forever, revealing their weaknesses to marketers, state-bodies, hackers and god-knows-who. |
|
|
|
|
The best quote I heard was the "... LIBOR has become dislocated from itself ... " , these were the kinds of psychological contortions they wrapped themselves into to justify to themselves they weren't involved in a criminal conspiracy to defraud millions of people from billions of dollars.
In the end though, the spiralling IT costs of wrapping secure app layers on top of an insecure core system, as they try to compete with inherently-secure systems, will cause the current system to bankrupt itself (and whoever else it manages to glob onto on the way down).
|
|
|
|
Not odd at all ... have you compared the overhead lately on the bitcoin network vs. namecoin network? E.g. there is no satoshi dice running on namecoin .. yet anyway.
Relative to the number of users namecoin is currently much more expensive to maintain. Or do you really think that namecoin has as many as 18% of the users as Bitcoin. "Relative to the number of users" huh?... and why would that be a relevant metric for anybody? To the end user, using namecoin to ensure a secure connection to a full bitcoin node is way cheaper than running a full bitcoin node ... or are you disputing that point? Obviously namecoin doesn't have as many users as the proportion of the hash power it commands, this is precisely the piggy-backing onto the bitcoin hashpower merged-mining allows ... this is the second time you have thrown up an irrelevant arguments without pointing out exactly where the problem is you are complaining about. Third strike and I'll assume you are just trolling. |
|
|
|
That's funny. Rushing to compete with Bitcoin crashed their ATMs.
Well maybe not so funny for the 12 million customers who's accounts have been frozen for almost a week now .... I'm just wondering if the unsaid words in all these articles on the RBS trainwreck are "security vulnerability"? Having millions of mobile devices suddenly able to have some kind of comms with the core banking systems sounds like a nightmare to me ... although I have no way of knowing how they are actually doing it. Makes one wonder though if the vulnerability that RBS has just discovered is in fact already out there, and waiting to do its thing, in all the other Smartphone banking apps that have been rushed to market recently? |
|
|
|
I just wonder .... the banks are rushing the Smart-phone apps out to leverage their brands and keep ahead of technologies like bitcoin ... has bitcoin phone app threat pushed some of them over the edge, technically speaking? (This guy seems to think so). http://www.thisismoney.co.uk/money/saving/article-2163048/NatWest-RBS-banking-problems-Millions-wages-meltdown-enters-second-day.html'More technical problems lie ahead for ALL British banks' Last week, RBS-NatWest launched a mobile banking app that lets people to withdraw money from cash machines using their smartphone. It is the latest bank to offer such technology as the industry moves towards making smartphones digital wallets. But the rush to offer new technology may come at a price. Experts warned that customers of UK banks would increasingly face such problems because of the rush to deliver new and evermore sophisticated services. Daoud Fakhri, senior analyst at consultancy Datamonitor Financial Services, said: ‘This episode is emblematic of wider problems facing the banking sector as a whole. 'Many providers, being early adopters of IT systems when the technology was still in its infancy, have been left saddled with inflexible core systems that are often several decades old, and that are increasingly unable to cope with the demands being placed on them. ‘The growing expectations of consumers around online and mobile banking means that the tensions between the provision of ever more sophisticated services and the capability of core systems to satisfy these demands are close to breaking point, and this increases the likelihood of episodes such as the NatWest mishap happening again.’ |
|
|
|
We assume this to be an independent probability.
This is a very strong assumption which I don't think is warranted. I agree, that was the bit I had trouble with also ... bit of a "who knows" though, i.e. unquantifiable. |
|
|
|
How do you resolve namecoin without having a namecoin full node Well obviously you would have to run a full node .... I thought you would know that? The rest of the questions are based on the straw man of not running your own node .... It seems kind of odd to me that you'd invoke running a full namecoin node as a means to avoid running a full bitcoin node— Not odd at all ... have you compared the overhead lately on the bitcoin network vs. namecoin network? E.g. there is no satoshi dice running on namecoin .. yet anyway. Basically if you want to trust a server to do the heavy lifting for a lightweight bitcoin client (the topic of thread), which it is increasingly likely most people will have to do, then you want the best security possible to authenticate with that bitcoin node server .... with the merged-mining hash power of the bitcoin network behind it namecoin offers similar security of authentication as a full bitcoin node (which is basically the best going right now) without the overhead. So it is a trade-off where you give up the absolute security of bitcoin, for a reduced overhead but piggy-back onto bitcoin hashpower to authenticate with a known good node on the bitcoin network .... I'd take that, it is the next best thing to a full bitcoin node. and only a partial means, since it doesn't do anything to tell you if the parties you're communicating with are actually distinct. Don't understand this part of your comment, before we go any further it maybe instructive to know how much you studied the namecoin system? |
|
|
|
How do you resolve namecoin without having a namecoin full node Well obviously you would have to run a full node .... I thought you would know that? The rest of the questions are based on the straw man of not running your own node .... |
|
|
|
|
Assume that you connect via the namecoin dot-bit dns to n chain-services controlled by different organisations/individuals .
(fixed)
|
|
|
|
That would make sense considering it would be much easier to convince a merchant to switch over if you could just say "download X software and you can start getting 0-1% transaction fees on certain transactions".
It would be even better to not have to convince a merchant at all. If it could function with existing merchant solutions and only be a change on the consumer side, I wouldn't need or want my bank accounts. I don't think these are mutually exclusive goals. The marketing for OpenPay would have several facets. The merchant side actually will focus on the severely reduced transaction fees, the lack of charge-backs and the ability to accept merchants without need of new equipment. The consumer side will focus on the security features (no one can touch your money but you) and of course the ability to spend BTC. There will also be an attempt to capture some of the un-banked marketshare as well. Lots of folks don't have bank accounts for one reason or another, lots of others are simply denied the ability to have a bank account without any due process at all thanks in large part to consumer reporting systems like ChexSystems. Thus for all intents and purposes, a person with an OpenPay card really wouldn't need a separate bank account once enough merchants begin to accept it. The complete proposal for OpenPay includes creating an infrastructure that allows an easy and seamless standard for transition between BTC , Local fiat, and back again. OpenPay as I've described it, is intended to be a payment standard AND a payment network. This payment network functions as a bi-directional, bitcoin to fiat gateway. It rides directly on top the bitcoin network and uses bitcoins as it's interchange currency. It is expected that other services will crop up to use the standard and create a healthy and competitive eco-system. To speed the adoption of, and promote the use of OpenPay, there will be a non-profit organization who's purpose is To promote the adoption of the OpenPay network by, #1 Developing the OpenPay standard and providing reference implementations of these standards for free or low cost, #2 Recruiting users (consumers, banks, exchanges etc) into the network. #3 Certify experts and provide an exchange of experts in OpenPay to assist incoming users in developing niche applications for the ecosystem. The proposed name for this organization is the "Open Payments Alliance", yes we've been calling it grandpa around here The only reason it's a proposed name instead of an actual name at this time is that a trademark search has yet to be completed and the name does seem like something that ought to have been trademarked by someone, however a cursory search shows nothing. I'm going to keep posting updates here a they happen, so stay tuned! Please do, this is sounding good. |
|
|
|
Multi-sig transactions and/or two-factor authentication can remove most of the risk of a 'Bitcoin card' ... so that the irreversibility is not a problem, except in an infinitesimally small number of cases, an acceptable level of risk.
I haven't taken multisig into account, just two factor. That's mostly because it's a new concept I'm not sure I fully understand. Is there a really good explanation of how that would work in the Bitcoin system? It might be I could incorporate it into this design, or rework the whole concept to leverage it properly. It is at dev stage, afaik, but Gavin has done a lot of work/testing on it and he is the lead dev. so it is probably not that far away ... |
|
|
|
I did not (but might).. I've just been using the install commandline from the linux download option at ecdsa.org.
Yeah, it's a little generous to call it a "linux" download .... Debian-Ubuntu is known to work, I don't know what else it has been tested on ... Edit: all right I tested the sudo pip-python install http://ecdsa.org/electrum/Electrum-0.59b.tar.gz#md5=4254bad432f44d61904b93917860069b on FC15 and it works. Note however though I already had the "slowaes" and "ecdsa" packages installed from previous deps on electrum work. I also tested downloading the .tar.gz manually, unpacking and running sudo python setup.py install inside the unpacked dir and that works also, but again with previous caveat about existing deps. So known to work on FC will be something like this: #
# use yum-ex and get packages PyQt4 PyQt4-devel
# or on command line
$ sudo yum install PyQt4 PyQt4-devel
# separately do same for packages python-setuptools python-pip
$ sudo yum install python-setuptools python-pip
# Install python modules ecdsa slowaes (crypto stuff)
$ sudo easy_install ecdsa
$ sudo easy_install slowaes
$ sudo pip-python install http://ecdsa.org/electrum/Electrum-0.59b.tar.gz#md5=4254bad432f44d61904b93917860069b
Note how the dep. packages need to be installed first, rather relying on electrum to install them. Anyway it is not good practice to "sudo" a whole lot of unknown packages onto your OS !! |
|
|
|
Can I get some love? FC16 2012-06-18:1919 PDT
[tux@powerball ~]$ sudo pip-python install http://ecdsa.org/electrum/Electrum-0.59b.tar.gz#md5=4254bad432f44d61904b93917860069b
Downloading/unpacking http://ecdsa.org/electrum/Electrum-0.59b.tar.gz#md5=4254bad432f44d61904b93917860069b
Downloading Electrum-0.59b.tar.gz (214Kb): 214Kb downloaded
Running setup.py egg_info for package from http://ecdsa.org/electrum/Electrum-0.59b.tar.gz#md5=4254bad432f44d61904b93917860069b
Downloading/unpacking slowaes (from Electrum==0.59b)
Downloading slowaes-0.1a1.tar.gz
Running setup.py egg_info for package slowaes
Downloading/unpacking ecdsa (from Electrum==0.59b)
Downloading ecdsa-0.7.tar.gz
Running setup.py egg_info for package ecdsa
Installing collected packages: slowaes, ecdsa, Electrum
Running setup.py install for slowaes
Running setup.py install for ecdsa
Running setup.py install for Electrum
changing mode of build/scripts-2.7/electrum from 640 to 755
changing mode of /usr/bin/electrum to 755
Successfully installed slowaes ecdsa Electrum
Cleaning up...
2012-06-18:1920 PDT
[tux@powerball ~]$ electrum
python-ecdsa does not seem to be installed. Try 'sudo pip install ecdsa'
2012-06-18:1920 PDT
[tux@powerball ~]$
Additionally.... $ pip-python search ecdsa
ecdsa - ECDSA cryptographic signature library (pure python)
INSTALLED: 0.7 (latest)
Tuxuvant : did you follow my Install instructions for Fedora posted earlier in the thread https://bitcointalk.org/index.php?topic=50936.msg948023#msg948023Would somebody mind posting them on the wiki or with the source or something for Fedora and other RH derivative users? |
|
|
|
|
Show Posts
