|
byteball is very interesting.
|
|
|
|
Dev Update for week of June 12th:
Changes made through this week to the core wallet:
Bugs fixed:
* [Consensus/PoS] Made sure that a PoS block's coinstake tx was only check if the block contained at least 2 transactions
* [Consensus/EVM] Made EVM gas behavior to work as expected regardless of the Qtum gas price
Work completed:
* [GUI/Qt] Changed blockchain size warning from 122Gb to 1Gb
* [Misc/EVM] Cleaned up the EVM's use of cout and stdout so that all log messages are put in a log file, rather than logged to the console
* [Consensus] Added consensus rule that a block may have a timestamp more than 15 seconds into the network time
* [Consensus/PoS] Changed some PoS support functions to use safer and more effecient data from the block header, rather than relying on block body data
* [Consensus/EVM] Added a consensus rule that a single contract execution can create no more than 1000 vouts.
* [Staker/PoS] Completely reworked the PoS staker so that it looks forward in time for valid stakes, only processes transactions after a stake is found, prepares a block up to 96 seconds before publishing it, and made it aware of time limits for PoS as well as fully aware of the cost of including contract transactions in blocks
* [Misc] Some refactoring and code clean up that does not affect logic
* [Misc] Renamed OP_TXHASH to OP_SPEND, as OP_TXHASH is no longer a represenative name for it's purpose
In-progress work and soon to be fixed bugs:
* [RPC/EVM] The default gas limits in the RPC interface are too small to do anything significant with
* [Staker/PoS] Staking (or PoW mining) on OSX does not properly construct blocks that contain contracts, resulting in rejected blocks. This does not affect Linux
more information on the Consensus algorithm? what's the biggest difference with normal proof of stake? |
|
|
|
One safe way to forge on a remote node would be to "lease" your XEL from a main account to a throwaway account. This account can then forge on a remote node ... it's not dangerous if the private key gets stolen, because your original account (which owns the lent XEL) is not compromised then.
have you got a XEL account?  i want you can save more polar bear i am saving some young elephant in kenya. thank you for make this happen for the community. |
|
|
|
|
looking forward the testnet release this month.
|
|
|
|
|
Byteball will grow as big as IOTA for sure.
|
|
|
|
when can we expect the next round ico? |
|
|
|
|
very few people really understand what Qtum is doing now.
it always take time for people to understand new approach.
Ethereum is based on account model and also still in POW phase.
Qtum is based on UTXO model and will start from POS directly.
|
|
|
|
Also how about we change Gbyte to Byte..
Gbyte are too expensive?
let's change to Byte ?
Gbyte to Mbyte should be ok. 1Gbyte will be too big in the future. |
|
|
|
just come back and say hi looking forward next week. let's expect some big will happen. |
|
|
|
|
skycoin should sold more coins to potential users.
|
|
|
|
|
people always have prejudice on some project, even today a lot of old people think bitcoin is a scam.
|
|
|
|
Hello, what's the difference between Elastic and SONM? Some people have told me that the differences are minimal and that practically Elastic is made up of a smaller team than SONM, is this true?
Just guessing here (guess might contain incorrect information)... the one exists in working prototype form the other doesn't? Also, because there is a constant team talk going on here: what would you prefer, a lady staying with you for an hourly payment, or one that really loves you even if you have nothing  I think we can be glad to have true enthusiasts and brilliant out of the box thinkers gathered around, and nor a highly paid PR team in pinstripe suits lol. most of people forget the real spirit of crypto world. one satoshi released the bitcoin network. |
|
|
|
|
good price for ico people, looking forward testnet.
and seems Qtum development is fast, usually these kind of project take 1-2 years.
|
|
|
|
The great thing about an open source project like this is that any developer can take it any direction they'd like as long as the community adopts it.
I'm open to ideas other than the SNs, just keep in mind there are a lot of constraints that need to be met. So if people have alternate solutions for how a distributed network can fully validate the POW / Bounty submissions without creating a bottleneck, please provide your ideas.
I've also pitched a couple of alternate ideas to EK, but really he's pretty busy right now so this would probably be the best opportunity to revisit this topic before he has time to work on the Core Server again.
One last thing...regardless of what we do, maybe it would be best to change the name of it...even in the current design it's not a SuperNode the way other blockchains think of it. It's simply a Core Server node that has the ability to run the ElasticPL engine to validate POW / Bounty submissions.
The very short version: A job requester would annotate an SSA form program (in a specific machine model resulting in a particularly structured (binary) flow graph) with a simple liveness/reachability model so that miners could (quickly, and without running any example case inputs) verify the necessary complexity bound of the job's individual work task before selecting. PoW solutions would operate a little differently (still using "per user" generated inputs incl nonce data, but basically hashing/checking "instruction by instruction" instead of at the end of each input run) so that PoW solution rates become uniform across jobs, being able to be found at any point mid-execution. (PoW prize pool would probably also need to work a little differently, with any amount of proof-of-work certificates able to be submitted before a bounty is found, and the PoW pool being divided proportionally after.) Bounty solutions would include an annotation of the original model with information about the eventual I/O relation, such that verifying the output submission can be reduced to an instance of a satisfiability problem. Nodes (all of them) would validate solutions against this model. (They would still need to "re-run the program" by a symbolic interpretation, but could know that they are doing so in an optimally efficient way - effectively skipping any "unrelated loops" encountered.) Jobs would always end after one bounty is found. I'm summarizing a lot, but that is the basic idea. great discussion and inputs. |
|
|
|
OK, I am in on this. BTC confirm taking forever, tho.  BTC mempool collapsed this weekend, more than 140000 unconfirmed transactions. that means byteball have some chance. byte have some big chance. |
|
|
|
|
nice to see some good move on Qtum project.
more transparency.
|
|
|
|
|
Elastic will make the history like NXT.
Congratulations to all the community people and donation people.
|
|
|
|
... Even if @EK finish his work with litewallet today I need some time (about week or two) to test everything.
He finished today. The package was sent to unvoid, I have tested for a few hours today but I would still suggest to: - Test if everything syncs fine from the P2P perspective in a real world environment - Check the genesis block for correctness - Just play around with it for a while to make sure everything works as expected What a weekend. Totally turned basement-nerd-style and drank 10 coffee per day while others were surfing at the beach. i have nothing to say, i want to buy you a beer and a new surfboard and save another polar bear! just sent another 0.5BTC to show my respect. https://blockchain.info/tx-index/8627759cba985b2d9f21eeb011f1f153ed08ea4bbea271e7db321b1c02115a60i am not rich like trump.. but i am grateful on everything.  i hope you are happy today! do not drink too much. |
|
|
|
|
byteball should worth 100M$ in 2-3 months.
|
|
|
|
|
did the dev set an accurate time for testnet release?
|
|
|
|
|
Show Posts
