★★DigiByte|极特币★★[DGB]✔ Core v6.16.5.1 - DigiShield, DigiSpeed, Segwit

[HR]

Now I'm pissed.... oh sorry... hi...

I won't be able to afford to run 8MB blocks, I can barely afford the 1MB already in place.
No way I'm letting all my coin in an exchange nor on a web wallet either.
This means it's time for me to exit DigiByte... I'd rather do it on here than on an exchange; I'm sure you can appreciate this.
Sucks for me, I know, I'll get over it, I lost million dollar deals before so no biggie.

Thing is I have a richlist stash and if I go on exchange will tank the price in a big way.
So I am giving the community the change to buy it all in one shot without messing up with the price.
I know this makes me sound like an asshole but consider I wasn't so nice with other coins as to make a thread about me selling out my entire vault.
It's the last thing I want to do but seems I have no choice.

My internet costs me at a rate of $10 per 1GB so yeah... that said I didn't even want to say anything but you guys are cool folks so... here I am.
Please PM me your offers in the form of "BTC Per Million DGB" by next Sunday November 08, 2015...
If no reasonable offers are received by wednesday, I will sell off then.
I hate to have my time wasted and right now I am wasting my time here talking about shit I never wanted.

Largest Total BTC offers = First Served
Maximum DGB: 10,000,000

Buy the whole stash above my asking price [secret] and get an extra 140,000 for free!!

-GigaBit

You might be jumping the gun a bit. For example, a bootstrap file that can be downloaded in a WIFI free zone would solve your problem (something that I figure would be easy for you since the rate you're referring to is a mobile/cell rate . . . ).

And who knows exactly when the rollout will happen. Like cryptonit said, sometimes it's better advised to wait for the need to arise first . . . and nothing better than meeting eventual need with a super thoroughly tested solution.  

Don't forget that the DigiByte team is much wiser, much more flexible, much more open to all types of input, than your standard crypto Dev team. Concerns raised here are more often than not dealt with head on and in an open source, open to the world, way. These guys are no chumps. Don't underestimate them - you'll only loose money if you do. They've never let anyone down. On the contrary, they have always surprised to the upside.

BTW, there's pretty good daily volume on the exchanges, enough to handle a fair sized liquidation if you sell into strength (versus dumping, and seeing severely compromised sale proceeds); of course, if you're talking about the #1 rich list figure (which looks more institutional to me than anything else), it would take you some time . . .


ADD: I'm also guessing that if you were the #1 you wouldn't be complaining about $10 per 1GB rates!!!  

[1695479968]

1695479968

[peonminer]

Go dgb gooooo
☆Pokémon battle stance☆

[Qusocia]

I find the DGB videos entertaining as they have a lot of likability. I'm not holding any DGB but I'm certain it'll still be a great project within the next few years.

[Sharkzz1]

i offered 10.1 btc but i don't think he'll accept it,
But why don't you just dump it on poloniex, you don't care about this coin anymore right?
So why do you care about messing with the price? Doesn't make any sense to be honest.

[myriadcoin]

I made the exact same decision as you not long ago mate. Myriad all the way. Besides, check out the awesome hash rate on sha256 and scrypt thanks to merge mining being implemented on those two algorithms last month. http://myriad.nutty.one/home

Myriad is a multi-PoW coin which actually came before DigiByte. Its community is not quite as active as DigiByte's, but there has always been activity. It's been picking up lately, and with a $50,000 market cap, the potential gains for your investment are so high. Many people feel they have missed the boat on DigiByte.

Check out the subreddit http://reddit.com/r/myriadcoin for news, including the new website about to be launched.

myriadcoin, you really need to get an avatar. I did some window shopping for you and came across this.



Chill out a bit. MYR will go back up, and probably at a rate inversely related to your barking, if you get my drift.

Thanks lol. I can't set an avatar yet.  Guess I need to post in this thread a bit more. Then I will set that picture as my avatar.

[Tyke]

DigiByte history book (release date: 5th December 2015).  Only five weeks left.

I'm definitly buying that book

I assure that you won't be disappointed when you read it

[cryptmebro]

Looks like the price is on it's way back down.

[Jumbley]

Looks like the price is on it's way back down.

yes, we was pumped again. Crypto is a mine field! Be very aware people about buying something rapidly rising and take a good look before jumping in.

DigiByte tries very hard not to encourage p&d activity but it is powerless to stop it!

This is a very good reason not to buy a coin based on price movement. Long term, I don't believe DigiByte has ever seen any price that isn't recoverable but if you don't know what you are buying you shouldn't buy it.

[peonminer]

Looks like the price is on it's way back down.

yes, we was pumped again. Crypto is a mine field! Be very aware people about buying something rapidly rising and take a good look before jumping in.

DigiByte tries very hard not to encourage p&d activity but it is powerless to stop it!

Builds strength, not really pumped, just more attention brought to. The dumping had open hands ready, even with bitcoin being up $150.

[Jumbley]

Looks like the price is on it's way back down.

yes, we was pumped again. Crypto is a mine field! Be very aware people about buying something rapidly rising and take a good look before jumping in.

DigiByte tries very hard not to encourage p&d activity but it is powerless to stop it!

Builds strength, not really pumped, just more attention brought to. The dumping had open hands ready, even with bitcoin being up $150.

This may be partly true in the f'd up world we live in and is mostly greedy people ripping off other greedy people but it's not anything to be proud of.

[DigiByte]

A Few Thoughts on DigiSpeed & Blockchain Scalability

Question #1: Why does DigiByte need to be able to match Visa's average transactions per second?

Short answer: Utility, usability, marketability and growth well into the future. "DigiSpeed" has already became a buzzword in the crypto community and has a very marketable appeal moving forward. More importantly DigiByte takes a bold step forward with DigiSpeed to dramatically scale a blockchain with multi-algorithim mining. However, this does not mean the DigiByte blockchain size will jump dramatically over night.

Question #2: I can't afford to mine and run 8 MB blocks on my PC?

Short Answer: We are a long way off from hitting 8 MB blocks. We are not even coming close to filling 1 MB blocks. This change simply removes a cap that Satoshi himself even admitted was an arbitrary limit he put together on the fly. Our assumption is we will not see 8 MB blocks until several years from now.

Question #3: What incentive will people have in the future to run a full DigiByte node when there is a large amount of data in the blockchain?

Short answer: The "DigiSize v5.0 wallet we are planning for mid-late 2016 will tackle this issue head on. This will include advanced pruning and syncing features as well as some increased incentives for running a full node. We are tossing around several ideas for what this incentive might look at. Perhaps a staking feature, perhaps a new type of mining algorithim or perhaps some other feature yet to be thought up. We would like all the input we can get on this topic. In the end the key to long term survival and network security is tens of thousands of people around the world running full DigiByte nodes.

Question #4: Wont people attack the chain with bloated transactions and OP RETURN data?

Short Answer: This is a very real possibility that we are going to mitigate up front by increasing the average transaction fee (still a very small amount). And we open the amount of this increase up to debate. The best way to explain this is if someone wanted to fill up an 8MB with thousands of small transactions in theory they could. But if it cost them exponentially more to carry this out the attack vector is mitigated. As for OP RETURN data, we will be keep this as is. Future security applications that embed data in OP RETURN should make use of distributed hash tables, not storing data directly on the chain.

Question #5: Transactions are becoming larger than 250 kb, wont this make the issue worse?

Short Answer: Yes some transactions are indeed larger than 250 KB and the average transaction size in the future will undoubtedly be larger but for now its a solid number to work from for averages.

Question #6: With such fast block times and sizes wont transactions be "lost"?

Short Answer: With multi-algorithm mining we are actually in a unique position compared to other coins who have tried with very fast block times. Even though the DigiByte network as a whole will see 15 second block times, each individual algo and mining pool actually is generating 1 minute 15 second blocks. Meaning each block has over a minute to pick up transactions. Some great data on network propagation can be found here: Microsoft Research: http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf

Question #7: Are you testing massive swings in difficulty?

Short Answer: Absolutely. But after DigiShield and Multi shield this is much less of an issue than the Bitcoin test data that was shown for BTC that showed this to be a problem with larger blocks. Bitcoin still retargets every 2 weeks.

Question #8: Where is the test data for DigiSpeed?

Short Answer: Before releasing the hard fork wallets we will release data on the following points:
*Transaction Times
*Block Times
*Algo Distribution
*Transaction Sizes
*Other data we find useful

Question #9: Why not release DigiSpeed by using a timestamp in the future or by network consensus instead of making network changes occur at a specific block?

Short Answer: By using a specific block everyone knows exactly when the changes to the network will occur. This dramatically mitigates several attack vectors. It also gives people the choice to opt out ahead of time if they so chose. It is also important to note this will be DigiBytes fourth hard fork. The previous three were carried out successfully in the same manner.

Question #10: With block-speed doubling wont that mean twice as many DigiBytes will be coming in to circulation each day?

Short Answer: No. At the hardfork point the reward will be cut in half so the same amount of daily DigiBytes will be mined.


In closing it is important to note we are not going to rush anything here until we are 100% happy with our test data and have addressed all of the communities questions. We would also encourage everyone to read this blog post by the Bitcoin developer Mike Hearn: https://medium.com/@octskyward/on-block-sizes-e047bc9f830

Let us know other technical questions you have and as they come in we will post replies below here:

[cliffmadsen]

Hey this is probably a stupid question, but I have finally, installed Linux, and need help.
which miner should I use to mine skein in linux.
sudo this and sudo That
I feel so stupid,is there a tutorial for beginners:)

[dgbpool]

Hey this is probably a stupid question, but I have finally, installed Linux, and need help.
which miner should I use to mine skein in linux.
sudo this and sudo That
I feel so stupid,is there a tutorial for beginners:)

AMD   -> https://www.nicehash.com/?p=software#amdgpu

nvidia -> https://www.nicehash.com/?p=software#nvidiagpu

miner config:

     readme.txt or readme.md

pool:

      http://www.digihash.co

[cliffmadsen]

Hey this is probably a stupid question, but I have finally, installed Linux, and need help.
which miner should I use to mine skein in linux.
sudo this and sudo That
I feel so stupid,is there a tutorial for beginners:)

AMD   -> https://www.nicehash.com/?p=software#amdgpu

nvidia -> https://www.nicehash.com/?p=software#nvidiagpu

miner config:

     readme.txt or readme.md

pool:

      http://www.digihash.co

Thank you very much

[bogglor]

Question #4: Wont people attack the chain with bloated transactions and OP RETURN data?

Short Answer: This is a very real possibility that we are going to mitigate up front by increasing the average transaction fee (still a very small amount). And we open the amount of this increase up to debate. The best way to explain this is if someone wanted to fill up an 8MB with thousands of small transactions in theory they could. But if it cost them exponentially more to carry this out the attack vector is mitigated. As for OP RETURN data, we will be keep this as is. Future security applications that embed data in OP RETURN should make use of distributed hash tables, not storing data directly on the chain.

I've been mining DGB since March 2014. My core wallet has over 20000 transactions in it, most are very small (less than 50 dgb) because I don't have alot of mining power and I have mined on pools that pay out immediately instead of waiting and sending in big chunks.

I'm going to be penalized with a higher transaction fee for spending these? Sounds like it's in my best interest to send them to myself now in large chunks before the automatic transactions fees go higher.

[bogglor]

Hey this is probably a stupid question, but I have finally, installed Linux, and need help.
which miner should I use to mine skein in linux.
sudo this and sudo That
I feel so stupid,is there a tutorial for beginners:)

For skein, I use https://github.com/reorder/cgminer_skein on my Linux miner.

At your linux prompt, do these commands in bold:

git clone https://github.com/reorder/cgminer_skein

a few lines of things will happen

cd cgminer_skein

./autogen.sh --enable-skein --enable-opencl

alot of stuff will scroll by, might take a minute or so

make

alot more stuff will scroll by, should take less than a minute

If everything went well, then you should be able to mine with your GPUs now...

./cgminer --skein -o stratum+tcp://pool.address.com:1234 -u username -p password

If something fails in one of these steps, then you probably don't have the right linux program dependencies installed.

[iikun]

Question #4: Wont people attack the chain with bloated transactions and OP RETURN data?

Short Answer: This is a very real possibility that we are going to mitigate up front by increasing the average transaction fee (still a very small amount). And we open the amount of this increase up to debate. The best way to explain this is if someone wanted to fill up an 8MB with thousands of small transactions in theory they could. But if it cost them exponentially more to carry this out the attack vector is mitigated. As for OP RETURN data, we will be keep this as is. Future security applications that embed data in OP RETURN should make use of distributed hash tables, not storing data directly on the chain.

I've been mining DGB since March 2014. My core wallet has over 20000 transactions in it, most are very small (less than 50 dgb) because I don't have alot of mining power and I have mined on pools that pay out immediately instead of waiting and sending in big chunks.

I'm going to be penalized with a higher transaction fee for spending these? Sounds like it's in my best interest to send them to myself now in large chunks before the automatic transactions fees go higher.

I admit I'm speaking without knowledge of what the planned transaction fees exactly are but I would doubt that such significant increases are planned. So saying, if you're able to send them in larger chunks now (as you wrote) then it wouldn't hurt to do so would it?

[bogglor]

Question #4: Wont people attack the chain with bloated transactions and OP RETURN data?

Short Answer: This is a very real possibility that we are going to mitigate up front by increasing the average transaction fee (still a very small amount). And we open the amount of this increase up to debate. The best way to explain this is if someone wanted to fill up an 8MB with thousands of small transactions in theory they could. But if it cost them exponentially more to carry this out the attack vector is mitigated. As for OP RETURN data, we will be keep this as is. Future security applications that embed data in OP RETURN should make use of distributed hash tables, not storing data directly on the chain.

I've been mining DGB since March 2014. My core wallet has over 20000 transactions in it, most are very small (less than 50 dgb) because I don't have alot of mining power and I have mined on pools that pay out immediately instead of waiting and sending in big chunks.

I'm going to be penalized with a higher transaction fee for spending these? Sounds like it's in my best interest to send them to myself now in large chunks before the automatic transactions fees go higher.

I admit I'm speaking without knowledge of what the planned transaction fees exactly are but I would doubt that such significant increases are planned. So saying, if you're able to send them in larger chunks now (as you wrote) then it wouldn't hurt to do so would it?

I'd have to sit down and spend several hours to do this. Working with a wallet with thousands of transactions is extremely slow.

In fact the other day I was messing around with my wallet, and tried to select about 10000 transactions just to see how it would react. After waiting 45 minutes with my wallet not responding, I just ended the process to close the wallet.

[bogglor]

What I'd really like to know is how are automatic transaction fees determined.

Can someone with knowledge of the how it's coded post this?

Something like: If a transaction is older than X days and/or has less than Y digibytes, then there is an automatic transaction fee of Z DGB.

This would help alot for me to determine which transactions have fees and which don't.

[Jumbley]

What I'd really like to know is how are automatic transaction fees determined.

Can someone with knowledge of the how it's coded post this?

Something like: If a transaction is older than X days and/or has less than Y digibytes, then there is an automatic transaction fee of Z DGB.

This would help alot for me to determine which transactions have fees and which don't.

I think it is like this:  Up to 6 inputs  = No fee
                            Up to 12 inputs = 0.04 DGB
                            and then an additional 0.02 DGB for each additional 6 inputs until transaction is too large.

                            something like that!