|
I've been thinking about this, and it doesn't solve all the problems but it may help to address some issues, it does still require some participation from GLBSE, which even when this first happened may have been difficult.
GLBSE and Goat each provide a hash of the data given (the full list) GLBSE to confirm Goat's list, Goat to provide proof of the full data, and someone generates a list of salted hashes of each redemption code and publishes these hashes. This provides evidence of all valid codes. When Goat receives a code, redeemed first come first serve, and publishes the code and it's salt (preferably the hash as well for convenience).
This provides:
-Evidence that a code does or does not exist
-Evidence of a code being claimed or not
This doesn't fix:
-Two people submitting at roughly the same time (probably trying to scam goat).
-GLBSE giving out the same code twice (hopefully they wouldn't, but assuming no trust).
-Goat claiming codes (since he already knows them all).
|
|
|
|
Its not misdesign, its trade-off. The 32 bit nonce is old design, probably it looked great when only CPUs where doing mining, but right now it looks like a bottleneck.
It doesn't not look like a bottleneck. It provides a factor of four billion in reduction in whatever serial task exists outside of that. I have yet to see any evidence that it's a bottleneck. My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average. You are getting 140+ Ghash/sec on a single device? Today? In reality? +1 Most devices don't process one hash from 0 to 4 billion in (total hashrate/4 billion), they run several processes in parallel across several chips. So each of your 20 onboard chips are each (relatively) slowly chewing through work and needs a new piece of work every several hundred milliseconds. Also as Gavin said, send more than one piece of work for each handshake. Between longpoll and everything else that's setup, I don't see any reason not to have several pieces of work queued up and ready to go on the device side of the USB cord. |
|
|
|
Nope. It's placing data in 96 bits of zeros ... as I said ... and it is still inside the 3rd round that already exists. That's not a new round I'm adding - it's already there. 3 rounds is not a change, I'm simply pointing out what a lot of people don't even realise is there already. ... and ... that most of the data added in the 2nd round is 'zero' If I am correct in understanding Inaba's comments about the BFL ASIC, they may even support this possibility already. (i.e. if they do a proper full 64 round hash each time and the silicon doesn't decide how that is processed - rather the replaceable firmware) --- Also, as I said, you already need to consider 2 orders of magnitude in dealing with the hardware ... before ASIC turns up. ASIC is less than 2 months away and that's just version 1 of anyone's ASIC hardware. ... which is another order of magnitude at the absolute least. Considering a forward planning change set to arrive in 2 years (or even one year) - who knows what the hashing performance will be by then. Consider an old ATI 6950 graphics card - it has the equivalent of 1408 complex cores in it (integer shaders) If version 1 of the ASIC has the equivalent of say only 100 and the complexity is well below that of an ATI core, then performance gains could easily be 128x in just the next generation of ASIC ... yeah I chose that 128 number on purpose  --- Unless you have something new to bring to the discussion, I think this one has ended. What I was saying is that you could add just over 300 bits of to the current data structure without messing with the three total rounds performed (the same three we have now). Right now the move to bigger and better is cost prohibitive. While BFL and competitors can crank out massive machines doing in excess of a TH/s, getting MORE will cost more. Unless a giant like AMD gets into things, it won't be as cheap as a $200 graphics card. Also in two years we'll be halfway through the 25 BTC blocks. At a quarter of the current reward (in 4 years) mining will be much less profitable (assuming BTC value doesn't shoot up, and I don't think expecting it to double each time the reward halves is reasonable). Things are getting faster. Much faster. So what? It just sounds like panic to me. I do think we've reached the limits of what we can argue about though. If nothing else we're not getting anywhere. Any chance we can get more details on the flexibility of the new ASICS? |
|
|
|
Firstly regarding the change. The current hash is actually 3 passes though the 64 stage hash function (2 x sha256 but the 1st sha256 is 80 bytes so requires 2 x 64 stages) The first pass is unaffected by rolling the nonce value or any added data after it up to a certain size (and also would be unaffected by rolling the time value ... there you go hardware people - implement the Roll-NTime hack in there with a difficulty input also - but that would be risky ... and is short term) Anyway, the size increase change would be to have a version 2 (or 3 or whatever is next at the time) block with the nonce field having 12 extra bytes (96 bits) added after the current nonce (which is currently on the end of the 80 bytes) making the block header 92 bytes. The rolling would one of: 1) anywhere the hardware likes in the 128 bits that suited the hardware design best OR 2) a subset given by a pool to allow the pool to avoid having to do any other major work than generate new merkle trees every time the transaction list needs updating (all the time ) I'd also add that the pool should be setting work difficulty high enough to appropriately (ask organofcorti) minimise work returned and work lifetime small enough to reduce transaction delays What this change would mean is that ANY device designed with this option could be given work (and difficulty setting) and 'could' be given a time frame and then the device could hash up to the time frame and then stop, independent of the performance of the device (of course as some of the hardware vendors know, returning valid nonce's during hashing is the best way to give answers back) Thus we also wouldn't have the other problem that the hacks cause: Extra delays in Bitcoin transaction processing since the time frames could be set to an appropriate value to minimise this effect (seconds) and ALL devices could guarantee that they could work for that (short) time frame and the mining software could spend that time processing results and setting up the next work ... as they all should (already  ) --- Meanwhile, it is interesting to see people shift the problem around e.g. slush saying it is the mining hardware problem - the hardware should have a faster 'wire' to deal with the problem - but it could rightfully be argued that it is also the pools problem - they should have faster hardware and better networks as required ... both are valid This solution solves both I will also give a very good example of how such arguments about the hardware ignore obvious limitations: Xiangfu (as anyone with an Icarus should know who he is) had 91 USB Icarus devices connected to a single computer and a single cgminer instance running (with plenty of CPU to spare ) ... so with such a setup, you have to consider 2 orders of magnitude in performance ............... My solution is a long term solution that (of course) is not going to happen today, but it seems the dev fear of hard forks any time in the distant future (and the fact mentioned by someone else that this nonce issue was brought up 2 years ago) probably means it will never be fixed. No idea if there is much else to say, but I guess if the discussion has no more merit (due to this last point) then this is a far as it will go. --- Aside: there is a well known bug in the bitcoin difficulty calculation that gets it wrong (always) but since it's wrong by a small % and that it requires a hard fork, it has never been fixed. Yes, how much you get paid for your BTC mining work, is actually always a faction low I make this comment so as to shed more light on other comments about hard forks The example you give is probably the biggest reason this won't be put in there anytime soon. While allocating even another 300 or so bits (to keep things in three total rounds of SHA256) would be just fine by me, the difficulty involved in making such a change in very basic levels of the protocol. If we ever have to move away from SHA256 I think that would be a good time to do this, but right now the biggest problem is latency between pool servers and the other side of the USB cord. Getting things across the USB cord is becoming a problem and will need to be addressed by hardware manufactures. A few implementation details (GBT from getwork) will change, and things will keep on keeping on. Yea there's a bit of optimism in that, but I don't feel it's unwarranted. |
|
|
|
can you please rename the thread to something like " http://www.pyramining.com/ - Mining Company - discussion thead" ? Just edit the subject in your first post, maybe that makes it clear for everyone. Thanks. I click on this thread everytime it pops up in my watchlist, only to find reveals and that is annoying. I hope this fix it. I personally got a bit of sick satisfaction out of the plan to somehow cripple the accounts that continued to post here (deactivating links, not regenerating referral links, general bad things). I suppose that's a little heavy handed though, especially since most of it has cleared up pretty nicely. |
|
|
|
Generating a merkle root is exactly the same operation as the ASIC is specifically designed for already (double SHA256). No need to embed a CPU on the ASIC (an ASIC is a CPU, but one for a very specific purpose only).
That doesn't mean they should - it can be done at any stage (in the pool, in the computer controlling the asic, in some intermediate controller chip, ... I don't care). The point is that this is not hard; it's only different from how the current infrastructure works.
While the merkle root does use double SHA256, the optimizations are different. Where dsha(h) = SHA256(SHA256(h)), the merkle root is dsha(dsha(A+B) + dsha(C+C)) (for three transactions, one of which is the generation transaction). And the block hash is a highly optimized (for fewer operations which leads to quicker completion and higher speeds) down to precomputing the first round of SHA256, and running through one of two rounds of the inner iteration of SHA256 (the other being precomputed in the previous step) and the first 94% of the second iteration (the last 4 rounds don't matter). TL;DR on that - merkle roots are a normal hash, insert data get answer. Block hashing wants a hash with a certain property and tries over an over with slightly different starting conditions to get a "special" end result. One cares about getting an answer for a specific input, one wants a specific output from a generic form of the input. Also, because of several factors, it's a lot harder to make the merkle root generation in silicon (I'm sure it can be done, there's just not as much point, you can make them much more easily than hashing them. A few hundred hashes versus a few billion). Also, an ASIC is by defenition Application specific. While you could make one to generate merkle roots via serial input, it'd be a lot of work for not a lot of gain. A CPU just does whatever you tell it to do. Generally on an embedded device like a mining rig a firmware update (more generally, a change in software) could completely change what the CPU is doing (for instance change how the merkle root is generated based on a new BIP), but the ASIC is stuck doing the exact same thing that it's orignally hardwired to do until it breaks. Again to suggest a mining rig with fairly simple setup of plugging into ethernet and power cords (and configuring to a pool) could use a microprocessor to do all the work (talking to the network, deciding what transactions to include) EXCEPT crunching blocks which would be left to the ASIC part of the chip. |
|
|
|
... So ... where is extra nonce referred to in the original Bitcoin document by Satoshi? Oh it isn't.
The same place scripts are referenced as well as locktime and nbits. Quote it - coz it isn't there. Have even ever read "Bitcoin: A Peer-to-Peer Electronic Cash System"? From wikiI don't know the code well enough to reference it, but here's a reference by Theymos on the wiki from December 2010, which at the very least predates anything fast on the network. Per http://bitcoin.sipa.be/ the network back then was under 100GH/s. So yes, people have been worrying about 2^32 not being enough for a long time, however if you're able to spin the merkle root yourself it's not a problem. Or if you're able to get a new one with relatively low latency (ie. Not from a remote web server, ie. pool) every time, it's okay and you can hash away on it. Nothing about spinning new merkle roots has to be in silicon, a small microprocessor (CPUs on my ASICs?!?!?) would work fine, and probably exists there for other reasons, although it may not have enough power to do anything useful like generate new merkle roots. |
|
|
|
Well there you go then. Because you know of no other method that your own, anything else must be false!!!
I do not sugguest there is a silver bullet, however, by being clever about things you can easily reduce your return time and hence your profits!
Still just skeptical. By design there's always going to be a bottleneck. Otherwise pyramining is just giving money away. The wait time is stuck in somewhere, even as your own referral one account at least has to wait. The 30% moving up the chain of referrals always moves up if there are any uncompleted referrals above you. Using an account with no referrals itself speeds you up by 15%, so it would be faster, but you have to know where one is first. Feel free to prove me wrong, but at this point I don't believe there's a magic way to game the system. |
|
|
|
I would say there is no magic formula but you can be a lot more clever than just getting referals! There are more intelligent ways of doing this rather than just opening an account, putting all your BTC in it and asking for referals!
Definitely. Just opening one account and running it gets you 10% returns and you pay out 30% (until their completion) to your upper level referrals). Opening two accounts (one as the other's referral) gets you 15% and you're paying 15% of one's referral to the senior account (slightly faster to complete the first account). Using several accounts like this you can get closer to 20% (using 10 accounts gets you 19% for instance). Doing it exponentially (0.1, 1, 10, 100, 1000) gets you closer to the 20% returns (without referrals) and referrals speed up payout and increase your bonus. I am entirely unaware of anything else you can do to speed payouts and I'm skeptical of anyone who claims otherwise. |
|
|
|
Sigh - it does become rather silly if you look at it from this perspective:
People are suggesting ways to solve the problem that the nonce size is too small (including Stratum and that other guff like that)
So ... what's the problem?
The nonce size is too small (as everyone agrees so far who has posted)
So ... make it bigger ... as I said in the first post 3 months ago ... though as I said later - 128 bits is a very long term solution.
... and as I said on the previous page ... create a version 2 block type that has the bigger nonce and set it to some time in the future
Yeah we've already lost 3 months ... though I guess in another 3, 6, or 9 months this wont be fixed and people will have the same excuse then that hard forks can't be done ...
The nonce size is too small (as everyone agrees so far who has posted)
I would like to very explicitly disagree with this. I've never thought this and I joined the thread over a month ago I'd say. There is no reason to go through the trouble of a hard fork to implement a solution in search of a problem. If this were put up for a vote by miners (similar to bip 16) where miners vote with their hashing power (though I do think this gives mining pool operators extra say since they're voting with their entire pool's hash rate), since they're the ones most affected and the ones who should care. |
|
|
|
WTF I just read. Use block version as extra-extra-nonce? * slush is checking today's date; no today isn't 1.April Yea, that's been my reaction on a lot of these proposals. To me a lot of this thread seems like "Holy crap, ASICs mean nonce won't be enough and bitcoin will break and my 56 billion bitcoins will be worthless because the network will break and my 23 TH/s rig won't be able to request work fast enough. And then ways to radically alter the syntax of the block to allow for more play room in each block (doubling the nonce range (which is one of the more sane requests), using two bytes of the version header as extra space for nonce, making things up to add in as extra hashes). Don't get me wrong, especially for larger rigs (BFL's 1.5TH/s for one) trying to use difficulty 1 getworks from a pool server isn't realistic at all. What I'd like to see is a small device (think the size and power of a phone or home router) that can manage a few miners (say around 10 TH/s of miners) over a local connection (which would help keep latency low among other things). On top of that I'd like to be picky and say that everything should be connected via ethernet, possibly even using power over ethernet (up to ~25W / 25GH with BFL's current specs). Just imagine if setting up new mining gear involved plugging in 1 ethernet cable per miner (plus a little config setup, or possibly them automatically syncing to the mining sever they're connected to). |
|
|
|
If you want a hand to maximise returns, let me know. I have a claculator which I can share with you, to show you how to make the most from your deposits.
Depositing with your own referrals in an exponential fashion can yield nearly an extra 10% on returns (it approaches that). 0.1 in the first account, 1 in the second, 10 in the third, 100 in the fourth, and on until you're satisfied. Nothing magical. Also, this sort of plan won't work as well for small investors. I would agree that this can be done as a starting position but there is more to it, if you really want to maximise your return quickly. You can do things to increase your total payout but also dramatically reduce the return on investment time. To be honest, I'm skeptical at best. Referrals and such beneath you can speed payout times, but at some point you're limited in that one account (without referrals) has to wait for a payout to finish. There's no silver bullet. That's part of the point of pyramining, that you're investing in hardware that has an inherently slow ROI. |
|
|
|
No need to change the protocol. Let it be an engineering problem.
Well, it's not a change in the protocol implementation. It's a change in the protocol semantics. Right now you can use part of the version field as nonce and nothing bad will happen AFAIK. Even that is still a hard fork. What you have to worry about is "How will an old client see this?" When the answer is "Like something broke" you have a hard fork. Messing with the version field (even resizing it) means that old clients will see a bucket full of fuck and have no idea what's going on. Particularly when mixing it with a fairly random field like the nonce it starts to see random version numbers on posts. Even leaving the version number the same and shifting the field over to make room in the future (making the two bytes meaningless until the switch) still means you're left shifting the version bytes and now you're seeing version 65536. If you decide to use the first two bytes then there really isn't much change until the abrupt changeover when majority agrees to switch and start using those extra two bytes for something they weren't before. |
|
|
|
No need to change the protocol. Let it be an engineering problem.
AFAIK a simple solution is to implement the capability into the mining rig to do merkle tree reorganization. Then if you have 10 transactions to play with you could create 10!=3628800 permutations of the same block. If you have less than 10 transactions, the mining software could create spaceholder transactions with unique hashes.
I've seen blocks come out after a minute with dozens of transactions. As long as the transaction rate stays relatively high I don't see this being a huge issue. Maybe the first set of blocks has fewer permutations to it, but not a huge issue. As for having mining hardware doing the merkle tree computations. Sticking a simple microprocessor in near the upstream communication would be trivial for anyone making these things, and hopefully it's something they've already thought of (at least the ability to adapt to small changes like the version number being incremented). The old system of fetching and reporting on difficulty 1 shares is pretty dead when ASICs come out, that's no shock. If I remember correctly Eclipse was considering switching to difficulty 10 shares a few weeks ago. It may just also be the case that the old standard for getwork's just won't work anymore either and something closer to the hardware has to manage the merkle root. |
|
|
|
While this sort of thing will probably be embarrassing and in the long term and I'm sure Usagi isn't particularly excited about that post, who cares? I know I've been on the forums drunk before, it can be quite fun and makes a lot of the bullshit much funnier (I personally ended up going off on someone spamming links in the pyraming thread). That being said six hours (per timestamps) is plenty of time to sober up, worst case is he's got a hangover at this point. That being said I'd say it does mean he gives a shit about his investors and realizes that the situation sucks no matter how you look at it.
I for one am not embarrassed. I do not run a mining company with hardware in the next room. If GLBSE closes, CPA closes, BMF closes, and NYAN closes. Poof. We just hold assets on GLBSE. That was in most of the contracts "...only invest ... GLBSE". Yeah so I got drunk (first time in a month or two) and then this happened and I suddenly became very sick. Yes, I am a human being. Thank you for noticing. If anyone plans to try and troll me over this it would be pretty pathetic but whatever. You got drunk, I don't care, and I agree that it'd be a pretty weak point to attack you on. I figured the drunken post might be not be one of your proudest moments but I know you do hold your companies in high regard and that's admirable, I'd be more worried if you didn't. With this GLBSE thing, I hope that I'm still a shareholder in a few days.
I'm starting to think we should treat the site as though it is in a sort of beta.
GLBSE has had wording on the main page that it is in beta as long as I have been using it. GLBSE might end up like GMail, there's probably going to be a very long beta and/or "beta" period. To keep from going too far off-topic, the best thread I've seen so far is at https://bitcointalk.org/index.php?topic=115467. Large upgrade/change, botched update, or FSA (British version of the SEC) looking into it and there are conversations with lawyers happening. To rephrase my earlier question and avoid Guruvan's post. When do you believe that CPA or yourself will be able to maintain a consistent bidwall at 0.99 for NYAN.A again? As CPA is an insurance company and not an investment company the value of the markets should be of little consequence. Also, do you believe the interconnectedness of your companies is affecting their abilities to function? Right now people are just selling because they want out of GLBSE. We only hold GLBSE assets. If the entire GLBSE tanks, please don't expect me to sell my car and my computer because someone on the GLBSE invested in something that they did not understand. I am sorry people lost money but I was very very clear and open about what I was doing. Without access to the assets and bitcoins on GLBSE there is really nothing I can do -- I don't even have a list of shareholders so even if I had mining hardware there would be no place to send it. The current plan is for GLBSE to come back up at some point, what happens is up in the air still since no official news has been published. We all just have to wait and see. And while GLBSE is down there's nothing to be done about any of it anyway, that's not the worry. What I'm wondering is (provided GLBSE is functioning as expected of an exchange) when can CPA provide the appropriate bidwall for NYAN.A? Or is CPA not currently able to provide for a bidwall at this time? |
|
|
|
I'll just leave this here. Glad to see you've quickly recovered recovered from your three wine spritzers, usagi. How solvent are your companies if you've lost your life savings and your wife is going to kill you? glbse has shut down............ i just transferred 200 BTC to GLBSE....... I am so sorry.. wtf.... glbse shut down.... i have been talking about this for days.. my life ssvings is gone,,, Look guys I am asorrt...l I am druni now.... its not my fault.. I will gibe you my work money. My wife wil kil me.. I mk sorry I am sorry.. I am sorry..///  While this sort of thing will probably be embarrassing and in the long term and I'm sure Usagi isn't particularly excited about that post, who cares? I know I've been on the forums drunk before, it can be quite fun and makes a lot of the bullshit much funnier (I personally ended up going off on someone spamming links in the pyraming thread). That being said six hours (per timestamps) is plenty of time to sober up, worst case is he's got a hangover at this point. That being said I'd say it does mean he gives a shit about his investors and realizes that the situation sucks no matter how you look at it. With this GLBSE thing, I hope that I'm still a shareholder in a few days.
I'm starting to think we should treat the site as though it is in a sort of beta.
GLBSE has had wording on the main page that it is in beta as long as I have been using it. GLBSE might end up like GMail, there's probably going to be a very long beta and/or "beta" period. To keep from going too far off-topic, the best thread I've seen so far is at https://bitcointalk.org/index.php?topic=115467. Large upgrade/change, botched update, or FSA (British version of the SEC) looking into it and there are conversations with lawyers happening. To rephrase my earlier question and avoid Guruvan's post. When do you believe that CPA or yourself will be able to maintain a consistent bidwall at 0.99 for NYAN.A again? As CPA is an insurance company and not an investment company the value of the markets should be of little consequence. Also, do you believe the interconnectedness of your companies is affecting their abilities to function? |
|
|
|
What a joke. This kind of unprofessional garbage is so typical of this place You never see real exchanges just randomly go down or get massively hacked, because real money and expertise is put into them.
They go down (FB IPO) and get hacked all the time. You think they're going to go around publishing it? They make an insurance claim and it's back to business as usual. Bitcoin is just a hodgepodge of cobbled together half solutions and none of you dares to question it.
A lot of us are working on the other half. Rome wasn't built in a day.
A lot of us are working on the other half. Rome wasn't built in a day.
One problem is that scams and sketchy businesses can proliferate at a much faster rate than legitimate ventures because they bypass the groundwork which is required to set up a legitimate, properly capitalised venture with a viable business plan. You also have the problem of the types of businesses which consumer demand is driving - which is basically high risk financial services. +1 to both of these. It has so far been very easy to setup a scam (I've got a business plan, but it's secret and I can't tell you, just give me the money and I'll get you whatever ROI you want). Plenty of things are coming out, to pull from a recent example SDICE just made a big splash, though I think they were still working on finishing out the IPO sales and a lot of people didn't want to invest in 5-10% a year return. |
|
|
|
Question: Can we advertise Pyramining with our referral link, on say coinurl? Or is this classed as mass referral generation - cheating? Thanks The link only works once, so it might not be cost effective Edit: typo Edit: More info Current full reward seems to have creeped up a bit more to around 14 months, but the site is up to around 13.5 MH/BTC and I've seen as many as 33 accounts completed (32 currently). And as always everyone, myself included, are looking for referrals |
|
|
|
If you want a hand to maximise returns, let me know. I have a claculator which I can share with you, to show you how to make the most from your deposits.
Depositing with your own referrals in an exponential fashion can yield nearly an extra 10% on returns (it approaches that). 0.1 in the first account, 1 in the second, 10 in the third, 100 in the fourth, and on until you're satisfied. Nothing magical. Also, this sort of plan won't work as well for small investors. |
|
|
|
ASIC update: it's not official yet, but we are in the order of 540MH/btc with next generation infrastructure. We're working hard on it.
 uaaau, I have just joined Pyramining (23-09) and you are doing a very good job, indeed. I am investing with the very few mbtc I have Just a warning about something I ran into, with small investment amounts (<10BTC or so) the time to realize any returns can be high. Not that this has stopped me either. |
|
|
|
|
Show Posts
