Topic: ★★DigiByte|极特币★★[DGB]✔ Core v6.16.5.1 - DigiShield, DigiSpeed, Segwit - page 1253. (Read 3058816 times)

The solution to the problem where you cannot send coins mined either from solo or p2pool (tx rejected by network) is to enable coin control in the wallet options, then select all inputs, and deselect any that have under 100 confirmations. The wallet is configured to look at everything as needing only 8 or so confirmations, while this is no longer true. 100 confirmations are needed for newly generated coins. The wallet attempts to send them with under 100 confirms, and the network obviously rejects them.

I think those blocks were found by someone else before our p2pool. Not sure about the 2 addresses, but it could be a private p2pool that someone set up? Because I haven't received any large payments in the past day or two.

I didnt know that, I've been using sgminer-sph as well.

Is there anything like that for linux?

If you want to mine Qubit on AMD GCN and you run Windows 7, what you really want to do is running M8M-376.
You might need to overwrite presentation.js.

Seriously, the kernels included in sph-sgminer for Qubit are very far from efficient and pretty much the worse it could happen on AMD architecture.

overcloking and downvolting

What software are you using for mining? I'm using spg-sgminer, and it's ~4.6Mh on Qubit

I have a digibyte qubit pool that I'm using for myself. It is now open to the public. It's at http://omargpools.ca/dgb

http://dgb-qubit.theblocksfactory.com/

So sad 

Too bad nobody can keep their qubit pools up and running for any given period of time....

On 280x :
 - X11 = 4.5Mh / 167W
 - Qubit = 6Mh /150W

My rigs have been mining x11 for months. I suggested over and over and over for DGB to include x11 in the multi algo mix. I want to mine DGB but I am not changing my rigs from mining x11. Lower temperatures, faster hashrates and less wear and tear on my cards. Please add x11 to the mix of algos

srcxxx,

Quick question that I hope you can clarify: all subsidies for blocks found on your pool ( http://cryptohunger.com:81/ ) have had 25% taken right off the top and sent to another address. What is the reason for that?

Here's the block explorer summary for Newly Generated Coins for blocks found by Crypto Hunger:
http://insight.dgb.cryptopoolmining.com/block/dd1f60e865d52fdc02561af3a5367d70a55ff51e9ed76eaae11fb620e38c4faa

As can be easily seen, there are two payout addresses:

D96y4y74NUegfYJ8yn9chxbPLrRiypCF6V
and
DBy3212dWAPPzPcyt5fSSchjyozyr5ejLw

When one follows the "money trail", one sees that there are indeed multiple payouts to multiple addresses (miner payouts) for D96y4y74NUegfYJ8yn9chxbPLrRiypCF6V .

HOWEVER, the other address, DBy3212dWAPPzPcyt5fSSchjyozyr5ejLw , has ONLY re-SENT coins to ONE address for a total of just over a million DGB and it also still has a current balance of just under another 3/4 of a million DGB!
http://insight.dgb.cryptopoolmining.com/address/DBy3212dWAPPzPcyt5fSSchjyozyr5ejLw

The address that has received the one million DGB, DRykTe2nXZpSX1KytPXjvPhGfCAXb4ZBM6 , has also received DGB from other addresses, has only sent 128,100 DGB and has a current account balance of 1,371,300.
http://insight.dgb.cryptopoolmining.com/address/DRykTe2nXZpSX1KytPXjvPhGfCAXb4ZBM6

That all means that, in less than four days, from Newly Generated Coins on Crypto Hunger, around 1.75 million DGB, or roughly 25% of subsidies, have NOT gone to miner payouts, but are currently "parked" in two separate accounts.

What's the purpose for this?

Just out of curiosity.

All details regarding the reasons behind the volume of coins should be in the first post and on the website.

More DigiBytes: 21 Billion DigiBytes will be created over 35 years.

    21 Billion DigiBytes vs. 21 Million Bitcoin in 100 + years.
    1:1000 ratio. There is 1 Bitcoin for every 1000 DigiBytes.
    Less price volatility with more DigiBytes in circulation.
    More transactions for every day Goods & Services.

Speed DigiByte transactions occur much faster that Bitcoin transactions.

    1-2 Second Transaction Notifications.
    60 Second DigiByte Blocks vs. 10 Minute Bitcoin Blocks.
    DigiBytes are confirmed after 6 minutes vs. 1 hour with Bitcoins.

Marketability & Usability: DigiByte is a very marketable brand to consumers.

    DigiBytes are much cheaper to acquire.
    $1 - $10 long term price target per DigiByte.
    Send 5 DigiBytes instead of 0.005 Bitcoin.
    Branding is easy for the average consumer to relate to.
    We have dropped the term “cryptocurrency” to avoid confusion.

If they were to fork and reduce the volume of coins, I'd be out in a flash because it would take away from the original mission statement.

Also forking to reduce total number of coins doesn't always lead to a price rise or stabilization, look at casino coin for an example.

Digibyte is one to hold, I've been mining and buying from the start. There has been steady development and a purpose from the start.

I think they said they were going to have a few days off rest, then hopefully an announcement!! 

20m is all i have since mining since the beginning of digibyte when diff was low . Maybe it's time to retire get some btc now and buy cheap after ... if it still decreasing... Holders like me will lose all the time they have been mining since 5 month...

the price will goes down for sure.

During the last month, the mining supply was very low due to multipool setting difficulty really high and leaving after.
Now, because blocks are generated fast and smooth, the mining supply is a lot bigger than before.

Imagine the total amount of mined coins gets close to 21 billion ? .... !!!
I do not want to make any price guess for that circumstance..... You know what it would be...

So therefore here I would like to hear from DigiByte, please let us know what would be the future of DGB...
Here is being a bit quieter and not hearing from him much for the future of the coin...

As I said before than anyone else, the price would be around 25 Sat at the first equilibrium. Can be found here when I said it 2 days ago: https://bitcointalksearch.org/topic/m.8642194 .Unless giving a good roadmap and future work, it will continue going down and within a few weeks it will be X-XX SAT.

I am not surprised about the price drop , 30sec block target and block reward 7647 , that means in 24h there will be more then 22milion new coins ,

if half of them get sold 11mil at 24sat , that would be around 2.75btc daily sell orders , but the buy orders are not increasing .

so I think the price will drop below 10sat in a few days , at this price we would see the same profitability like other coins and more stable and people would stop dumping them as soon as possible.

but I also could be wrong and I`m not ashamed to admit it .

or change groestl to Neoscrypt

The issue isn't a 51% attack issue, it's a monopolization issue, or unfair competition if you will. His pool has an unfair advantage that basically eliminates other competing Groestl pools.




Well, I wasn't really proposing anything as it was that I was simply documenting what I was seeing, but now that you've asked . . .

Your pool ( http://cryptohunger.com:81/ ) has an unfair advantage that makes other Groestl pools uncompetitive with you. We all know that is not fair, and no-one would argue that it is.

It's simple common sense: who would mine on any other pool when they could get a higher hashrate (and payout) on your pool with the same equipment? (All other things being equal and baring things like hidden fees, questionable payouts, and other similar issues that can cause a user to distrust - only distrust would cause someone to forego a more profitable opportunity, until the larger community steps in to enforce equal opportunity and general fairness that is.)

So you attract all mining to your pool and you make good money yourself. Sounds like a good capitalist proposition, but the problem is that your unfair advantage eliminates competition (other pools) and capitalism places a higher priority on competition than it does with one entity's individual desires to get rich at others' expense.

Therefore, the obvious proposal would be to correct the problem, and that would be done by addressing the unfair advantage, either by making it possible for other pools to use your optimized kernel, or by discontinuing its use on your pool (which would be easily verifiable).