Anti-Orphan (51%) attack... (Natural or actual attack)

[ISAWHIM]

I am just thinking out-loud here, and I may be completely off on this possible suggestion... (as always).

But...

If the wallets/servers/programs were setup to only allow a stack of 8 blocks, before they have to "get a new block, with a non-ME header"... That would ensure that 51% was not possible, would it not? EG, If I mine with my army-o-miners, and start a fake-block and hit block #8, the network will just reject the addition of block #9 with that same "miner account" as the first transaction. Thus, no-one "adding to the fake chain", which is causing all the "valids from the real chain to become an orphan".

Going a step further... If you force a "reject" of a double-block mined by the same "wallet"... That would auto-round-robbin the entire chain. Thus, once you "hit a block", you have to wait for anyone-else to have found the "next block", then you can start mining again. (That would also force large single-wallet pools to create multiple wallets, thus, again, ensuring that no 51% attack was possible, unless there were only two miners/wallets running at the same time.)

The chances of hitting two blocks in a row are slim. The wait-time for a new block to be available is not a major loss, and ensures that even less losses from 51% and orphans.

(NOTE: A maliciously created server/wallet that "allows" these blocks to happen, would not function when the others have these limitations set in place. That would cause the fake block to continue to be mined alone, never getting past that 8th block. He/she can mine away all day, nothing would ever confirm.)

Also, why is it when an "orphan" is found... do the wallets/servers not "grab another chain", that is not orphaning... or "force a chain revalidate", to detect and kill the fake chain, before it grows. (Kill = ignore it as a group/network.)

[vinne81]

I am just thinking out-loud here, and I may be completely off on this possible suggestion... (as always).

But...

If the wallets/servers/programs were setup to only allow a stack of 8 blocks, before they have to "get a new block, with a non-ME header"... That would ensure that 51% was not possible, would it not? EG, If I mine with my army-o-miners, and start a fake-block and hit block #8, the network will just reject the addition of block #9 with that same "miner account" as the first transaction. Thus, no-one "adding to the fake chain", which is causing all the "valids from the real chain to become an orphan".

Going a step further... If you force a "reject" of a double-block mined by the same "wallet"... That would auto-round-robbin the entire chain. Thus, once you "hit a block", you have to wait for anyone-else to have found the "next block", then you can start mining again. (That would also force large single-wallet pools to create multiple wallets, thus, again, ensuring that no 51% attack was possible, unless there were only two miners/wallets running at the same time.)

The chances of hitting two blocks in a row are slim. The wait-time for a new block to be available is not a major loss, and ensures that even less losses from 51% and orphans.

(NOTE: A maliciously created server/wallet that "allows" these blocks to happen, would not function when the others have these limitations set in place. That would cause the fake block to continue to be mined alone, never getting past that 8th block. He/she can mine away all day, nothing would ever confirm.)

Errr.. a "wallet" doesn't generate a block. A program generates a a block, then directs the outputs to a certain public address.

That program could generate a new unique address for each block.

You wouldn't know it's the same user I think?

There's no you and me, there's just the pool and addresses.

[ISAWHIM]

You MINE in CGminer, to your "wallet", which is the "server/daemon". Your mined rewards go directly into your wallet, as the header, the first-transaction of every block is YOUR 25BTC reward. (Or your pools wallet, if you mine in a pool.) You CAN use a headless wallet, called a daemon... but it is still a wallet. It has your wallets-public/key and address and private/key.

NOTE: I am just getting frustrated that I can't mine FTC or LTC, due to these recent hold-ups... They "SAY", we are mining the real block... but everything is returning as "orphaned", thus, not giving credit... or apparently not giving credit... and no-one is saying "Yes, it will go through, once the fake chain is gone."

So little two-way communication between the wallet/network and the actual miner/program... You don't even know it is failing, until you waste half a day and ultimately see no results, then you still have to figure-out why there are no results, which is impossible, due to the lack of actual feed-back or information as to the failure. Just shut-down and restart, and HOPE it works the next time... (Gotta wait a day to find out again. Such a poor design. A simple "test" dummy block would immediately let you know, something is wrong, before "trying" to hash away, failing, due to a code-glitch that never indicates it is actually failing.)

[vinne81]

You MINE in CGminer, to your "wallet", which is the "server/daemon". Your mined rewards go directly into your wallet, as the header, the first-transaction of every block is YOUR 25BTC reward. (Or your pools wallet, if you mine in a pool.) You CAN use a headless wallet, called a daemon... but it is still a wallet. It has your wallets-public/key and address and private/key.

If you generate a new address, send the 25 BTC rewards to that address, how would the world know that that address belongs the the same wallet as the previous? You don't know the addresses of other users. They just got a private key that matches their addresses, that's all.

[ISAWHIM]

If you generate a new address, send the 25 BTC rewards to that address, how would the world know that that address belongs the the same wallet as the previous? You don't know the addresses of other users. They just got a private key that matches their addresses, that's all.

You can SEE the "recipient" of the mined coins. The address is the first one in the block, that is who mined the coins/block. If you couldn't see it, you couldn't "validate" the transaction for that wallet-address. (That s how they KNOW who created the orphan-chain... They sustain the chain to hide a fake-spend or a double-spend, until it gets them what they want, and then they let-go of the chain, and the fake transactions disappear... thus, coming out of someones wallet, as that was not a "valid" receipt of funds, as they don't exist on the real chain.)

We build the NEXT block, off that block... (If that block is fake, that person is creating the next one, and the next one, and the next one... not us...) Thus, they are all one address, and can be "ignored" by the network/wallets, which gives the miners the work/jobs.

It is not difficult to "record the last 9 addresses from the blocks creator", and if all 9 are the same, you ignore them and look for another chain to "build on". (Since that would be a fake one.) Or, in the event that it is all from "one pool", thus, "one address"... that forces any other miner to make the next "single" block... Which could be the pools "other wallet", which would never be noticed, by anyone other than the network.

[vinne81]

If you generate a new address, send the 25 BTC rewards to that address, how would the world know that that address belongs the the same wallet as the previous? You don't know the addresses of other users. They just got a private key that matches their addresses, that's all.

You can SEE the "recipient" of the mined coins. The address is the first one in the block, that is who mined the coins/block. If you couldn't see it, you couldn't "validate" the transaction for that wallet-address.

We build the NEXT block, off that block... (If that block is fake, that person is creating the next one, and the next one, and the next one... not us...) Thus, they are all one address, and can be "ignored" by the network/wallets, which gives the miners the work/jobs.

It is not difficult to "record the last 9 addresses from the blocks creator", and if all 9 are the same, you ignore them and look for another chain to "build on". (Since that would be a fake one.) Or, in the event that it is all from "one pool", thus, "one address"... that forces any other miner to make the next "single" block... Which could be the pools "other wallet", which would never be noticed, by anyone other than the network.

I am not 100% sure, but I think you are absolutely wrong. Every miner can have thousands of addresses. (in fact, I do with BQC)

If I mine 20 blocks, with a new receiving address of the mined coins every time, how the hell could you (I mean your program, the 49%) know that I'm the same person? There's no link between the addresses.

[ISAWHIM]

I am not 100% sure, but I think you are absolutely wrong. Every miner can have thousands of addresses. (in fact, I do with BQC)

If I mine 20 blocks, with a new receiving address of the mined coins every time, how the hell could you (I mean your program, the 49%) know that I'm the same person? There's no link between the addresses.

You don't select the "wallet address" to mine with, unless you use multiple wallets. It is the wallets address, not an address you normally see. (The change address I believe.)

Even still... you can not "manage" multiple blocks as one chain, from one client. The way you "dominate" is by having a HUGE army of more than 51%... you would need two of those, to build up a chain with two addresses. The point is, it is a 51% attack, thus, all blocks are one of those addresses. Detecting orphans is instant... If YOU mine and it shows as a "transaction", but there is no actual transaction... that was an orphan block... You have to use the command-line to find that actual transaction, it does not display in the GUI list. That is when you "check the block-stack", to ensure there is no double-spend. If there is, you throw out that block-stack, and get a new one from some other client. (It should be doing that anyways, but it just keeps building off that same source-block, trying it over and over, and failing... Orphan after orphan... Unless it is actually building on the "real block", which will later become non-orphaned, and just show-up in your wallet at that point. But it never tells you... Invalid chain detected on network, building on new chain. or ignoring invalid chain. "Thus, reassuring you that your orphans are not just wasted processing time.")

If he/she HAS to get a new ID in the block-stack, that is not his/hers... that instantly invalidates the "fake chain/block" they created. It only LIVES if they are able to keep stacking onto it, with machines they own, using the same ID. EG, no solo miner (single machine) could ever attack the network this way. (I solo-mine, with all my machines, on one wallet, thus, I am my own pool. I could do this with 25%, not 51%... but it would not last long enough to do real damage. )

[coinerd]

I'm not sure if I'm confused, or you are.

The coinbase is associated with an address, the block chain has to know who has the coins. It's only (a quirk) at the wallet end that you don't see any address.

Or you can, as p2pool does, write your own coinbase to include multiple addresses.  There is more than one way to get the actual "Required" information from the server, and the miner can actually write the blocks how they like.  I think you could even make it generate valid blocks for an address you don't own.

So, identifying the creator of the block by the wallet or address associated with the block is not, as far as I know, reasonable.

Besides, someone like you could just use a wallet for each machine, and instead of mining "your own pool" you will be "5 miners" or however many machines you have.

My BIG confusion here is that I don't understand how, after everyone goes off and mines, say 8 blocks, we all re-org back into a single block chain. Sounds like a dead block chain forking itself every time a new miner logs on - a sort of crypto-chicken with it's head cut off.

[ISAWHIM]

Additional addresses in a wallet, are just that... additional...

The first one generated, is NEVER shown to you... you only see the 2nd one, which displays in the list of address.

The hidden one (not sure if there are two hidden ones)... holds your "CHANGE" and your "Miner receipt address", if you mine. Change is what happens when you spend 0.5 from an address that has 1.0 coins. It spends the whole 1.0, but returns/moves the other 0.5 to your change-address, which is instant. (You only see the end-result, of 0.5 spent) That is how you end-up with a lot of "dust", which causes things like your next 0.5 transaction to be built off the many change-address coins, to total 0.5 from 0.000121, 0.02122, 0.011223 etc... suddenly asking you to pay a fee of something crazy, like 0.04238 to send it, because it is merged from all those mini-change addresses you don't see.

However, I believe the mining address is only one address, used over and over. (That is what I see in my mined blocks. Unless I am seeing a psudo-address in the blockchain.. I never tried sending coins to that address, for fear it night break my miners or my wallet, since I think it only "expects" that address to contain the "block reward".)

In any event... it should be detectable in code, as it is visually by us... and acted upon, by the network itself... As opposed to the half-assed solution of... let it build until it can't be sustained, and then fall and collapse... without telling the miners if they are on the good-end or the bad-end of the chain. It is detectable, because it can be invalidated, or it would remain in the chain, and never have caused an orphan in the first place.

Naturally, they only survive a few blocks... Thus... the imposed suggestion of the forced "8" limit...

[vinne81]

Additional addresses in a wallet, are just that... additional...

The first one generated, is NEVER shown to you... you only see the 2nd one, which displays in the list of address.

It is an address like any other. It can NOT be validated or traced back to a certain user.

Seriously, if one would want to do a 51% attack, don't you think they would be able to make minor modifications to the code? So that the "first" address is just a random address they generated, to which they hold the private key?

You are talking like this software is "as is". It's not. It's open source. People can make changes.

I really  think your plan is totally impossible, and you are describing how a normal compiled bitclient works. One could easily change that and still generate good solid, untraceable blocks.

[ISAWHIM]

It doesn't matter if it is traceable... they are all held by the same person... and invalid... thus, why they do it. It is detectable, because it always fixes itself. It would not matter if they used a custom program, they are not the only ones mining, and us, with the valid programs... would not be assisting them.

However, the end-result is that miners leave, prices fall, the market gets damaged, and we all loose, not just the person they scammed out of the double-spends.

Ok, I have added all I can add...

Anything beyond this point is just me adding confusion. lol...

Hopefully someone will see this, and it will trigger something in the dust-factory, that can be implemented, or discredited from implementation, in the future. Until then, I am back to being at the mercy of mining blind, with no indication whether or not my efforts will actually be paid-off for mining. (Switched to another coin for now... let the rest loose or win, at the programmers expense.)

You would think the pool-operators, making all this money would spend less on glitter and glow, and put more directly where it benefits them the most... into preventing and stopping losses from this crap. As a solo-miner, I just move to another coin.