Today I went and learned the sad sad story of Etoken.

https://bitcointalk.org/index.php?topic=436750.0
https://bitcointalk.org/index.php?topic=403597.0

A 'rare' coin with a one-coin per block reward -- except that there were two 'special' blocks that paid a million each.  It was managed with periodic bonus multipliers, whose harmonic periods created a pattern of constructive reinforcement.   Which was, of course, destructive to the value of the coin.

Did they not look at the source code and realize what it meant?  Could they not do math?  Or did they make the more profound mistake of implicitly trusting a completely unknown, untraceable human being? 

I mean bitcoin's proof of work can act as a timestamp mechanism for more than just bitcoin.

With Bitcoin blocks coming out every ten minutes, an altcoin that quoted a recent bitcoin block's hash would contain a reference to that ten-minute period.  You couldn't generate the altcoin block before that period arrived.

Heh. 

Once upon a time, I was in that euphoric first few weeks of a brand new relationship and one of my longtime friends said, "I didn't know you were into Asian women...."

I corrected him.  "Mike," I said, "I'm into WOMEN...."

And at that point Hibaki smacked me.  I honestly have no idea what the "correct" response here was.  Agreeing with Mike would have made it sound like I was dating her just because she was Japanese, and disagreeing with him (at least the way I did) made it sound to Hibaki like I would date just anybody who was female.

You know what I think?  I think she shoulda' smacked Mike.

If you want to prevent someone from preparing a chain of blocks ahead of time, it's worthwhile to require each block to contain some kind of observed event that can't easily be known in advance. 

A Bitcoin block ID/Hash would be a pretty good example of that, I'm thinking.

If you require a bitcoin hash from, say, 2 hours ago in each block of your block chain, you're immune to reorgs on the bitcoin blockchain unless they're over 2 hours long, and the time of appearance of each bitcoin block is publicly known.  The result is that nobody can make a block of your altcoin chain more than 2 hours in advance.

I looked at KGW and didn't much like it. 

The code I posted in the other thread adjusts when several moving averages are in agreement as to the adjustment needed, and doesn't make the kind of nonlinear twitchy adjustment KGW can do.  It can make adjustments every block, but does not make its decision about adjustment based on the timing of just the last individual block.  The very shortest moving average prevents most adjustments once they're in the neighborhood of being right, and the longer moving average doesn't permit adjustments unless they're justified by the more statistically significant larger sample size.  So you get a significant adjustment every block when a pool or a burst miner jumps on or off and you're way out of balance, but you don't get twitchy stupid adjustments when a couple of blocks come in within seconds of each other.

Merged mining is a very good thing, but if you're trying to implement it for an altcoin be very careful.  It's done correctly in namecoin, but incorrectly in several other places.  It can be a vulnerability for an altcoin unless done safely.  Several alts have been attacked after implementing merged mining wrong.  Also, think very clearly about why you want to implement an altcoin.  What are you doing that Bitcoin (and instruments based on it) does not and cannot do, and is there a significant niche where that is actually needed?  If there's no answer, your altcoin doesn't have a mission -- nor a chance in hell of success.

Having satisfied myself that Bitcoin is not particularly vulnerable to time warp at this time, I would say that one thing you could do to protect an altcoin from a timewarp would be to include a recent bitcoin block hash in its block, to authenticate the timestamp.  A block 2 hours old is fairly immune to Bitcoin chain reorgs and would flatly prevent anyone from being able to form altcoin blocks more than 2 hours in advance of their claimed timestamp. That means a time warp, even if successful, could not claim very many 'extra' coins. 

Nope, adblock doesn't do it.  No graphics are being served from anywhere else.

What we have is a <span> element with styled text, appearing inside an <a> element. 

50 BTC is not an example of "reasonable". 

I'll work with the CSS thing.  They're actually abusing the 'span' element to achieve the banner-ad like effect. 

Really?  

Seriously, you are going to insist on baiting someone into demonstrating this attack before you believe in it?  

You just like to watch the world burn, huh?

On the coingen.io site there's a list of coins that people have paid him to generate.  One such coin was named 'lovecoin'.  I don't know whether it's the one you're working with, or whether a coingen framework was where the previous dev started, or what.  But there's definitely been a 'lovecoin' generated via coingen.

I went and investigated about Lovecoin in order to update it properly and make sure that there's a proper distinction between the first round and the relaunch in this list. 

It's a real shame about the scammy first version, 'lovecoinproject' vanishing with the premine, etc.  Best of luck trying to resurrect this. 

If you don't mind me asking, what's your motivation here?  Why would you come in behind a fairly clearcut case of a scam, and try to relaunch or 'redeem' this thing? 

In most threads, a banner ad appears under the first post on a page, these days for Antminer.  That banner ad is very wide.  It forces a horizontal slider bar onto the browser, and hides the right edge of all the posts on the page, unless you have your browser open to about 1600 pixels wide.  And the slider bar and the hiding-the-right-edge "feature" persist even when you're reading posts further down the page where the banner ad no longer even shows.

That's really annoying for those of us who would prefer not to keep our damn browsers 1600 pixels wide all the time.

Is there any way this wide banner ad could be broken up into "left half" and "right half" - meaning, people who have their browser 1600 pixels wide would see it exactly the same way, but for those of us who really like to leave half our screen for other things (like, say, an editor for taking notes or a terminal shell for doing work) the page compositor could just stack them one atop another?

Alternatively, is there some "reasonable" account upgrade I can buy to get rid of the damn page-layout breaking banner ad?

Actually a high latency, or a slow computer, can cause very slow downloads in the bitcoin blockchain, even if you have good bandwidth.

The way the initial block download works, your client goes and asks somebody, "what's the current block", and they say, BLOCK ID XXXXX.  And then since you don't have XXXXX, you ask them for that and they send it to you, but after you download it, then you look at its block header and discover that the previous block was WWWWW - and you don' t have that one either!  So you ask, "Hey could you give me  a copy of Block WWWWW?"  And they send that, and you look at it, and its parent was VVVVVV, and you don' t have that either, so you ask.....  and so on, back to the Genesis block.

The deal here is that you don't know which additional block you need next (and therefore can't ask for it) until you've gotten the current block, so you can only have one request for a block out there at a time.  If you have a high latency, or the peer you asked the block for has a high latency, it can take a few seconds to get each and every block, even if you both support very high transfer rates.

Then there's a CPU bottleneck to worry about.  Your peer does all kinds of cryptographic checks on each downloaded block, so if your CPU is slow, that may even dominate the latency time. 

It's worthwhile to get the bitcoin blockchain using bittorrent; with the bittorrent protocol at least you can have requests out there and active for more than one block at a time. 

one problem with the ASIC race is that the force we're trying to secure the blockchain against is the same force that we're using to secure it.

It's hashing power on the attack and hashing power on the defense.  If the legit market calls hashing power into existence, then some future reversal or shift in circumstance can move that hashing power from defense to attack.  And with marginal profits from defense approaching zero, the miners are always balanced on this knife edge where the smallest change could make an atack more profitable than continuing defense.

I'm reminded of what Pratchett's character Vetinari said about hiring mercenaries:  You have to pay them to start fighting, and unless you are very lucky you also have to pay them to stop.

No.

That's more or less the definition of 'Turing-complete' - if you have a Turing-complete language, then anything that can be expressed in it can be translated into any other Turing-complete language. 

The reason they're called that is because Alan Turing proved a result in computability theory that showed all such languages are absolutely equivalent in terms of what they can express.

If you have something that isn't a Turing-complete language, then it is fundamentally not able to express some set of algorithms in the set that Turing-complete languages can express.

IOW, if you're writing in a Turing-complete language, then much of what you write can never be expressed in BTC's script language.  Ever.  At all. 

Offhand I'd say no, not a problem.  Ignore them and they'll eventually go away.

Colored Coins etc. make it much harder to know how much value we need the blockchain to protect.  The fact that these values are essentially "hidden" from the protocol means we can't tell what we need to do to maintain any kind of parity with them.

One popular (and possibly correct) view of things is that in the long run the cheapest available price of electricity times the amount of electricity spent per block, will approach the value of the block reward in a PoW system. 

Right now we have a Bitcoin block reward worth approx. $12000.  If this view is correct, we should expect, worldwide, to see about $12000 worth of electricity (increasingly concentrated where electricity is cheapest) expended per block by hashing rigs. 

Right now transaction fees are providing a very small percentage (one third of one percent?  I think?) of the block rewards. 

At  some point in the future, moving to transaction fees as a primary source of mining revenue, implies that each kilowatt-hour of electricity invested in securing the blockchain will have to secure three hundred times as much value (relative to its own value) from attack as it does now. 

I'm convinced that's not really enough.  If we stick with Proof-of-work, we're going to have to start charging transaction fees based on how much value is changing hands, because we want to buy security proportional to the value we're trying to secure, not proportional to the amount of space it takes to store the transaction.  And that means the amount of value changing hands has to be visible, and that therefore Colored Coins etc will have to be more 'transparent' in terms of the protocol knowing how much they're worth (and therefore how much security we need to buy to keep them secure).

I've been meaning to look at it in more detail.  Thanks for providing info.

https://en.bitcoin.it/wiki/Transactions gives info but it's a bit hard to understand.

Each input of a transaction contains a 'ScriptSig' and each output contains a 'ScriptPubKey'.

The checking mechanism is that the ScriptSig is concatenated with the 'ScriptPubKey' and the result is treated as a script for the script engine to work on, right? 

And the distinction between 'pay to script hash' and 'pay to pubkey hash' is:

In the 'pay to pubkey hash' the scriptsig consists of <signature><pubkey> and the script instructions are in the ScriptPubKey.  The ScriptPubKey says something like OP_DUP ,OP_HASH160, <pubKeyHash>, OP_EQUALVERIFY, OP_CHECKSIG, so the initial 'script' when the script engine starts is

<signature><pubkey> OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY, OP_CHECKSIG.

In the 'pay to script hash' the Scriptsig consists of OP_HASH160 <hash> OP_EQUAL and the ScriptPubKey consists of whatever signatures and script the spender puts in, making the initial script when the script engine starts be

OP_HASH160 <pubkeyhash> OP_EQUALVERIFY ...signatures.... ... custom spending script .... 

But the script engine works exactly the same way regardless and doesn't even realize there's any difference between these two cases.  You'd have to patch it to detect and exclude the pay-to-pubkey case if you wanted to make pay-to-script-hash uniform, right?  It doesn't care what's in these fields, it just concatenates them with each other and treats the result as a script to run.

Today added VirtualMiningCoin(VMC) to the list. 

Also updated Cannacoin - someone wrote to tell me it isn't dead, and to be fair its market cap is over $5K at the moment.  We'll see if it makes it for 90 days.

I notice Bellacoin and Skeincoin are back over $5K too.  I hope those make it out of the grave, but I'm not going to play favorites. 

And I notice Aphroditecoin's whole market cap has declined from less than the price of a pizza to less than the price of a decent hamburger.  But it's still there.  What's up with that?

When you're talking about a 'redeemscript' you need to be specific as to which transaction you're talking about it in.

Let's say you have a transaction B, which is using as its inputs the outputs from transaction A. 

In transaction A, the 'redeemscript' would be a fixed-length hash.  (8 bytes?  16? I'd have to go look)

In transaction B, it's two pieces; the first piece (script) has to hash and match up to the hash given in transaction A.   Both pieces (script and data) have to be loaded onto the stack and then the script engine is run. 

Anyway, the scripts are limited to 201 steps. 

The DECOR idea is good, for several reasons. 

First because the hashing power spent on a fork is hashing power which can be counted as having been spent on the main chain, when comparing the main chain to any *other* fork. 

This is also useful because it makes "preparing an attack chain ahead of time in secret" less plausible; the root of the attack chain failing to appear in the "orphaned blocks" of the following block on the main chain would make the falsehood of the attack chain much more obvious. 

It would be advantageous, IMO, to generalize it; instead of just recording siblings of blocks in the main chain, you could record siblings, their children, their grandchildren, etc - for as long as the attack chain was within, say, 3 blocks' worth of hashing work of the main chain.  This would make it possible to track the progress of a threatening "fork" from the main chain, at least if the "fork" consists of blocks that have actually been announced.   And unannounced blocks suddenly appearing on a chain more than three blocks behind the main chain should be regarded with suspicion, at the very least. 

It might be reasonable to require a 4-to-1 work difference before switching to a fork whose root isn't recorded in the chain you're switching from, simply because such a fork is much more likely to be an attack chain. 

The important thing here is that someone could make a conclusion about the status of the blockchain's security by looking at a block.  If there's no announced fork running, you can be sure that a fork prepared in secret will have to contain four times as much work to displace the chain you're paying on, and if there is an announced fork, you can wait until the main chain is seven blocks ahead of it before you make any major transactions.