Bitcoin Forum
December 08, 2016, 06:08:10 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 176 »
  Print  
Author Topic: Devcoin  (Read 369167 times)
markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 17, 2013, 07:47:09 AM
 #1221

With so little hashing-power bitcoins, namecoins and devcoins would be lotteries, over the months you will from time to time find a block but if you set up p2pool for bitcoins you will get tiny fractions of a bitcoin regularly, and p2pool supports merged-mining so alongside the bitcoins you can merged-mine namecoins, devcoins, ixcoins, i0coins, groupcoins and coiledcoins. YOu might find a namecoin block every several months or maybe one a year or couple some years or something, from time to time you will happen across a devcoin block, ixcoin blocks you will find more often, but i0coins, groupcoins and coiledcoin you will keep raking in all the time. Currently coiledcoins a little slower than groupcoins and i0coins but I suspect that is because coiledcoin got stuck at a high difficulty when many miners abandoned it and it has been taking a long time for its difficulty to drop down to match the current low amount of miners that are working on it.

Basically 200 MHash is tiny so you need the coins like groupcoins, i0coins and coiledcoins that the "big boys" consider to be beneath their notice, but p2pool can let you get a trickle of fractions of a bitcoin while you do that.

It would maybe be nice for p2pool to be patched so that it can use devcoins as primary chain, so people could use it to get a steady trickle of devcoins while merged mining other chains instead of devcoins having to be one of the merged chains, since variance is massive on merged chains that are difficult as compared to your hashrate. (You get a whole block every once in a possibly long while instead of a steady trickle of fractions of block-reward all the time.)

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
1481177290
Hero Member
*
Offline Offline

Posts: 1481177290

View Profile Personal Message (Offline)

Ignore
1481177290
Reply with quote  #2

1481177290
Report to moderator
1481177290
Hero Member
*
Offline Offline

Posts: 1481177290

View Profile Personal Message (Offline)

Ignore
1481177290
Reply with quote  #2

1481177290
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481177290
Hero Member
*
Offline Offline

Posts: 1481177290

View Profile Personal Message (Offline)

Ignore
1481177290
Reply with quote  #2

1481177290
Report to moderator
rob1313
Full Member
***
Offline Offline

Activity: 162


View Profile
February 17, 2013, 12:12:48 PM
 #1222

thanks markm. i had trouble finding much info on dev coins

tip if i help you. doge: D7zzbMR9mxmtDQWWNfrRGY5fFNUnrwexSQ or BTC: 1Fot8CrsuxcZUw6qYX3sVpNo5MDtaf7ZS2
leave rep here for any transaction. 
BTC mining contracts for only 0.0058 BTC / GHs
dust
Hero Member
*****
Offline Offline

Activity: 840



View Profile WWW
February 18, 2013, 01:35:11 AM
 #1223

Is http://sourceforge.net/projects/galacticmilieu/files/ the latest official source?

Cryptocoin Mining Info | OTC | PGP | Twitter | freenode: dust-otc | BTC: 1F6fV4U2xnpAuKtmQD6BWpK3EuRosKzF8U
markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 18, 2013, 02:05:50 AM
 #1224


Technically I think it is out of date by one github patch, someone submitted a pull request on github to turn off the compiling in of the mini plug and play library because the version of plug and play this old code uses is much older than the one more-recent bitcoin-derived code uses so most people if they have the plug and play lib installed at all probably have the newer version that uses a different syntax (different number of arguments in a function call).

I don't think I bothered to make a new package for sourceforge for just that tiny change, since in any case anyone not wanting to compile in the lib would just put USE_UPNP= on the make invocation line instead of USE_UPNP=0 or USE_UPNP=1

Basically the change was to make it default to empty string instead of the 0 or 1 it used to default to.

The github repos are

https://github.com/knotwork/old-devcoind

and

https://github.com/knotwork/old-devcoin-qt

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
dust
Hero Member
*****
Offline Offline

Activity: 840



View Profile WWW
February 18, 2013, 02:41:25 AM
 #1225

Thanks.  The "old" in the repo name threw me off.

Cryptocoin Mining Info | OTC | PGP | Twitter | freenode: dust-otc | BTC: 1F6fV4U2xnpAuKtmQD6BWpK3EuRosKzF8U
markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 18, 2013, 02:45:02 AM
 #1226

Yeah the plan was to make new ones based on more-recent bitcoin code, just didn't get to that yet. Once 0.8 is stable, maybe.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Icoin
Hero Member
*****
Offline Offline

Activity: 585



View Profile WWW
February 20, 2013, 10:36:59 PM
 #1227

Quote
Yeah the plan was to make new ones based on more-recent bitcoin code, just didn't get to that yet. Once 0.8 is stable, maybe.
please check: DVC Block 75878
http://devda.ch:2750/chain/Devcoin?count=1&hi=75878
Will it be possble to confirm this block with version 0.8?

markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 21, 2013, 07:17:57 AM
 #1228

Quote
Yeah the plan was to make new ones based on more-recent bitcoin code, just didn't get to that yet. Once 0.8 is stable, maybe.
please check: DVC Block 75878
http://devda.ch:2750/chain/Devcoin?count=1&hi=75878
Will it be possble to confirm this block with version 0.8?

What are we supposed to be looking for in that block?

Presumably there is something about it that causes you to wonder; what exactly is it about that you are wondering about?

What exactly is it about 0.8 that you thing might not like this block?

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Icoin
Hero Member
*****
Offline Offline

Activity: 585



View Profile WWW
February 21, 2013, 10:38:27 AM
 #1229

Quote
What are we supposed to be looking for in that block?

Value Out:        35 110 016 DVC
Date:                2013-01-31 00:15:30
Confirmations: 0

I just wanna know if the 35 Mio will ever arrive.

markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 21, 2013, 10:52:20 AM
 #1230

Oh, it is not actually a transaction that is in the blockchain? (Zero confirmations?)

I thought you were talking about a block that is in the blockchain, thus one that presumably has more and more confirmations all the time.

And it has no fee? Or does it have fee?

-MarkM-



Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Icoin
Hero Member
*****
Offline Offline

Activity: 585



View Profile WWW
February 21, 2013, 10:56:59 AM
 #1231

Quote
Oh, it is not actually a transaction that is in the blockchain? (Zero confirmations?)

I thought you were talking about a block that is in the blockchain, thus one that presumably has more and more confirmations all the time.

And it has no fee? Or does it have fee?

-MarkM-

Mark this is no question about fee or no fee, its 35 Mio means incoherent to the whole 21 Mio policy of bitcoin. The transaction is writen to the chain, as you can see in the Blockexplorer, http://devda.ch:2750/chain/Devcoin?count=1&hi=75878 But the block never was confirmed by anyone till today.
According to me this is a serious Devcoin Bug, and with the present version of Devcoin it never can be solved! Lets assume DVC continue to grow, sooner or later it will be normal that a block becomes bigger than 21 Mio DVC. Every time this happens, the block doesnt get confirmed.

markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 21, 2013, 11:08:01 AM
 #1232

Hmm I am pretty sure we tried to increase a bunch of the "highest number of coins" constants when we created DeVCoin, but, I think that there is one that  limited by the fact that the number of "devtoshis" is a 64-bit integer. So the for-real limit caused by using 64-bit integers should be maxint64 divided by one hundred million.

Thus I think we ended up trying to limit the number of coins at any one spot in the binary representation to the inherited 21-million number. I cannot recall if that meant no more than 21 million at any one address or no more than 21 million as any one input or output.

I think actually it might have been, no more than 21 million in any one calculation, so whenever adding them up or multiplying them etc the result must always be within the limit.

Arguably 21 million might not be quite the very largest number of whole coins a 64 bit signed integer can represent, I don't recall ever thinking too hard about that, maybe just figuring Satoshi likely already had and had thus tuned the total minted coins in the original bitcoin to be a number of Satoshis that int64 can handle.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Icoin
Hero Member
*****
Offline Offline

Activity: 585



View Profile WWW
February 21, 2013, 11:12:16 AM
 #1233

Hmm I am pretty sure we tried to increase a bunch of the "highest number of coins" constants when we created DeVCoin, but, I think that there is one that  limited by the fact that the number of "devtoshis" is a 64-bit integer. So the for-real limit caused by using 64-bit integers should be maxint64 divided by one hundred million.

Thus I think we ended up trying to limit the number of coins at any one spot in the binary representation to the inherited 21-million number. I cannot recall if that meant no more than 21 million at any one address or no more than 21 million as any one input or output.

I think actually it might have been, no more than 21 million in any one calculation, so whenever adding them up or multiplying them etc the result must always be within the limit.

Arguably 21 million might not be quite the very largest number of whole coins a 64 bit signed integer can represent, I don't recall ever thinking too hard about that, maybe just figuring Satoshi likely already had and had thus tuned the total minted coins in the original bitcoin to be a number of Satoshis that int64 can handle.

-MarkM-


What brings us back to the initial question, will it be possible to confirm this block or are this 35 Mio DVC lost in the Devcoin Abbyss?

markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 21, 2013, 11:25:22 AM
 #1234

What brings us back to the initial question, will it be possible to confirm this block or are this 35 Mio DVC lost in the Devcoin Abbyss?

I don't know, but I don't think bitcoin 0,8's code will fix it, as the limits constants inherited from bitcoin aren't any different from one version of bitcoin to another.

So if we can fix it, we can do so right away, with a fix to the current old-bitcoin-code based DeVCoin; no need to wait for some day when we get around to making a version of DeVCoin that is based on the 0.8 bitcoin code.

Basicically if we can figure out what number where in the code is preventing it from being processed into a block, we will then be able to check whether preventing it getting into a block is necessary; if it is in fact necessary we should fix the user interface (the RPC calls for sending coins, and whatever the GUI code to do it is in the GUI version) to prevent users from being able to do such transfers in the first place, so that they never get sent to the block building system in the first place.

I suspect the problem, at root, is that users are being allowed to [try to] send more than 21,000,000 coins at once.

Possibly we can also adjust the actual limit constant definition, which is probably currently set to 21,000,000 coins, to (maxint64/100000000) too, if that is so much larger than 21M that such a change is worth stepping away from the number 21M that coiners already have genetically coded into their expectations of maximum number of coins of a bitcoin-based / bitcoin-derived coin system.

-MarkM-

EDIT: As to actually losing the coins, probably if you double-spend them, that is, send them in batches of less than 21 million somewhere else, your new transactions might get into the chain, making the old one obsolete, leading to it being dropped from the memory pool. If that doesn't work without a fee, maybe adding a fee too could help if the block building code actually does prioritise transactions that have fees over ones that have lower fees or no fees. Whether clients tend to allow one to easily attempt such re-sends aka double-spends I do not know.

(That might be where newer bitcoin code might come in: maybe the old code we used does not have coin-control and does not have a raw transactions RPC call.)

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Icoin
Hero Member
*****
Offline Offline

Activity: 585



View Profile WWW
February 21, 2013, 11:55:13 AM
 #1235

Quote
probably if you double-spend them
Yes, i agree that could be the solution by now for the 35M when i would be the sender. But how do you wanna prevent that all transactions worldwide become greater than the 21M Block limit? Means when i send 11M DVC then i have to hope that noone else sends 11M DVC in the same block?

markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 21, 2013, 12:16:25 PM
 #1236

Quote
probably if you double-spend them
Yes, i agree that could be the solution by now for the 35M when i would be the sender. But how do you wanna prevent that all transactions worldwide become greater than the 21M Block limit? Means when i send 11M DVC then i have to hope that noone else sends 11M DVC in the same block?

We need to go over the user-interface again, making sure it rejects any attempt by the user to send more than max number (currently probably 21M) coins at a time.

It might even turn out that it is the GUI that is allowing it not the deamon, as I know nithing about wxwidgets nor QT widgets and input/output forms/templates and so on thus I'd think myself far more likely to have missed a spot in the GUI code than in the daemon. But maybe not, maybe both don't check user inputs against the max and reject ones that are too large.

I also wonder what will happen when a user interface tries to tell aq user the total balance of a wallet or account if that wallet or account contains lots of addresses that each have the full 21M coins in them. I don't even know if doubles (double precision reals) are used for such displays and the addition that leads to them or if int64 is used there, a timebomb waiting to overflow the integer. I vaguely recall or have an impression that I had a cursory glance at it but I think I basically took it on faith from Unthinkingbit that it is the total per transaction/address that needs to be limited, the grand total of all coins in existence of in a wallet or account or whatever not being limited to using int64., Not sure though at this late date.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
February 21, 2013, 12:18:48 PM
 #1237

Quote
probably if you double-spend them
Yes, i agree that could be the solution by now for the 35M when i would be the sender. But how do you wanna prevent that all transactions worldwide become greater than the 21M Block limit? Means when i send 11M DVC then i have to hope that noone else sends 11M DVC in the same block?

We need to go over the user-interface again, making sure it rejects any attempt by the user to send more than max number (currently probably 21M) coins at a time.

It might even turn out that it is the GUI that is allowing it not the deamon, as I know nithing about wxwidgets nor QT widgets and input/output forms/templates and so on thus I'd think myself far more likely to have missed a spot in the GUI code than in the daemon. But maybe not, maybe both don't check user inputs against the max and reject ones that are too large.

-MarkM-
well, this is only a hotfix, the bugfix would be to lift the 21M coinlimit.
atleast u can delete the TX so u get ur coins back Smiley

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 21, 2013, 12:22:27 PM
 #1238

As I said really the limit is the use of int64 in the blockchain.

We'd need a blockchain based on, I guess, 128 bit integers instead of 64 bit to really lift the limit properly.

The constant set as 21M though maybe could be tuned up to maxint64/100000000.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Icoin
Hero Member
*****
Offline Offline

Activity: 585



View Profile WWW
February 21, 2013, 12:29:19 PM
 #1239

Quote
It might even turn out that it is the GUI that is allowing it not the deamon
The transaction was sent trough the deamon

Quote
We'd need a blockchain based on, I guess, 128 bit integers instead of 64 bit to really lift the limit properly.
I guess we are not the only ones that need to do that. What brings me back to 0.8

markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
February 21, 2013, 12:31:23 PM
 #1240

0.8's blockchain uses 128 bit integers?

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 176 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!