Bitcoin Forum
June 18, 2019, 04:15:55 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [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 ... 346 »
  Print  
Author Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer  (Read 449642 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
March 22, 2016, 07:10:20 AM
 #221

Will it be possible to send BTC directly from Coinbase Account to Elastic project?
Or do I need to transfer first the BTC from coinbase to a wallet (example blockchain.info) then to Elastic project (to get the private Key)
The address to send will be 3Q2aKEGFTKDw3hghsBifXp39CZVMtZukxn correct?
Thanks,

You should never use an exchange to directly withdraw to the donation address if you want to receive some ELC.
A coinbase account should be fine, but the easiest way is indeed to send everything to a private account first.

If you use your coinbase wallet you would need this information:

- 3 extended public keys (xpubkeys)
- User seed
- Shared encrypted seed
- Your vault password

0% MINING FEES FOR THE NEXT MONTH. GET PAID IN BTC, ETH, XMR or RVN.

www.cudominer.com Learn More
Easily run CudoOS from a USB flash drive.
Designed for rigs. Manage your mining remotely from Cudo Console.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1560874555
Hero Member
*
Offline Offline

Posts: 1560874555

View Profile Personal Message (Offline)

Ignore
1560874555
Reply with quote  #2

1560874555
Report to moderator
Dazza
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 22, 2016, 07:55:44 AM
 #222

That is about 5 months before bitcoin reaches that block number. Longest ICO ever? Is there any incentive to "donate" now versus waiting?

You get more ELC for your BTC if you donate now versus waiting.
Dazza
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 22, 2016, 08:00:12 AM
 #223

Definitely send it to your Private Wallet first. I made the mistake of sending 0.5 BTC from my exchange account so I lost that money.
Hope this helps.

Ben

Sorry this happened to you.  However the instructions on the website have always been clear on this point.  It's not anyone else's fault if you didn't read them or couldn't comply with them.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
March 22, 2016, 08:06:15 AM
 #224

Last night, when I couldn't sleep, I was thinking about the N-account attack, specifically this version here (let's call it N+2 account attack):

Quote
What also came to my mind: what he could also do is to move the funds to a different account the moment he has found a block. This of course would lock his new account down for the next N blocks (until the ASV is mature) but allowing him then to mine a block with a new "identity" without any "past". He just needs enough "coins in the buffer" to pull it off successfully. Calibrated correctly, every block, a new account (belonging to the attacker) with a sufficiently high ACV wins.

I.e., Assuming C coins is enough to win a stake and N>M, then the attacker needs (N+2)*C coins (split over N+2 accounts with an ASV of C) of which N*C coins cannot be used as they need N blocks to get mature (we call them coins-in-the-queue), while 1*C of them are used to "be sent to a different account" one block after they staked a block, and 1*C are winning the current block.

EDIT: Removed possible solution, as it clearly was none.
Dazza
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 22, 2016, 02:27:55 PM
 #225

Last night, when I couldn't sleep, I was thinking about the N-account attack, specifically this version here (let's call it N+2 account attack):

Quote
What also came to my mind: what he could also do is to move the funds to a different account the moment he has found a block. This of course would lock his new account down for the next N blocks (until the ASV is mature) but allowing him then to mine a block with a new "identity" without any "past". He just needs enough "coins in the buffer" to pull it off successfully. Calibrated correctly, every block, a new account (belonging to the attacker) with a sufficiently high ACV wins.

I.e., Assuming C coins is enough to win a stake and N>M, then the attacker needs (N+2)*C coins (split over N+2 accounts with an ASV of C) of which N*C coins cannot be used as they need N blocks to get mature (we call them coins-in-the-queue), while 1*C of them are used to "be sent to a different account" one block after they staked a block, and 1*C are winning the current block.

EDIT: Removed possible solution, as it clearly was none.

Very briefly, as I'm busy with real life, the attacker gains nothing doing this because he could pull off the same attack with the same N accounts over and over.  He doesn't need to create new ones.

I do have a new idea to defend against this.  Hope to be back late this evening, but gotta go now.

Edited to Add:  M is always >= N, it can never be < N.
Dazza
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 23, 2016, 01:54:39 AM
 #226

I will rephrase your method quickly with my own words just to make sure I got everything right. Questions are inline.

First, we have:

- ASV = Account Stake Value: It is equal to the lowest balance that the account has had during the last N blocks.

Yes.

Quote
An account that was recently created or which has won a block fewer than N blocks ago has an ASV of zero.

I did say that, but then changed my mind.  Forgot to unsay it; beg pardon.

The current iteration of this scheme allows accounts to win more than once per N blocks, but only as a last resort.  A valid block from any account which has not won in the last N will always beat one from one that has, but this is now done further into the algorithm, not here.

Quote
- BSV = Block Stake Value: The BSV of the block extending a chain equals to it's own ASV plus the ASV of all other PoS+B and PoS-B extending the same chain (in the future or in the past? Is it just the cumulative ASV up to "now"?). No account's ASV is counted more than once in the past N blocks.

My original thinking was as follows:

All PoS contain a hash of the previous PoS+B, specifically of the branch they regard to be the current winner.   Out of all the valid PoS+B submitted extending this branch, the one with the bighest ASV will win, but its BSV will then equal the sum of the ASVs of every PoS hashing to the same previous PoS+B.  You should interpret every PoS as a vote to extend a particular chain, though only PoS+B come with a block to extend it.

A side-chain may also receive PoS-B and PoS+B from various accounts which indicates that other nodes think that the side-chain is in fact the main chain.  If a side-chain attracts more stake value than what a node believes to be the main chain, then that's an indicator that the node's belief is incorrect.

The PoS part of a PoS+B would do double duty, both supporting the block nomination, and voting for the chain it tries to extend. Hence if both a PoS+B and a PoS-B were received from the same account, delete the PoS-B.

My current thinking revises this as follows

It would be simpler if the PoS+B were simply to nominate the block, while the PoS-B (which would come later in the revised 4-stage schedule) votes for which chain to extend.  Consequently, both a PoS+B and a PoS-B from the same account should be expected and accepted.  An honest PoS miner ought to vote against his own winning block, if he saw a block on a close-running side chain supported by a much higher ASV.  However there's no way to enforce this.

Quote
- CSV = Chain Stake Value: The CSV is the sum of the last N blocks' BSVs. (did I get it correctly that we have sums of sums of ASV's? Counting older ASV's more often then newer?)

Yes, sums of sums of ASV's, in principle all the way back to the genesis block.  In practice you only need to go back as far as the oldest live forkpoint.  My current thinking is that only the most recent PoS-B, (in any branch) should count.  Hence if an account switches its support to a different branch, it's previous support is cancelled.

Quote
Then, we have two different "proof of stakes":

- PoS+B = PoS with associated block (i.e., including and confirming transactions)
- PoS-B = PoS without associated block

Yes, but according to my current thinking, the PoS+B only nominates a block, it does not vote for the chain it extends.  The account should send a PoS-B to do that.

Quote
Now starts the so called so-called voting period:

- Nodes broadcast a PoS+B block for each of their accounts A where ASV(A)>x% * OLD_WINNER_ASV, that is, the ASV of account A is x% of the ASV of the winner of the last block or higher.
- Additionally, each Node broadcasts an PoS-B (here, without a block, i.e., without confirming any transactions) for each of their accounts A where ASV(A)>threshold. The threshold is fixed and no hash target has to be met.

My current thinking is that there are two periods which might be called the "nomination period" when PoS+B are launched and the "voting period" when PoS-B are launched.  I also think a node should always launch exactly one PoS+B, the best it can for the branch in considers to be the winner unless it receives a better PoS+B from somewhere else before it launches its own.  I've abandoned the idea of a lower limit of x%.

Thinking about "Nothing @ Stake", I cannot see a way, if a node controls more than one account, to prevent or detect it launching multiple PoS+B, each from a different account, each to a different branch.  There would be no point in launching multiple PoS+B to the same branch, because it will know ahead of time which one would win.

I am assuming that there is nothing tying an account to the node that controls it.

Quote
Then this happens


Quote
All launched PoS (both PoS+B and PoS-B) should extend the chain with the greatest CSV, according to the launching node. (not sure I get that: all valid blocks extend that chain? Not just the "best" one?  Or is it rather one best PoS+B and one best PoS-B? I fear I am not 100% aware of what exactly is added to the collateral and what is extending the chain. Also, is the collateral persistent, or is it just for the voting phase?)

Current thinking is just the one best PoS+B (There can be only one winner), but as many PoS-B (each for a different account) as the node can validly launch.  Collateral is persistent, until that account launches another PoS-B, at which the previous collateral for that account is cancelled.

Quote
The end result of all of this, is that so long as a node controls at least one account with ASV > 0,

Or even if it doesn't, if we allow zero-ASV account to PoS+B if there is nothing better.

Quote
there will be at least one chain extended by a PoS+B.

Again, this works only if we abandon the >x% criterion and allow any account to PoS+B

Quote
Any chain not so extended dies.  Also a chain dies if it's CSV is less than y% of the CSV of the winning chain.

Current thinking is that any new side-chain <y% be allowed a stay of execution of a limited number of blocks, just in case it has more support than the node knows about, perhaps due to connectivity problems.

But yes, at some point a judgment has to be made that a side-chain is no more; it has ceased to be; It's expired and gone to meet its maker.

Quote
Apart from the addition of PoS-B, The new scheme differs from the previous in that an account's ASV is no longer the time integral of its balance.  Instead it is equal to the lowest balance that the account has had during the last N blocks.

Yes.

Quote
An account that was created or which has won a block fewer than N blocks ago has an ASV of zero.

Created fewer than N blocks ago, yes, because its balance before creation logically must have been zero.

Last won a block fewer than N blocks ago, no.  So long as it maintained a +ve balance throughout the last N blocks, it will have a +ve ASV.

Quote
The block extending a chain has a BSV equal to it's own ASV plus the ASV of all other PoS+B and PoS-B extending the same chain. Call these other contributors of ASV to the BSV "collateral support".  No account's ASV is counted more than once in the past N blocks, so if any of the PoS, including the winning PoS+B has already contributed collaterally to the BSV of an earlier block in the chain, then it is not counted again.

See above.  We will be counting only an account's most recent PoS-B, so it is the earlier one(s) which will be ignored.

Quote
Nor, if a block is added to a collateral supporter, does the new block add to the collateral support.  In other words, collateral support is given to sisters, not aunts.  The CSV is the sum of the last N blocks' BSVs.

Current thinking is that PoS+B never contributes collateral support whether or not there is a PoS-B from the same account.  All a PoS+B does is nominate the block.

Strictly speaking collateral support is given to mothers, but of course it is all the winning daughter who are supported when mother is supported, i.e. the sister of the collateral supporter.  I hope this makes sense.

Quote
The idea behind collateral support is that the main chain will benefit from honest PoS more than any side-chain, including a side-chain being built by an attacker.  (If the attacker's chain benefits more, then it is the main chain by definition.)  Moreover an attacker can gain nothing by diverting his resources into his own collateral sybils, since this will just take away ASV from his winning blocks.  This is a zero-sum game for him.  PoS-B allows every account-holder with any ASV at all a chance to contribute collaterally to blockchain security, though they can never win a block unless their ASV is enough to allow them to launch a PoS+B.

Yes.

Quote
Every PoS, with or without block, will need to has all the PoW supporting it's predecessor.

Don't understand the sentence.

Quote
So essentially, at least from what I understand, we no longer rely on any hash. As the hash was the only random factor in the scheme we now have a deterministic order

Deterministic, but not necessarily predictable because an attacker (or anyone else) does not know which other accounts will stake at any time.

That said, my ultra-ultra-latest thinking is that, just to inject more randomness into the system, perhaps we should have a hash target, but one that is the same for all accounts, and independent of the SV.  However we will have to be careful to ensure that an attacker can neither predict whether an account he doesn't control will pass its target on a particular turn, nor manipulate the accounts he does control to ensure that they will.

Quote
who from a subset of N "online" users will win which block.

The subset is not limited to N.

Quote
Also, I an not yet fully sure how the ASV will be "reaccumulated" after it was dropped to 0 upon creation of a new block. Will the ASV recover fully after N blocks have passed?

That was my original idea.  The sole purpose of dropping to zero was to prevent accounts from staking more than once in any N consecutive blocks.  This is now achieved in a different way.

Quote
If so, this could leave an attacker the possibility to create N high-stake account and winning blocks with them "round robin".

Yes, he can do that.  They would have to be all higher than any other staking account, which would be quite hard to achieve.

(Snip recapitulation of obsolete scheme.)

Quote
Sorry if I get that wrong, bit don't we have the same problem here? Its just not that you need N accounts, but M accounts (which is less actually, as M<=N?)

M >=N.  M is actually the distance back to the last confirmed block.  This will be N unless there is a long-lasting fork whose fork-point is further back.

Quote
Quote
Step 1.  Normalise each candidate's ASV by dividing by the largest ASV of any of the last N block winners.  This will not affect their rankings in any way.  From now on, when I refer to a candidate's ASV, it is the normalised value I'm talking about.

Step 2.  Iterate through the candidates in decreasing order of ASV.  For each candidate, if the account last won more than max(M,N/ASV), or if it has never won, it wins; exit.  Otherwise multiply the ASV by the number of blocks to the last win.  Use this figure in the tiebreaker described in step 3.

Step 3.  If no candidate won during step 2, then the winner is the candidate that has won the least number of times during the last M blocks.  If there is a tie, then use the figure calculated in step 2 as a tiebreaker.



There is still a strange, though not necessarily undesirable property about this system.  Sometimes more stake can hurt an attacker.  For example, suppose the same honest accounts are staking throughout.  An attacker with N accounts each with equal balances greater than the highest-value honest stake would win every block forever (or until a non-staking account with a higher balance decided to start staking)  If these N accounts were the N highest, the attacker could permanently shut out transactions of his choice, including any transaction that might enable another account to compete.

But it would be really obvious that he was doing this.  So let's suppose that the attacker had some more funds, and randomly increased the balances of some of his accounts, then he would no longer prevent accounts he doesn't control from winning the occasional block.

Maybe its just because its sunday midnight, but I don't see the point why increasing his amounts would break his monopole. Could you please explain that in 2 lines?

Not in two lines, but in one short paragraph:  If all the attacker's accounts have the same minimum balance, i.e., the same raw ASV (and all no lower than the honest account with the largest raw ASV) then, after the normalisation in step 1, all the attacker's accounts will have a normalised ASV (nASV) of 1.  On the other hand, if one of his accounts has a higher ASV than the others, the highest account will normalise to 1 and the lower accounts will normalise to < 1  These account will not be able to win every N blocks.  Instead, they will win every N/nASV > N blocks (assuming that M is not higher than this.)

Quote
What also came to my mind: what he could also do is to move the funds to a different account the moment he has found a block. This of course would lock his new account down for the next N blocks (until the ASV is mature) but allowing him then to mine a block with a new "identity" without any "past". He just needs enough "coins in the buffer" to pull it off successfully. Calibrated correctly, every block a new account (belonging to the attacker) with a sufficiently high ACV wins.

I.e., Assuming C coins is enough to win a stake and N>M, then the attacker needs (N+2)*C coins of which N*C cannot be used as they need N blocks to get mature (we call them coins-in-the-queue), and 1*C of them are used to "be sent to a different account" one block after they staked a block, and 1*C are winning the current block.

I think he only needs N accounts all with a raw ASV higher than any other staking account, to win every block forever.  He won't need to shuffle his money around.  The question that needs to be asked is, what can an attacker achieve if he succeeds in his attempt to do this?  As far as I can see, other than winning all transaction fees, the only thing he can do is shut out transactions of his choice.  To attempt to double-spend would require a side-chain attack, and the rule that (1) no transaction is considered confirmed if it is not in a block preceding the earliest fork point, and (2) no forking block is accepted if it is later than a confirmed block, prevents all possible double-spending attacks.

In other words, the worst that an attacker can do is DoS.

I have two ideas to defeat this.  First is the ultra-ultra-latest idea of randomness.  No matter how low we set the probability of an account not being allowed to stake that turn, and no matter how many high-value accounts he has, eventually all his accounts will be blocked in the same turn, and his monopoly (or even his monopole Smiley ) will be broken, if only temporarily.

My second (brand new) idea is to introduce a new metric that nodes can use to decide which branch is the current winner - not difficulty, nor stake-value, but unsociability.  A branch's unsociability is the total number (or perhaps the total value) of all transactions the node knows about that are not yet included in the branch, excluding very recent ones, and perhaps giving a higher weight to older ones.  Anyone not including all the transactions he knows about into his blocks will soon find his branches losing to more sociable side-chains.

And if the attacker with N high-value accounts locks out all others, and is completely sociable, in what way is he attacking?
devking
Member
**
Offline Offline

Activity: 96
Merit: 10


View Profile
March 23, 2016, 04:30:12 AM
 #227

Its a good project. I have invested my 1.5btc Needs patience. Good luck devs.

Join the Elastic revolution!  Elastic - The Decentralized Supercomputer
ELASTIC WEBSITE | ANNOUNCEMENT THREAD | ELASTIC SLACK | ELASTIC FORUM
Blockchain.Ventures
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile WWW
March 23, 2016, 04:43:26 AM
 #228

Great discussion going on in ELC.
Waiting to see a working product before putting some BTC in.
Bgjjj2016
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250

Ben2016


View Profile
March 23, 2016, 06:36:48 AM
 #229

Definitely send it to your Private Wallet first. I made the mistake of sending 0.5 BTC from my exchange account so I lost that money.
Hope this helps.

Ben

Sorry this happened to you.  However the instructions on the website have always been clear on this point.  It's not anyone else's fault if you didn't read them or couldn't comply with them.

Thank you ! I never blamed anyone on my post.

My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
Join the Elastic revolution! Elastic Network: The Decentralized Supercomputer 
ELASTIC WEBSITE|ANNOUNCEMENT THREAD|JOIN THE SLACK
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
March 23, 2016, 07:01:32 AM
 #230

Hi guys, I will be offline for the next 5 days as I will have no access to an internet connection from where I go now. I will be working offline and present you my work and my thoughts as soon as I come back.
cryptoheadd
Hero Member
*****
Offline Offline

Activity: 868
Merit: 500


View Profile WWW
March 23, 2016, 08:44:39 AM
 #231

Do you guys have a Slack?
Mrboot
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000


View Profile
March 23, 2016, 02:25:01 PM
 #232

Hey Elastic team,

About a day or something after i deposit 1,27 Btc exactly the same amount got withdrawn from your wallet.

Im just here to ask if my ico deposit still is oke ? and this funds was just for development withdrawn.
jaynipal
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
March 23, 2016, 08:22:52 PM
 #233

Today, I sent 0.75 BTC to your project via my Coinbase wallet about two hours ago and still don't see it on the GitHub records.

I appreciate your time and input.

Maybe I can help,
check: https://raw.githubusercontent.com/elastic-project/genesis-block/master/genesis-block.json
and scroll to the very bottom. There it is.  Cool

Is it ok to send from coinbase account?
Dazza
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 23, 2016, 11:24:40 PM
 #234

my ultra-ultra-latest thinking is that, just to inject more randomness into the system, perhaps we should have a hash target, but one that is the same for all accounts, and independent of the SV.  However we will have to be careful to ensure that an attacker can neither predict whether an account he doesn't control will pass its target on a particular turn, nor manipulate the accounts he does control to ensure that they will.

To ensure that an attacker cannot predict whether another account (i.e., not under the control of the attacker) will be able to stake or not, what is hashed should be the account's digital signature of something.  The "something" needs to be something that the account owner can't manipulate, (so that he can't PoW it), it shouldn't be different if he chooses a different branch (so he can't N@S), and it should be no older than N blocks (so he can't try a bunch of accounts and see which one will be able to stake before he has to fund the account.)  I propose that the "something" be the PoS hash N blocks ago.  This is not entirely N@S proof because forks can last longer, but this will be unusual, I think.

Quote
Quote
Step 1.  Normalise each candidate's ASV by dividing by the largest ASV of any of the last N block winners.  This will not affect their rankings in any way.  From now on, when I refer to a candidate's ASV, it is the normalised value I'm talking about.

Step 2.  Iterate through the candidates in decreasing order of ASV.  For each candidate, if the account last won more than max(M,N/ASV), or if it has never won, it wins; exit.  Otherwise multiply the ASV by the number of blocks to the last win.  Use this figure in the tiebreaker described in step 3.

Step 3.  If no candidate won during step 2, then the winner is the candidate that has won the least number of times during the last M blocks.  If there is a tie, then use the figure calculated in step 2 as a tiebreaker.

I'm now thinking that the dependency on M in this algorithm is likely to cause more problems than it solves, because M is not a network-wide parameter.  Different nodes will have different views on what M is, and so will have different views about which candidates are eligible to win in Step 2.  This is a recipe for forks.

So replace the above with:

Step 1.  Calculate each candidate's normalised ASV (nASV) by dividing its ASV by the largest ASV of any of the last N block winners.  This will not affect the candidates' rankings in any way.

Step 2.  Iterate through the candidates in decreasing order of nASV.  For each candidate, if the account last won more than max(N,N/nASV), or if it has never won, it wins; exit.  Otherwise multiply the nASV by the number of blocks to the last win.  Use this figure in the tiebreaker described in step 3.

Step 3.  If no candidate won during step 2, then the winner is the candidate that has won the least number of times during the last N blocks.  If there is a tie, then use the figure calculated in step 2 as a tiebreaker.
Dazza
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 23, 2016, 11:28:49 PM
 #235

Is it ok to send from coinbase account?

That question had already been answered on the very same page you asked it.
cryptoboy.architect
Hero Member
*****
Offline Offline

Activity: 513
Merit: 500


View Profile
March 24, 2016, 03:34:28 AM
 #236

I want to do some distributed machine learning. Would be absolutely amazing if this could also allow for CUDA or OpenCL optimizations within the Python running.

I would actually pay for my calculations to run. But still waiting to see how far you guys go with this.
Sam123
Hero Member
*****
Offline Offline

Activity: 980
Merit: 502


View Profile
March 25, 2016, 12:14:02 AM
 #237

I just make a donation from blockchain.info wallet.
Why my public key does not match btc_tx from genesis block please
Thanks,
dulinxu
Sr. Member
****
Offline Offline

Activity: 363
Merit: 250


View Profile
March 26, 2016, 02:02:01 AM
 #238

why the ICO amount showed in main page doesn't match the balance of the address??? Scam?

TERRA - Bring profits to support community, starting from cross-border payment ❘|❘ ICO ❘|❘ DISCUSSION
BigBoom3599
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


View Profile
March 26, 2016, 05:18:55 AM
 #239

why the ICO amount showed in main page doesn't match the balance of the address??? Scam?

The ICO had a different address is the begining, the balance on the page is the combination of the two addresses
Limx Dev
Copper Member
Legendary
*
Offline Offline

Activity: 1680
Merit: 1298



View Profile
March 26, 2016, 11:40:15 AM
 #240

Hmm... How much coins will be create? Best Regards Christian
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [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 ... 346 »
  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!