Bitcoin Forum
July 08, 2024, 09:15:15 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 [157] 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 ... 573 »
3121  Economy / Gambling / Re: I have a +EV method for a dice site,[CONFIRMED +EV is possible] on: July 04, 2015, 02:29:26 PM
Here is what he told me when I told him that with such house edge you are literally cheating people...

https://i.imgur.com/8Kvb5KF.png

I don't think the 4960x bets are a problem:

>>> 100 - 4960 * 0.02
0.8

That's a 0.8% edge as advertised.

The 200x bets have a 2% edge:

>>> 100 - 200 * (99.99 - 99.5)
2
3122  Alternate cryptocurrencies / Service Announcements (Altcoins) / Re: Scrypt.CC | Scrypt Cloud Mining on: July 04, 2015, 02:20:10 PM
Why would you recommend the khashier Block explorer when the Presstab Clams explorer is way better? http://www.presstab.pw/phpexplorer/CLAM/index.php

I recommend both, but for viewing transactions khashier is better.

Compare khashier and presstab on the same transaction and you'll see. khashier shows more information in less space, more clearly. Presstab doesn't tell me which outputs are spent and wastes lots of space writing out txids when a simple short link would be better. Presstab doesn't tell me the fee, or the amount transferred, the transaction size, etc.
3123  Economy / Scam Accusations / Re: scrypt.cc is provably lying about their 850GH/s Scrypt mining on: July 04, 2015, 02:08:00 PM
Hmm.. New funds paying out old investors - https://bitcointalk.org/index.php?topic=444495.msg11783964#msg11783964

Ponzi?  Huh

That's cashflow and proves nothing.
3124  Alternate cryptocurrencies / Service Announcements (Altcoins) / Re: Just-Dice.com : Invest in 1% House Edge Dice Game on: July 04, 2015, 01:59:44 PM
Dooglus, you might do something about old accounts from bitcoin just-dice that still have set up the old bitcoin address as emergency withdrawal address. I didnt find info that clams can be sent to a bitcoin address, only can be claimed from one, right?

It's possible to calculate the CLAM address that has the same private key as any given BTC address. So I can 'send CLAMs to a BTC address' in the same way that the initial CLAM distribution was done.

But people should update their emergency address to a CLAM address.
3125  Economy / Gambling / Re: I have a +EV method for a dice site,[CONFIRMED +EV is possible] on: July 04, 2015, 01:56:46 PM
Seems Joter learned nothing from this:

Quote
[06:50] <[ADM]Joter85> they reported this issue on forum
[06:50] <[ADM]Joter85> and they want 1,5 btc for it
[06:50] <[MOD]Lutpin> he needed it to buy something
[06:51] <[ADM]Joter85> we want to give them 1 btc
[06:51] <chiny> ohh... i see...
[06:51] <[ADM]Joter85> but they didn't want it
[06:51] <chiny> then how much they want?
[06:51] <[ADM]Joter85> maybe kewl will give them 1btc not sure
[06:51] <[ADM]Joter85> if you ask me i wouldn't give them nothing
[06:51] <[ADM]Joter85> as they were rude
[06:51] <[ADM]Joter85> and insulting all the time
[06:52] <[ADM]Joter85> problem is
[06:52] <[ADM]Joter85> we didn't realized severity of this problem
[06:52] <chiny> yes.. if i am a mod i will mute them imidiately in chat... haha
[06:52] <[ADM]Joter85> if we would know it is such a big issue we would pay
[06:52] <[ADM]Joter85> ah no need
[06:52] <[ADM]Joter85> i leave them to cry here
[06:52] <[ADM]Joter85> and on forum too

The lesson should be when people smarter than you try to help you, shut up and listen!
3126  Bitcoin / Bitcoin Discussion / Re: WARNING: blockchain split on: July 04, 2015, 01:42:10 PM
As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks.

Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block.

Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far.

The bolded points:

95% of the network was claiming to be mining v3 blocks,
50% of the network was SPV mining,
but only 50% of the SPV miners were claiming to be mining v3 blocks?

Doesn't that mean that 50% of the SPV miners, and so 25% of the network wasn't claiming to be mining v3 blocks?

If so, how did we reach the 95% trigger?

Perhaps they were only claiming to be mining v3 blocks but not actually doing so... ?

I think you missed my point.
3127  Bitcoin / Bitcoin Discussion / Re: WARNING: blockchain split on: July 04, 2015, 01:30:57 PM
As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks.

Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block.

Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far.

The bolded points:

95% of the network was claiming to be mining v3 blocks,
50% of the network was SPV mining,
but only 50% of the SPV miners were claiming to be mining v3 blocks?

Doesn't that mean that 50% of the SPV miners, and so 25% of the network wasn't claiming to be mining v3 blocks?

If so, how did we reach the 95% trigger?
3128  Economy / Gambling / Re: I have a +EV method for a dice site,[CONFIRMED +EV is possible] on: July 04, 2015, 05:00:38 AM
Here's the video.  This marks ~25,000 consecutive rolls without a win.  This means in 25,000 rolls, a 1/200 chance -- any number over >99.945.

>>> 1 / ((99.946 / 100) ** 25000)
732080.9049554196

That's a 1-in-732k chance?

Also, "The video you have requested is not available." - what's up with that?
3129  Economy / Gambling / Re: I have a +EV method for a dice site,[CONFIRMED +EV is possible] on: July 04, 2015, 04:55:30 AM
I think ive already suggested a proper fix for this earlier in the thread; make the multiplier based off of the winning chance: multiplier = 0.992/(win chance)
right now, the win chance being dependent on the multiplier is causing the rounding issues.

Exactly this. There are 10k different possible rolls (or 100k, for now, etc.) so have the roll target and the stake be the things which define the bet, and have the payout multiplier be derived from that (and calculated to enough places that the rounding doesn't matter).
3130  Economy / Gambling / Re: I have a +EV method for a dice site,[CONFIRMED +EV is possible] on: July 04, 2015, 02:52:56 AM
ive already offered just 1 BTC to give the details of the bug allowing for +EV bets, and another .5 BTC for a more serious bug found by dooglus.

I think the issue I found would go away as soon as they fixed the bug that you found to be honest. They're pretty related.

I've been offline most of the day so haven't been able to keep up with this thread. I'll edit this with replies to later posts as I read them.

We are pretty confident in our code. We log many different hack attempts every day.

Exploit it please, and earn 1 btc. When you do we are willing to pay you 1.5btc extra to tell us about it. We are tired of this lame scam attempts. We get mails of exploits weekly, but no one proved or steal anything. Only reason why we offered you any amount is because you have others users backing you up.

I told you that I verified that he is able to get a 30% edge over the house.

Do you think I'm lying to try to scam 1.5 BTC out of you? Really?

Lol. Foolish remark on Crypto-Games' side. A bug or an exploit shouldn't be taken lightly, especially when it involves money.

Not only that, but it's other people's money they're risking here. They take 'investments'. I wonder if they have any idea who came up with that idea...  Roll Eyes

ill consider that as an invitation for me and dooglus, we'll start when hes awake.

I don't think I will. The site has the old-fashioned kind of provable fairness where they change the server seed every roll, and so you need to do an awful lot of work to verify the fairness. You would need to note the server seed hash before every roll, change the client seed unpredictably before every roll, then verify that the revealed server seed really hashes to the provided hash and that the two seeds together give the correct roll. Every roll. It's just too much work to expect anyone to do.

No modern dice site uses this kind of provable fairness any more. Even Prime Dice finally switched to using the static server seed + nonce method that Just-Dice pioneered about a year ago after many requests from players.

heres how bad it is, credit goes to dooglus for compiling this:

multiplier, win chance, edge

6613x  0.02% 32.26%
3968x  0.03% 19.04%
2834x  0.04% 13.36%

I have ran simulation for this cases, and don't see any issue with it.... Am I missing something....

Yes! Players expect to win the 0.03% bet once in 3000 rolls. When they do, they are paid 3968 units. If you have a greater than 1/3968 chance of winning 3968 units, that's +EV. In this case it's a 19.04% edge for the player.

It beggars belief you don't recognise the problem even after having it spelled out to you.

As I said this is issue I can't reproduce in my simulator, I won't bother doing math as we have already did. Now we run only simulations....

Is there a grown-up anywhere near you? Maybe get them to help you. For fuck sake man, this is insane.

Or you know, just use fucking maths. Hint: It's two multiplications and one addition. Sum of the probabilities by its respective profit, which gives you the players EV. If it doesn't equal -0.01 you're got the wrong payouts.

Taking the most extremely wrong one:

0.02% chance of 6613x

That's a 0.0002 chance of a profit of 6612, and a (1-0.0002) chance of a profit of -1

Or:  0.0002 * 6612 + (1-0.002)*-1 = 0.3244

...a players advantage of 32.44%

Your math is a little wrong, and overly complicated. The player's edge is 32.26%, not 32.44%:

heres how bad it is, credit goes to dooglus for compiling this:

multiplier, win chance, edge

6613x  0.02% 32.26%

You used 0.002 when you should have used 0.0002:

>>> 0.0002 * 6612 + (1-0.0002)*-1
0.3226

But it's easier just to calculate the payout. It's 0 when the player loses, and 6613 when they win, so return to player per 100 bet is:

>>> 6613 * 0.02
132.26

ie. a 32.26% edge.

You are wrong somewhere as I have entered exact parameters in simulator and result after 10 mil is 0 btc.

Has it occurred to you that it is possible that you might be wrong? The alternative is that everybody else is wrong, since they all seem to be telling you the same thing.

For this 32% issue or whatever it is impossible to reproduce, so you are wrong at some point, not sure where.

Since you don't seem to believe in math, I wrote a simple simulation of the 3968x at 0.03% bet:

Quote
#!/usr/bin/env python

import random

payout = 3968
chance = 0.03

starting_balance = 1
bet = 0.00000001
rolls = 10000000

def roll():
    return random.randint(0, 9999) < 3

balance = starting_balance
count = 0
while count < rolls:
    balance -= bet
    if roll():
        balance += payout*bet
    count += 1

    if (count < 100000 and count % 10000 == 0) or count % 100000 == 0:
        print "after %10d rolls, risked %7.4f, balance %10.8f, profit = %f%%" % (count, count*bet, balance, 100 * (balance - starting_balance) / (count*bet))

When you run it, the profit is up and down at first, but it settles down after a while:

Quote
after      10000 rolls, risked  0.0001, balance 1.00001904, profit = 19.040000%
after      20000 rolls, risked  0.0002, balance 0.99995872, profit = -20.640000%
after      30000 rolls, risked  0.0003, balance 0.99993808, profit = -20.640000%
after      40000 rolls, risked  0.0004, balance 0.99995712, profit = -10.720000%
after      50000 rolls, risked  0.0005, balance 1.00001584, profit = 3.168000%
after      60000 rolls, risked  0.0006, balance 1.00007456, profit = 12.426667%
after      70000 rolls, risked  0.0007, balance 1.00009360, profit = 13.371429%
after      80000 rolls, risked  0.0008, balance 1.00007296, profit = 9.120000%
after      90000 rolls, risked  0.0009, balance 1.00001264, profit = 1.404445%
after     100000 rolls, risked  0.0010, balance 0.99995232, profit = -4.768000%
after     200000 rolls, risked  0.0020, balance 1.00038080, profit = 19.040000%
after     300000 rolls, risked  0.0030, balance 1.00065056, profit = 21.685334%
after     400000 rolls, risked  0.0040, balance 1.00088064, profit = 22.016000%
after     500000 rolls, risked  0.0050, balance 1.00130912, profit = 26.182400%
after     600000 rolls, risked  0.0060, balance 1.00153920, profit = 25.653334%
after     700000 rolls, risked  0.0070, balance 1.00176928, profit = 25.275429%
after     800000 rolls, risked  0.0080, balance 1.00192000, profit = 24.000001%
after     900000 rolls, risked  0.0090, balance 1.00215008, profit = 23.889778%
after    1000000 rolls, risked  0.0100, balance 1.00241984, profit = 24.198401%
...
after    9000000 rolls, risked  0.0900, balance 1.01892160, profit = 21.024001%
after    9100000 rolls, risked  0.0910, balance 1.01895328, profit = 20.827781%
after    9200000 rolls, risked  0.0920, balance 1.01942144, profit = 21.110261%
after    9300000 rolls, risked  0.0930, balance 1.01961184, profit = 21.088001%
after    9400000 rolls, risked  0.0940, balance 1.01972288, profit = 20.981788%
after    9500000 rolls, risked  0.0950, balance 1.02019104, profit = 21.253727%
after    9600000 rolls, risked  0.0960, balance 1.02073856, profit = 21.602667%
after    9700000 rolls, risked  0.0970, balance 1.02096864, profit = 21.617155%
after    9800000 rolls, risked  0.0980, balance 1.02107968, profit = 21.509878%
after    9900000 rolls, risked  0.0990, balance 1.02111136, profit = 21.324607%
after   10000000 rolls, risked  0.1000, balance 1.02118272, profit = 21.182721%

The math predicts a player profit of 19.04%. The simulation shows a player profit of 21% after 10 million rolls. If you ran the simulation for longer, it would settle down at 19.04%. So I guess you either didn't run your simulation for long enough or made an error coding it.

You are the worst sort of idiot. You can't compute basic probability, yet are arrogant. I was wrong in thinking that no one could exploit your site, as you'd wonder why they were betting thousands of bets at a high multiplier, but apparently even when you are told the bug you are too daft to comprehend it. He probably could've bled your bankroll dry and you wouldn't never realized.

When subSTRATA came to me with this and I confirmed it was a real issue, he asked for my advice on how to proceed. I told him I have had mostly bad experiences with bug bounties. Most site operators will stiff you on the bounty if they think they can get away with it. We had a discussion about the morality of making the +EV bets just enough to earn what the feel the bounty is worth, and then reporting it "for free". subSTRATA was very much of the opinion that that would be wrong, and that he would just approach the site directly. I think he assumed that they take his message seriously since I was vouching for the fact that it was real. I think we were both shocked by the arrogance of their response.

Look you idiot, tell me all parameters that he used and I will check.

But if you bet on payout 3968
And roll under 0.3

You don't make any profit at all in 100 million bets. But if I am missing a parameter that you didn't tell me then it's a different story.

You missed a zero. It's 0.03% at 3968x. At 0.3% the profit should be huge, since that's an edge of 0.3 * 3968 - 100 = 1090.4% for the player.

I even gave him a clear mathematical working to only be called an idiot in kind.

You called me idiot first.  And yeah, I will miss you very much.

That's different. He called you an idiot because you were being an idiot.

You called him an idiot because you were butthurt.

And thanks for negative feedback whoever gave it to me. Kiddie.

I wouldnt call quickseller of all people a "kiddie...."

Maybe he is a man that can't read then? All issues in this thread were fixed.

I think the biggest issue in this thread is the horrible way you dealt with the whole situation. I can't imagine how you could have been any less professional. I don't have any reason to believe that you will react any differently to future bug reports. Do you?

And I hate red color. I hate math too, but can still code. F***.

You should stop coding. If you don't understand the math underlying the algorithms that you are coding you end up with horrible errors like we have seen here. You are lucky that subSTRATA took the approach he did rather than slowly bleeding your bankroll dry. It seems like there is very little chance you would have ever found out how it was happening considering how hard it was to pound the understanding into you in this thread.

I did about 10,000 rolls at .0002BTC, stopping occasionally.  The first 5,000 rolls were hit or miss.  The next 5,000 rolls I didn't win any to the point where I needed to cut my bet size down in half.  Once I started betting .0001BTC, I never won a single wager.

I had a similar experience yesterday. I had horrible losing streaks, but put it down to variance. I didn't keep logs at all, and didn't have any kind of seed logging in place either.

The site claims to be provably fair, but for all intents and purposes the amount of work the player needs to put in to verify the fairness means it may as well not be.

They should change to use a system like Just-Dice uses, where the player can make a million rolls at <0.02% and then at the end reveal their server seed and easily check how many times they should have won by running the provably fair algorithm in a loop with a single seed pair and an ever-changing nonce. Lots of sites have adopted that system - it's free for anyone to use.

if dooglus wants to post one too ill gladly edit it into the op, the guy really deserves credit for finding some back-end bugs.

1JtD6uG43feZrUqgxTYsQAPTmgmq8hogCt is an address for me. But don't feel the need to tip me - I didn't do anything other than vouch for subSTRATA's find.

Wait, so Dooglus blackmails other sites too? word it anyway you want but this was blackmail, pay my price or I release / sell the exploit that would harm not only the owner but innocent investors who probably didn't know better.

right? Or am I missing something here?

No, here's how I do it: I email the site and disclose the bug report up front. Then they try to find excuses not to pay me. Sometimes they end up paying something, but most often I get nothing.

In this case I was merely vouching for subSTRATA. He didn't want to get ripped off by the site and so wanted to get paid up front. They wouldn't believe him if I didn't vouch for him. And didn't believe him that I did. Ho hum.

I don't think anyone was threatening to release or sell the exploit, but maybe I'm wrong.

"I have found an issue with your site that others could potentially use to steal from you, I have no intention of disclosing it to anyone other then you, nor do I have any intention of using such exploit personally, although I cannot guarantee that others will not use the same public information to exploit this same issue."

I think the above would pass the test of not being blackmail, while still being reasonably compensated for your time/skills.

The fact is that gambling sites are for-profit entities, and giving advice as to how to prevent yourself from getting robbed when large amounts of money is at stake should not be given for free. These sites should invest in the time/effort to prevent these kinds of exploits from existing in the first place.

Exactly. It is common practice for gambling sites NOT to reward people who help them fix security holes, and so it doesn't seem unreasonable to withhold information until the reward is paid. Their site contains text claiming that the DO reward people who report bugs, and so it doesn't seem unreasonable to use what is effectively an escrow to hold knowledge of the bug in exchange for the reward.

Or, in other words: They say "we pay for bugs". There is a history of sites breaking that promise, and so using a "bug escrow" (like me) seems reasonable. And not like blackmail at all.

it may be that your ip/account is blacklisted to skip nonces or something of the sort.

No need to skip nonces. The site doesn't use them. It makes up a new server seed for each roll.
3131  Economy / Scam Accusations / Re: [SCAMMER ALERT] FAKE Bittrex-Richie || 360 CLAMs stolen || Just-Dice.com on: July 03, 2015, 11:09:45 AM
I don't think its Poloniex either, and Bittrex won't comment if its there's or not.. but by now its probably too late. Just hope no one else falls for this again.

I contacted poloniex and bittrex immediately.

Poloniex very quickly told me it wasn't their address.

Bittrex were very unhelpful and eventually told me:

Quote
Your request (...) has been solved. To reopen this request, reply to this email.

Bill   
Bill (Bittrex)
Jun 24, 21:02

Hi Chris,

Could you encourage that user to contact the appropriate authorities to conduct an investigation?

Thanks,
Bill

I think when they say it "has been solved" they mean it "hasn't been solved but please go away". They never would even tell me whether they owned the address the stolen coins were sent to or not.

I hadn't tried their customer support until then, but this was all the experience I needed to know that I should withdraw my balances ASAP.
3132  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake on: July 03, 2015, 11:02:17 AM
*lol* Sounds like a currency that rewards you for NOT using it as a currency. If i would have read it without knowing clams i would think this is a scamcoin and the creators did this to become rich. Tongue

Maybe you misunderstood. Staking destroyed age, setting it back to zero. So it's not like old coins keep getting old and staking at the same time. You choose: stake, or gather age. The idea seemed to be that you could load up your wallet once a month and collect all the built up staking that had accumulated due to the age. But when staking is meant to secure the network surely you don't want people only doing it once a month. Hence the abolishment of 'age'...

Thanks for the explaination. So the sets of parameters for each second are fixed. You cant try different hashes in one second. Or 16 seconds, now. Would one have an advantage when calculating hashes in advance? I guess so since finding hashes for the same second should be hard. I mean where do you take the second from? Your second can be some seconds after the seconds of other miners, so you would be late all time, not finding a block ever.

All the inputs are fixed. You can't increase your chances of finding a 'good' hash by throwing more CPU at it. You could calculate hashes somewhat in advance (though I think some of the inputs depend on recent blocks, so not too far in advance) but hashing doesn't take long anyway. The JD staking wallet checks something like 30k outputs in 4 seconds.

src/kernel.cpp says this:

Code:
// Stake Modifier (hash modifier of proof-of-stake):
// The purpose of stake modifier is to prevent a txout (coin) owner from
// computing future proof-of-stake generated by this txout at the time
// of transaction confirmation. To meet kernel protocol, the txout
// must hash with a future stake modifier to generate the proof.
// Stake modifier consists of bits each of which is contributed from a
// selected block of a given block group in the past.
// The selection of a block is based on a hash of the block's proof-hash and
// the previous stake modifier.
// Stake modifier is recomputed at a fixed time interval instead of every
// block. This is to make it difficult for an attacker to gain control of
// additional bits in the stake modifier, even after generating a chain of
// blocks.

and this:

Code:
// ppcoin kernel protocol
// coinstake must meet hash target according to the protocol:
// kernel (input 0) must meet the formula
//     hash(nStakeModifier + txPrev.block.nTime + txPrev.offset + txPrev.nTime + txPrev.vout.n + nTime) < bnTarget * nCoinDayWeight
// this ensures that the chance of getting a coinstake is proportional to the
// amount of coin age one owns.
// The reason this hash is chosen is the following:
//   nStakeModifier: scrambles computation to make it very difficult to precompute
//                  future proof-of-stake at the time of the coin's confirmation
//   txPrev.block.nTime: prevent nodes from guessing a good timestamp to
//                       generate transaction for future advantage
//   txPrev.offset: offset of txPrev inside block, to reduce the chance of
//                  nodes generating coinstake at the same time
//   txPrev.nTime: reduce the chance of nodes generating coinstake at the same
//                 time
//   txPrev.vout.n: output number of txPrev, to reduce the chance of nodes
//                  generating coinstake at the same time
//   block/tx hash should not be used here as they can be generated in vast
//   quantities so as to generate blocks faster, degrading the system back into
//   a proof-of-work situation.

I've never tried to understand it fully, but it looks like the author went to some lengths to make it hard or impossible to game.

And you said the wallet checks each of your addresses. Does this mean you can have different addresses in your wallet and you could try out each one if it creates a correct hash?

I did? I didn't mean to. It checks each *output*. You can have multiple unspent outputs per address. JD keeps most of its value split into 30k separate outputs at a single address. The wallet loops through all the unspent outputs it controls, does a hash for each of them, trying to find one that hashes low enough to stake a block.
3133  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake on: July 03, 2015, 09:49:04 AM
I really hope their update isn't done.

Yeah, you don't just leave dead links like that. I'm sure it's just an oversight.
3134  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake on: July 03, 2015, 08:02:58 AM
Appears Altquick has added CLAMS Smiley

https://www.youtube.com/watch?v=9D-QD_HIfjA

*cums*

Edit:  Wait can ppl sell here or are they only letting people buy...?

Double Edit:  Looks like they list everything Shapeshift does.

Is this the right place? https://www.altquick.co/ ?

I tried clicking 'sell' at the bottom. Got this:



It's not entirely clear what the site is. Is it only for converting between altcoins and US dollars?
3135  Alternate cryptocurrencies / Service Announcements (Altcoins) / Re: Scrypt.CC | Scrypt Cloud Mining on: July 03, 2015, 07:26:18 AM
In a way yes, when Blocks are static in POS it's a little like a lottery (because the same amount of reward is being generated each Block and each day) you would assume that larger Blocks are better because they would Stake sooner. The Skill is in finding that sweet spot in which you can generate the highest amount of Stakes possible with the amount of Coins you have. I thought larger Blocks were better too until presstab broke up all his Blocks super small, I called him crazy but he proved me wrong. There is such a thing as too small as well and may dwindle at max age if going too low, if lots of people start using small Blocks, then you would need to use larger Blocks in order to compensate.

OK, you're talking about splitting outputs into optimal sizes for staking. I see. Smiley I do that too...
3136  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][CLAM] CLAMS, Proof-Of-Chain, Proof-Of-Pearl, Recent Mandatory Update on: July 03, 2015, 04:42:00 AM
Anyways, this gist of my post is that I didn't quite see the use, and that a normal bootstrap skips over blocks that you already have. But now that I more fully understand your reasoning behind this, and how much faster this actually will process the blocks that you already have... this is amazing! This could really be useful when you stop a bootstrap midstream and need to start it backup. Or if you have been out of sync for a month or two.

I guess I see things differently. I use satellite Internet and have a hard cap on monthly data transfers. I don't want to be downloading a relatively large bootstrap.dat if I know that I only need the last 2% of it. The fact that the CLAM client will take a few minutes to skip through the 98% I already have isn't that big a deal. The wasted file transfer is. (Chopping the big bootstrap.dat into little parts happened on remote servers with proper Internet connections and didn't involve my having to upload or download anything other than a few command lines over the satellite connection).

It would be nice to have this automajically in the client, to go out and download the bootstrap that is needed to get up to date....  

The problem with that is that you're trusting me to provide the true longest chain. It adds another kind of centralisation to CLAM. Of course, the client validates every block it reads from the bootstrap file, and only adds it if it is valid, but I still don't like the idea of having the client know about my particular copy of it.

Having said that, what do people think about updating the checkpoints in the CLAM client? I bet that hasn't been done for quite a while now:

Code:
    // What makes a good checkpoint block?
    // + Is surrounded by blocks with reasonable timestamps
    //   (no blocks before with a timestamp after, none after with
    //    timestamp before)
    // + Contains no strange transactions
    //
    static MapCheckpoints mapCheckpoints =
        boost::assign::map_list_of
        ( 0,      hashGenesisBlock )
   ( 6666,  uint256("0x000002129d8a2b43509d2abb0aa24932b7af2f760e869d5952dee97d4b8ea8bf") )
        ( 10000,  uint256("0x00000de398b1ec72c393c5c54574a1e1784eb178d683e1ad0856c12fac34f603") )
        ( 29000,  uint256("0x068769a2ab0e35fc3ac31690158401b9538a7cce2a97096b22d47e50355b2e1f") )
        ( 175000,  uint256("0xec64deeb7f1295216f20ce5dbe68b0bd28189a5a644a111e722c05451d51e66c") )
        ( 250000,  uint256("0xb560c121438f630401c102767587b70cb0cc7d1e0c09114dd0b91455262aa64c") )
    ;

So we have checkpoints up to block 250k, staked on Sat Dec 13 15:14:24 2014, but nothing since. I think that means that theoretically MtGox (say) could dig up a whole load of CLAMs tomorrow, and use them to completely rewrite the chain from last December, wiping out all the transactions and blocks that have happened since.

The "reasonable timestamps" isn't an issue any more I don't think, since we no longer accept timestamps out of order.

Block 530000 was staked 5 days ago, has no weird times around it and contains only a simple staking transaction:

529995 Sat Jun 27 17:35:12 UTC 2015
529996 Sat Jun 27 17:36:00 UTC 2015
529997 Sat Jun 27 17:36:32 UTC 2015
529998 Sat Jun 27 17:36:48 UTC 2015
529999 Sat Jun 27 17:37:04 UTC 2015
530000 Sat Jun 27 17:37:20 UTC 2015
530001 Sat Jun 27 17:37:36 UTC 2015
530002 Sat Jun 27 17:39:12 UTC 2015
530003 Sat Jun 27 17:39:28 UTC 2015
530004 Sat Jun 27 17:40:00 UTC 2015
530005 Sat Jun 27 17:40:16 UTC 2015

I guess I'll add a checkpoint for it.

Edit: note those 11 timestamps just above, and how they are all exact multiples of 16 seconds apart from each other. That's the 16 second window I keep going on about. As far as CLAM staking is concerned, there is no point of time between 17:40:00 and 17:40:16. Time passes in 16 second lumps.
3137  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake on: July 03, 2015, 04:37:35 AM
When you gave the example of a solo staker vs JD finding a block at the same time then you said that JD has a 75% chance of being able to build on it's block and the solo staker I guess has the other 25%.  Is this because of the volume of clams that JD is holding?  By holding such a large amount JD has a better chance of finding the next block and orphaning sologuy's?  Or is it because of better connections to peers than solog guy?  Or some combination thereof?

JD has a 75% chance of finding the next block because JD has 75% of the total staking weight on the network. I don't know how much effect network connectivity has. JD's wallet isn't connected to many peers most of the time - and I don't know if that helps or hinders it. I figure the 16 second length of the time windows means network latency isn't a big deal for the most part but I could be wrong there.

If the solo staker has 5% of the staking weight and JD has 75% then there's 20% elsewhere. We don't know whether they'll be working on JD's block or the solo-staker's block - it would depend which of the two they saw first. So the 75% chance for JD is a minimum.

The situation is further complicated by the fact that we don't know with any accuracy what the total network staking weight is. People who are trying to stake with small amounts but failing are effectively invisible. There's no way of knowing how many CLAMs are trying to stake other than trying to infer it from the network difficulty and the rate at which blocks are found. But the difficulty swings up and down quite drastically many times per day, making such calculations tricky.
3138  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake on: July 03, 2015, 04:30:54 AM
Though i wonder how blocks are found at all. It sounds like calculating like with bitcoin but its not the case. I heard its random but that doesnt account for how orphaned blocks can happen then. You dont need to explain when you think i should investigate myself. Wink

It's not particularly easy to find out.

When I first discovered CLAM, I couldn't find out how staking worked, so I read the source code and summarised it like this:

you work out the "clam days" of your outputs. If you have 0.13 CLAM that hasn't moved for 3 days, you have 0.39 "clam days" (multiply value by age). I think that 0.39 is then rounded down to an integer, which might be your problem, since it will go to 0 for you. But suppose you had 13 CLAM that hadn't moved for 3 days.  That's 39 clam days. That gets multiplied by about 4000 (depending on the current difficulty). So you get 39*4000 = 156,000. Then every second your client hashes a bunch of stuff and gets an effectively random number between 0 and 4.3 billion. If the number is less than your 156,000 then you get to stake. 156,000 is about 27,500 times smaller than 4.3 billion, so you get to stake about once per 27,500 seconds (458 minutes, 7.5 hours).

So 13 CLAM that's 3 days old stakes every 7.5 hours or so. As it gets older, its chance of staking increases.

And I think your 0.13 CLAM needs to be 1/0.13 = 7.7 days old before it gets over 1 "clam day", and so even has a chance of staking, though I might be wrong on that point.

It has changed since then. There is no longer the concept of "age" - the weight of an output is simply its size (once it has matured and not been involved in a transaction for 4 hours). And the "every second" changed to "every 16 seconds". And the difficulty became about a million times easier.

But basically, every 16 seconds your client looks at each of your unspent outputs, finds the ones which are mature and haven't moved in the last 4 hours, and hashes a bunch of information together (including the current time, the txid, etc.). If the hash is smaller than the current network-wide target times the value of the output then that output gets to stake a block. Multiplying the target by the size of the output makes the ease of staking proportional to the size of the output.

It's "random" in the same way that Just-Dice rolls are random: it isn't, but it appears to be due to the nature of hashing. Imagine hashing "abc123"+current_time_in_seconds with sha256 until you got a number less than a million as the hash result. There's a particular time in the future when that will happen, but without trying it for every current_time_in_seconds you can't predict when it will happen.
3139  Alternate cryptocurrencies / Service Announcements (Altcoins) / Re: Scrypt.CC | Scrypt Cloud Mining on: July 03, 2015, 04:21:15 AM
Can you still compare scrypt.cc with "classic-ponzi-scam-few moths-for-assholes" sites? /bitcoincloudservices for example.../

There's not really any comparison. In scrypt the assholes get imaginary "KHS". In the moths-for-assholes site they at least get a few moths. Do you have a link? It sounds kind of interesting. I'm wondering how it compares to my new site, butterflies-for-dingbats.com
3140  Alternate cryptocurrencies / Service Announcements (Altcoins) / Re: Scrypt.CC | Scrypt Cloud Mining on: July 03, 2015, 04:10:30 AM
Inflation is currently 0.5% per day (static 30 coins per Block) but if really good at Staking you could get something like 1.5% per day [...]

Define "good at staking"? Is it a game of skill?
Pages: « 1 ... 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 [157] 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 ... 573 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!