|
And I like going with less amount of total coins versus bitcoin too. There's the psychological effect of something being worth more than a dollar (like bitcoin has seen), or an exchange rate of 0.01 versus 0.001 even through there's 10x as many coins.
|
|
|
|
|
Idea: Initial coin release is done through the equivalent of set difficulty mining - generate processing intensive hashes, if the first X bits are all zeroes AND that coin isn't already made then you just created a coin.
Example:
de345cf32de1ab9: no coin
96f7410e7925cc5: no coin
000000ac9531cee: coin
0000001ab98f9dac: coin
[...]
000000ac9531cee: no coin (already made)
Can just use TX hash for that. If TX hash starts with X 0 bits, AND it has no inputs, AND it has only one 1 coin output, AND first x bits of the TX hash is unique, then it passes the successful create coin check.
Those "create coin" TXes would be broadcasted and would be confirmed after being included in the blockchain. The blockchain is purely generated by Proof of Stake. Proof of Stake mining just earns transaction fees (which are required to send transactions, so the create coin TXes would have to include a fee that the PoS finds acceptable)
Initially the network would be seeded via a genesis block that gives the seed PoS node 0.5% of the total monetary supply.
Advantages:
* No mining pools needed! Each PoS block is expected to hold multiple create coin TXes with PoW.
* Rate of new blocks not tied to hashpower vs difficulty.
* Can't be 51% attacked unless you own more than 51% of all coins in existence
* No "mass block time" at the start of the coin's life, difficulty goes from 1 to 4 to 16 to 64 because that's the max jump..
* Energy efficient after all the monetary supply would have being created
* Scales with more hashpowers which can be somewhat linked to new users
* Limit on max amount of coins.
|
|
|
|
|
Re: Automated checkpoints would make it centralized. We definitely will have checkpoints with each update through.
Also, what are your thoughts on "quicker blocks versus less storage for blockchain"? I don't think we need to continue the "litecoin is silver to gold" - I like a monetary base of around 20 million or even less.
|
|
|
|
BoB, the fake betting site, basically did exactly what MNW did, for which he got a scammer tag.
If one side of the bet had come in, in favor of BFL, then they'd have paid out.
When the other side came in, clearly and unambiguously, they said ha ha, just kidding. That's a scam.
I'm not going to give Matthew N. Wright a scammer tag. By betting in his game, you agree that he will decide the outcome. |
|
|
|
Bug? I already wagered some bitcoins but I still get this message:
Maximum amount that you can withdraw is 1.0140. You have a pending bonus of 1.0000. In order to get this reward, you need to wager 10.0000 more.
Went down a bit, but it doesn't go down anymore when I bet.
The rollover calculation is not instant. It is recalculated once the game session is complete. This happens approx. 10-15 minutes after the game is complete. If you still do not see your rollover increase, please let us know your username. The best way is to email support. Thank you for playing at BitcoPlay.com and good luck. Thanks, probably a good idea to note it on the 100% bonus page |
|
|
|
|
Thanks for the nice writeup! Here's my thoughts:
The biggest problem with very fast blocks is that the block headers will need to be stored. If a client wants to rely on the full blockchain, then they'll need to download the blockchain which will become unfeasible on mobile phones and soon slow internet speeds. There's thin clients, but that still downloads headers (and that'll be unfeasible if we have a block every 15s).
Faster blocks also makes having connections to the most peers more important, it actually benefits mining pools to some extent. In addition, faster blocks does not make it faster for transactions to be more secure, it just reduces the variance of it. To get 6 confirmation "bitcoin-level" security you'd need 24 confirmations for litecoin for example. So we shouldn't overdo the block times.
Deflation is a tricky issue - why would people want to acquire an inflating coin, especially when the largest coin is deflationary? I think we will lose a large part of potential users.
I agree that we should change the block reward change schedule to make it release faster. However, perhaps it shouldn't have but instead is reduced by 25% every X months in block time? Would be less of a sudden jump.
The coin denominations - it is already that way really. In the code / transactions, 1 bitcoin is expressed as 1e+8 units. You can call satoshis the "bitcoin", and a millibit is just [blah] satoshis.. Either way this isn't about the core part of bitcoin but how the UI presents it.
If we want faster blocks, we really need to reduce the size of blocks and transactions in them. Like I mentioned before, my suggestions are:
1. Less unit divisibility (smaller ints stored in each transaction)
2. Reduced prevBlockHash and merkleRootHash for each block header
Maybe also a smaller address stored (160 bits instead of 200) - checksum would take a large hit to still provide enough address space.
|
|
|
|
|
How can one enable to light / client mode in bitcoind referenced in issue #7?
|
|
|
|
Good luck!  |
|
|
|
|
Very neat! Through, I still don't understand why people like mobile versions through. I prefer full versions of site over condensed mobile versions having tons of whitespace (for a small screen) and lack of functionality (which I understand is because you're scrapping the content)
|
|
|
|
This is a poll for Community Cryptocurrency Foundation's new coin. Regarding the mining aspect, do you want a coin that is CPU & GPU & ASIC friendly (same hashing algorithm as Bitcoin, ?), CPU & GPU friendly (scrypt, ?), or just CPU friendly (GPU hostile algorithm, tweaked parameters, or as dreamwatcher suggested, increased network hashrate would result in increased parameters, ?). I'm aware that ASICs can be made by scrypt, thanks, but it is much harder and existing ASICs will not be able to mine there. |
|
|
|
|
BTC and TRC addresses are the same.
|
|
|
|
|
Doesn't it become harder over time to find another prime number? Thus, the 'difficulty' would always increase, unless you allow people to generate the same prime number which wouldn't work.
I think the idea to tweak parameters / mining as the difficulty increases is a novel idea, however my personal opinion is that it's overengineering it. Why not find a set of parameters for scrypt that makes GPUs useless for the next 10 years or so, and by then there wouldn't be a coinbase.
We can't do as the network difficulty doubles, more iterations of SHA256, because then you'd just get ASIC or FPGAs that repeats SHA256 x many times depending on the network difficulty.
|
|
|
|
|
The deposit bonus is +EV if you play jacks or better at least. However, the site does not calculate the wagers correctly.
|
|
|
|
|
Show Posts
