I started playing around a bit with your code. I think I managed to produce a bug (don't know where it is, though, might be in the upstream server) using the following code in the client. addy = (yield f.rpc('firstbits.resolve', ['1B3SX6Y',]))
yield f.rpc('blockchain.address.get_balance', [addy])
yield f.rpc('blockchain.address.get_history', [addy])
produces this: < {'params': [u'1B3SX6YRmVkXAxeNioAyWvjdfcek5eCFa7'], 'id': 14, 'method': 'blockchain.address.get_history'}
> {u'result': None, u'id': 14, u'error': [-1, u"Traceback: <type 'exceptions.Exception'>: Corrupted data from old electrum server\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:362:callback\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:458:_startRunCallbacks\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:545:_runCallbacks\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:1095:gotResult\n--- <exception caught here> ---\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:1039:_inlineCallbacks\n/mnt/sda3/home/nick/bitcoin/electrum-server/helpers.py:91:ask_old_server\n"]}
Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
Failure: custom_exceptions.RemoteServiceException: (-1, u"Traceback: <type 'exceptions.Exception'>: Corrupted data from old electrum server\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:362:callback\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:458:_startRunCallbacks\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:545:_runCallbacks\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:1095:gotResult\n--- <exception caught here> ---\n/usr/lib/python2.7/site-packages/Twisted-11.1.0-py2.7-linux-i686.egg/twisted/internet/defer.py:1039:_inlineCallbacks\n/mnt/sda3/home/nick/bitcoin/electrum-server/helpers.py:91:ask_old_server\n")
The servers spews a load of tx infos (as probably expected), but the json string seems to have overflowed or something. I tried investigating: http://blockexplorer.com/address/1B3SX6YRmVkXAxeNioAyWvjdfcek5eCFa7One of the transactions being pulled in: http://blockexplorer.com/tx/caa3eaa7bb72046f6e6cc81e21724d81271049bf493961592f63840b030b822bSo it's a lot of data. |
|
|
|
This is by far the longest last word I've ever seen.
Lol. I keep thinking the same thing every time I see the thread. It's like at a funeral, when the priest just doesn't want to finish. Get him below ground already and let's eat! |
|
|
|
I'd like to enourage pythonist interested in Electrum client to review code implementing new network protocol (proposed in https://docs.google.com/document/d/17zHy1SUlhgtCMbypO8cHgpWH73V5iUQKk_0rWvMqSNs/edit?hl=en_US - the last chapter is not finished yet). Repository of server is https://gitorious.org/electrum-server/electrum-server. You can start server by typing and run some easy client side by . You'll need to install Twisted framework (easy_install twisted). The goal of my project is to provide easy, extensible protocol and fast, flexible, service-based, multi-layer implementation. For now, TCP socket and HTTP(S) polling is implemented. Pubsub infrastructure described in google document (server which actively broadcast messages to clients) is in progress. This is alpha implementation and there can be some weird bugs thanks to asynchronous server implementation, but so far I don't see any of them. Feel free to ask me to anything or comment the solution. Constructive criticism is welcome. nick@zero ~/bitcoin/electrum-protocol/python-twisted $ python client.py --help
Registered <class 'services.ServiceDiscovery'> for service 'discovery', vendor 'Electrum' (default: True)
nazdar
[u'node', u'firstbits', u'discovery']
[u'firstbits.com']
[u'resolve', u'create']
1MarekMKDKRb6PEeHeVuiCGayk9avyBGBB
1marekm
so, after a rough look, it seems you implemented "firstbits" lookup by falling back to firstbits.com api, right? This seems to me it would be the time now to start implementing a "real" server? What exactly are you asking us to do? |
|
|
|
def mn_encode( number ):
return [words[number],] if number < n else [words[number%n],] + mn_encode( number/n + number%n )
def mn_decode( wlist ):
r = words.index(wlist[0])
return r + n*(mn_decode(wlist[1:]) - r ) if len(wlist[1:])>0 else r
Error -1: Stack Overflow Was that translated from lisp code or something? ^^ |
|
|
|
fizzisist, I would happily pay for the cable if that method works. I hate that "xilinx platform cable" anyway.
You would have to ship it to germany, but it should probably fit in a letter, right? If shipping is prohibitively expensive, I can solder myself given you tell me what goes where.
fpgaminer, would that work?
Hm, doesn't seem fpgaminer is reading this... Hi Molecular, yes it does seem like this is the easiest way to maintain support for the X5000, although you'd have to spend a little bit for more hardware. fpgaminer said he would test this out with his X5000, but I'm not sure he's had time to yet. It is a very slim chance that it won't work, though, so a test is really only a formality. How about I buy that cable, send it to you, and if it works you pay me for it? If it doesn't, keep the cable for a future project and we'll look for another solution. Awesome offer! Of course I'll go for it. I'll PM you my snail mail address. Thanks in advance. |
|
|
|
I have a graduate course in optimization this spring. Maybe I could use this as my project.
I'm up for getting involved with anyone who's implementing this coding wise.
I want in, too. Do you guys hang out on irc? There are many questions now, most importantly: what language could we agree on? I'd vote for java or python. |
|
|
|
How can you possibly determine
1. How many trading models there are and which ones
2. Proportion for each model
3. Whether you missed any models
1 and 2: by "teaching". We'd "guess" these values, then evaluate them against historical data, make another, hopefully better guess, try again... rinse and repeat. 3: as Dan argues, the set of models the "optimizer" has at his disposal does not necessarily have to be complete, just "good enough". |
|
|
|
"User account does not exist, try a different public_id"
does anyone else get the same error?
Yup, I'm getting the same message. ok, thank you! me too |
|
|
|
And yes, I completly agree regarding how a beginner can see things others can't, really the best of both is the best. As a programmer I am very aware many in my industry seem to have kept things hard for beginners, almost seemingly on purpose. Keeping things accessible is close to my heart, ironically working out the simplest way of doing something so that it still all works well can be very complex.
Sounds like you've been programming for a while. In the end you sometimes (if you're lucky), look at your egg of columbus asking: "why didn't I just do it like that in the first place?" That's why "stealing ideas" from others in this realm is to be considered smart behaviour. It's also why "patterns" have been so successfull. "to develop" sometimes means to start with something, then keep "developing" (changing, rearranging, cleaning out, morphing around, bending, hacking, adding, removing, abstracting,...) until you have somehting nice and simple that does the job and is often smaller, simpler and more usable than the "first working version" you had when you started developing. For me, at least, it's very hard to take a problem, think about it for however long it takes and then finally implement a good solution on the first try. This might also have to do with the fact that the problem is usually not well-defined in the first place. ok, I'm rambling now... better stop. |
|
|
|
Hmm. If only someone 200 years ago had devised a method for analyzing signals in terms of simpler signals... Honestly, financial signals don't really work well under spectral analysis. The feedback mechanism is too noisy. Doesn't fourier transform assume periodicity of the time domain function? If so, it'd be unusable for making meaningful predictions, no? Sometimes a naive approach by someone unencumbered can yield better results than using proven tools. I'm not saying this is the case here, just suggesting to not dismiss the approach prematurely. Surprisingly, fourier works perfectly fine on non-periodic signals, sorta. You can decompose any signal into periodic components, but in lots of cases those components aren't very meaningful. A random signal will decompose into random components, a DC signal will compose into odd harmonics, etc. If you model "the past" as being periodic, the future will just be predicted as "the past repeated", right? |
|
|
|
Fourier transform doesn't "assume" anything about your signal. It just is a different way of looking at the same data. What it does it make clear any frequency peaks or cutoffs in your data that you probably can't see in a time domain.
My best idea for "tricky analysis" would be to numerically model the trading models of others. In other words, try to predict the models that everyone else is using to trade, and then model that. So take all of the bitcoin in existence, and all of the money and divide it up by what model you think that money is following. For most of it, the model will be "no trading". It is really simple to model that. Add to that a random model. A certain amount of money and bitcoin will just act without any logic or reason. Add to that a buy and hold model for people wanting to horde bitcoin. After that, maybe something simple like a trailing average model. If the price is above the average, sell, if it's below, buy. The size of the trailing average would be a spectrum along which money would have to be allocated. Then a linear prediction model based model where a given time history is used to build a linear trend which is used like the trailing average again on a time spectrum. On top of this, add a panic sell model for buying/selling to minimize loss. Calculate for each timestep, how money moves between these models based on gains/losses, and also how untraded money moves into the market perhaps based on external events. Optimize the initial distribution on historical data and see if you can get any usable results. Of course this would in practice be a lot harder than I've made it sound, which is why I haven't actually done it. But since there are very few "fundamentals" governing the value of bitcoin, its price should be mostly dictated by the psychology of those trading it.
Excellent idea, it's nice to see someone is on this page as I've thought about this too and I've been reluctant to try it because of the amount of work it is to do it. Actually to have some benifits along the way I thought about going by roughly this route: - implement trading bot abstraction layer and market abstraction layer (benefit: be able to write "general" trading bots for multiple markets)
- implement some bots (benefit: have bot implementations for actual trading use)
- implement some real exchange apis on market abstraction (side benefit: you have usable trading bots)
- implement "simulated market" replaying historical data to test/optimize bots and swarm models
- implement some (continuous) optimizer (search algorithm) to find locally optimal values for initial state and flux model
- to close the loop, implement a bot that uses predictions made by our optimal model instance
I'm stuck working (very slowly) on the first 3 items and there's a lot of "implements" in the list that are either non-trivial or a lot of work or both. I am sure this idea carries some problems, too: for example the flux between the different trading models (or in-/outflux from outside) might be high and unpredictable enough to render the predictions unusable. I'm not sure wether introducing yet another layer on top here would be sensible. Maybe people (money) switching trading models can be modelled to be triggered by certain market conditions (e.g. your "panic mode"). Also individuals could be modelled to run out of money, for example, and are then forced to switch trading model. Should that be modelled down to the individual level or can that be modelled by flux to different bots? Will we end up with too many possibilities of "optimal distributions" and no predictive power in the end? I think these (and more) problems cannot be easily answered without getting our hands dirty and trying the idea. On the other hand: this just has to be better and more (automatically) flexible than technical analysis  Actually this has to have been tried already or be used in the wild (non-bitcoin trading world), no? |
|
|
|
|
small beautification request:
shouldn't line 22: from ecdsa.tuil import ... be in the try-block below to catch not-installed ecdsa?
|
|
|
|
Hmm. If only someone 200 years ago had devised a method for analyzing signals in terms of simpler signals... Honestly, financial signals don't really work well under spectral analysis. The feedback mechanism is too noisy. Doesn't fourier transform assume periodicity of the time domain function? If so, it'd be unusable for making meaningful predictions, no? Sometimes a naive approach by someone unencumbered can yield better results than using proven tools. I'm not saying this is the case here, just suggesting to not dismiss the approach prematurely. |
|
|
|
|
jeeesh! how much prize money are we talking about? or is this about "being right"?
|
|
|
|
Stefan Thomas ... his emphasis on splitting secrets across two independent hosts with different security measures was inspiring. When I tried to talk to him about the basic idea he left a narrow minded impression to me as my interpretation of his response was something like "you can do it your way. my software does it this way." Kind of a downer but maybe it was a misunderstanding. I feel like I should explain where I was coming from there. I'm definitely sorry I came off so dismissive. My point was that I don't presume to know what the right solution is. After the talk, I talked to ten or more different people and every single person had their own different idea on how it should be done. So at some point I just threw up my hands, saying "I don't know what the correct way is." We will have to follow multiple avenues and let the market decide. What people end up using/recommending and what gets hacked the least, that's the best solution. Thanks for clearing this up. When I read giszmos comment back when he made it, I thought to myself: strange, Stefan came across as a really nice and reasonable guy to me. Indeed we're looking at interesting times concerning solutions to how people can manage their money. Let's just hope we don't run into too big of an exchange rate bubble too soon. I doubt we'll run into another mybitcoin fiasco, at least not one of that magnitude. People are warned now and what Stefan and many others work on are much better solutions obviously. |
|
|
|
When the € goes tits up[...]
pix plz |
|
|
|
Thanks for posting the videos. They look and sound great.
+1, Excellent quality, Thanks All thanks go to worldly for some awesome editing! |
|
|
|
worldly (Mitch) finished editing the second talk. |
|
|
|
http://www.youtube.com/watch?v=0lpeZ01H_BkStefan Thomas, a web developer and bitcoin fanatic is the author of BitcoinJS. In his talk, Stefan argues the the weusecoins video he was involved with didn't actually accomplish what they where after: mainstream adoption. The reason for this being, as he says, that "the client itself, just isn't there yet". He gives a rough overview of the different types of clients that exist and explains how his project, WebCoin, fits in there. The main part of the talk is about WebCoin and different possible implementations of the Split Key approach to securing access to money.
|
|
|
|
|
Show Posts
