|
rEnHyoQXk1GfosmLXRnNtoPuqpmfURh8o4
|
|
|
|
I take it that currently the US would have no jurisdiction to seize assets from a Japanese company, in Japan, but if those assets are now held in the US, by a US company does that not open up that kind of situation?
To my understanding USD is always held in the US, banks in Japan or any other country have holdings accounts with US banks, so if you have a currency account in another country, the USD still are in the US, it only appears to you they're not. https://bitcoinfoundation.org/blog/?p=63That's not strictly true, although it is the norm. US dollar deposits held entirely outside the US have existed since the 60's and are called eurodollar deposits (regardless of whether they are actually physically located in Europe - although originally they invariably were). They were basically created to satisfy the Soviet governement's desire, during the cold war, to hold US$ funds in the Western financial system but outside the reach of the US government. These days eurodollar deposits are fairly routine (and similarly eurosterling deposit are sterling deposits held outside the UK, and euroeuro deposits (!) are Euro deposits held outside the EU. roy |
|
|
|
Interesting ideas. At this moment I wouldn't dare sending someone 1000 coins without at least confirming the last few letters of the address over the phone or through another independant channel.
Be careful - it's pretty easy for someone to generate an address that has the last few characters they want (and first few, for that matter). People do it all the time with vanity addresses, but it could just as easily be done to try and defeat a simple 'over the phone' check of a few characters of the address. roy |
|
|
|
The default fee handling needs to prioritize transactions with higher fees. Most mining pools do this already, but the default client should too. If not all acceptable transactions could be included into a block, include the ones with the highest TX fee first.
This has been done for a long time. Surely only since 0.7? Or does that count as a long time in bitcoin time? :-) |
|
|
|
Yes, but it's a " so you're telling me there's a chance" can. With a=0.4 and wd=1, the chance that a share will cause a loss of more than a reward of a single block is about 1 in a quintillion, I think they can handle it. Ok, if that's really the case then I withdraw my objection. The probability of Ozcoin being wiped out at a=0.4 is many orders of magnitude lower than the probability of a meteor destroying all life on Earth :-) roy |
|
|
|
Personally I'd prefer a smaller a which would make the cap unnecessary.
The maximum value of a share is still effectively unbounded, even for smaller a, so a single share can still bankrupt the pool. This seems to me to be a different type of risk from that which a PPS operator takes, for example - where the rate at which the pool can lose money is clearly bounded. |
|
|
|
|
@ckolivas: I can see, for people who want a high variance pool to essentially gamble, that rewarding shares above current difficulty might be part of the attraction. Indeed, having the maximum share payout be (significantly) above 25 BTC would be, too. Given Graet is choosing fairly agressive parameters, I'm assuming that's what he's after?
@kano: that example isn't really that extreme. Assuming it's ballpark 30 times difficulty you'd expect the network as a whole to generate such a block every 30 blocks or every five hours. And you got less than half what you'd got if you'd mined that block yourself. (EDIT: so Ozcoin would expect to get such an event every five days or so - such events will average out nicely.) It's the tail events that pose the risk to the pool operator. (EDIT: eg the 1G share, which Ozcoin will find once every year-and-a-half, and which will cost Graet 400 BTC at a=0.8, or the 10G block that Ozcoin would expect to see once every 10-15 years which would cost Graet 2500 BTC. Hope I got my maths right, that was a very quick back of the envelope back of the bc -l extrapolation and I may well have messed up.)
|
|
|
|
Currently there's no upper bound on the value of a share... If someone finds a share of difficulty several billion, several quadrillion, whatever, it will just bankrupt Graet. It's possible for someone to submit a share that earns a payout of more than the 21,000,000 BTC that will ever be mined. Would it not be prudent to put a cap on the maximum payout from a share, say BTC 250 or BTC 2500 or whatever Graet feels comfortable with. (This would also have the side effect of making the variance finite. In reality such a payout limit already exists - but better to implement it in the maths than by bankruptcy  EDIT: Of course, this almost certainly makes the analysis a complete bitch. EDIT: Also of course, a simple cap would make the expected payout dependent on the work difficulty. I imagine there are ways of fixing that, at least if the pool is also willing to impose a maximum work difficulty when using this scheme. (The alternative approach would be a scheme that puts a cap on share difficulty, perhaps at some multiple of the current difficulty.) roy |
|
|
|
[...] and I'm 90% sure i've seen it report that pool 3 (slush) saw a new block, even when it thought pool 3 was dead.
I should add, I (think I) saw that immediately after restoring the network connection. I was assuming at the time it was just coincidence that a new block happened then - but maybe it's an artifact of the network outage... |
|
|
|
Steps to reproduce:
1. Ensure you are happily mining on pool 0, with cgminer showing all pools as alive
2. Pull the network connection and wait until cgminer declares all pools dead (may take a few minutes)
3. Restore the network connection. cgminer will declare pool 0 alive and start mining. Pools 1-3 remain dead indefinitely.
roy
Just to add, in this state I see cgminer maintaining TCP connections to all pools (including the ones it thinks are still dead) and I'm 90% sure i've seen it report that pool 3 (slush) saw a new block, even when it thought pool 3 was dead. So some part of cgminer knows the pools are alive and is talking Stratum to them, but for whatever reason they're not getting marked as alive for pool management purporses. roy |
|
|
|
I've noticed two problems with stratum backup pools, that still exist on 2.10.1. The bigger problem is that stratum backup pools can become permanently dead. This is only happening on my rigs with wireless connections, so maybe it's a problem with latency / packet loss? Second problem is that with failover-only disabled, most leaked shares seem to go to my getwork backup pool, even though it's last on the list. I have two stratum backup pools with higher priority than the getwork pool, but they rarely (if ever) get leaked shares. This is only a small matter, since share leakage is very low.
I need to investigate the dead pool issue. I haven't seen it happen myself. As for leaking shares, stratum and gbt pools actually don't leak shares at all with or without failover-only mode. You only get leakage if the primary pool is getwork and you're not in failover only mode. I think this is probably the same issue that I hit. It seems easy to reproduce. [EDIT: the dead pools issue, that is] I have pools configured as follows (2.10.1-ish build). Pool management is failover, failover only is disabled. stratum+tcp://us1.eclipsemc.com:3333 stratum+tcp://us2.eclipsemc.com:3333 stratum+tcp://eustratum.ozco.in:3333 http://api.bitcoin.cz:8332 (which upgrades to Stratum anyway) Steps to reproduce: 1. Ensure you are happily mining on pool 0, with cgminer showing all pools as alive 2. Pull the network connection and wait until cgminer declares all pools dead (may take a few minutes) 3. Restore the network connection. cgminer will declare pool 0 alive and start mining. Pools 1-3 remain dead indefinitely. roy |
|
|
|
|
v2.10.1 tag seems to be missing
|
|
|
|
Just had 2.10.0 fail to failover on me.
Also it failed to failback. us1 came back last night, but as of this morning cgminer is still mining on us2 (even though the pool management screen shows all pools as alive). I thought that in the default failover policy it was supposed to failback to a pool higher up the list, once it's been stable for a little while? roy |
|
|
|
api.mining.cz doesn't exist. use api.bitcoin.cz instead. Or, preferably, "stratum+tcp://stratum.bitcoin.cz:3333"
Sorry, I had a brain error when typing that, but I am indeed using http://api.bitcoin.cz:8332 (which auto-upgrades to Stratum anyway) I'll switch to the using the stratum+tcp URL if that's prefered. roy |
|
|
|
Ok, you and Con have convinced me that host CPU isn't of itself going to be a problem. But does this architecture really scale? What if your host is driving a couple of dozen 60GH/s miners? Are you confident that the USB bus will take kindly to hundreds of transactions per second? Are you confident that all host OSs you're targeting will service the USB interrupts in a timely enough manner when you're doing hundreds of transactions a second?
As for running a dozen 60 GH/s miners. Assuming we ever get to that point where a single device is registered as 60 GH/s [something tells me those ASICs will be recognized as multiple smaller devices], and somebody has a farm like that with a single controller PC, the miner could use ntime to reduce overhead if needed. Assign each device ntime+x, and send them the same work with a unique ntime [this is assuming the devices do not support internal ntime adjustment]. Not sure that helps a whole lot, except to reduce the number of Merkle roots the host has to compute (which we've already agreed is a non issue for the forseeable future). With your proposal the host still needs to send work to each 60GHz miner 14 times a second to keep it busy. (That's true no matter how it's structured as a cluster, I think.) roy |
|
|
|
Still seeing backup pools that use stratum+tcp URLs detected as down by cgminer (2.9.6) e.g. neither of these seem to work right as backup pools : stratum+tcp://us3.eclipsemc.com:3333 stratum+tcp://eustratum.ozco.in:3333 However specifying them as http (even though they're not) seems to work: http://us3.eclipsemc.com:3333http://eustratum.ozco.in:3333(Note I only see this problem for backup pools - specifying stratum+tcp for my first pool seems to work fine) roy Yeah, not ideal, is it? Just get rid of *any* prefix and let cgminer figure it out. eg eustratum.ozco.in:3333 I think Con answered this here, unless there is something different Yes, this appears to be something different, although it could well be related. The original problem with stratum+tcp:// URLs was fixed. |
|
|
|
You can still roll the time once per second, starting the second nonce field all over again. It really isn't going to be an issue unless some dramatic new technology that doesn't even exist yet is thought up and developed and manufactured and released in the decades ahead. Quantum computers anyone?
Why only once a second? An ASIC is going to run through all nonces in far less than a second - why can't it roll ntime rapidly at least for a few seconds? No one cares if ntime is exact to the second, as long as it's roughly right. You still haven't understood? To go through all the nonces with stratum currently as is, would require it to check 18,446,744,073,709,551,616 hashes. If that's not enough, you can just increase the size of nonce2 from 4 to 6 and get 1,208,925,819,614,629,174,706,176 hashes. This is without rolling the ntime at all. If that's not enough, rolling the ntime just once every second will give you 1,208,925,819,614,629,174,706,176 hashes per second. The argument (I think) is that you'd have to rebuild the merkleroot with each extranonce, which requires extra work to either be done on the CPU, or on-board future ASICs (would be recommended, due to latency of relaying new work between the miner and the ASIC), meanwhile with ntime rolling there is no extra building of work, just increasing a secondary counter in the header. Right. What I'm envisaging happening is that host will tell hardware to mine with a given block header and ntime range (from now to now+30 seconds, say). a 60GH/s miner will take about 2 seconds to complete this work. Then the host will increment extranonce and compute a new block header, and again tell the hardware to mine with the new block header and a new ntime range (again from now to now+30). So one transaction every two seconds per 60GH/s miner. The alternative, when driving hardware that doesn't support calculating Merkle roots, would be a minimum of 14 transactions per second per 60GH/s miner, maybe more depending on the design of the mining protocol. Ok, you and Con have convinced me that host CPU isn't of itself going to be a problem. But does this architecture really scale? What if your host is driving a couple of dozen 60GH/s miners? Are you confident that the USB bus will take kindly to hundreds of transactions per second? Are you confident that all host OSs you're targeting will service the USB interrupts in a timely enough manner when you're doing hundreds of transactions a second? It may well be a non-issue. But it just seems so easy to avoid potential problems here simply by allowing the hardware to work with an ntime range. ETA: is there a risk of USB bus contention if asynchronous notifications are rapidly coming back from a large array of miners (e.g. to notify completion of work units)? roy |
|
|
|
Just had 2.10.0 fail to failover on me. My configured pools are: stratum+tcp://us1.eclipsemc.com:3333 stratum+tcp://us2.eclipsemc.com:3333 stratum+tcp://eustratum.ozco.in:3333 http://api.mining.cz:8332us1.eclipsemc.com appears to have gone down (for stratum at least) and cgminer displayed the following: Lost 19 shares due to stratum disconnect on pool 0 Pool 0 stratum+tcp://us1.eclipsemc.com:3333 not responding Pool 0 stratum share submission failure ....and then nothing more (and no failover). The top of the screen still showed Connected to us1.eclipsemc.com with stratum as user ... And the pool management screen showed all four pools as dead. Restarting cgminer, it now shows only pool 0 dead, pools 1-3 alive, and is happily mining on pool 1. roy |
|
|
|
You can still roll the time once per second, starting the second nonce field all over again. It really isn't going to be an issue unless some dramatic new technology that doesn't even exist yet is thought up and developed and manufactured and released in the decades ahead. Quantum computers anyone?
Why only once a second? An ASIC is going to run through all nonces in far less than a second - why can't it roll ntime rapidly at least for a few seconds? No one cares if ntime is exact to the second, as long as it's roughly right. |
|
|
|
Early on I spoke to some of the ASIC-to-be manufacturers and suggested they do target testing for higher diffs internally as well, so I expect at least some of them to take a target as well That and as Eleuthria said, it's still insignificant CPU to test them anyway.
I'd just taken that as a given - it would seem to be madness not to do that in the ASIC. |
|
|
|
|
Show Posts
