Funny on the picture in OP is that there are only guys. No women at all. I guess some female ideas would be a good step forward.
I also was firstly searching for Yellen, but then noticed - other issue ... |
|
|
|
Staking and mining are both minting methods but staking is not mining.
So then the risk is in staking. Still, could that reduce your stake to 0? |
|
|
|
|
If I understand it right, new Casper design is based on betting and unlucky miners might end up in loosing money, not earning as usually expected. So without a proper risk management your wealth (coins) is really exposed?
And if so, who really wants to do that?
|
|
|
|
Always knew that the bitcoin community would reach a consensus, i love Game Theory.  Game of Thrones ?  |
|
|
|
Could be the last chance for Google to succeed over Apple / Samsung pay and others. BTW, does not Google have a banking licence? So they would be biggest BitcoinBank on earth if they would embrace it.  |
|
|
|
|
I fear that will be really possible only scaled down on an intranet like basis. Not really fully distributed-but is not that exactly banks & corps are looking for? Take a shared part DB instead....
|
|
|
|
I think bitcoin markets are too easily manipulated for this. All it takes is some random large holder to make some anti comments and we see bitcoin drop 10%.
I meant more from that point: If fiat has it's Black Swan than BTC goes to da moon.... |
|
|
|
Thanks  |
|
|
|
|
Only temporary, when China Gov. decides to do own coin and take over existing mining power by politcal act. Maybe in combination with a >50% attack and massive short selling...
After that decentralisation might be better and trust might come back by time.
|
|
|
|
The bitcoin price is now growing steady for mor than a week now.
The halving is coming and the price will not go bellow $400 hundred again.
So, if you have them, you better hold them tight!
... Consensus reached... |
|
|
|
Just wondering about that (maybe this was already discussed than pls ignore):
Would it be possible and make sense to correlate the recommended hashrate to the actual transaction count in the que, so that it will enable to create blocks faster in times of high volume and makes it impossible to mine empty blocks?
It is impossible to know how many transactions are in everyone else's queue. You can only know how many transactions are in your queue. If your queue doesn't exactly match every other queue in the world, then your difficulty won't match theirs and there will be no way for them to know if you chose a valid difficulty for your block. Yes I know that. But could be a proper solution not be to allow a miner to reach the new threashold ( lowerd by transaction count* somefactor) earlier than compared to now? Than every node can validate that and miners would pack block with more tx? Keeping mainly same 10min on day average... |
|
|
|
|
Funny I just had the same idea and posted that in the tech blog...
I'd also just think of a very slight Modifikation in the recommended hash threshold, just that much that miners ensure to really pack as much as possible transactions into a block (1 or 2 MB i dont care yet).
But finally stay to the average of 10min ( maybe 9.5 then) and there would appear no empty blocks any more.
I have not done the math but how much transactions were there over last week? I suppose they still can be included in that 10 min and 1MB frame yet , but than slghtly better...
|
|
|
|
|
Just wondering about that (maybe this was already discussed than pls ignore):
Would it be possible and make sense to correlate the recommended hashrate to the actual transaction count in the que, so that it will enable to create blocks faster in times of high volume and makes it impossible to mine empty blocks?
|
|
|
|
|
Finally, I try to post my thinking on future use cases for ETH and IBM/Hyperledger:
Those both will be seen in a race to replace the central Backoffice infra-structs for banks and other corps and will tend/stay central (= bank interconnecting). Nobody of those really want a fully decentralized solution that they cannot really control...
|
|
|
|
Ouffff.... Do they really know they have about 300Mio on stake and seems to me no clue on solving the crux at all? That's getting hotter than hot. |
|
|
|
I'm not sure if that helps (if anything does at all) at all but I read that part here with the ..interactively verifying the presence of data in a foreign blockchain ... "The Power of Binary Search In the next two sections, I will give two specific examples. One is about interactively verifying the presence of data in a foreign blockchain, the second is about verifying general (deterministic) computation...." in https://blog.ethereum.org/2016/02/17/smart-contracts-courts-not-smart-judges/ |
|
|
|
|
I'd say it is same issue with Casper:
Decentral:
You need a trustless clrearing system / notary in between - some say that 'could work' with some betting design....
Central: Easy but open to hackers.
Think of the actual process in trading as is:
- Client (has ccy1) & wants to change it to ccy2
- Client needs to deposit (maybe partial) ccy1 first at market maker's account (market maker that could offer ccy2 vs ccy1)
- Market maker activates client to trade since now there is a credit limit = reduced counter party risk to market maker
- Client hits market maker (pays a fee for that service incl settlemet cost)
- Market maker might send real time confirmation notice to client (last chance to cancel?)
- Settlement is initiated by market maker (or escrow service) - atomic
How can you put some code around all that in a decentral way ?
|
|
|
|
Pardon. Reading the header with SWAP and then parsing the story I finally understand you try to achieve just an "easy" crypto ccy SPOT trade (Even more correct a same day forward) by executing one of the "easiest" smart contract and already struggle with that? Why not trying some betting stuff? (Sorry, just caspering around a bit ) I really want to know and see such easy stuff working before more complex things should be developed, savely.... How about some 2factor like mechano? |
|
|
|
|
Show Posts
