I have a theory that there are many sockpuppets on this forum of Megacoin developers, creating hype and inflating Megacoin's value. Here are some suspected accounts. Notice the poor spelling/grammar consistency, close dates of registration (around the time of the first Megacoin thread, May 29 2013), blind support of Megacoin, and use of animated gifs. There are also common "marketing bullshit" terms used throughout their posts, such as vague descriptions of the "kimoto gravity well," excessive emphasis on being based on the "lastest bitcoin code," cult-like praise of Kimoto, discussion of future "planned" features of Megacoin, etc. Whoever the puppetmaster is, they are working hard to make these accounts seem legit. They also are passionate about altcoins and use that passion to make lots of posts. Just check out the following accounts' post history and decide for yourself...

kimoto - the main account

vtr99

bholzer

blarg

amytheplanarshift

A L I E N

orco#2

It's not a good idea to have an idea rely upon "if it hasn't been done, it can't be done."

The only system I can find that openly pays for CPU time is cpusage.com

There is no discussion on how they secure against cheaters. In principle, they cannot verify the result of an arbitrary computation without themselves performing the computation. It is likely the client is not open source because it would be too easy to cheat.

Folding@Home keeps the client closed source because it would enable easy cheating. I doubt anyone would trust a closed source coin.

How would these distributed computing projects know if someone is cheating? Ex compute fake SETI analysis which takes much less CPU time than real analysis. This is not a problem currently because there is no incentive to fake work in these computing projects. Once people get money to do it, there will be an incentive.

This is why proof of work is easy to verify.

I love when people post ways to improve BTC without trying to make it into something tangible... I'll believe an account-tracking cryptocurrency is better when I see one that is better.

Yes it seems true that the solution finder has no way to protect their claim without mining their own block. I suppose you could add extra conditions to require certain public keys, such as to issue the bounty to specific individuals. You could for instance make a contract with a supercomputing company to find a solution by requiring their public key and signature in addition to whatever other conditions in the script. The problem there is that the funds are locked up unless there is some backup key to redeem them if the company fails to find a solution. Regardless, I think we will see more complex uses for output scripts as time goes on...

Say someone sent some BTC to an output with a script of math operations that are equivalent to a complex equation. The input script, or what the redeemer of these BTC needs to supply, is the solution to this equation. The BTC are thus a "bounty" to solving this equation. With a limit of 10kb and 201 instructions, one could come up with some fairly complex equations. By including the text "bounty" in the script, others could be made aware of it.
Has anyone else thought about this? Do you think we will ever see this become a feasible idea?

Example 1: find the square root of 9
ScriptPubKey: BOUNTY OP_DROP OP_DUP OP_MUL 9 OP_EQUAL
ScriptSig: 3
Explanation: squares the input and checks if it is equal to 9

Note: OP_MUL is currently disabled...

Example 2: find a SHA256 hash collision
ScriptPubKey: BOUNTY OP_DROP OP_2DUP OP_EQUAL OP_IF OP_RETURN OP_ELSE OP_SHA256 OP_SWAP OP_SHA256 OP_EQUAL OP_ENDIF
ScriptSig:
Explanation: Check that string1 and string2 are not equal, then SHA256 each one and check that they are equal

From the source:


So it converts every 4 characters to three words from that list.

1. I'm not sure what you mean by "escrow form." In plain M-of-N the public keys are known to the network when funds are sent to them. In P2SH only the hash of these public keys is known. To create a Tx that spends these funds, one must know which public keys those were and also sign with the private keys. One person could collect public keys and create a P2SH address in which the other public key owners don't know about each other. The would have to trust this person to not create a different P2SH address and all owners would find out about each other's public keys when funds are spent from that address.

2. In plain M-of-N, the public key is known. In P2SH M-of-N, one must know the public keys to spend the funds. If you have a list of possible public/private keys, you have to try every possible combination. You don't even know what M and N are. This is why users of P2SH need to also store the output script (which contains the public keys) for that address.

3. They are trying to create an output script, which has public keys in it in some order, that hashes to the P2SH address.These keys are not publicly viewable on the blockchain unless funds have been spent from the address before.

4. A P2SH address is the hash of an output script. In M-of-N the output script looks like "M ... M OP_CHECKMULTISIG". When a Tx spends funds from the address, nodes check that it contains the output script by checking the hash of it against the address and then check that the signatures match the public keys. When someone sends funds to a P2SH address, they are essentially saying "any script that hashes to this hash can redeem these funds." That script doesn't have to be M-of-N (though it may be non-standard if it isn't).

It depends. If funds had been sent in an M-of-N transaction with the output script exposing the public keys, the attacker can select the 20 private keys which belong to those public keys and create a new transaction spending the funds to himself. If the funds had been sent to a P2SH (pay-to-script-hash) address, and no funds have ever been spent FROM that address, then the attacker only knows the hash of the 20 public keys. In that case, he would have to brute-force it, trying every subset of 20 public keys from the 100. It turns out there are about 5.4 * 10^20 possible subsets, so it might not be possible to brute force in a reasonable time.

M-of-N are now a standard Tx, and thus relayed/mined.

See here:

https://en.bitcoin.it/wiki/BIP_0011
https://en.bitcoin.it/wiki/BIP_0016

M-of-N signatures are checked in scripts by OP_CHECKMULTISIG

It is limited to 20 public keys, so the limit of M and N is 20.
Source: https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L871

The limit exists out of concern for limting the size and computational complexity of transactions. Private keys are not divided in M-of-N transactions. Rather, there are N private keys, of which M need to sign the transaction for it to be valid.

I think from an economic standpoint, it makes sense to scale block size based on Tx fees. For example, at each difficulty adjustment, calculate average Tx fees in a block over all blocks since last adjustment, and scale block size based on that. That way, the extra cost to miners of storing larger blocks is made up by larger Tx fees. When competition for block space increases and people start paying more in Tx fees, the block size scales accordingly. This of course opens an attack vector where a miner mines many blocks himself, collecting his own Tx fees, to raise or lower the block size artificially. Also the equation to calculate block size from average block fees would still be an arbitrary/magic component.

I'm not convinced my exploit has been resolved, but it may be a misunderstanding of the proposal here. Either way, you haven't convinced me this proposal is sound, and the burden of proof is on the ones claiming they have found a way to make zero-conf Tx safe. If you are really serious about this idea, program it into an altcoin or testnet and get people to run attacks against it. If you are successful, you might create a valuable altcoin or be responsible for a critical fork to bitcoin. At this point however I'm done examining this proposal which is difficult to discern without code.

The Tx that Merchant A receives may or may not be heard about by Merchant B. It is unwise IMO to make a security feature rely on the assumption that all nodes will know about all unconfirmed Tx. Then, then the buyer mines his own block sending the coins back to himself. Merchant B will accept zero-conf Tx building off that block if he doesn't know about the Tx from Merchant A. The buyer could peer directly with Merchant B so Merchant B is likely to see the new block faster than Merchant A. This gives the buyer more time for his zero-conf Tx to be accepted by Merchant B. Merchant A must "be on the ball" to quickly realize the dbl-spend and make sure all other nodes know this. Naturally or purposefully occurring 1-2 block blockchain forks may make this proposal unreliable as well.

Also, what if there are buyers who always dbl-spend coins, so that merchants will be discouraged from accepting zero-conf Tx using this method? There is no additional cost to buyers who dbl-spend in this scheme anyway.

That is a risky method due to invalidating a Tx already in a block. Consider if a dbl-spender mines his own block with a Tx that dbl-spends coins, invalidating a zero-conf Tx he sent a Merchant A. He then immediately pays Merchant B from the dbl-spent coin who accepts zero-conf Tx (presumably because of their trust in this proposal). If he pays Merchant B before he hears about Merchant A's invalidated Tx, then Merchant B will have their zero-conf Tx invalidated and the dbl-spender gets away with effectively dbl-spending coins (got same coins accepted by two merchants).

This also sets up the possibility for extortion, where a buyer threatens to dbl-spend coins (making the merchant lose the coins) unless the merchant does something.

Similar to the goal of a Bitcoin mixer, this idea's purpose is to make it harder for someone to analyze the blockchain and associate transactions/addresses with an identity. Every Bitcoin user has a directed "Tx graph" where the vertices/nodes are Tx's a user has made and connecting edges/arrows point to a Tx from others it uses as inputs. This graph could be perfectly constructed by a user if they kept track of all their Tx. Deriving it accurately from the blockchain is difficult but possible in some situations. In most cases one could only derive Tx graphs for an identity which were probabilistic. I.E. there is an x% chance this Tx graph is accurate, x% chance this other one is, etc. One could construct another graph that assigned probabilities to each edge which represent the likelihood a Tx was made by the identity in question. A more detailed graph could be made tracking individual outputs as well. There are many different methods for constructing graphs of the blockchain and many methods for deriving identity association from it.

To make identity association more difficult, this proposal works as follows:

1. n parties create a new address and send X BTC to it
2. These parties agree to construct a single Tx (or use a service they trust to do this for them) where they each input X BTC from said address and get an output to a new address they control for X BTC (minus the Tx fee)
2. Each party signs the Tx with the key they used for their X BTC input and publish it
3. Each party can do multiple "rounds" of this process

By doing many rounds of this, parties connect/converge their Tx graphs, blending identities together, because one cannot know which output connects to a specific input. Users would need to be careful to not use obfuscated BTC with non-obfuscated BTC in the same Tx.

Obfuscaters could use a P2P network to find each other and construct these Tx. There would need to be standard amounts to obfuscate, such as powers of 10 (0.1 BTC, 1 BTC...) since every input/output in these Tx needs to be the same.

Just learned about Bitmessage. I suggest people go read the white paper on their wiki - short and to the point. It has the potential to upset email because of the increased privacy, built-in mailing-list functionality, and anti-spam measures (proof of work makes it hard to create lots of messages fast). This Open Transaction use case is a perfect example of the innovation possible with it.

And thus begins solving math problems to redeem Bitcoins

Wow, the address that received the block reward is very rich...

https://blockchain.info/address/1Baf75Ferj6A7AoN565gCQj9kGWbDMHfN9

I am referring to this page:
http://blockchain.info/strange-transactions

The page is nearly useless because "real" strange Tx are lost among the huge P2Pool generation/coinbase Tx's.

On that page, you will see a bunch of large Tx with the last output unable to be decoded. You can know these Tx are from P2Pool by looking at the last two outputs (example, scroll to bottom of page):

http://blockchain.info/tx/abf4749cad03660deaace40b25a2f1d3e441c4c0bbef7682386984c2f5b7955b

The 2nd to last output is always a donation to the P2P donation address, 1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4. This is seen as an output to a public key rather than the address itself:

The last output is always 0-valued and has an invalid script which is used internally by P2Pool (just a hash of some data), documented here. It is this output that is marked as strange.

I suggest that these Tx be removed from the Strage Transactions page. I think such a page is useful for looking at innovative uses for Bitcoin or learning about Tx scripting. With P2Pool Tx in there, it is hard to find other strange Tx. Perhaps exclude "garbage" output scripts which don't have any valid opcodes from being marked as strange, or just exclude generation Tx which send to the P2Pool donation public key.