Regarding merged-mining, that would make my ideas just another alt-coin, which I definitely want to avoid, and I would lose the ability to crowd-fund. You're only "just another alt-coin" if you don't do anything different. Why do you assume you will lose the ability to crowd-fund? Still, I expect that a message-based protocol built on top of bitcoin would be considered abuse of the block-chain by many people. Unfortunately (or fortunately?), there is really no way to prevent people from "abusing" the block-chain with experiments like this. As long as a transaction is valid from a bitcoin miner's perspective, it will get included, regardless of what other information it carries. Not quite. Work has been underway to prevent storing anything other than hashes in the blockchain. When reading your paper, I was giving you the benefit of the doubt, and assuming you didn't mean to literally store the (other) information in the blockchain, only the minimal transactions to make it function. Really, there is no value in storing information in the blockchain (other than abusing others' required storage of it). |
|
|
|
|
I think you should reconsider the design a bit.
While it could certainly be argued that most* of the transactions you're talking about are financial, and thus within the "social contract" of what is acceptable in the blockchain, there is no need for this and it doesn't make sense to bloat the blockchain when it is unnecessary.
A better implementation of this would do its main work in one or more merged mined blockchains, or block-data (not all purposes need a chain).
While past merged-mining altcoins (yes, you are creating altcoins here, even if they are embedded in the Bitcoin blockchain!) function independently from Bitcoin, there is no reason yours couldn't be tied more closely to it, and function just as cooperatively as you propose - or even moreso: you could implement the p2p exchange of bitcoins directly, without any need to convert to "mastercoins" at all, if you want to.
Using a merged-mining system could possibly also, if planned out in advance, allow interoperability with multiple currently-unconnected cryptocurrencies (eg, both Bitcoin and Freicoin).
* The example of "hereby take your bet" is clearly informational and abuse of the Bitcoin blockchain, in addition to being completely unnecessary.
In the specific case of the distributed exchange, I would suggest leaving out the "intention to buy" step - it doesn't really do anything useful that I can see.
Instead, just have potential buyers broadcast a purchase that includes the transfer of funds to the seller.
This can be an atomic action that confirms (or doesn't-get-confirmed) both transfers at once.
I'm not sure I follow your GoldCoins/GoldShares example.
It doesn't make sense to claim a user currency tracks the value of gold unless it actually is backed by gold, by some central authority.
If you have a central authority, there is zero value to tracking ownership in a blockchain: the authority should just sign new ownership records every day/week/howeverlong.
You also state that "Owning GoldShares is equivalent to betting that demand for GoldCoins will rise. Owning GoldCoins is equivalent to owning ounces of gold (betting that the value of gold will rise).". Considering that demand rising also means the value would rise, what is the difference between the two supposed to be?
Finally, your whitepaper only covers a very high-level view of these ideas, and actually implementing everything mentioned would probably take a lot of time, not just coding, but also thinking through the design requirements and how it can be translated into a lower-level protocol.
I think a lot of it could probably be prototyped much easier by combining testnet use with some temporary centralized service.
This would allow you to get some practical testing done, to see what works and what doesn't, and perhaps more importantly, what other things might be desirable to have that nobody has thought of yet.
|
|
|
|
You can probably set all these to 1 since you don't use GBT/getwork with an Avalon. You mean Arvicco specifically did not configure it to use GBT/getwork, or cgminer on Avalon is by default is configured to not use it (ie. use stratum?) I meant the former (that it was not in use, as evidenced by his first message), but cgminer's GBT is known to be broken, and AFAIK there aren't any cases where you'd actually want to use getwork on it (cgminer's getwork can't handle over a few Gh/s without rollntime, which Deepbit doesn't support; I don't know any other getwork-only pools) |
|
|
|
Now, if only you could tell me what is the significance and consequence of the multiple Eloipool log entries like this:
JSONRPCServer INFO Nobody to longpoll No GBT/getwork longpoll connections were connected during a longpoll... and
merkleMaker INFO Transaction-longpoll requested 102 seconds ago, and still not ready. Is your server fast enough to keep up with your configured WorkQueueSizeRegular maximum? Your CPU isn't able to maintain the WorkQueueSize* configurations. You can probably set all these to 1 since you don't use GBT/getwork with an Avalon. |
|
|
|
Try to use this: pkill -f -USR1 eloipool.py I'm guessing the problem is caused by running ... python3 eloipool.py ... instead of |
|
|
|
Hello. Iīm trying to compile 3.0.2 on windows but itīs imposible to me.   I would like to have the BFG 3.0.2 compiled with the --enable-cpu and --enable-scrypt. I know that only CPU mining is a waste of time, but itīs for testing. I'm trying to test CPU and GPU mining (only for FUN and for make diferent testing). someone have the BFG 3.x.x with "--enable-scrypt --enable-cpu"? You'll probably have better success working with the latest git code. I posted binaries a few days ago with scrypt CPU mining supported as well. sorry but, download from here: https://github.com/luke-jr/bfgminer ?? I'm trying to run bfgminer (3.0.2) with my 30 erupters but I'm getting about 3-4% h/w errors. I cool them in a specially designed cooling case. The temperature on the sinks is abut 24-26C. Here is a screenshot with stats: http://www.petermoss.com/akbash-dev/bfgminer-erupters.jpgMy question is: In your experience, what is the root cause of h/w errors? More importantly, can it be improved in s/w? Usually you can clock FPGAs/ASICs higher without damaging the chips themselves (overclocking), but getting instead logic errors resulting in things like this. Since the overall hashrate is higher (desite the errors), it's usually considered "normal" to clock it to such a level (although 5% is quite a bit). Unfortunately, for Block Erupters, there is zero software control available, so the only thing that can be done is try to cool it better. It might also be possible that since their hashrate is about 10% higher than advertised, they simply declare them "good" even if there are actual defects that reduce the hashrate within that 10% - in which case there may be nothing you can do even with cooling. |
|
|
|
Hello. Iīm trying to compile 3.0.2 on windows but itīs imposible to me. I would like to have the BFG 3.0.2 compiled with the --enable-cpu and --enable-scrypt. I know that only CPU mining is a waste of time, but itīs for testing. I'm trying to test CPU and GPU mining (only for FUN and for make diferent testing). someone have the BFG 3.x.x with "--enable-scrypt --enable-cpu"? You'll probably have better success working with the latest git code. I posted binaries a few days ago with scrypt CPU mining supported as well. |
|
|
|
FWIW, I don't intend to provide general support for patchsets which haven't even been proposed as merge requests yet (though anyone else is welcome to). Hopefully this will encourage people to submit their changes upstream  OK - i got rid of this strange message - it was just problem with python... Bu i have a general problem with configuration: ShareTarget value is totally unclear for me and I used several calculators and can't get expected results as minimal difficulty. Can anyone help me with this? feeleep For pdifficulty 1, you want 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff; divide this by the desired difficulty for others. For bdifficulty, it's the same, but based on a truncated value, 0x00000000ffff0000000000000000000000000000000000000000000000000000If you enable dynamic targetting though, this is just a minimum, so I'd leave it at pdiff 1. |
|
|
|
FWIW, seems my Emerald is dead already.
It's regressed to over 95% hardware errors despite having plenty of constant external cooling for a while now.
Hoping my Sapphire lasts longer...
...the Emerald had a heatsink? Emeralds don't have heatsinks. Update: Stuck it in the freezer for 15 mins, it got 1 good nonce immediately after I plugged it in, but doesn't seem to be working any better. Update 2: Looks like it might be related to the excess power demands of the Emerald... switching to another USB hub works fine for now. |
|
|
|
|
FWIW, seems my Emerald is dead already.
It's regressed to over 95% hardware errors despite having plenty of constant external cooling for a while now.
Hoping my Sapphire lasts longer...
|
|
|
|
FWIW, I don't intend to provide general support for patchsets which haven't even been proposed as merge requests yet (though anyone else is welcome to). Hopefully this will encourage people to submit their changes upstream |
|
|
|
Now that 0.8.2 is out, perhaps pool operators can start updating the list, especially that the default minimum low-priority fee in pre-0.8.2 is 0.0005 BTC/kB and from 0.8.2 is 0.0001 BTC/kB, so its quite important to see which pools use which policies.
Not quite. I'm pretty sure the 0.0005 BTC was only for sending fees. The reason behind reducing it was that miners were already accepting the lower fees anyway. |
|
|
|
I received my order but I am unable to get it to work properly. On cgminer 3.0.1 I am able to get 6 devices up and running (the number of Cairnsmore1's I have)... but they only has around 380 mh/s regardless of any timing settings I use. Try BFGMiner with -S all |
|
|
|
Ok, I'm a relative neophyte regarding ASICs. Up to this point have been mining on GPUs. So I need a bit of hand-holding step-by-step here  I'm getting a USB block erupter and if I want to mine with BFGMiner under Win7 x64 , to my knowledge this is what I need to do: 1. install SiLabs VCP driver 2. run bfgminer -S all [mining pool parameters] Right, though the VCP driver install should be automatic in most cases. Questions:
1. do I need WinUSB driver too (and zadig to install it)? NO! This will break it. 2. how to I specify specific com ports (-S 1 for COM1 or is it -S COM1)? -S \\.\COM1 but -S all is sufficient to probe every COM port |
|
|
|
I've setup some mailing lists (email) for BFGMiner that hopefully can be useful: All three lists have concealed member lists (only admins can see who subscribed), but will reveal your email when/if you decide to post to it. |
|
|
|
I'm trying out this pool and still don't have a good grasp of shelved shares and CPPSRB despite reading the FAQ. I realize that the shelved shares are those that have not received funds from a block yet. How long will it take for my shelved shares to get paid out if we find like 3 or 4 blocks today... all other things being equal? I have about .3 coins shelved. I just saw this post and it looks like some shares going back to November were not paid out until February. Could I conceivably have to wait 3 months to receive these? I understand runs of bad luck happen. I am just looking for a typical ballpark figure here... am I looking at hours/days of waiting or months? https://bitcointalk.org/index.php?topic=23768.msg1501533#msg1501533Perhaps I am misunderstanding, but if I'm not, I don't think CPPSRB is for me. Depends on luck. With most other reward systems (DGM, proportional, PPLNS), you'd never see the shelved shares amount unless you happened to also be mining when the pool was lucky. |
|
|
|
Compilation error: ... miner.h:38:20: fatal error: uthash.h: No such file or directory
util.c:51:20: fatal error: utlist.h: No such file or directory As mentioned in the (updated) README, uthash-dev is now an external dependency. |
|
|
|
# cgminer -T
[2013-06-02 21:42:15] Started cgminer 3.2.0
[2013-06-02 21:42:15] Loaded configuration file /root/.cgminer/cgminer.conf
[2013-06-02 21:42:15] USB init, set config 1 in use - CMR device 5:75
[2013-06-02 21:42:15] Icarus detect (5:75) failed to initialise (incorrect device?)
[2013-06-02 21:42:15] USB init, set config 1 in use - CMR device 5:74
[2013-06-02 21:42:15] Icarus detect (5:74) failed to initialise (incorrect device?)
[2013-06-02 21:42:15] No devices detected!
[2013-06-02 21:42:15] Waiting for USB hotplug devices or press q to quit
[2013-06-02 21:42:15] Probing for an alive pool
# cgminer --ndevs
[2013-06-02 21:43:47] USB all: found 17 devices - listing known devices
.USB dev 0: Bus 5 Device 75 ID: 0403:8350
Manufacturer: 'FTDI'
Product: 'Cairnsmore1'
.USB dev 1: Bus 5 Device 74 ID: 0403:8350
Manufacturer: 'FTDI'
Product: 'Cairnsmore1'
[2013-06-02 21:43:47] 2 known USB devices
FPGA Cairnsmore1 are no longer working with cgminer. Any solutions? Upgrade to BFGMiner. |
|
|
|
|
FWIW, I've known digitalmagus and senseless informally on IRC for some time, and things seem to be in order for this (the weakest link IMO is Metabank.ru, whom I've never heard of before).
The photo at Bitcoin Conference does appear to me to be really there - I think right by the entrance (which would mean the booth visible to the left is BFL/BitPay/BCMagazine).
I plan to support BFGMiner for/on these (though the question of interface specifications is still in the air AFAIK), and have purchased one for development.
|
|
|
|
Hello, someone with experience compiling in windows??? windows-build.txt is outdated. A contributor is working on bringing it up to date for 3.1.0; his current progress is in http://pastebin.com/raw.php?i=drN7QHBV |
|
|
|
|
Show Posts
