Hehe  the poll address is fake just intentionally, ok so I downloaded 4.10 ver for my windows machine and it acts the same when i'm trying to mine with my gpu, bfgminer-3.10.7-win64 works fine with the pool i use , bfgminer-4.10.0-win64 does not. The same issue is on linux. May it be a pool is incompatible? I am mining there with dmaxl's cgminer but it's not updated anymore. Please use http://luke.dashjr.org/tmp/code/webisect/webisect.php to identify the regression. 1. Enter anything random for Session name, click Go. 2. For "Working commit:", put bfgminer-3.10.7 3. For "Broken commit:", put bfgminer-4.10.0 4. Click "Start" 5. Wait for the webserver to build a CUSTOM version of BFGMiner (ignore the version it claims to be when you run it). 6. Download the custom build, and test if it works. Click the relevant button. 7. Go back to step 5 until it gives you a "verdict" on which change is guilty for breaking it. 8. Post the final result here. |
|
|
|
Speaking of which, how would fees work here? The paper talks about how it's most beneficial to the miners to mine on every sidechain they can, but how do sidechains provide a reward? When users are using a sidechain do they need to provide fees to the network with their own bitcoins? Yes, just like any bitcoin transaction... Sidechains might also use things like demurrage to give miners a subsidy. |
|
|
|
"First, the miner must assemble a transaction set for both block chains." http://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-workSo if I'm reading that right, merge mining would mean that miners would need to assemble a different transaction set for every sidechain and then mine them? Then for every successful block for any sidechain the miner would send that work to the sidechain. I'm very confused about how the hashing calculation can be independent of both Bitcoin and the sidechain, I thought PoW built on top of a hash of the latest block, in which case the hashes from one blockchain can't be used to secure another blockchain. The PoW algorithm for <sidechain> would include a Bitcoin block header in it. But we're now somewhat off-topic for this thread, which is about sidechains, not merged mining... |
|
|
|
The small space available for configuring the SPV proofs, the ease of 51% attacks, the high resource costs, fairly high complexity, and few use cases ends up making me very skeptical that the thing should be in Bitcoin, but I think it's a neat protocol. Uh, what "ease" of 51% attacks? Or high resource costs? And only few use cases? O.o Maybe I misunderstood, but I thought that this thing needed to have it's own hash-power in order to avoid attacks from the main blockchain. Therefore, unless the sidechain has enormous hashpower it would be trivial for a party to break away from the primary chain to do a 51% attack. Merged mining solved this a long time ago. I say it's few use cases because I'm not convinced that there are alot of uses that would be preferred to be in a sidechain, rather than a totally separate solution. Though I'm not financier or whatever, so I'm probably just ignorant of all the potential. I can't think of any uses that would prefer a totally separate solution (other than scams). |
|
|
|
The small space available for configuring the SPV proofs, the ease of 51% attacks, the high resource costs, fairly high complexity, and few use cases ends up making me very skeptical that the thing should be in Bitcoin, but I think it's a neat protocol. Uh, what "ease" of 51% attacks? Or high resource costs? And only few use cases? O.o |
|
|
|
If SIDECHAIN1 binds to some output on the Bitcoin chain, how can you guarantee that I can't run an otherwise duplicate SIDECHAIN2 that grants all bitcoins to myself and then I just turn around and take the coins on the output of Bitcoin?
"4.2 Fraudulent transfers" is apparently talking about this issue, but I still wonder what prevents a total reorganization from the genesis of the sidechain by whoever made it and having the flexibility of deciding to do this anytime in the the future?
It seems like no matter what you have to trust whoever created the side-chain for as long as the side-chain exists. You have to trust the miners on the sidechain not to 51% attack it with a "SIDECHAIN2", yes. Just like Bitcoin*. * Not exactly "just like" if you're using SPV proofs. |
|
|
|
Boussac and I are trying to better figure out the details of the peg mechanism and their consequences at a higher level (economic). Basically, the question is the one asked by Boussac: Let's say I have locked one bitcoin to release one sidecoin. To release the locked bitcoin, does my sidechain-enabled wallet simply collect one sidecoin (plus tx fee) worth of sidechain unspent outputs or are there other constraints on my sidechain transaction transferring the coin back to the bitcoin blockchain ? Once a bitcoin is locked to a sidechain, it is entirely up to the sidechain rules what the terms are for the release. The obvious case is 1:1 equivalence, but there's nothing saying a sidechain must do it that way. Thanks but my (very basic) question is about the fungibility of the sidecoins. I rephrase the question. Is the release of a locked bitcoin (or any fraction thereof) tied to a specific sidechain transaction OR is there flexibility in the choice of the unspent outputs on the sidechain to release the locked bitcoin? Pratical use case: suppose I have locked one bitcoin in tx A to release one sidecoin in tx A' on the sidechain. Later, I lock another bitcoin in tx B to release another sidecoin in tx B'. Can I redeem the second sidecoin to release the first bitcoin ? If tx A and tx B are transferring from the same parent blockchain, they should be the same asset on the sidechain. Obviously you can redeem any "sidecoin" of the same asset type using any of the locked coins, since as soon as you do a transaction on the sidechain the original transferred-in coin is consumed. |
|
|
|
Boussac and I are trying to better figure out the details of the peg mechanism and their consequences at a higher level (economic). Basically, the question is the one asked by Boussac: Let's say I have locked one bitcoin to release one sidecoin. To release the locked bitcoin, does my sidechain-enabled wallet simply collect one sidecoin (plus tx fee) worth of sidechain unspent outputs or are there other constraints on my sidechain transaction transferring the coin back to the bitcoin blockchain ? Once a bitcoin is locked to a sidechain, it is entirely up to the sidechain rules what the terms are for the release. The obvious case is 1:1 equivalence, but there's nothing saying a sidechain must do it that way. On my side, I would add this question: Am I right if I say that parent chains don't choose their sidechains but sidechains (devs, community) choose their parents ? Yes, that's correct. The parent chain could try to prevent sidechains below it, but even then as long as there is multisig you can always do a federated peg sidechain. |
|
|
|
Well, seems better to wait for answers from the experts.
Still waiting. The way this fungibility issue is ignored in this otherwise awesome white paper is puzzling with so many bright minds as co-signers. I assume for simplicity a 1:1 peg between bitcoin and sidecoin. Perfect fungibility would mean I can redeem any set of unspent outputs totalling one sidecoin on the sidechain to release any locked bitcoin on the blockchain. To illustrate this notion, suppose there is perfect fungibility and the sidechain is used as a mixer for the blockchain. I assume for simplicity a 1:1 peg between bitcoin and sidecoin. "Dirty" BTCs are transferred to the sidechain and come back clean as sidecoins but with a 10% laundering fee: in the off-chain market I can only get one sidecoin for 1.1 BTC because I would need 1.1 BTC to get a clean sidecoin in a sidechain transaction. The point is that, with fungibility, the spread between the pegged rate and the market rate can be significant. I could have taken any example where the function of the sidechain requires fungibility and commands a transaction fee. Transaction fees on a sidechain are not necessarily market driven because of market imperfections. Therefore fungibility is an important design parameter for sidechains. Can you come up with an example that is plausable? Having a hard time following enough to figure out what the actual question is... |
|
|
|
SC1 decides to "cut the link" with this chain. What? SC1 is a blockchain, not an entity. |
|
|
|
There are a few issues with this system though, specifically as it comes to "stale" work. If somebody has a share being paid in the current coinbase, and a new piece of work comes out where their work has been pushed off the payment list, they could purposely remain mining the old work (as long as the block itself isn't stale). While this can be prevented by making it so their new submissions are considered stale as far as the pool is concerned, they would still get their reward if they solved a block. No different than if they were solo mining and claimed the full 25 BTC... As long as you don't credit stale shares (from the pool's perspective), nobody is hurt. |
|
|
|
Is it possible to get this kind of architecture ?  Yes, but BTC-via-SC1 and BTC-via-SC2 would be different assets on SC3. Although you can treat them identical if you want to (ie, if you trust SC1 and SC2 equally). |
|
|
|
Thanks, I'll lock this one. |
|
|
|
Would this negate the shift scheme we currently use? I only ask since from time to time it takes less than a minute for the network to solve a block and in the past we/pool had luck getting some of those consecutive blocks, a momentary users restart could leave someone out in the cold after running 30+ days nonstop and Windoze wants an update/restart and the pool was unlucky the prior 8 consecutive hours.
I don't see why you would expect it to change the reward scheme at all. |
|
|
|
I am also exploring ways that the pool could make a transition to coinbase payments to further reduce the amount of funds at risk at any given time. This probably won't happen for a few months, if it happens at all.
+1. I much prefer direct payouts, and it eliminates a lot of your risk. Does this mean that instead of an hourly disbursement of funds to/for accounts meeting the user's settings minimum threshold from their accumulated balance, that we would have a payment after each/every matured block award which accepted shares were submitted for? Or somehow still utilize a shift scheme to determine contributions? One nice thing about PPLNS (and why p2pool uses it) is that it's very easy to make the block reward mined distributed among all the miners it's supposed to pay. So you wouldn't need to wait until the block matures to get a payout - you'd "just have" the payout in your wallet the moment the block was mined, and it would never touch BTCGuild's wallet at all. Disclaimer: I don't know what (if anything) Eleuthria has planned for implementing this, this is just how I would do it, if it were me. |
|
|
|
Most common reject cause is because it is already in the memory pool. If Discus Fish picked it up then it likely was relayed pretty normally and we already had it when you pushed.
Well http://eligius.st/~wizkid057/newstats/pushtxn.php was the first place where I pushed it but still transaction was rejected and not relayed, why so? CPFP is only implemented for the mining policy, not the mempool. This means your parent transaction need to pass the mempool's checks on its own before it will be considered for CPFP prioritisation. |
|
|
|
|
To "factory reset" a pi, usually you just take the SD card out and reprogram it...
|
|
|
|
How can I fix that? pool does not see any work of course.
[2014-11-02 11:42:21] HTTP request failed: Protocol "stratum+tcp" not supported or disabled in libcurl
Try updating libcurl (if you're using Linux). Definitely try: sudo apt-get install build-essential autoconf automake libtool pkg-config libcurl4-gnutls-dev libjansson-dev uthash-dev libncursesw5-dev libudev-dev libusb-1.0-0-dev libevent-dev libmicrohttpd-dev hidapi sudo apt-get update sudo apt-get upgrade You may also have to rerun ./configure and make again... His libcurl is fine. No version of libcurl supports stratum+tcp, so this is an ordinary message before it uses its own implementation. Also, I don't see any actual problems in his log... |
|
|
|
|
Show Posts
