OpenSSL has been revealed to have a huge gaping hole.

http://www.bbc.com/news/technology-26935905

Those who have been securing communications using https (which is essentially all of us) should change all passwords they have used with those systems. 

Those who have used the same password in https that they have used to encrypt their wallets - yeah, you can figure that out, right?  An attacker may have the old password.  You should be using a different one.

I may start believing there's a problem if the 180 day moving average starts to decline.  On the other hand, the new version is out and addresses some trust issues with payment-protocol stuff.

I don't believe it's the right answer for the trust issues, but I'm waiting for the market to show what investors believe about it.  So far, they haven't heard. 

The problem that makes the time warp possible at all is that difficulty is being measured wrong. 

Having a lower difficulty threshold and more blocks, generated by a small fraction of the main chain's hashing power, should NEVER result in the difficulty calculation thinking that you have more total work than the main chain.

Consider two forks, one with a difficulty of, say 20 and one with a difficulty of, say, 11.  If there is actually more work on the chain with 11 difficulty, it will have more blocks that meet the 20 difficulty than the other chain has total blocks.  It shouldn't be getting any work credit at all for blocks that don't meet the hardest branch's difficulty.

That, IMO, is one of the problems that this is needed to address.  Making people aware of dev discussion *should* instill some expectations about dev actually happening.  At least, I'd sort of hope so.

But if we're not talking about any single coin?

Seriously, if someone wants to talk about alternative schemes for how to use proof-of-stake to secure a blockchain, there isn't a particular coin which that's about.  There isn't a particular coin's forum that it ought to go on.  And it isn't a failing of any particular coin's community that such a thing doesn't exist.

If the objective here is to host development discussion for absolutely nothing except bitcoin, I guess I can respect that.  But I would think it's a real shame to maintain a situation where there's no central development board that's common to cryptocurrency in general and a shame to support the fragmentation of the development community such that developers aren't likely to have heard about theory and discussion created in other cryptocurrency contexts. 

The problem with that is that there is only a single altcoin that any such forum is devoted to.  The need I had hoped for this forum to address is that of a forum for discussing the development of cryptocurrencies in general.

If someone owned coins that had a higher value than they were actually worth, because of misrepresentations or in spite of flaws in the implementation, and the coins have become less valuable due to a correction precipitated by the exposure of this misrepresentation or flaw, that person joins the ranks of the millions of people who owned houses whose value was artificially inflated due to misrepresentations during the mortgage meltdown.  When the misrepresentations were exposed, the market corrected and the houses became less valuable.  Sucks to be them, but they're not getting that money back.

To blame BCX here here is the equivalent of blaming the people who exposed the fraud for the lost value of the homes.  It isn't their fault the mortgages were fraudulent.  And it isn't BCX's fault that somebody was misrepresenting a blockchain they hadn't secured as trustworthy.  Sucks to be the bagholder, but you were the victim of fraud, not vandalism, and if anybody deserves to go to jail, it's the people who made the fraudulent claims in the first place. 

Heck, if you consider anyone who destroys the value of coins, through an otherwise legal action, to be a criminal, you might as well try to prosecute the IRS for declaring that cryptocurrencies are property and subject to capital gains taxes. I predict you wouldn't get very far with that either.

Most forms of "development" discussion are not in fact welcome in subforums of the "bitcoin" section because outside of a very narrow range, such discussion is discussion of something which is not *EVER* going to become part of Bitcoin itself.

This is not a good reason to avoid discussing it at all - but it is nearly impossible to pick any useful dev discussion out of the altcoin forums because effectively all threads in those forums are devoted to particular altchains, and these threads have a rate of new posts that rapidly drives all discussion about development off the leading pages. 

Therefore I believe that a "technical and development" subforum is needed under "altcoins."

Honestly I believe that the proof-of-work is better measured without regard to the difficulty level.

The way difficulty works, you might need some particular number of  leading zeros to make a block.  If the number is thirty, approximately one in a million hashes actually are capable of making a block.  But regardless of what you need to make a block, every hash that *actually has* thirty-one leading zeros is evidence of approximately two million hashes being done, every hash that *actually has* thirty-two leading zeros is evidence of approximately four million hashes having been done, every hash that *actually has* thirty-three leading zeros is evidence of approximately eight million hashes having been done, and so on.

I'm just saying that you can compare like with like in terms of estimating block difficulty.  Pick a target that definitely would have formed a block, regardless of the time, regardless of which branch -- corresponding to the highest of any difficulty for either branch during the time in question, and count the number of blocks with a hash below that target.  Whichever chain has the most such blocks is, as best anyone can tell, the chain that's had the most hashes done in support of it, regardless of where the difficulty level for the chain was set at the time or how many total blocks are in that chain.

While it is true that bitcoin cannot be effectively totally banned, the facts are that if it is legislated against in any way that makes it not worth the time and effort of most of the population, it will become effectively valueless to the remainder because there will be no network effects.

IOW, if you can't use a Bitcoin to buy anything from a "legit" vendor, then the network effects will be such that it's worth under a buck to everyone else.  A tiny corner of the financial world, indeed.

mmm.

The best response to the FUD, IMO, is fixing things. 

The concerns that people have are real -- mostly centering around our pathetic failures to protect ourselves from fraudsters, thieves, and broken exchanges.  We just got ripped off for a whole lot of value by a half-dozen enormous frauds, starting with Mt.Gox.  If we can't fix it so that won't happen any more, they don't wanna be us.

So, we need support for contracts.  We need support for proving that exchanges actually have all the coins they're promising to have at any given moment.

We have a global open ledger.  We need to fix it so we can use that to eliminate fraud.  THAT is when we will have a good answer to the people who don't wanna be us because we are vulnerable to fraud.

Y'all may not have noticed this, but local rhetoric aside where 'fiat' is always short for 'government fiat', from an economist's perspective, or a literalist's, Bitcoin is absolutely a fiat currency. 

A fiat currency is defined by the fact that there is no one promising to exchange it for a fixed quantity of some valued object or service as a way of guaranteeing its value.  Nobody's offering to give you a beer (or whatever) per bitcoin even if the bitcoin price drops below the price of a beer (or whatever), and that makes Bitcoin a fiat currency. 

Hrm.

On closer inspection of what the code actually does, you are right and the comment I was looking at is wrong. 

Thank you. 

No...  I'm looking straight at the code now.

0x03 and 0x53 both push the value '3' onto the stack.  They are the same.

0x4d aka OP_PUSHDATA2 means 'the next 2 bytes contain a number of following bytes to be pushed onto the stack' and 0x04e aka OP_PUSHDATA4 is the same thing for 4 bytes. 

If you wanted to push a 3-byte number onto the stack as a unit, you'd write

OP_PUSHDATA1, 0x03, DATA1, DATA2, DATA3

Script has unnamed opcodes from 0x01 to 0x4b whose semantics are that the values are simply pushed onto the stack.

Then it has OP_1 (aka OP_TRUE) through OP_16 from 0x51 through Ox60 whose semantics are that the values from 1 to 16 (a subrange of the above) are pushed onto the stack. 

0x51 through 0x60 repeat exactly the semantics of 0x01 through 0x10.

What is the rationale for not having simply given the names OP_1 through OP_16 to the codes 0x01 through 0x10?  Would anything work differently if the 0x51 through 0x60 range were reserved and completely unused? 

Cryddit

Actually I found something today that affects the discussion.

The RPC calls to bitcoind transmit amounts using a 'double' quantity which has only 53 bits of significand precision. 

So an RPC call which represents anything up to the number of bitcoins that actually exist will suffer no rounding error.  With about twice the number of bitcoins that actually exist, small rounding errors would become inevitable.

This is something that can be fixed (you can encode the RPC as a string for example), but given the 21-million coin limit there is no need to fix it in Bitcoin. 

Alts with lots more coins though will have accounting bugs in any financial application using RPC calls to their coins unless they fix it.

Okay...  After reading, this is all technically feasible and plausible.  Except for the last point.

And the last point is, what benefit does the community at large derive from this activity that makes it reasonable for them to freely choose to act as guarantors?  Why would they not prefer  another cryptocurrency that exposes them to no guarantor risk?

BTW, I am delighted to have someone who actually knows something about financial markets here, and I sincerely want to understand how that knowledge can be used to improve the state of the art in cryptocurrency.   I appreciate your work and knowledge, and sincerely thank you.

I don't intend my responses to be belligerent or argumentative, but instead keep asking questions because much still isn't clear to me.  I don't understand for example the motivations of people who would choose to use an over-collateralized market in debt instruments over the option of using the collateral itself.

Okay, what I'm reading into this is that in order to borrow 15 coins (sell 15 repocoins worth of bitcoin with an offer to buy the same amount of bitcoin back for ~15.005 repocoins the following day) the borrower must "lock" collateral worth a bit more than 15 repocoins for the duration of the time he's borrowing. 

If this collateral is repocoins, then obviously his borrowing makes no sense because repocoins are fungible.  whatever purpose he has for the repocoins he intended to borrow would be just as well served by the repocoins he's locking up for the duration.  Therefore I conclude that the collateral here must be in some other asset.  But if the collateral is in Bitcoins, then he's locking up the same amount of Bitcoins that he's loaning out, so wouldn't he be charging additional interest because this is tying up twice as much of his assets as are actually appearing on the market?

After some quick research; a repo market is a very specialized type of bond market.    Someone sells a bond (borrows money), then buys it back for slightly more money (or repays the bond plus interest) 24 hours later.  

In the conventional financial world, this is done with government bonds.  The people who need to borrow large amounts for very short periods are almost all banks and brokerages, looking at short-term imbalances in the flow of money among themselves.  

Obviously, there are no government bonds in a cryptocurrency blockchain, so we couldn't do it that way.    It is possible (though some hard work would be involved) to make a decentralized market part of a blockchain.  

However, in the absence of a way to verify and preapprove the identity of the counterparty, it would be completely insane to buy a debt instrument such as a bond on that market.   Picture the buyer, one day later, calling the police: "somebody owes me a million coins, but I don't know who.... " Even if you do have a pretty good idea who, there is still counterparty risk which is effectively absent from repo markets in which the government is the counterparty, and counterparty risk will raise the interest rates in an unpredictable way.

Legal identities are essentially the relationship between people (or businesses) and governments.  When we need to convince people that they can use the government to enforce our agreement on us, we need to give them the legal identity that links that government to us.  So the participants in the repo market must necessarily first publicly register a legal identity and bind it to a key.

And at that point we're no longer talking about a completely decentralized service, because governments are huge pits of information all of which is external to the blockchain.  

Oh... kay....  I'm game, but still struggling to see how to do it.

First explain carefully what a "repo market" as opposed to, say, a bond exchange or stock exchange or futures market is, or when one or more of the latter counts as a repo market.  Second, exactly how an interest rate relates to such a market.  The only one of those market types where interest rates are directly measurable seems to me to be some kind of futures market. 

If it's a service that we can figure out how to completely decentralize and build into the blockchain itself, then we're cooking with gas. If it's something that would be an external resource, or that would have to be centralized at a website somewhere, then it gets us nothing. 

The basic requirements here for the automatic reaction that we're looking for is that it has to arise in a decentralized p2p service, where the information that's being reacted to is visible to and checkable by literally everybody who can see the blockchain up to the point where the information matters.  Essentially the problem is that if it's an external source of information - if it reflects information not immediately visible to everyone looking at the blockchain - then people will not be able to check the blockchain to see that the response to it was correct at every point.   Being part of the blockchain, in turn, means it has to be a fully decentralized P2P application. 

Now, if it "still doesn't seem too hard" to you, then obviously you have a lot of experience designing fully decentralized P2P applications.