Possible exploit: A chain made in secret with double-spends could absorb blocks from the main chain, allowing an attacker to overtake the main chain with a mere fraction of the hashrate and a little luck.
I'm not sure this will work. You'll have a rule saying that the parent with the most PoW contribution is scanned first (and continuing in descending order). So when the attacker absorbs blocks from the main chain, he needs his side chain to be larger if he wants his double-spend transaction to be included. I haven't worked it out but it might turn out that to succeed in the end he needs >50% hashrate. Of course there's a lot that needs to be thoroughly investigated, but I'm still not convinced my way fails. Proof by counter-example: Assume the attacker gets lucky at some point and finds two blocks in a row. They normally find blocks every 6 "-", while the main network finds blocks every 4 "-", thus the attacker has 33% of the network's hash rate. Number indicates total proof-of-work. Attacker:
|------2--3--------6-----------10-------12------15
| / / / / / / / / /
|----1----2----3----4----5----6----7----8----9
Main:
With conflicts resulting in unusable blocks... Attacker:
|------2--3--------4-----------5--------6-------7
| / |(control regained)
|----1----2----3----4----5----6----7----8----9
Main:
As you can see, in this example, the network regains control from the secret blockchain after 3 blocks (WITHOUT EVEN KNOWING ABOUT IT!), whereas if the only restriction for merging was having a longer chain at the time, the 33%er would likely keep secret control of the blockchain for quite a long time. How will rewards be handled? Seems the most reasonable way is that only blocks on the main chain get generation rewards and transaction fees. This has the disadvantage that mining rewards will be less predictable because of the high orphan rate. Also might be an opening for denial-of-reward attacks.
I don't see a reason not to credit transaction fees. I talked about this on the OP of this thread: That's a good point. One requirement of merging might be that the coinbase of the block that is doing the merge must also credit the same coinbase out scripts from the absorbed blocks with the transaction fees. The only problem with that, however, is what do you do about Eligius? You'd have to require that coinbases can only have one output. You can't credit the whole block reward, because if the difficulty goes up, people would just mine off of older blocks and hope that they get merged. Orphan blocks MUST be practically worthless. That being said, when there is no more block reward, the same difficulty manipulation could be used to get just the transaction fees. Thus, we are left with two choices (both of which are good): 1) Require crediting transaction fees (doing this for the block reward would be a breaking change to the protocol that requires 100% of nodes to upgrade) to the absorbed block's miner if, and only if, the block was mined on the same or higher difficulty. 2) Don't credit anything. (works much better with the existing code) To add to this, crediting the full block reward, assuming the difficulty is the same or higher and that the block would be taken into consideration when calculating the next difficulty, would be a GREAT idea for the next Bitcoin. Here's why: It successfully solves the problem of interplanetary mining. Think about that. The only issue remaining is to solve the double-spend issue with the lag, and I have some ideas in my head for that. Unfortunately, this just made me think of a DANGEROUS exploit against my scheme. An attacker could store up orphan blocks that they mined in order to include them later in a conflicting chain. This can be mitigated by setting my X to a low number, say 2-6. (20-60 minutes worth of blocks on other chains) HA! I'm stupid. The miners just need to "discourage" the blocks from the new chain internally long enough for somebody to make a new block that adds those newly released orphans. Then, the main network has full control again. In fact, clients don't need to even indicate that there's potentially an issue to the user if the orphan came out of nowhere, but before a chain split due to invalid blocks. It's only a temporary problem for anyone who happens to choose just then to sync up with the network, so we'd just have to tell people not to trust full clients that have just re-synchronized to the network. Problem solved. X is back to whatever. When a mining client receives a VALID, unused orphan block/blockchain that connects to the main chain somewhere in the last X blocks (where X is a number that I haven't really decided on), What's the interest of having a X maximum block delay for merging? Wouldn't it be interesting to allow miners to intentionally branch blocks deep in the past for some reason, like spending an old output with an easier difficulty? I don't see any problems with that. Originally it was to prevent block spam and to allow pruning, but as you see above, it's now more important than before. Anyway, this now needs more of an explanation. After a certain number of blocks when you're at the point where you are completely confident that there will never be a chain split that reaches that far, the additional orphans are useless. Thus we can prune them. It would be best for the network if there was a hardcoded point where they would be outright rejected, but it doesn't matter. Your usecase is interesting, though. It would allow you to spend those coins without a transaction fee, since no miner would be stupid enough to reject your free additional proof-of-work out of fear that someone else would accept it and invalidate your block. However, I'm not sure that it's a usecase the should be supported. |
|
|
|
How will rewards be handled? Seems the most reasonable way is that only blocks on the main chain get generation rewards and transaction fees. This has the disadvantage that mining rewards will be less predictable because of the high orphan rate. Also might be an opening for denial-of-reward attacks.
I don't see a reason not to credit transaction fees. I talked about this on the OP of this thread: That's a good point. One requirement of merging might be that the coinbase of the block that is doing the merge must also credit the same coinbase out scripts from the absorbed blocks with the transaction fees. The only problem with that, however, is what do you do about Eligius? You'd have to require that coinbases can only have one output. You can't credit the whole block reward, because if the difficulty goes up, people would just mine off of older blocks and hope that they get merged. Orphan blocks MUST be practically worthless. That being said, when there is no more block reward, the same difficulty manipulation could be used to get just the transaction fees. Thus, we are left with two choices (both of which are good): 1) Require crediting transaction fees (doing this for the block reward would be a breaking change to the protocol that requires 100% of nodes to upgrade) to the absorbed block's miner if, and only if, the block was mined on the same or higher difficulty. 2) Don't credit anything. (works much better with the existing code) The only attack I can think of off the top of my head to reduce the effectiveness of this is to send different double-spend transactions to each peer, in the hopes of making any orphans that are created unmergeable. However, this can be reduced if the miners actually choose to communicate with each other and decide which transaction to go with, or use other such heuristics.
This can probably be solved the following way: Decide on a specific order among the parents and scan them in that order. Include any transaction which does not conflict with any previously encountered transaction, but do not invalidate a parent just because a transaction conflicts with one in another parent. NO! ABSOLUTELY NOT! There's a reason I made it that way in the mini-spec. Big picture: A block that doesn't conflict with the chain is a vote for that chain. If something in the block DOES conflict, however, that's clearly a vote for another chain. Possible exploit: A chain made in secret with double-spends could absorb blocks from the main chain, allowing an attacker to overtake the main chain with a mere fraction of the hashrate and a little luck. Unfortunately, this just made me think of a DANGEROUS exploit against my scheme. An attacker could store up orphan blocks that they mined in order to include them later in a conflicting chain. This can be mitigated by setting my X to a low number, say 2-6. (20-60 minutes worth of blocks on other chains) When a mining client receives a VALID, unused orphan block/blockchain that connects to the main chain somewhere in the last X blocks (where X is a number that I haven't really decided on), What's the interest of having a X maximum block delay for merging? Wouldn't it be interesting to allow miners to intentionally branch blocks deep in the past for some reason, like spending an old output with an easier difficulty? I don't see any problems with that. Originally it was to prevent block spam and to allow pruning, but as you see above, it's now more important than before. |
|
|
|
I just realized why we are seeing that consolidation... It is true that we could disclose all of the Bitcoin payment addresses we manage and let everyone look them up and track the lineage of the coins. This is also troublesome due to the way that we defragment small payments to keep the processing engine speedy. Someone, somewhere, restarted the MyBitcoin engine without realizing the implications. Thanks to that process, just about the entire MyBitcoin inventory is clearly visible to us. Thanks to his stupidity, we might eventually be able to track good 'ole Tom down.
I am trying to follow this, but to simplify it, a Bitcoin business of some kind would have to be involved to confirm the identity of a person who is trying to spend the Bitcoin? Is this where Mt Gox comes in? I figured a person would be smart enough to spend the coin on goods and services rather than try and exchange it out for cash in front of everyone's face. Or it is done little by little daily or something. Someone call Bruce or the Bitcoin Police? Or were they doing more damage than good for this cause? You pretty much have it down. We likely won't be able to find much, but he might slip up. He just needs to slip up once. |
|
|
|
Where are you getting the addresses from? And how much did that phony release say they "lost"?
From the non-change of the inputs to the change of the transaction from the OP's first address. Sunday, August 7th, 2011
MYBITCOIN ASSETS AND LIABILITIES DISCLOSURE
Liabilities (Bitcoin) Assets (Bitcoin) Percentage
-----------------------------------------------------------------------------
154,406.34272079 75,666.76066691 49%
With a script (since I won't do it by hand), we could do some accounting on those numbers. Additionally, we'd be able to gather up a large number of the addresses and start tracking them. Thanks to his stupidity, we might eventually be able to track good 'ole Tom down. |
|
|
|
|
Damn, someone REALLY needs to run a script on this. I barely scratched the first connected transaction, and I've already found over 500 BTC in 21 addresses.
|
|
|
|
|
They weren't sent to MtGox. If they were, they would have moved already. I have no idea about that weird consolidation, though. Luckily, it was done so poorly that we can now trace a very large amount of funds. With a script, you could trace each input, as well as the change, to find all spends out of what is known to be mybitcoin from the input and change information. It'd be cool to get a final number, too.
|
|
|
|
|
I hate to bring up the Satoshi argument, but Luke is right. If Satoshi thought that it was better to save a few bytes than to use a standard design, he would have used <pubKeyHash> OP_ADDR1 instead of OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG for the scriptPubKey of a standard address transaction. Worse than that, this is like suggesting that he should have just made it so <pubKeyHash> infers that.
|
|
|
|
Just so it's clear what I'm responding to... 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.)
Dear God. You may have just solved the latency problem. By the latency problem, I'm talking about the fact that an attacker can generate blocks on a low-latency network without orphans, whereas the main network is more likely to have orphans. If this problem is solved, there would no longer be as much risk in lowering the target block generation time to a few seconds. Think about the implications of that for a second. The Finney attack would become almost useless, since you could no longer hold onto a pre-generated block while you spend coins elsewhere. A smart person would still wait for 60 minutes worth of confirmations, but it would definitely reduce the risk of accepting transactions quickly. Here's a quick spec. Interestingly enough, it would be possible to merge it with Bitcoin as a recommendation for clients by replacing certain MUSTs with SHOULDs. However, it would be most effective on alt-chains.
Definitions: VALID - means that the orphan would have passed all block/transaction validation checks at the point where it would have ended up in the chain. The orphan MUST be from a chain that, when you add the orphan, has a lower total proof-of-work than the current chain. Additionally, to prevent an attacker from using this against the main chain, the transactions in the orphan chain (ignoring coinbases, which are discarded) MUST NOT conflict with the current chain. To start, this spec only affects a blockchain's total proof-of-work. All other blockchain rules remain in effect. Assumption: all VALID orphans would have increased the total proof-of-work of the main chain if the network had zero latency. A block would be redefined to allow additional parents. However, there will still be a main parent, just like today. In Bitcoin, this could be added to the coinbase instead of making a new field in the header. (I wonder if the merged-mining format could help here...) When a mining client receives a VALID, unused orphan block/blockchain that connects to the main chain somewhere in the last X blocks (where X is a number that I haven't really decided on), they SHOULD add that orphan as an additional parent to the current block they are working on. Additionally, they MUST(/SHOULD) add all transactions that haven't been confirmed yet to the current block. When a client receives a block with an additional parent, it checks that the additional parent is VALID and connects to the main chain somewhere in the last X blocks. If the additional parent doesn't connect directly to the main chain, the client MUST recursively lookup that orphan's main parent until it finds a block that has either already been merged with the current chain or was part of the current chain. From there, the orphan chain's proof-of-work is added to the current chain. Any additional parents included in the orphan chain are then also processed in the same manner.
This is most definitely more complicated than it's worth for Bitcoin, but it might be useful for an alt-chain. The only attack I can think of off the top of my head to reduce the effectiveness of this is to send different double-spend transactions to each peer, in the hopes of making any orphans that are created unmergeable. However, this can be reduced if the miners actually choose to communicate with each other and decide which transaction to go with, or use other such heuristics. Also, there's a neat side-effect if you require a merge to also include the unconfirmed transactions from the merged chain: an attacker making empty blocks, and thus refusing to do a merge, would be beaten every time a real block is released by an ever-increasing amount of work. Example: (number indicates total proof-of-work) Attacker: 1----2----3----4----5
/ \ \ \ \ \
Main: 0 2----4----6----8----10
|
|
|
|
I do prefer the old algorithm though as with the new one won't all the short prefixes be used much quicker?
Yes, but that doesn't matter. What matters is the depletion of meaningful prefixes. For example, if someone makes 1Locu..., the probability of it also taking the much more meaningful 1Locus by chance (assuming that they really did want just 1Locu) is quite low. That's the beauty of the firstbits working all the way through the entire address. It allows people to generate a longer prefix than needed and have that longer, intended, prefix work forever. In a way, it makes it possible for the algorithm to determine what a person was really aiming for, without ever having to ask them. |
|
|
|
Apparently it used to be 50 posts, not 5.
Only for like two days. That was before it was figured out how to implement the 4-hour time-online delay. 50 posts was necessary to create a proper barrier. If you have ~4 hours of online time and your existing posts are good, then you will be whitelisted on request. There's no need to post any more. So after 4 hours and few posts, you have to ask to be whitelisted, its not something automatic? Its not very clear from the stickied newbie restriction thread. Would be good if this was clarified. It is automatic. I don't see how it could be confusing... |
|
|
|
with the hope that someone on staff or another member helps accelerate this process. If the latter is the case, please PM the proper authorities.
Sincerely, Bruno
I hit 'report to moderator'. That should get someones attention.  It does, but... he was whitelisted for over an hour by the time you sent the report. In fact, I didn't even know about this thread until now. I had just processed the request that was put in the main queue... |
|
|
|
Edit: I would like to request a formal scammer investigation be opened usually conducted by Maged as I have seen it before on here.
I would do that, but since theymos and most of the other mods disagree that Luke scammed his users, the case was closed before it even started. My opinion on the matter, however, is already well-known. |
|
|
|
I guess thank you for asking (well you did not really ask...) me first if I was serious or a troll before you banned me... Wait... you were banned? That had nothing to do with me. I never submitted your name for a ban review, nor did I ever mention anything to theymos directly. |
|
|
|
|
Fine, I renamed the thread to more match what the split topic was about, since I was the one that named this thread in the first place.
As for your complaints about potentially being banned, that was over excessive trolling, not posting off-topic. However, you proved that you weren't trolling after all, so the issue solved itself. Keep in mind, at the time, you were massively derailing a topic and bringing up points that had already been discussed. Had I complained to theymos instead of talking with you at the time, you would likely have been banned for a few days.
|
|
|
|
|
You're overreacting and not keeping a level head. We do the things we do to make the forum more readable. In fact, by complaining about moderation in the Eligius thread, you quite successfully changed the topic at hand from what was REALLY important (Luke abusing his pool's power) to something extremely trivial. Remind me to do that in the future when I do something extremely stupid, because apparently it works. We're not your enemy - Luke is. In my opinion as a user here, he SHOULD be banned and have his pool blacklisted by the forum, but as a moderator I have to keep my opinion out of things.
@Goat, thanks to me, you made a bunch of money. I hope you remember that.
|
|
|
|
I don't have to read anything thing into to it I already know what your fellow mods are up to and it is just plain fucking disgusting that it is allowed to continue to happen.
It's one mod. And no, I don't like it either. The fact that this is the third complaint this month is just disgusting. My only consolation is that, at least 90% of the time, it hasn't been an issue. That being said, I hate drama, so I won't make it my mission to do anything about it. My concerns are well-known. |
|
|
|
Just so people know what this is it is a thread some mod made to take posts from different threads and put them in one place.
I did it to save your asses. If I didn't split this off, you all would have kept this going and gotten yourselves banned. Unfortunately, not so to the mods who systematically remove posts that
simply present factual information about the guy (e.g. his IRC posts).
Post this stuff in a new topic in Off-topic and I very much doubt that it will be deleted. And from what I have seen going on here in the last few days I very much doubt that is true.. No, it is true. The rules outside of the Mining board are much more relaxed. Not to mention, there are fewer mods out here that can decide to delete your posts. Read into that what you will. |
|
|
|
|
The interesting part is that there is a place to enter a gift card on the final order page, AND it's AJAX. That would make it really easy to have the script wait for the gift card code from the server, submit the gift card code, and then submit the order.
|
|
|
|
|
It *WAS* deleted. However, me and tysat petitioned theymos to have it restored and moved.
|
|
|
|
|
Show Posts
