[DEAD] Coiledcoin - yet another cryptocurrency, but with OP_EVAL!

[makomk]

Interestingly, it looks like there is actually a way of making coins immune from this particular attack that doesn't require any kind of trusted central authorities and can't be used to fork the blockchain. Unfortunately it'd be a huge pain to implement correctly and wouldn't be able to deal with 51% double-spending attacks.

The trick is that there's no inherent reason why the Bitcoin blockchain actually had to be in the form of a chain. Simply add a rule that blocks can merge multiple non-conflicting forks of the blockchain by having multiple parents, calculating its total work as the sum of its work and work done for all its ancestor blocks. That way, it doesn't matter that Eligius is mining faster than the rest of the network because we can use the attacker's work against him - our non-attack versions of the best chain are counted as having the strength of all his work plus all ours, and the only way he can benefit from this effect is if he includes other's blocks and transactions which is what we wanted in the first place!

There's almost certainly some subtle flaw in this and it'd be a nightmare to implement correctly and in a way that couldn't be exploited, but on paper it seems like a clever idea. Don't think I'm going to go through with it though. (There are a whole bunch of subtle details that have to be taken care of. For example, we need to cap how far back a fork that's being merged can come from to block spam, but this limits the power of this scheme against denial-of-service.)

[DeathAndTaxes]

Interestingly, it looks like there is actually a way of making coins immune from this particular attack that doesn't require any kind of trusted central authorities and can't be used to fork the blockchain. Unfortunately it'd be a huge pain to implement correctly and wouldn't be able to deal with 51% double-spending attacks.

The trick is that there's no inherent reason why the Bitcoin blockchain actually had to be in the form of a chain. Simply add a rule that blocks can merge multiple non-conflicting forks of the blockchain by having multiple parents, calculating its total work as the sum of its work and work done for all its ancestor blocks. That way, it doesn't matter that Eligius is mining faster than the rest of the network because we can use the attacker's work against him - our non-attack versions of the best chain are counted as having the strength of all his work plus all ours, and the only way he can benefit from this effect is if he includes other's blocks and transactions which is what we wanted in the first place!

There's almost certainly some subtle flaw in this and it'd be a nightmare to implement correctly and in a way that couldn't be exploited, but on paper it seems like a clever idea. Don't think I'm going to go through with it though. (There are a whole bunch of subtle details that have to be taken care of. For example, we need to cap how far back a fork that's being merged can come from to block spam, but this limits the power of this scheme against denial-of-service.)

How exactly do you deal w/ conflicts.

Chain A says coins transferred from address 123 to address 456.
Chain B says coins transferred from address 123 to address 789.

Where do the coins go?

Forget 51%.  Double spending is as easy as making a duplicate block w/ different transaction.

[makomk]

How exactly do you deal w/ conflicts.

Chain A says coins transferred from address 123 to address 456.
Chain B says coins transferred from address 123 to address 789.

Where do the coins go?

Forget 51%.  Double spending is as easy as making a duplicate block w/ different transaction.

Yeah, that's the problem. It only works so long as whoever's attacking the chain doesn't attempt a double spend. We can still cope with sub-50% double spend attempts by essentially picking the side of the double-spend with the most confirmations (though there's a lot of subtlty in how this must be calculated) and throwing away the other double-spend block and its descendants, but greater-than-51% ones are a huge problem.

[EhVedadoOAnonimato]

This idea of considering short forks as valid to prevent "freezing attacks" is interesting. I opened a topic about it, with some elaboration already done, but certainly a lot missing. Here it is: https://bitcointalk.org/index.php?topic=57647.0

[btc_artist]

Hmmm, some good may have come out of this yet.

[Luke-Jr]

Now that the scammers are (at least mostly) gone and shut up... I'm offering a 50k CLC bounty to a practical, technological solution to my monopoly on CLC. If there are multiple people involved in the solution (eg, one person designs it and another implements it), I will decide how to split it up among them.

I'll say straight off, that this does not include "solutions" like the all-too-common FUDing and slander, nor special-casing to my particular blocks (that is, I should still be able to mine like everyone else after it's fixed), though fitting to the particular nature of this monopoly is acceptable.

When/if this solution is implemented, I will consider CLC to have made a legitimate contribution worth leaving it alone.

Bonus points if you can give it also a legitimate long-term use to bring it fully out of "scamcoin" status, and then I'll offer it as a merged-mining option on Eligius.

[markm]

Cute. I was thinkiing of calling is Lukecoin or Dashcoin and then I find you seem to be thinking along the same lines.

(Last time I'd checked the block count was still increasing so it evidently wasn't dead, just being pre-mined by it's owner uh I mean pwner.)

I have been wondering if one potential solution might simply be to outbid other pools in the amount of reward offered to miners. Basically paying them in just one currency, probably devcoins, bitcoins, paypal, pecunix, or that liberty silver thing, and doing it as residual where the shares they submit all count toward perpetual (until they sell the shares; the pool would be trying to buy them as well as paying out on them) share of proceeds of all the ever increasing numbers of blockchains (not necessarily only coin blockchains) the pool works on.

Since there are many more blockchains that still do not have pool support, and at least some might potentially have some value, I am thinking such an approach might actually end up being able to pay more per unit of work than pools that merge only a few best-known chains.

-MarkM-

[ovidiusoft]

Now that the scammers are (at least mostly) gone and shut up... I'm offering a 50k CLC bounty to a practical, technological solution to my monopoly on CLC. If there are multiple people involved in the solution (eg, one person designs it and another implements it), I will decide how to split it up among them.
I'll say straight off, that this does not include "solutions" like the all-too-common FUDing and slander, nor special-casing to my particular blocks (that is, I should still be able to mine like everyone else after it's fixed), though fitting to the particular nature of this monopoly is acceptable.

I'm not involved in CLC and I don't have the knowledge to implement it, but I think this idea of mine might work: https://bitcointalk.org/index.php?topic=53128.0
Basically, we consider miners who don't include old transactions in mined blocks are hurting the network so we invalidate their blocks. The idea was rejected because it was considered it would take away freedom from miners. In CLC context and your attack, something like that seems to be perfect - your hashing power would allow you to only delay all trasactions up to a maximum limit.
Let's make the rule really simple: blocks are invalid if there are tx'es older than 8h not included. What do you think?

[Luke-Jr]

Let's make the rule really simple: blocks are invalid if there are tx'es older than 8h not included. What do you think?

I'd "time" them in blocks. What if there are too many to include in a single block?

[ovidiusoft]

Let's make the rule really simple: blocks are invalid if there are tx'es older than 8h not included. What do you think?

I'd "time" them in blocks. What if there are too many to include in a single block?

I kind of doubt there will be a "too many tx in the same block window" problem any time soon, but sure, blocks works just as well.

[DeathAndTaxes]

Let's make the rule really simple: blocks are invalid if there are tx'es older than 8h not included. What do you think?

I'd "time" them in blocks. What if there are too many to include in a single block?

I kind of doubt there will be a "too many tx in the same block window" problem any time soon, but sure, blocks works just as well.

Have you thought that all the way through?  Try thinking like an attacker.

How does an arbitrary node on the network know how old a transaction is?
How could an attacker use the requirement to have all transactions older than x blocks included to attack the network?

[RandyFolds]

Let's make the rule really simple: blocks are invalid if there are tx'es older than 8h not included. What do you think?

I'd "time" them in blocks. What if there are too many to include in a single block?

I kind of doubt there will be a "too many tx in the same block window" problem any time soon, but sure, blocks works just as well.

Have you thought that all the way through? 

Of course not. God does the thinking around these parts.

[ovidiusoft]

Have you thought that all the way through?  Try thinking like an attacker.

Probably not. I'm not that evil

How does an arbitrary node on the network know how old a transaction is?
How could an attacker use the requirement to have all transactions older than x blocks included to attack the network?

Assuming that tx propagation is reasonably fast, simply take into account the time the node got the tx. This assumption might not be true, but I think I read that it's somewhere under 30 seconds. As long as the case where a new block appears in the network while some txes are propagating is very rare, I think it's not a problem. Am I wrong?
Regarding the attack scenario, an attacker might want to withhold old transactions and forward them with delay, so they will invalidate other miners' blocks. But if the other nodes will see this as new transactions, this attack will fail. I can't think of other ways, it's late, I'm tired and I think I have brain damage from doing Gtk in Python

[ovidiusoft]

Of course not. God does the thinking around these parts.

My mama told me I should wash my hands, be nice to old people and don't answer to Internet trolls, but I guess I'll bite this time. As per any dictionary a forum is: "A meeting or medium where ideas and views on a particular issue can be exchanged." . I didn't realize there's also a requirement to do deep research on any random idea I have and want to share with the rest of the community. Allow me to apologize and rest assured the I will immediately start working on a paper that will analyze my idea from all conceivable point of view, including but not limited to environmental impact, religious aspects, dependency on weather conditions, influence on snow tigers (they're an endangered species!) and so on. You seem really nice and friendly, I will make sure to send you a first draft for review, I'm sure you'll help.

[RandyFolds]

Of course not. God does the thinking around these parts.

My mama told me I should wash my hands, be nice to old people and don't answer to Internet trolls, but I guess I'll bite this time. As per any dictionary a forum is: "A meeting or medium where ideas and views on a particular issue can be exchanged." . I didn't realize there's also a requirement to do deep research on any random idea I have and want to share with the rest of the community. Allow me to apologize and rest assured the I will immediately start working on a paper that will analyze my idea from all conceivable point of view, including but not limited to environmental impact, religious aspects, dependency on weather conditions, influence on snow tigers (they're an endangered species!) and so on. You seem really nice and friendly, I will make sure to send you a first draft for review, I'm sure you'll help.

I was poking fun at luke-jr...I should have pared down the quoted posts. Sorry for the offense, but I look forward to your dessertation...wait, it's a dissertation. Nevermind.

[Syke]

Assuming that tx propagation is reasonably fast, simply take into account the time the node got the tx. This assumption might not be true, but I think I read that it's somewhere under 30 seconds. As long as the case where a new block appears in the network while some txes are propagating is very rare, I think it's not a problem. Am I wrong?

Very wrong. Nodes come and go all the time. No tx propagates to all nodes. Consider when a new node comes online, so it didn't see all the previous txs, and it solves a block. Then the whole network invalidates its block because it doesn't include old txs it never saw.

[markm]

Its fun to have huge quantities of cryptocoins, even ones thought to be pretty much worthless.

Since pool users evidently do't mind pool operators mining umpteen atlcoins without giving them a cut, all the pools might as well do it. We can use the coins in all kinds of games or something. It'll be fun.

-MarkM-

[ovidiusoft]

Assuming that tx propagation is reasonably fast, simply take into account the time the node got the tx. This assumption might not be true, but I think I read that it's somewhere under 30 seconds. As long as the case where a new block appears in the network while some txes are propagating is very rare, I think it's not a problem. Am I wrong?

Very wrong. Nodes come and go all the time. No tx propagates to all nodes. Consider when a new node comes online, so it didn't see all the previous txs, and it solves a block. Then the whole network invalidates its block because it doesn't include old txs it never saw.

You are, in theory, right. In practice (for Bitcoin proper at least), miners are always online and on a very fast connection. Not to mention that there's very little chance to miss an old tx. Remember that a block will be invalid if a mined didn't include a very old tx - no problem if it missed a very new one. I think there's very little chance that a miner comes online and solves a block in the time that it will take to receive all tx'es. But if that is real concern, i guess it makes sense for a miner to simply wait a few minutes to connect to very stable nodes and sync with the network until it starts hashing, no?

[ovidiusoft]

Of course not. God does the thinking around these parts.

My mama told me I should wash my hands, be nice to old people and don't answer to Internet trolls, but I guess I'll bite this time. As per any dictionary a forum is: "A meeting or medium where ideas and views on a particular issue can be exchanged." . I didn't realize there's also a requirement to do deep research on any random idea I have and want to share with the rest of the community. Allow me to apologize and rest assured the I will immediately start working on a paper that will analyze my idea from all conceivable point of view, including but not limited to environmental impact, religious aspects, dependency on weather conditions, influence on snow tigers (they're an endangered species!) and so on. You seem really nice and friendly, I will make sure to send you a first draft for review, I'm sure you'll help.

I was poking fun at luke-jr...I should have pared down the quoted posts. Sorry for the offense, but I look forward to your dessertation...wait, it's a dissertation. Nevermind.

Oh. In this case, I'm sorry for being so trigger happy. Let's all be friends (and expect a 150+ pages document very-very soon ).

[Syke]

Not to mention that there's very little chance to miss an old tx.

New miners can't "receive all tx'es".  They can only receive newly broadcast txs. So basically every time a new miner comes online, it will be missing lots of old txs.