I'm surprised the plot on coinpulse is merely linear for the past month. I'd expect exponential adoption.
At this rate it would take an unreasonable long time to catch up with Visa, but the curve is distorted due to the nov popularity spike and will look better in a few months. |
|
|
|
|
Count me in!
The old Nxt won't be able to compete with a zero cost buy in fork.
|
|
|
|
|
Normally the Coin Control window waits for user input and doesn't update itself
when a new block is accepted. However it does update the number of confirmations when "List mode"/"Tree mode" is toggled
and the selections and sorting is preserved when toggled back (which is pretty awesome).
Is there any trouble to expect if CoinControlDialog::updateView()
would run every time nBestHeight goes up?
|
|
|
|
Slothcoin
Block Time: 30 Seconds
shouldn't it be 30 minutes?  |
|
|
|
But you will need to have your belongings in cryptocurrency so that no one gets hold on your belongings while you are dead.
That means bitcoin price could reach millions in a few years time if cryonics and/or chemical brain preservation becomes really popular.
And cryonics could finally become popular because of bitcoin and the ability to preserve your belongings. |
|
|
|
The angle I like on this is not a PoB system exactly, but a PoB method of transfer to a new crypto-currency. It allows for gradual and voluntary transition to a system with incompatible rules. I think if a better system than bitcoin was devised a PoB bridge could save it years of bootstrapping.
It allows for voluntary transition to a new system, but isn't it a waste of BTC? I.e. if you have 2 new systems with incompatible rules, one requires PoB and the other just "Proof of Ownership", otherwise they are identical, I don't see the reason why the PoB version would have higher market value, except "people made sacrifices for it, therefore it must be valuable". |
|
|
|
|
1 bitbit = 0.0001 BTC <-should be easy enough to remember
1 nakamoto = 0.000001 BTC
|
|
|
|
Will it be similar to Chronokings, but played on hexes? |
|
|
|
|
I would like to test this one...
|
|
|
|
A few people are engraving on stainless steel:
Hopefully this is just the canary wallet. The real saving wallet could have a slightly different private key. |
|
|
|
Never. What you need is another client
No kidding... Run two patched clients and have an exchange. Traders would send one transaction transmitting size, limit price and time in force of an order (e.g. 1.00027950 LTC for "want to buy 0.02795 BTC for 1 LTC, fill or kill") If matched or partially matched or expired, exchange send the coins back. Simple and stupid. No accounts, just a pair of addresses for the exchange and for each trader. Technically this is not very difficult. What we need is a common protocol, so that the patched clients, made by different people for different coins, can communicate via the blockchains. Still no cash, just crypto. |
|
|
|
having to sign up with an exchange which deals with XRP, converting XRP into BTC and incurring a fee
You could use the dividendrippler-LTC <-> XRP order book in Ripple. It wouldn't incur a fee (at least not for dr-LTC issue). |
|
|
|
In order to exchange coins, both party send their coins to the software and once the software verifies both party completed their part, the software will exchange the coins else it will resend the coins to the original sender.
Ripple+Dividendrippler are a "working example" of this, but you still have to trust two counterparties (one for a prolonged time), pay 3 fees, and there is not much liquidity even for BTC<->LTC. If the automated crypto currency exchange has to require trust (once we admit this it becomes technically simple) then the "software" should be an extension of the qt-client, so that everyone can set up an exchange and compete with other nodes (for trust and fees). |
|
|
|
Could this work?
Definitely, if your offline Bitcoin-QT knows about the outputs/coins in question at all (i.e. they need to be older than the offline blockchain is outdated) No need for raw transaction. Send coins as usual, burn wallet.dat to CD and copy it to an on-line Bitcoin-QT installation. Bitcoin-QT will rescan and then broadcast the transaction, not immediately but within an hour. |
|
|
|
|
The 'trustless' requirement for a cryptocoin<->cryptocoin exchange seems to be the show stopper
because it would probably require a hardfork in one of the coins.
What if the exchange does require trust but
-makes it easy to split orders into reasonably small parts
-is really just an user friendly piece of software so everyone can set up an exchange (making it p2p)
-records all trades in the blockchains so the exchanges could earn trust over time
This would still be an improvement over the current state of things.
|
|
|
|
a bot that would listen to the bitcoin network for a list of specific transactions associated with specific bitcoin addresses
Patch the Qt-client. Take a look at the console commands (getrawtransaction etc), everything you need is already there. |
|
|
|
Sure MTC <-> BTC... But the biggest hurdle remains BTC <--> $ And even if there were a Bitcoin-MTC and a Litecoin-MTC-clone you still couldn't exchange Btc vs Ltc with them because they would be totally separated. |
|
|
|
Is it possible to reduce ping time and timeout? Like this: https://github.com/sipa/bitcoin/commit/f9eeb06c10d826a56389b8473ec48549d4d57787but just changing the numbers to 2 and 5 minutes is fine, i.e. // Keep-alive ping
// if (pto->nLastSend && GetTime() - pto->nLastSend > 30 * 60 && pto->vSend.empty())
if (pto->nLastSend && GetTime() - pto->nLastSend > 2 * 60 && pto->vSend.empty())
pto->PushMessage("ping"); and // else if (GetTime() - pnode->nLastSend > 90*60 && GetTime() - pnode->nLastSendEmpty > 90*60)
else if (GetTime() - pnode->nLastSend > 5*60 && GetTime() - pnode->nLastSendEmpty > 5*60)
{
printf("socket not sending\n");
pnode->fDisconnect = true;
}
// else if (GetTime() - pnode->nLastRecv > 90*60)
else if (GetTime() - pnode->nLastRecv > 5*60)
{
printf("socket inactivity timeout\n");
pnode->fDisconnect = true;
} Additional traffic is only a few bytes every 2 minutes and it really does help everyone with crappy internet connection to stay synced to the latest block and game turn, as the connections tend to "stall" otherwise after some time. (connection showing up as 'established' when it's actually dead) |
|
|
|
As for millions of each colour (crammed world), I "think" natural selection should balance things out... but.. one thing we were thinking about is "self destruct" - each player can destroy himself and all players surrounding him, with a 25% chance of killing friendlies. This should add a bit more strategy
With a chance of killing friendlies it's very easy for bot players to camp the player spawn area and kill everyone who returns. If it looks like people are going to "play/mine" huntercoin, eventually we will have point and click for attacking too.. and if you select to attack someone who is on a square with many people, it will (maybe) popup something so you can select which one to attack
Auto-attack seems trivial to implement and is probably essential. You could level the playing field and give it to everyone right from the start. Is an incremental (and eternal) progress from Huntercoin to Chronokings possible? (test new feature on testnet while main network has a hard coded you-must-upgrade-now block height, release new version, rinse, repeat) |
|
|
|
|
With current rules (no upkeep on players and no limits on how many players can be on the same square,
and can attack from the same square) the map will become rather crammed.
Like 10*10 phalanxes with thousands of players moving slowly (to avoid tx fees) into battle for the next harvesting ground.
Perhaps there should be a rule "if a player A moves to a position already occupied by another player B
of the same color, then player A cannot attack until A has moved again".
|
|
|
|
|
Show Posts
