 Show Posts
|
|
Pages: [1] 2 3 4 5 6 7 »
|
The rules for starting a new voting period can be reduced to asking a couple straightforward questions:
Did all the PoW miners upgrade to the latest dcrd release?
Did 75% or more of the stakeholders voting in the last stake version interval upgrade to the latest dcrwallet release?
If these 2 conditions are satisfied, the stake version is incremented and the next voting period begins. There is a third condition, but it is more technical and messy to explain, so I'll gloss over it.
If you have any further questions about the release, feel free to ask.
Thanks for the update! For those of us interested, can you explain the third condition? Or point to a thread/blog where it's already explained?  Sure thing, IncludeBeer. This may be more technical than some readers want, but it's necessary to explain why and how this 3rd condition works. Since Decred's hybrid PoW/PoS system scales the block reward received by a PoW miner based on the number of PoS miners whose votes are included in that block, i.e. a block authored by a PoW miner that includes 3 of the 5 votes only receives 3/5 of the usual subsidy for mining that block, we cannot apply the same kind of enforcement, rejection and activation logic as Bitcoin uses for the block version to the stake version. If votes are rejected based on their version, e.g. full nodes start rejecting anything but v3 votes, it unfairly penalizes the PoW miner for that block due to a PoS miner not upgrading. Not rejecting votes creates an enforcement problem: it is not possible to guarantee a monotonic march to activation by rejecting older versions. Without rejecting older vote versions, it is possible to have the following scenario occur: during one stake version interval (SVI), the 75% threshold is crossed by a new version, then during the next SVI, that same version falls short of the 75% threshold. The 3rd condition is * Instead of determining the stake version only based on the votes in that interval, we also check what version the last SVI was. If the previous SVI was some version, the current version must be that same version or greater. By preventing the stake version from decreasing, we avoid other complex failure modes that could occur when the stake version goes from 3 to 2 or similar. |
|
|
|
i don't wanted to build a link or something else.
i just wanted to say, that new coins and airdrops always gain some attention, some more, some less.
and the litecred point was just an example, how much attention is possible.
Oh no, it wasn't an accusation of linking to anything. The name seemed to resemble Decred, so it had to be said that there is no association - worried about users getting confused, if it's not made clear. It's appreciated that you brought it up. I was present last night during the airdrop of licred, and i swear on my parents is a BIG SCAM. Fake airdrop with fake users.The coin will go to the 2 chinese boy how did the scam BTW is not their first SCAM here from these people. Decred is another coin, with real people anD a project. You can't compare decred and litecred licred or wtf they call. Litecred is a Chinese SCAM build up in 3 days. Decred is a star in the sky. While I'm unwilling to condemn litecred as a scam, here are some things to consider: - Decred has been developed in private over an almost 2 year period (started in April 2014). - Since none of the Decred source code is public yet, any project based on Decred almost assuredly has no code of its own. Once the source code is public, this will obviously change. - There has been zero contact between the litecred project and Decred. My assessment of litecred is that it falls in the "too soon" bucket, so proceed with caution. |
|
|
|
I want to clarify: the time between blocks of 5 minutes, the average block size in the first year, 25-23 coins?, about 105K units a year? This is the right calculations, I assumed that in the first year will produce around 4.7 million coins. That is, the financing of the project will be transferred to 470 thousand coins in the first year? (10%). Just want to understand everything before starting. It's very much like a full line of numbers bitcoin. Okay, the calculation roughly correct? Just earlier I was thinking that the blocks in the first year will be about 9-10 coins.
If you have a look at our previous post about the subsidy system https://bitcointalk.org/index.php?topic=1290358.msg13412287#msg13412287you can see how this works out in detail. For clarity, I'm reproducing the figures here: - The per block subsidy starts at approximately 31.19 coins and decreases by a factor of 100/101 every 6,144 blocks, approximately 21.33 days assuming 5 minutes per block.
- The total number of coins by the end of year 1 is approximately 4.7M, with 1.68M coming from the premine and 3.02M coming from PoW, PoS and dev org subsidies.
- The dev org will get approximately 302K coins over the first year, most of which will be spent on an ongoing basis on development of the software.
|
|
|
|
To express that we're risking misleading people is itself misleading. PoS votes in the Decred lottery system can be used to vote for or against a new consensus rule, which allows stakeholders to vote on issues on-chain. Note that it was not claimed that this allows voting on all issues, but changes reflected in consensus code can be voted on. |
|
|
|
Coming here from the post on Slashdot. I like several features of this currency, and have a few questions.
Cold staking and decentralized stake pooling. Sounds great but how? After a stake ticket is purchased, there is no need for the funds used to purchase that ticket to be online. Example: You used 100 coins to buy a stake ticket, which requires a transaction be created, signed and broadcast to the network. After a maturity delay the ticket is eligible for selection in a lottery, and when the ticket is selected, it can be voted without having the original wallet used to purchase the ticket online. This is what is meant by "cold staking". The funds used to purchase tickets need not ever be "hot" either, it can be done using a cold wallet. Voting/polling is good. But why is the plan to split blocks 60% with miners and 40% with stakers? Why not make it an even split?
Your numbers are slightly off, the split is 60% PoW, 30% PoS, 10% dev subsidy. PoW has real and substantial hardware costs associated with it, so we felt it made more sense to have this subsidy higher than the PoS subsidy. The 30% PoS subsidy was chosen so that a semi-passive rate of return on holding coins was not absurdly high. Immutable tx ids, excellent.
Script enhancements and new OP codes, what will these be and for what purpose?
The stake transactions have new opcodes. These opcodes allow users to purchase tickets (SSTX), vote tickets when selected in the lottery (SSGEN), and revoke tickets (SSRTX). Self-funded development via block subsidy, 10%. I feel this is way too much of a cut. Please consider reducing it by a lot or withdrawing these plans altogether considering you're also taking 4% of the 21 million total premine.
While I understand that you may feel 10% is too high a rate, as someone who has funded a lot of development work over the past 5 years, I disagree with your assessment. At a 10% subsidy rate, the dev organization will accumulate approximately 302,000 decred during its first year. If we assume the value of 1 decred averages to USD 1.00 over the first year, this means we'll have USD 302K to spend on development work. This is a small amount of funding and can pay for 3-4 full time developers for 1 year, so if we went below 10% dev subsidy it would mean the project cannot fund itself unless its exchange rate is well over USD 1.00 per decred. The 4% of the premine was paid for in USD, BTC and labor by Company 0 and its developers. Unlike other projects, we did not push the risk of failure onto the community by asking them to fund the work. We have made an effort to lead with our deliverables in a niche where there is lots of vaporware and questionable offerings. As our btcsuite work shows, this work has been going on for years, even without any funding except from me. "Simple GPU miner." I'd look at getting mining Decred supported in a mature mining program like bfgminer or sgminer instead of rolling something new. These mature mining programs support AMD Overdrive features already, so that means overclocking, temperature reading, etc built-in. Ethminer, the miner program for Ethereum, was less useful without these features.
We will consider these suggestions, but keep in mind that too much scope creep means our planned deliverables will slip. There is a lot of infrastructure that goes along with a cryptocurrency, and we're trying to get it all out in a timely fashion without ruining our timeline. |
|
|
|
Any plans to merge mine with BLC and the other coins in the Blake ecosystem?
Is this 8 round blake?
No plans to merge mine as of yet. Decred is 14-round. History about SHA3 and Blake-256: 14 rounds was only pushed in final stage sha3 comp as the fear was it was too fast and wanted to win votes from judges to become sha3 but as we know they ended up choosing the next secure hash based on sponge function so others basically got ignored! Original Blake-256/Blake-32 was 10 rounds and was tested as such so should have 2 256 security you will see with the successor of Blake-256 > Blake2s they reduce the rounds back to 10 anything more is overkill and the whole blake hash design is slightly overkill to start with anyways!  no need to waste compute as it is always going to be there on every platform and may force in some places to spend time/effort doing optimizations when you could start more optimized by factoring the reasons why your hash algo is what it is, tune-able number of rounds is very powerful feature not to be ignored before you start things like root hashes/checksum so you can look at it like this: 1. ignore and carry on not looking into why you can have 10/8 rounds (huge headache when you find you cant change after) 2. use the 10 round spec and have minimum 2 256 security and hash is in big endian so will fit with BTC code 3. use the 8 rounds and have minimum 2 200 security ( tested so known minimum security with best attack no guess work!) 4. use blake2s or blake2sp and have minimum 2 256 security, performance is slightly worse for blake2s vs 8rnd blake-256, blake2 is also little endian so if you wanted to go full on you could remove the big endian conversion and just do everything in little endian as most software does why did I tweak blake-256 to 8 rounds simple for the wallet you would want a design goal of at least 2 128 you could do with 2 160 and I thought 2 192 would give enough margin that other flaws in wallet would be of more worry! this seems to have been proven correct so far and the margin on 8 rounds was better than my original estimation @2 200  before anyone starts saying oh but 8 round is only available in c/c++ this is just not true if you care to see my github you will find versions for php/python/java/c/c#/ go/opencl and specifically these may be of interest to the Decred dev/devs 8 round blake-256 in golang https://github.com/BlueDragon747/blake256 8 round blake-256 checksum tool in golang https://github.com/BlueDragon747/blakesumshame about auxpow and merge mining but might be ott in go at this time so much needs to match for it to be valid and with your described pos/pow hybrid it would make far more work for dev/devs, hope that everyone can take some notes about blake-256 it is a good algo but the 14 version is fubar was made only to please judges during final of sha3 which it did not win nor was most of the testing done on 14 rounds! efficiency is important it helps all nodes even if not mining for as long as you use the algorithm, quicker and higher throughput will lead to quicker propagation time though the nodes on the network if you can save 20-40% off the bat from just understanding the why is blake-256 x rounds and do we really need more security margin than we can use at cost of wasting compute and taking more time? Hi there, BlueDragon747. While you make some compelling arguments for using 8 or 10 round Blake256 instead of 14 rounds, we are not interested in having Decred merge mined with other Blake256 coins. This choice was intentional and 14 rounds was chosen to be be conservative about security. Bitcoin uses SHA256(SHA256(data)) to provide potentially more effective security. Boomerang distinguishers attacks are available for 8-round BLAKE256 already. It's unknown what attacks might arise in the future. Therefore, as recommended in the 2010 BLAKE paper from the authors, 14 rounds are used. |
|
|
|
Question is:
-They have 4% of coins pre-mined plus 10% of every block minted for ever.
-4% of coin premined,based on 21 millions supply....which is the amount for first 5 month or first year?
I mean, if for first year the coin minted will be 10 for example, they have not 4% but 40%.
Using the information posted earlier in this thread for the total coin supply as of end of year 1, 4704267, which is roughly 4.7M, we have the following: - 4% premine for developers, 840K coins, constitutes 17.8% of the available supply at end of year 1 - 10% dev org subsidy is [4.7M (total issued eoy 1) - 1.68M (8% premine)] x 10% = 302K coins, which is 6.4% of the total available coins at end of year 1. Note that the subsidy only starts after the premine, thus the subtracting of the premine when calculating this figure. This gives a sum of 17.8% (dev premine) + 6.4% (dev org subsidy) = 24.2%. So,how long will be the pow phase? To determine the effective % of pre-mine.
I am not sure exactly what you are asking. Can you be a bit clearer about what you're looking for here? |
|
|
|
|
i'm not normally one to completely ignore a book based on its "cover", but the very first sentence of this paper gets it so wrong.
"On February 2014, $650.000.000 worth of Bitcoins disappeared."
you mean BTC 650,000 and it didn't all instantaneously disappear. this paper is _awful_. if the authors cannot even get the most basic facts straight about what happened, any conclusions contained inside must be worthless.
|
|
|
|
|
since the blockchain is essentially a WORM filesystem, this fragmentation issue will obviously become a bigger issue in the future.
it does make me smile to think that at some point people will see messages like "Your wallet is being slow, would you like to defragment your wallet?".
|
|
|
|
|
as someone who has paid to have a filesystem built for a bulk-storage service (cyphertite online backup), i can tell you that having a FS just for cryptocurrencies is a bad idea. creating and maintaining an FS is a ton of work without a whole lot of gain in this case.
existing FSes work just fine when storing and manipulating a blockchain. the blockchain is already its own sort of userland filesystem.
|
|
|
|
Cause if you only get back a generic success message, that doesn't seem that secure because attacker with access to your machine could modify your code and bypass the key.
Correct. YubiKey does authentication, not encryption, which is what you really need to protect your wallet. The way YubiKey (and similar 2FA systems) work is, the server runs software that generates one-time codes from a seed, and the YubiKey also generates one-time codes from the same seed, and sends it to the server. If the codes match, the server allows you to log in. If the don't match, your login is refused. This works exactly the same as if you had logged in with a password, except that the one-time code changes every time you log in, so old codes cannot be re-used, thwarting keyloggers. The important thing to note here is that both the seed and the software to generate one-time codes are stored on the server, which is obviously not secure at all if an attacker is able to access files on the server (and if they can't access your files, your wallet is safe anyway - hence the usefulness of cold storage). To protect files that an attacker could potentially access, you need encryption, and YubiKey cannot help you with that. grue and foxpup make good points regarding how yubikeys work. in order to use the yubikey in the manner you prescribe, you would need to have a configuration like - have wallet stored on a separate system
- that separate system uses yubikey as a first authentication factor to prevent users without yubikey from getting in
- once a user auths using yubikey, they can enter their passphrase and remotely unlock the wallet
- transactions would need to be composed on this separate machine
this cannot be done properly on a single host for the reasons mentioned in the earlier posts. you are pretty much required to have a 2nd machine which houses the yubikey private key. we support yubikey at coinvoice.com using our (golang) yubikey library, https://github.com/conformal/yubikey . |
|
|
|
It's like removing seat belts from cars and declaring yourself a genius for making us slightly more comfortable. lol! to your point about it being monolithic: after having my devs collectively spend several man years rebuilding bitcoin from scratch (starting in late feb 2013), even having bitcoind as a reference, it's still not finished. there are myriad new features proposed in ETH that all have to be tested before they are released. i suspect that even with a pile of VC money, say >USD 10M, you would be hard-pressed to get all these features coded, tested and added. while bitcoin is itself relatively complex code-wise, its fundamental insight is rather simple - "use proof of work as both (1) a distributed timestamp and (2) a minting/reward mechanism". if you take 10 such insights, roll them into one, then try to hack out the code, you will soon be in over your head. |
|
|
|
What is going on  Who is controls all those coins? ?? you have just asked the 64,000 bitcoin question. i'll be here all week. making my old math instructors proud. |
|
|
|
After browsing the threads about Mt.Gox and the malleability issue here are a couple of questions.
Q1. Is there any way to ascertain that the Mt.Gox bankrupcy was indeed induced by transaction malleability?
I understand that the malleability issue is real. Indeed it has been real and known for more than two years. I still fail to understand how it could be realistically harnessed to heist hundreds of thousands of bitcoins.
i am not normally one to speak positively of regulation, but this is one of several reasons that money transmitters and MSBs require licenses in the US: too many unscrupulous people have started up such businesses, then there is a "theft" of funds and all the customers are missing money. there are numerous ways a tx malleability exploit should have been stopped at mtgox. incompetence is a decent defense in the BTC markets when you consider how little most people know about BTC. Q2. Are we sure that the whole thing wasn't orchestrated with the complicity of Mt.Gox management? Can we ever be sure?
Q3. Consider a Bitcoin maketplace model where major exchanges mysteriously go bankrupt and handwave their alleged losses to some technical issue, previously regarded as minor. Is such a model viable in the long tem?
if BTC 600K or more has been "stolen", which has not been reliably confirmed by any means, i would bet a large amount of money on it being an inside job. you don't just end up having your cold wallets emptied and not know something is up, even if you're as incompetent as MK. |
|
|
|
The government created Bitcoin. They want you using it... They just need you to believe it's controlled by the people so you accept it. Similar to how the Federal Reserve was marketed as the people's bank even though it was the exact opposite... Think about that... The more you know...
can you say backup plan for an ailing USD and an unsustainably large mountain of debt? good thing we can trust all these seemingly arbitrary constants in secp256k1. |
|
|
|
First rule of software engineering: more man months!=better software.
i couldn't agree more. if there were more developers, then the core devs couldn't bask in the limelight of their celebrity without really hacking. i said this and more in a recent blog post i penned https://blog.conformal.com/redecentralization-robust-developer-network/it may also be worth noting that the proposed fixes to bitcoind's wallet code are insufficient to fix the real problem per https://blog.conformal.com/transaction-malleability-no-shortcuts-allowed/upshot with tx malleability is that _all_ wallets, not just those at exchanges and wallet services, need to properly make the identificatoin A = A' (mod mutations). half-ass solutions will not fix this problem. |
|
|
|
One of the non-obvious reasons Bitcoin works is transaction fees are based on the size (in bytes) of the transaction. And since there are no loops executing a transaction, CPU usage is bound by transaction size.
If CPU usage to verify a transaction is NOT related to the transaction size, then you open yourself up to denial-of-service attacks. Like:
...
this is precisely why a turing complete scripting language is a bad idea in the context of cryptocurrencies: it is highly non-trivial to put bounds in place to prevent or mitigate exploits. |
|
|
|
Satoshi probably left it out because making a Turing-complete transaction scripting language safe is more difficult. You have to prevent scripts from running endlessly while also allowing them to run long enough to be useful, and you can't let them access too much external data or they might become invalid after being valid for a while and really screw things up. A Turing-complete transaction scripting language would be really cool, though. If done well, it could be used to add all sorts of new features (even new crypto) in a backward-compatible way.
I don't know much at all about Ethereum, but it looks like their scripts can access info about blocks, which seems dangerous. If this was possible in Bitcoin, then a reorg could cause many fully-confirmed transactions to all of a sudden become invalid by accident, without even any attacker. This is very undesirable. Maybe Ethereum does something to fix this -- I don't know.
i definitely agree that the reason this kind of functionality was not added to bitcoin was that it makes shooting oneself in the foot far easier. a related question that could be asked is "why are many of the script opcodes disabled in bitcoind?" and it has the same answer - the functionality that comes with more scripts and more opcodes is risky and creates many more corner cases to code around. it's obviously possible to do amazing things with more powerful scripting options but i suspect it would not be sufficiently stable and secure as currently proposed in ethereum. bitcoin's success is strongly related to the fact that it is a digital currency system with a few key innovations that added a ton of value, the main innovation being the distributed public ledger. ethereum proposes sweeping changes that are not minor variations and have unknown dynamics in a real-world use case. i do quite like the ideas proposed in the ethereum proposal. |
|
|
|
i'm glad you enjoyed the blog post. we're 20-25 rpc calls away from being a drop-in replacement for bitcoind :-) |
|
|
|
|
