But is Segwit really working now ? I see the transactions are high fees, many transactions stuck without confirmation...
It hasn't been activated yet so no, it's not working, because it can't be. |
|
|
|
Can someone explain to me, in simplest possible language, how to arrive at:
"If we find the block right now, your payout is: X.XXXXXXXX BTC"?
The "payouts" entry for that bitcoin address in: http://ckpool.org/pool/pool.workIf it's not in payouts, it's not due for a payout this block. |
|
|
|
veqtrus, what I personally prefer or what you personally prefer is irrelevant. SegWit2x has 92.76% support among miners at the moment, well above the needed threshold of 80% for activation. The only reason SegWit is being enabled is because it is part of SegWit2x. P2pool needs to support the majority blockchain. Supporting minority blockchains like Bitcoin Core or Bitcoin Cash is desirable if it can be implemented in a way that does not conflict with support for the majority chain. Until that code is written, p2pool should consider minority chains to be unsupported. You don't like 2x. I don't like SegWit. It doesn't matter. The majority has spoken. https://coin.dance/blocks/proposalsIf you wish to maintain your own no-2x fork of p2pool with a separate share chain, that would be appropriate. Jtoomim I need to point something out to you. Irrespective of what your and my positions may be on the fork, this forum will be following core's lead since it is a private forum run by Theymos. This means that if and when a 2x fork happens, anything mining on 2x will be considered an altcoin and your p2pool will be relegated to the altcoin pool section. Let me make it clear that I'm not passing my own judgement on the issue here, but simply pointing out how it will be handled on the forum. Feel free to debate it in meta/ (and not with me, I'm not the one deciding here) but I can guarantee you that's how it will play out. Yes it's going to be very lonely in here... |
|
|
|
|
I will put up a donation address only if and when we find our first block since I don't expect anything for a pool that has failed to perform, but I'm more than happy to accept someone to write up a style page for the few pages that do exist and I'll include them. You have the basic data that's included on the pages, just pm me, or send me an email. I greatly appreciate the offer, thanks.
We need about 3.5PH (and climbing) to find a block every 2 week period. At this stage, I'm not even sure what stops people joining even a free pool, but I don't think it's just one thing. The combination of inertia/history, insurance, perception, features, interface, language, culture, location, advertising and so on no doubt all contribute so I doubt it's just one thing, but if we were larger to begin with they'd simply come anyway - and that has always been the catch 22 I mention every few days on this thread. Can't attract hashrate if you don't have hashrate unless you're offering something radically different. This pool DOES offer some very different things (and is free) but the vast majority of miners are big entities that are blind and feel obliged to be contracted to one of the big rip off merchants in China.
Things may change drastically if we end up with a small hashrate core bitcoin and large hashrate 2x bitcoin fork. I can't even begin to convey how dangerous this period is for bitcoin's stability, especially now when it's worth more than ever...
|
|
|
|
Pobre kano  why did you get kicked out? Also, would It be worth to use your pool if i had 2 ant s3's? This is offtopic for this pool's thread. Please take it elsewhere or I'll start deleting posts. |
|
|
|
|
No, it makes no difference what GPU you're using when mining bitcoin since no GPU can meaningfully mine bitcoin any more.
But then you're probably talking about altcoin mining so I'll move the thread to where you'll get the answers you're looking for.
|
|
|
|
Hello, some one can tell me if I am doing something wrong.
Today I receive 24 submit stales:
andre@andrelaptop3d:~/asp/gnu/cgminer$ nice -20 ./cgminer -c bitcoin.conf
[2017-08-12 21:31:25.781]
Summary of runtime statistics:
[2017-08-12 21:31:25.781] Reject ratio: 0.4%
Different hardware has different rates of producing stales, and the rest is determined by your latency to the pool so make sure you are not using a high latency connection such as wifi/3G. Your reject ratio is only 0.4% which is perfectly fine. |
|
|
|
[2017-08-10 04:52:23.089] Possible block solve diff 2957289611403.020996 !
[2017-08-10 04:52:23.304] BLOCK ACCEPTED!
[2017-08-10 04:52:23.343] Solved and confirmed block 479926 by 1D6jWP3f9C8YevncEYiB7EZiuhkt4VypoW.pj
[2017-08-10 04:52:23.343] User 1D6jWP3f9C8YevncEYiB7EZiuhkt4VypoW:{"hashrate1m": "166T", "hashrate5m": "169T", "hashrate1hr": "172T", "hashrate1d": "170T", "hashrate7d": "168T"}
[2017-08-10 04:52:23.343] Worker 1D6jWP3f9C8YevncEYiB7EZiuhkt4VypoW.pj:{"hashrate1m": "24T", "hashrate5m": "23.8T", "hashrate1hr": "23.5T", "hashrate1d": "23.5T", "hashrate7d": "24T"}
[2017-08-10 04:52:23.345] Block solved after 438911113327 shares at 47.5% diff
|
|
|
|
I fully understand what Matt & BS are about. They WANT to split from btc1 - and so make btc1 and the 2x to be an alt..
Uh hang on, did you expect core to support the 2x fork? Absolutely none of the core developers have ever officially supported it. This is why I'm far more concerned about the 2x part of segwit2x and not the segwit activation thanks to BIP91 making it compatible. Nothing will make core compatible with the 2x component so it's now a standoff between core and the bulk of the miners. We'll see if the miners follow through with 2x or if a significant number now drop off their NYA support. |
|
|
|
|
After segwit locks in, fees won't automatically decrease until people start using segwit addresses for their transactions which take up less block space. Using up block space is what determines how high fees are. Since the core wallet won't be generating segwit transactions by default it means it will actually take some time before we start seeing a lot of segwit addresses in use. I suspect initially it will be larger exchanges that do a lot of transactions that have upgraded their infrastructure will use segwit to benefit from the improved transaction fees and in time regular user wallets will likely default to segwit addresses further decreasing fees. If you have all your bitcoin in existing addresses you will indirectly benefit from others using segwit addresses which will ease the pressure on block space.
If someone starts spamming the network again then it makes no difference what capacity the block is nor what addresses are in use - it will again push fees up artificially.
|
|
|
|
The really bad news is this here: https://github.com/bitcoin/bitcoin/pull/10982Blockstream really wants to isolate and keep core power centralized, rather to compromise and allow multiple client implementation. Will all follow by blindly upgade to 0.15 ? No, you're really not understanding what that's doing. There would be serious partitioning and disconnects with bans with multiple incompatible clients out there leading to a complete mess of a network. The whole purpose of this PR is to ensure that when the fork happens, it happens cleanly. The goal is to make nodes not ban each other, not have cross talk between chains, and avoid partitioning the network. By disconnecting (not banning) peers with these service bits, we are making it easier and more likely for those peers to be able to connect to other peers that will be using the same consensus rules, i.e. btc1 peers are more likely to make connections to other btc1 peers. This minimizes the risk of network partitioning following the fork as the btc1 nodes will be connected to each other.
In the PR thread, people mentioned that this will encourage nodes to lie about what their version is and the service they support. This behavior would actually be detrimental to btc1 peers. The service bit is used for preferential peering. By removing their service bit, they will be less likely to connect to other btc1 peers and more likely to end up partitioned from the rest of the btc1 network following the fork. In order to avoid that, it would be best for them to use the service bit for preferential peering and maintain connections to other btc1 nodes before the fork so as to have the same connections after the fork.
Lastly, the PR ensures that the network topology changes gradually. At the time of the fork, what will happen is that the network topology will change suddenly and possibly fracture the network into multiple partitions. By disconnecting the peers that we know will be following different consensus rules than us, we are ensuring that the network topology will gradually shift from a mixed pool of nodes, to two pools of nodes mostly separated, but still connected to each other. At the time of the fork, this will split in two instead of into multiple pieces.
|
|
|
|
|
Fees are based on transaction size, not value transacted. This is normal.
|
|
|
|
|
Satoshi earned about 1 million bitcoin mining. I doubt most people would be wanting to reveal how much money they made to you.
|
|
|
|
|
You can move your own thread, plus you can use the report to moderator button. Moderators don't have time to read every single post, but you're lucky this time.
|
|
|
|
Q: My SP30 says it's running v4.7.0, using an old sdcard image I found on webarchive. Do you think I should try to get a newer version built / installed? Not sure if I'm ready for segwit. Maybe a newer version would squeeze a few more hashes out? I'm just using this miner until a couple S9's show up in a month or two, so maybe it's not worth the trouble.
It's working, don't touch it, especially from a discontinued company. If you screw something up by attempting to upgrade it you may never be able to fix it. There is nothing to do at the miner level for segwit; the pool takes care of all that. |
|
|
|
Hi!
Trying this pool out, looks cool.
Watching the pool stats, block height just went up a couple times in the last few minutes. Did pool find two blocks that fast?!? Seems like I'm misreading it, I figured a 60T pool would take a long time to find a block. Maybe got super lucky?
Block height is the current bitcoin block height that the pool is working on... not the pool's block. |
|
|
|
|
Those extolling the virtues of bitcoin cash as a solution to what Rusty is saying here are completely ignoring what he's saying and are using it as some kind of excuse to bash his words for small blocks. Rusty mentioned increasing the block size as well and is talking about the real technology limits of scalability no matter what approach is being used. If core ends up using a multi-pronged approach and does a block size increase as well - when it's needed, then bitcoin cash is actually offering less, not more. Bcash only has more capacity for the time being and it's been shown we don't even need that capacity at the moment, and with bcash's significantly smaller number of transactions the extra capacity is pointless anyway.
|
|
|
|
Does every USB port have an ID that can be optained via cgminer in order to see which of your ASIC miners is broken?
No,they're assigned randomly by the operating system. |
|
|
|
|
Show Posts
