|
Hm, I read a post about issuing some new shares for buying new card here few days ago, right? Or it was another thread? Anyway, all shares are sold already, are you going to add second card?
|
|
|
|
I just pushed first version of electrum protocol implementation to https://gitorious.org/electrum-protocolIt's json-rpc based bi-directional protocol implemented (currently) on top of TCP socket transport. Current server implementation also support 'services' and service discovery; see 'service_repository/firstbits.py' and 'client.py' for an example. In the future I want to implement more transports (HTTP Poll, HTTP Push, websocket) and more client implementations (namely PHP client and plain Python without a Twisted). Some longer explanation of protocol design can be read here (last chapter "Services" is not finished yet): https://docs.google.com/document/d/17zHy1SUlhgtCMbypO8cHgpWH73V5iUQKk_0rWvMqSNs/edit?hl=en_USI'm going to implement proxy for services provided by current Electrum server to enable rewriting Electrum client to this protocol. Later it would be nice to have full Electrum server implementation in Twisted. |
|
|
|
|
My today's success story: Computer of friend of mine crashed two days ago. He went to some IT guy, asking for repair. That guy recommended "format & reinstall" (wow, are all issues with Windows still solving this way?) and asked, if backup of office document and some other stuff is enough for him. Today, friend called me that he has reformatted harddisk and fresh install of Windows and he completely forgot to his bitcoin wallet with 80 BTC, asking me if there is any way how to recover them. I played with pywallet some time ago and I barely noticed such cool feature of finding private keys on raw device, so I told him I'll try the recovery.
It went smooth (except that issue with corrupted blocks - which btw means that "format & reinstall" didn't fix previous issues with Windows) and his wallet has been fully recovered. Thank you jackjack for so cool application, small donation is going your way.
|
|
|
|
I'm trying wallet recovery on corrupted notebook disk, but it failed on IOError when pywallet touched corrupted sector. Following code fixes this issue by skipping bad block in first_read(): try:
data = os.read (fd, inc)
except Exception as exc:
os.lseek(fd, inc, os.SEEK_CUR)
print str(exc)
i += inc
continue
|
|
|
|
|
Agree, luck over 200% is pretty nice satisfaction for few last days.
|
|
|
|
It it just me or has the pool luck been really bad lately? 66% in the last day...
Yep, recent luck is pretty strange. Pool probably celebrated too much and now have a hangover... |
|
|
|
|
Red Emerald, I think we all understand benefits of green addresses. There's only the only problem with distribution of that list of trusted (green) addresses.
I like the idea to have some user interface for manually modifying "green addresses" in the client. If merchant decide that he want to trust Instawallet or Mtgox, why not, it's his choice. But distributing green addresses with client sounds dangerous.
|
|
|
|
|
Today it's exactly a year when I open the pool for public. Happy first birthday :-)
|
|
|
|
Duration Total shares Shares/Minute BTC reward Block #
0:55:03 824609 14984 0.18219482 157529
0:46:21 711990 15367 0.01990589 157519
Wait, what's "shares per minute"? It's calculated for total shares of the pool, right? So if your miner had a short outage, this value don't change... |
|
|
|
|
Reading email discussion about "BIP15 / Aliases" in development mailing list, lot of funny proposals here. However I pretty like proposal for using URLs for retrieving sending addresses. It's the most clean, easiest to implement and easy to understand by normal people, what I read there so far:
When you'll ask for receiving address, counter party give you general URL instead of Bitcoin address. HTTP(S) request to that URL should give you an address used to this transfer. It's on the decision of counterparty if this address is static (every HTTP request returns the same address) or it's randomly generate or counterparty provide you customized URL just for this specific trade.
Any reason why *not* implement this into Electrum (even if it won't be chosen as "official" alias system into standard client)?
|
|
|
|
|
If you don't agree with me, please propose some method how to approve disbursal accounts for distributed list in a decentralized way. Is MtGox trusted enough to add his green address into the list? Tradehill? bitcoin7? mybitcoin?
|
|
|
|
The replies from slush and SgtSpike show that they simply don't understand
I remember to our discussion about mining interface very well and I don't want to turn this thread to similar mess. Please stop repeating "you're doing everything bad". I think I understand GA idea very well, but current proposal does not fit to decentralized solution like Bitcoin. If somebody submit a patch which allow user to define custom set of addresses which will appear in client as confirmed even with zero confirmation, then - why not. But implementing some automatic updates of this list from centralized source goes against decentralized nature of Bitcoin and it's even not solving any real issue. And by the way not everything "widely used in 21.century" is good enough. |
|
|
|
"Green Address" is just a weird name for the old practice of having a "disbursal account".
Call it green address or disbursal account, but it don't change the fact that I don't see the point in implementing this into the general purpose client. It does not mean that I don't see the benefits, green addresses may be great for B2B clearing (like ewallets can trust themself up to some amount, so moving bitcoin funds from mtgox to tradehill will be instant). But I see that GA can be misleading for normal users unless they fully understand GA concept. |
|
|
|
OK, I just made clean git clone. Autoconf failed again, autoconf -i did something, then autoconf passed. I have another error in ./configure now: $ ./configure
configure: error: cannot find install-sh, install.sh, or shtool in build-aux "."/build-aux
I'm little confused. Am I doing anything wrong? My system is pretty standard Ubuntu 11.10. |
|
|
|
@slush, try autoreconf -i
$ autoreconf -i
Can't exec "libtoolize": Adresář nebo soubor neexistuje at /usr/bin/autoreconf line 196.
Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196.
src/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined
src/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
src/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again.
src/Makefile.am:1: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
src/Makefile.am:1: its definition is in aclocal's search path.
autoreconf: automake failed with exit status: 1
|
|
|
|
|
I must say that I don't see a point in supporting green addresses.
a) It expects some central point for making decision what's "trusted enough" and what's not, making client potentially weak from some kind of attack, especially when user don't understand what "green address" mechanism mean.
b) I don't think green address mechanism is needed at all. If you're receiving few bucks for a coffee, you don't need to wait for a confirmation at all. When you're receiving money for selling your house, you will probably wait for some confirmations in any case. So where's the use case for green address?
There are few proposals for decentralized solutions for preventing double spending which should be supported by Electrum servers rather than green addresses in the future. But for now I don't see double spending as a real problem.
|
|
|
|
I can't see what it was at the time of block 157519, but typically (like right now) it is about 0.18284650 BTC. When I compare the two blocks listed in my post, I see that duration and shares between the two are proportionately closer than BTC reward. I thought I should see something more like 0.18 not 0.019.
I checked those two rounds, but don't see anything wrong. It looks like your miners disconnected for some time, so your block reward was lower than usual. |
|
|
|
NMC block explorer is now working correctly, I'll find a time to recalculate nmc rewards during tomorrow.
NMC reward is fixed now. |
|
|
|
What's your expected block reward? I don't see anything wrong with those blocks. Should BTC for bock 157519 be recalculated?
|
|
|
|
Has this been resolved?
NMC block explorer is now working correctly, I'll find a time to recalculate nmc rewards during tomorrow. |
|
|
|
|
Show Posts
