Bitcoin Forum
January 27, 2023, 03:29:06 PM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 [2] 3 4 »
21  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] ExtremeCoin | Cryptc.me Stratum Mining Pool [US] 2% Fees - DDOS Protected on: September 11, 2013, 02:47:42 PM
Anyone else who wants to lodge a claim, post or PM. Last call, list will close in a few hours.

Pool operator is saying he won't pay out - but maybe he'll come around, and at least we'll have a rough indicator of how many coins were affected.

22  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Extremecoin (EXC) - The 2 month block reward only Crypto. on: September 10, 2013, 09:18:25 PM
Lollaskates, in the interest of at least corroborating your story that the coins are lost, not stolen -- will you provide your contact at your service provider (CloudFlare?), and/or what was their incident case number for this issue? It's a pretty major error, accidentally wiping out a customer's entire system - so they have a record and someone, say CaptChadd, could confirm that aspect with them.  No need to post publicly, just PM him the details.

Once again, the primary reason this matters: we're talking a huge fraction of the coins minted to date, (3.8% and counting), and their disposition significantly affects the EXC economy.
23  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Extremecoin (EXC) - The 2 month block reward only Crypto. on: September 10, 2013, 06:22:29 PM
There is only one problem with this list. If someone out there who wanted to manipulate the total lost/stolen coins, they could PM you, lie and say they had 50,000 coins on the pool for example. You have only their word on this as there is no proof on how many coins were actually on the pool.

We need a list of lost/stolen coins but also proof to back it up.


That's true, though I'm not sure what would constitute proof of mining on a pool, without the operator's own records.  And since the operator is saying they won't even pay, it seems to reduce incentive to invent a claim.   I'll apply some discretion to tracking further claims, only within the next 24 hours or so, and any extra-large ones are implicitly subject to reputation (so “Anonymous” has to be taken with a grain of salt).

If Lollaskates decides to come up with some funds, he can review the time sequence/reputation of posters.

To avoid cluttering this thread, I moved the tally list to: https://bitcointalk.org/index.php?topic=276707.0

For further updates/claims on the pool situation, please post over there.
24  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] ExtremeCoin | Cryptc.me Stratum Mining Pool [US] 2% Fees - DDOS Protected on: September 10, 2013, 05:57:26 PM
Redirected from main thread at: https://bitcointalk.org/index.php?topic=276609.240

Regarding Lollaskates exc.cryptc.me pool that has disappeared :


UPDATED TALLY of lost/stolen EXC spoken for so far:

Adeel06 ?
boxuser 200
bitezze ?
mill0601 9000
bandjhughes 250
Jaden 20000
bluestang 2300
YukonCoinelius 6000
javyer (login jagetinfovyer) 5000
krasnyoktyabr 10000
pliznau 230
Frangomel 3000
Orrechorre 150
Anonymous 2100

TOTAL = 58230 EXC ++, which is 4.2% of the total mint (1380000) as of block 6900 on Sept 10.

Anyone else with lost coins or ? noted above, post or PM me, and I'll update the tally with your amount (anonymously if you prefer not to be listed), so we can understand what % of the coin has been lost/stolen here.
25  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Extremecoin (EXC) - The 2 month block reward only Crypto. on: September 10, 2013, 05:07:24 PM
I said it was my fault, it was my responsibility to make consistent wallet backups that I hadn't gotten around to doing yet. There are no backups, there is nothing to retrieve. The hosting provider does not perform backups on dedicated servers. The hardware is decommissioned and repurposed.

They. are. gone. There is nothing left to be done. I'm not a scammer, accidents happen. I'm not reimbursing anyone because it was your responsibility to use autopay and not accumulate all your coins on a pool somewhere out of your control, for reasons just like this.

You can call me a scammer if those coins ever leave that wallet, which they won't. All the coins are lost for everyone, period. It sucks, deal with it. Jesus. Stop PM'ing me novels.


Fine you are accepting fault, but you're not accepting *responsibility*. Your self-justification for not even attempting a partial reimbursement, is ridiculous. A pool is a type of financial service provider. You are contracting to provide a service, including responsibly holding people's funds. I have seen other pools go down, and the operators make an effort to get everyone's coins back. If an exchange gets hacked, they make an effort to refund any losses, at their expense. Because that's the ethical thing to do, and much better for long-term reputation and business.

It's *not* miners' responsibility to frantically pull their coins out of pools just in case the operator is a thief/incompetent. That is a safety valve we have - it does not absolve the operator's responsibility to not lose/steal the coins in the first place!  The entire coin is only a few weeks old - it's hardly unreasonable for miners to leave funds in a pool for a few weeks.

We extended you trust, and you failed it.

And now you're compounding the problem, by trying to brush it away, and not even trying to make things up.

The other reason we need you to make an effort, is because otherwise the coin has the shadow hanging over it of a potentially stolen major chunk of coins. If instead the coins can be believed as most likely lost, then we can just factor that into the total picture. And you can help that belief by making a bona fide effort.

I'm sure the miners would work with you, and accept even a partial settlement if the whole amount is too much for you to make up.


UPDATED TALLY of lost/stolen EXC spoken for so far:

Adeel06 ?
boxuser 200
bitezze ?
Queegeh ?
mill0601 9000
bandjhughes ?
Jaden 20000
bluestang ?
YukonCoinelius 6000
javyer (login jagetinfovyer) 5000
Anonymous 2100

TOTAL = 42300 EXC ++, which is 3.1% of the total mint (1380000) as of block 6900 on Sept 10.

Anyone else with lost coins or ? noted above, post or PM me, and I'll update the tally with your amount (anonymously if you prefer not to be listed), so we can understand what % of the coin has been lost/stolen here.
26  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Extremecoin (EXC) - The 2 month block reward only Crypto. on: September 10, 2013, 04:05:26 PM
Regarding Lollaskates exc.cryptc.me pool that has disappeared :

I also had coins on the pool, 6000+, my entire EXC holding, except for a kind gift I received for my help on this coin.

Tally of lost/stolen coins spoken for so far:

Adeel06 ?
boxuser 200
bitezze ?
Queegeh ?
mill0601 9000
bandjhughes ?
Jaden 20000
bluestang ?
YukonCoinelius 6000

TOTAL = 35200 EXC ++, which is 2.5% of the total mint (1380000) as of block 6900 on Sept 10.

Anyone else with lost coins or ? noted above, post or PM me, and I'll update the tally with your amount (anonymously if you prefer not to be listed), so we can understand what % of the coin has been lost/stolen here.


I've PM'd Lollaskates to pursue the options of 1) follow up with the hardware provider for data backups or credits,   2) reimburse users by purchasing the coins on exchange, and 3) arrange partial settlements or payments over time with the users, if the lump sum is a hardship.

His story/position so far appears to be: hardware accidentally “decommissioned”, “we” all lost from this snafu, not my fault, darn the luck -- i.e. zero personal responsibility.

If there's no ethical awakening here in another day or two, I'd imagine some users will look to give Lollaskates negative trust feedback and scammer tag.

Can someone confirm the pool payout address CaptChadd posted, PGyfub9FA8aa1chMRXyXvrwQpVJswPBRBJ, and what the balance there is? (Note that even if the balance is there, we have no way to confirm whether the wallet/keys are really lost; Lollaskates could just be saving them for later.)

27  Alternate cryptocurrencies / Altcoin Discussion / Re: MemoryCoin - Grant System Failing - Surgery Needed on: September 03, 2013, 10:33:39 PM
A 1 or 2 week voting round, with a nice summary of the open proposals each week, would give people some time to read, assess, vote - even if they only dropped in to the forums a couple times per week. The default voting case should be “status quo” (versus the current “streaming firehose”), so the voting system can be running and tabulating things, but monies are not actually awarded until the community is really at a consensus.

Also I'd say advertise and apply the voting system as a *Feature* more. Seems to me you missed a golden opportunity just now with the logo prize - a tailor made issue for the community to vote on, and really belonging to them. (this oversight could be a little what's driving the “quantplus” voices -- that you are talking “community/foundation”, but actions have a flavor of “sole proprietor”. To my perception you are at least trying to balance that line to get the coin bootstrapped, but others may see it differently.)

Remember, voting in itself takes time and overhead -- people are not going to do it unless it is clear, simple, and there is some definite purpose and benefit. “More coins for me” everyone understands -- beyond that you get into promises, philosophy and abstraction. It also needs documentation, and an easier UI.

Also, in a pure community consensus, you would have to accept if they don't want a “Foundation” and demand the developer(s) bug off and “stop stealing their coins” Smiley It doesn't help to “strike” or “raise awareness” about it. There's a limit to the enlightened self-interest out there, and generally speaking miners want 110% of a coin that somehow also has a market value, and automatically keeps working forever with no developer support.

However, it seems you as the designer envision MemoryCoin must have a Foundation support structure (a reasonable position, imo) -- even if it requires dictatorial override. So then you cannot be in pure consensus. Instead just send 1 or 2 or 5 of the grant streams to MCF permanently and that's that. I think a significant part of the community would support that.

By the way, whatever the MCF grant amount is, I would recommend just grant yourself something for development work out of those funds, in an open way. Having 1 stream for the MCF that you admin, and then be soliciting more grants for your work, may give users a sense they are “paying twice”.

Finally, you probably need the foundation to have more directors/steering committee before too long.
28  Alternate cryptocurrencies / Altcoin Discussion / Re: MemoryCoin - Grant System Failing - Surgery Needed on: September 03, 2013, 10:27:27 PM
Changing from 5 grants to 1 grant likely will not solve anything. That will probably be gamed into an interest pool too. Here are some other ideas:

MemoryCoin Voting - Ideas and Suggestions, 2013-Sept

  • A long way to solution is first of all massively slowing down the grants - to give a reasonable timeframe for drawing up proposals, laying them out, users understanding them, voting on them. Even something like 1 grant round per week or two. Or maybe the addresses encode a time period through which they are valid. Or a voting round ends when there's a threshold winner, as I mention below. You could keep the 5 parallel lines. If you want to keep the same relative proportion of grants to total mint, you can increase the grant amount per round, or have it on a different schedule (so the grant awards go out past the 2 years, after mining subsidy has dropped).

  • To stop the exchanges or largest holders from dominating the voting, you could cap the vote power at some moderate amount (e.g. max vote is 100 coins), or make it a logarithmic scale. For example 1 coin = 1 vote, 10 coins = 2 votes, 100 coins = 3, etc.  Or make a “House/Senate” system where the decision has 2 components: the proportional coin amount as currently, plus a new component of 1 address = 1 vote.

    This would counter the self-grant pooling, because the primary motivators for such pools would likely want to divide the proceeds on a proportional basis; small holders would not benefit in such pools, and thus vote for something else, and on a log scale their small vote is more significant.   (This might still be game-able - for example, by mass-splitting a wallet, but hopefully that would be more trouble than it's worth?)

  • A 1-address 1-vote component could also have some interesting uses for “American Idol” style votes -- even on issues completely separate from the coin itself. This could generate high interest and demand for MemoryCoin. i.e. General popularity votes, with repeat voting allowed as a “measure of enthusiasm”, yet constrained by the non-zero cost. Consider 2 million Idol viewers seeking 0.10 MEG accounts to vote (!!)

  • You could set a minimum percent of the total outstanding mint needed for a vote to succeed. Instead of just beating all the others, it has to both win and be above N%. So proposals need widespread community response to win. Grants that don't reach the minimum are not allocated and the funds carry forward to subsequent rounds.

  • Maybe votes should automatically reset after each round? (This should be a relatively easy code change too - just count the voting transactions over the last N blocks, instead of forever.)

  • Can MEG support multiple styles of voting -- all the above and more, encoded in some way, like in the grant addresses. There should also be votes de-coupled from money awards (this is possible with the current system, but could be made easier to use - so the whole community, or subsets of users could be running their own distributed votes on lots of issues simultaneously).

  • I had been thinking from early on, that maybe some grant addresses should be a scarcer resource, or subject to a level of pre-validation. Say they had to be issued and digitally signed by the MemoryCoin Foundation at (small) fee, with some preliminary statement about the purpose. That would give a better record of what the proposals involve, and potentially deter self-grants. Plus it's an additional source of funds for the MCF. And it's reasonable to have the coin foundation enforcing the one rule that “you can't wish for more wishes” (i.e. no self-grant votes)

29  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Extremecoin (EXC) - The 2 month block reward only Crypto. on: August 26, 2013, 01:17:54 AM
Done and I have tested it on my main rig again and it has synced.
New Fix Windows QT client : https://www.dropbox.com/s/bjym7nxc62pbxzn/Extremecoin%20V1.1.zip
Now it is a lot more simple.

int64 static GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 200 * COIN;

if(nHeight>17280) nSubsidy = 1 * COIN;
   
return nSubsidy + nFees;
}

200 coins until block 17280 and then reduces to 1 per block.


This is good -- simple is better, and compatible and will sync with the current blockchain.

One last bug though is:  17280 * 200 = only 3456000 coins.
For 4 million coins, the height limit needs to be 4000000 / 200 = 20000

So the final correct function is as follows  (you can drop this right over the other one):


Code:
int64 static GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 200 * COIN;

if (nHeight >= 20000) nSubsidy = 1 * COIN;
   
return nSubsidy + nFees;
}


This will mint 20000 blocks of 200 coins each = 4 million total, then switch to 1 coin/block forever after.  (which is about a 2.6% inflation rate, and rate is decreasing into the future).



By the way, I haven't checked Mincoin, but if that bad code was from there, then Mincoin is wrong too, and some of its blocks are silently losing txn fees.  The function always returns *something*, so it can easily appear to work.  And as long as it's wrong consistently, it can even sync with itself.    (The sync problem for EXC came in because originally you had the fees, and then the Mincoin code has a bug with dropping the fees.  With the above code, EXC is back to good on the fees, so all is well).

30  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Extremecoin (EXC) - The 2 month block reward only Crypto. on: August 25, 2013, 10:11:45 PM
Here is the new block value code in update 1.1:
It's broken.  


Code:
int64 static GetBlockValue(int nHeight, int64 nFees)
{
if(nHeight<4320) return 200*COIN; //720000 coins in two weeks
else if(nHeight<8640) return 100*COIN; //144000 coins in four weeks
else if(nHeight<12960) return 50*COIN; //72000 coins in 6 weeks
else if(nHeight>17280) return 1*COIN;
    int64 nSubsidy = 1 * COIN; // 1 Coin until 5 million limit reached

if(nHeight>5000000) nSubsidy=0;

    return nSubsidy + nFees;

}


First of all, the immediate problem is, it won't sync the existing blockchain, because
the return value is not adding the nFees now.  (the bottom line is never reached
except when nHeight is between 12960 and 17280).  The effect is probably that
anybody starting a fresh blockchain download with the new code will probably hang up
at the first block that has significant fees.

Second, what this code is actually doing is issuing 200 coins/block for 15 days (4320 blocks),
then 100/block for 15 days, then 50/block for 15 days, then 1/block for the rest.
That's (200 * 4320) + (100 * 4320) + (50 * 4320) + 1 + 1 ... = 1512000 + 1 + 1 ... total coins.

So it will issue 1512000 coins in 45 days and then drop to 1/block.  
That's still not what you've described as the intended design.

Also the comments make no sense.  I thought your intent is to issue 4M coins in 8 weeks?
720000 + 144000 + 720000  does not equal 4M either.
    
Also, the (nHeight>5000000) test is not the right way to reduce subsidy to 0 after 5M coins.

Also, if you change the protocol in future, it needs to be switch-controlled at a particular block height.
(you can get away with no switch this time, because the chain is still under block 4320).

Finally, it needs to be structured so the nFees are always added.



Chad, I have very limited time to check/fix this coin.

If you PM me in words what exactly you want as a minting protocol, I will see about fixing it up for you this time.  (though I can't guarantee that's the only problem - I haven't checked all the rest of the code/changes).


31  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Extremecoin (EXC) - The 2 month block reward only Crypto. on: August 25, 2013, 08:59:46 PM
ALERT -  UPGRADE 1.1 BROKEN  -  do not upgrade


Upgrade 1.1 is broken in the block value computation - it's not sensible and also appears to be incompatible with the existing blockchain - the existing blockchain cannot sync to this upgrade.

I will post more details in another message or edit here shortly.
32  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Extremecoin (EXC) - The 2 month block reward only Crypto. on: August 20, 2013, 05:12:51 AM
A %-based transaction fee is probably the wrong direction, and might actually *reduce* the net fees. Small txns (ie. most of them) will be paying less than the current fixed amount, and large transactions will be throttled in some degree, (because users will “think twice” about sending big amounts if it costs an extra %). I don't know that a coin penalizing large transfers is very sensible -- large transfers are actually preferred because they involve less processing and database overhead in the blockchain.

Also, the bitcoin txn fee is already “proportional” - relative to the computational complexity of the transaction, as it should be. In other words, if it has to assemble a 100 coin payment out of a bunch of 0.05 inputs you got, then the txfee is higher than if you already had a 100 coin input sitting there ready to go. That's why sometimes it gives you a warning and multiplies the base fee.  It might be very tricky to keep this important property, while making the total amount a percent too. You might end up with code that multiplies the *percent*, and for a complex txn suddenly wants to charge not just 1% but 10%!

I don't see the txnfee code as a good area for tinkering. Any such changes must be carefully tested on the testnet, including for extra large and small amounts.



If you want to try something reasonable and new, then fund mining with a 5% inflation after the initial 4M issue - no other fast-issue coin is doing that. So after the first 2 months, you want 5% more issued per year. From 4M, that's 200000 coins, across 105120 blocks/year, so let the final block reward stay constant at 2 coins, instead of going all the way to 0. That gives you an inflation rate of 5.256% per year going to the miners, and with only 4M issued, it can run for many years. (and actually with a constant 2 coins, the effective rate is scaling down -- i.e. after about 20 years, when there are 8M coins out, the inflation is only about 2.5%.   (If instead you want to keep the *rate* constant, then the 2 coin reward has to increase a bit into the future, which is a bit more complicated.)

(Note: if you do set an inflation minting, you need to increase MAX_MONEY - it should be very high; the limiting happens in the minting protocol. If you figure on 200,000 coins per year for 1000 years, then max money should be 200M + 4M)
33  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Extremecoin (EXC) - The 2 month block reward only Crypto. on: August 19, 2013, 04:24:49 AM
Sorry to point out, but ExtremeCoin has nothing new -- the entire idea is already in progress with IFC InfiniteCoin for several months, with a more reasonable accelerated mining schedule and a proper halving scaledown. IFC has already a large community, and building many markets and developments, and has been trading for a good while and widely distributed. So what is the point in duplicating all that - your efforts would probably be better spent contributing over there.

Further, and my main reason for posting: ExtremeCoin does not appear to implement your stated 4M limit, and will need a hard fork asap. Right now, the block reward is constant at 200, with no provision for throttling at 4M. It will continue allocating coins past 4M and/or break at that point. You set MAX_MONEY to 4M, but afaik, that is an error check, not a limiting device. Instead, the limiting is supposed to happen in main.cpp, where it currently says:

Code:
int64 static GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 200 * COIN;
return nSubsidy + nFees;
}

At minimum you need something like:

Code:
if (nHeight < (4000000 / 200)) nSubsidy= 200 * COIN
else nSubsidy = 0;
However, a sudden drop like that would produce market shock, so a gradual scaledown is better.
So then you are back to basically duplicating IFC.

Well, if you continue with this coin, please look to a fix asap.
And if this happens to go forward, you and any vested miners please set aside a sizable bonus for me, for saving your bacon here Smiley
34  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] Infinitecoin - IFC high coins per block! V1.3 Released! *Please Upgrade* on: August 13, 2013, 06:12:55 PM
The ring of 1s and 0s looks very cool! 

Is there a font where the 1 is just a single straight line?   Like a pure hash/tick mark, a typical engraving on coins, and will look like a radiating pattern.

Would love to see what you can do with a color contrast on the infinity-sign.  The shiny golden sign actually looks great already, but so many other coins are also using the gold-on-gold pattern, and it's hard to distinguish them when scrolling through small thumbnails/listings.  If would be good if the IFC infinity symbol really stands out, to be quickly recognizable and sharp-looking, even at 1cm square.
35  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] Infinitecoin - IFC high coins per block! V1.3 Released! *Please Upgrade* on: August 13, 2013, 04:28:11 PM
Good work on the website, very informative, functional, and looks great.

However, that top part where the logo splits to 1s and 0s looks distracting to me. I'd say stick with the whole coin logo - clear and simple.


Some ideas for the logo I have been meaning to post:

* To evoke the infinite digital nature, what about a ring of golden 1s and 0s around the outside of the coin, instead of the stars there now?  (in alternating pattern, 0101010...)

* Also, I've noticed the gold-on-gold color pattern of the logo is hard to distinguish when it's small. I see more visual appeal and easy recognition if the infinity-sign were a contrasting color - something that goes well with gold - say, Glossy Cobalt Blue. (burgundy or white would also look nice, but blue is typically a strong confidence color).

36  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] MemoryCoin | Fork at 1566 on: August 12, 2013, 04:20:38 AM
Hung system again, after a few hours on 4 cores. 

For a very hard crash, it might be related to the chip overheating.

You might want to keep an eye on the chip's temperature with a system monitor utility - if it's crashing a particular temperature each time, that would be a good indicator of the problem.

n.b. on my own quad core, with 8 logical processors, I find I can get 95% of the hash rate by running just 5 processes for about 65% processor use.

Hmm,  good idea,  I'll monitor it.    Note however, I'm able to mine other cpu coins (xpm, qrk, ...) full throttle indefinitely.

I did monitor the MemoryCoin RAM usage and seems that was not an issue.  High water mark a few 100KB for RSS, and 1.9GB VSZ.

37  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] MemoryCoin | Fork at 1566 on: August 11, 2013, 09:23:52 PM
btw, I am also getting the crashes/hang on multi-core mining under Linux (it takes down the whole machine, very severe). (actually, to clarify, I was getting that on the old code, but have not yet reproduced a crash on this latest code - it usually takes 0.5 to 1+ days)

Thanks, let me know how that goes. I think the voting code was leading to instability. It's still in there, but shouldn't be called except at startup. I'm going to prioritize stability over the next week - for the network and the clients.

Hung system again, after a few hours on 4 cores. 
38  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] MemoryCoin | Fork at 1566 on: August 11, 2013, 05:44:57 PM
ok, I squeaked onto the new code at block 1579, as soon as I saw it today. 8 hours from code release to hard fork time probably sets a new record.

FreeTrade, please consider my timeline comments above for any future forks/protocol changes. A conservative time frame from code release to hard fork time is about 4+ weeks into the future. Obviously you can get away with less with a smaller/new coin, but you really do not want to get in the thicket of multiple competing blockchains. Even when the main one goes forward intact, if there's outcry from miners who “lost their coins” on spurious chains, it detracts from the reputation/confidence.  

Looks good so far - nice work and support on sustaining the blockchain!

btw, I am also getting the crashes/hang on multi-core mining under Linux (it takes down the whole machine, very severe). (actually, to clarify, I was getting that on the old code, but have not yet reproduced a crash on this latest code - it usually takes 0.5 to 1+ days)
39  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] MemoryCoin | Fork at 1566 likely on: August 11, 2013, 02:00:30 AM
Block 1566 is much too early for the hard fork for the changes under discussion, as we are in block 1400s now.  At 240 blocks per day, that's less than 1 day time and the code is not even released.  Can't be done.

The first immediate challenge is shepherding everybody thru the upcoming 1680 fork, in about 24 hours.  This version needs to be clearly marked and available.  (This is really an "implicit" fork; it's the first time the reward scaledown code activates, but anybody not on the new code will not see it, so they will produce wrong blocks.)   Since this code was already released, I think you have to stick to that schedule, otherwise it will just be too confusing.

Once this transition is accomplished and given a couple days to stabilize,  then the next batch of protocol changes we are discussing here can be rolled out.  There should be at least a few days from when you release the code to when the new protocol goes active.

Also you might promote/version these updates as sort of a paired unit (like "1A / 1B"),  so people expect the imminent next part and don't get surprised/fatigued by having to update again.

It's very important to get a majority of miners forward onto the new protocol before its activation time.  If most miners stay on the old protocol/software, it sort of 51%-attacks your own coin.  You can/should have checkpoints to protect the blockchain, but really it's crucial to alert everyone forward to reduce user (and software) confusion.

So we are looking at a schedule like this:  (Note: PROPOSED, NOT FINAL)

Block 1680: protocol switches to latest current release ("1A"), fixing the block reward scaledown.
1680 + 2 days = block 2160:  1A transition confirmed stable and good.  Code Release update 1B, protocol switch time at least 3 days into future.
2160 + 3 days = block 2880:  protocol switch time for update 1B.

If 1B needs more time to get ready, then just adjust as needed.
40  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] MemoryCoin | Fork at 1566 likely on: August 11, 2013, 01:01:39 AM
6 minute block time is actually a wise design parameter choice by FreeTrade, and indicates dedication to having a strong network, while still being somewhat improved over Bitcoin's 10-minute time.

You cannot just randomly twiddle key design parameters and expect everything to keep working.   (not that it's stopping anyone in most of the altcoins, of course Smiley

Neither can you just randomly compare different coin designs.  Primecoin has PPCoin's *distributed checkpoint system* which offers a 2nd layer of security (along with its own plus/minuses), and is probably the reason SunnyKing felt 1 minute was long enough there.   BitCoin does not have that, thus neither does MemoryCoin which derives from it.  (it has checkpoints, but of a different kind.)

The strong advantage of a longer block-time is that it gives plenty of time for each block to percolate through the whole network and all nodes to settle and agree on a coherent distributed picture.  This improves network stability and resistance against certain types of attacks.    (For example, with short block times it becomes much easier for an attacker to get in front of the network, out-orphaning everybody  because they cannot even "see" the front of the blockchain, let alone mine on it.  Attacker does not even need a sustained 51% to do that, just "get lucky" a few times in a row.)

The reference below estimates potential end-to-end latencies in the "tens of seconds" = say 15-40 seconds, that's just for the network transmission.  Apply a 10x factor for security, reliability, processing, databasing, actually getting in a little mining... and you're at 10x (15-40) = 150-400 seconds = 2.5 to 6.6 minutes.

So we've got LTC at 2.5 minutes, MemoryCoin at 6 -- both reasonable.  I could see MemoryCoin maybe at 3 minutes, but it's not a clear-cut improvement, rather a trade-off.

The 30-60 second coins are really operating right at the margin of what is possible.  And they have not been proven against attacks  (on the contrary, several of them have been exploited).  And they strongly advantage the clustered GPU farms, because while everybody else is spending much of the blocktime just trying to receive the blocks, the clusters have tight internodal transmission and thus  proportionately more mining time as well.   (this is why small/solo miners often get continuous orphans on these coins).  So the longer block time in MemoryCoin does help solo miners.  (Also remember, these are average, not exact blocktimes.  At 3 minutes, some blocks will take only 1 minute; at 30 seconds, some blocks take only 5 or 10 seconds, and lots of miners never even got a chance.)

Another issue with short block times is they are just generating a lot more data = significantly increased overhead.  Especially early in the life of the coin, the blocks are nowhere near full capacity in terms of the number of transactions they can hold, so why spew out dozens in place of 1.  Remember a main point of these coins is to carry transactions.


See also:
https://bitcointalk.org/index.php?topic=211535.20
the block time needs to be more than several times the maximum end-to-end propagation delay.  This is needed to prevent competing nodes from generating blocks at the same time and convincing large parts of the network that their respective block is the winning block.  
...
So what is the maximum end-to-end propagation delay?  Bitcoin networks are constructed by randomly connecting to IP addresses.  This means that Bitcoin networks ignore geographic locations, so end-to-end communication can cross the globe multiple times.  The network construction also does not limit the width of the network, so end-to-end communication can require numerous hops.  Add processing delays on each node and you can easily get a maximum end-to-end propagation time that is tens of seconds.
Pages: « 1 [2] 3 4 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!