 Show Posts
|
|
Pages: [1] 2 3 »
|
Even if miners agreed with you (and >50% of the hashrate belongs to miners that don't care about Bitcoin at all), Maybe, but even those miners care about their mined coins being worth something in $. that would be too dangerous a precedent to set. I get what you're saying, but if it always takes 50%+ of the network to make things like that happen, where's the danger? This is democracy in action. |
|
|
|
remember noobs, selecting tx based on fees is straight forward.
Other than that, you're just fcking around without knowing jack about TXs.
Actually, I wrote my own python-based bitcoin client a year or so ago. and that's all I have to say about that. |
|
|
|
No I wouldn't. If people find out that bitcoin can be manipulated by a group of people it would just do harm. It can be "manipulated" if and only if 50% of miners decide that it's desirable. I don't see this as manipulation, I see it as miners being aware on a large enough scale of what makes bitcoin work and acting in its interest. It's basically voting with your hashpower. How would you know which are SR coins?
I thought the address they confiscated was already known. I could be wrong. so all it would do is delay it. No. Mining pool #1 makes a 2 block long addition to the blockchain that includes the tx, mining pools #2 and #3 make 3 blocks in the same time that do not contain the tx, everyone's client chooses the longest chain (chain #2), tx doesn't get into the blockchain. so tx's are already being hand picked allowd/disallowd based on pool miners preference. which in luke jr's case is greed. but that does not make it physically impossible to make it done for other reasons. Actually, "greed" works in favor of what I proposed. If we knew with certainty that the bitcoin price will tank after the auction, miners would definitely have an interest in stopping that tx in order to protect their profits, and in doing that they would also be protecting bitcoin. |
|
|
|
|
So, earlier I was thinking about the SR auction situation we have now and I had a few thoughts that I'd like to discuss.
As one of the people who joined the network because of their libertarian values, the auction bothers me because
1 - It might cause the bitcoin price to plunge if one or more of the groups that win the auction sells their share or part of it.
2 - Even if the coins sell at $250 each, the government that basically stole them still gets to be $7 million richer.
I was thinking about ways to stop this or at least make those coins worth less, and my mind went back to ideas that were proposed before, like merchants blacklisting coins from "tainted" addresses, which would need a lot of people to sign on, making it impractical.
Another was a hard fork with an alternate blockchain where those coins are unspendable. Again, this is impractical since, unless it becomes the main chain, the fork coins would need their own exchanges and merchants and so on and judging by the forums, most people don't care enough about this issue to go through the trouble.
Finally, I had my third idea. I am sure this was proposed before in other situations but the timing couldn't be more right for it.
Mining pools like Ghash.io could refuse to include any transaction spending those coins in their blocks. If 50% or more of the miners believe it would be a good thing for bitcoin if those coins are never spent then we could easily collectively choose to keep them where they are.
I realize that I might be too late proposing this solution, but I thought I might as well put it on the record in case there is still time or if something like this happens again in the future.
To test that last idea, I added a poll (for miners only). The question is this:
If you could switch to mining a blockchain that treats the SR coins as unspendable in just one easy mouse click, would you?
Keep in mind: mining that chain would only be profitable if 50% of all other miners do the same.
|
|
|
|
|
How about this,
Transaction #1: moves some coins from one of your addresses to a new address (the "my end" address), includes a comment in scriptPubKey using OP_DROP (could be your vows for example).
Transaction #2: moves some coins from one of her addresses to a new address (the "your end" address), includes a comment in scriptPubKey using OP_DROP (could be her vows for example).
Transaction #3: takes the two previous transactions as inputs, outputs to a 1-of-2 multisig address (or 2-of-2, depending on your values and the strength of the relationship). The "binding" transaction.
|
|
|
|
 Price vs cumulative usd volume. Volume (horizontal distance) is the same between highs and lows (marked with vertical lines). Apex at 1.4 billion dollars traded on MtGox. Symmetrical Continuation Triangle - Trending123Generally, a triangle pattern is considered to be a continuation or consolidation pattern. Sometimes, however, the formation marks a reversal of a trend. Converging trendlines of support and resistance gives the triangle pattern its distinctive shape. This occurs, Kahn explains, because "the trading action gets tighter and tighter until the market breaks out with great force." Buyers and sellers find themselves in a period where they are not sure where the market is headed. Their uncertainty is marked by their actions of buying and selling sooner, making the pattern look like an increasingly tight coil moving across the chart. What do you guys think ? Which line do you think bitcoin is going to break ? I think it's interesting how the distance is the same between every high and low so far (the lines are not the same distance apart on a time graph). The chart seems "organic" and what you'd expect in a market with many people each holding a small amount. This is the first time that I'm trying my hand at TA, so be nice. |
|
|
|
I thought the same thing before and came up with a few ideas on how this can be done. The problem, basically, is that the data in the blockchain is already very dense. I remember doing a few tests and finding out that it can't be compressed to less than 60% of its size. For anyone who's interested, these are the ideas I had: - Replacing the previous block's hash with the current block's height in the block format, saves 28 bytes/block, 6 megabytes overall, almost nothing.
- Removing the Merkle root, can be deduced from the transactions in the block, saves 32 bytes/block, 7 megabytes, almost nothing.
- Replacing the previous output field in each input with the output's block number and its transaction's order in the block, saves 26 bytes per input. assuming 1 input/transaction, and going by blockchain.info's 17000000 transactions, this would save 431 megabytes.
- For 99.999% of outputs, there are four bytes (OP_DUP,OP_HASH160,OP_EQUALVERIFY,OP_CHECKSIG) that can be removed (i.e. they would be "implied" in the compressed format unless otherwise indicated). again, assuming 1 output/transaction, this would save 68 megabytes.
- Repeat uses of the same address. If the average address receives 5 payments, then 4 of those five can be replaced by a reference to the first time it appears in the blockchain (4-7 bytes long). With each address taking up 20 bytes, this saves 13 bytes per repeat output (4/5th), possibly another 172 megabytes.
With the current blockchain taking up 9 GIGABYTES of disk space and taking weeks to be downloaded and verified, this doesn't really change anything. The size of the blockchain is a fundamental flaw in bitcoin and nothing is going to change that. It just happens to be the best technology we have now, but the moment something else is invented that has the same advantages and fewer drawbacks, bitcoin will be wiped out. |
|
|
|
Ummm... I don't know if anyone pointed it out yet, but the transactions (at least the ones scintill mentions) were included in blocks #230229 and 230231, more than three weeks ago, about a day before the crash. (coincidence?) Also, since I'm here, might as well link my own thread on the subject https://bitcointalk.org/index.php?topic=128171.0edit: quote from my OP there Price tanks, I make a heap of money by going short beforehand. |
|
|
|
I share Luke-Jr's view that hardforks should usually have two years of advance notice, but this hardfork is definitely necessary sooner. The behavior of old nodes is closely tied to the behavior of BDB: the limits are not on the number of transactions or bytes, but on database-specific things which aren't easy to track. Without this hardfork, all full nodes would be required to either use BDB or come up with some very complicated heuristics (which don't currently exist) to guess at what BDB would do. Even worse, old nodes don't always have consistent limits. It isn't reasonable to leave the network in this messy state for two years.
Okay, it makes more sense to me now... (still uncomfortable with the whole thing though) anyway, thanks for explaining. |
|
|
|
Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing.
Dude, several chains would make things super confusing. Bitcoin is already hard enough to understand for new people, do you want them to have to learn how to segregate different chains as well? It's already pretty easy. Just run a client/version of a client that is incompatible with the chains you don't want. So if 99% of the hashing power makes 0.8 blocks after May 15 but there's still 1% left making an 0.7 compatible chain all the 0.7s will tune to the second blockchain automatically. At least that's my understanding. Except it's already done. The vast majority of the mining pool hashpower has already switched. The miners flushed somewhere between $500-$1000 of mining revenue down the toilet to buy time for people to update in a more orderly fashion, you can be pretty sure they won't do it again. Miners won't risk being on the wrong side of a fork.
When a miner with nefarious figures out that they can knock the un-upgraded miners off the main block chain by deliberately creating one of these blocks and that they'll get a larger share of the mining rewards as a result.. *somebody* will do it. It's just a question of when. It probably won't fly before may 15th, but it'll be game-on after then. I think there's an agreement between everyone involved that the pools won't make 0.7 incompatible blocks until May 15. I was just saying that technically what the announcement said wasn't true. Because bitcoind 0.7 can be configured generate a valid block that can cause other bitcoind 0.7 instances to overflow their lock tables and drop the valid block. Why would anyone generate such a block ? |
|
|
|
0.7 can in fact create blocks that 0.7 will reject. By increasing the number of locks, 0.7 will create the very blocks other 0.7 clients would reject. Both statements are therefore true.
What does set_lk_max_locks do ? and why didn't we have this problem before people started mining on 0.8 ? |
|
|
|
I think an intentional fork is exactly what we need right now. At least to have something to come back to as the main bitcoin becomes less and less attractive.
Are you saying you want 2 blockchains going? Your wording is a little confusing there. Yes. meant to say if/when the main bitcoin etc... It would be better than having only one blockchain going in the wrong direction. Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing. |
|
|
|
Two more problems I have with that announcment, Miners/mining pool operators
And if you are creating blocks and cannot upgrade to version 0.8.1 for some reason, you should not set_lk_max_locks in a DB_CONFIG file until May 15th; if you increase locks before then you run the risk of creating or building on blocks incompatible with the rest of the network. Correct me if I'm wrong, but this is not exactly true, is it ? If enough miners decide to start mining an alt blockchain now that is only compatible with the 0.8's there will just be another reorg on May 15 and their chain will become the main one. They actually stand to benefit from this. Why this is necessary
A bug caused a temporary block chain fork on 11 March, 2013. After investigating that bug, we determined that the bug can happen even if the entire network was still running old versions of Bitcoin-Qt/bitcoind. How ? |
|
|
|
|
I agree with what everyone else said about the wording.
Also, I think our benevolent dictator dev(s?) decided the only thing they can do to push this (unnecessary) upgrade is to use stronger language without giving any reasons or details, which is comforting to me tbh.
Bitcoin is not decentralized until it's working like an actual protocol with multiple clients and possibly blockchains. Right now there's only a handful of people who understand the (undocumented) source code and who are writing its future as they see fit. This cannot be good.
I think an intentional fork is exactly what we need right now. At least to have something to come back to as the main bitcoin becomes less and less attractive.
|
|
|
|
Been meaning to do this since The Night of the Two Chains, finally got the time to do it today. A list of all transactions included in the .8 fork but not the (current) main chain. i.e. possible double spends. 270 transactions out of 11914 fit that description (2.26%). (got the data from here, for some reason that page doesn't work anymore) I might go through all of these later and try to find any "special" ones. For now though I have to study... : / p.s. sorry for the huge post. [spoiler] tag not working. how do I spoiler stuff on this forum ? |
|
|
|
Of course if the total number of users was 10x higher, each fork could have more people using it and more money flowing through it than the current system does. I'm not sure that would be a failure.
Agreed. Each network would only have to process and keep track of a fraction of the total transactions. This could actually be better for bitcoin. It's fun to speculate about this. What if the networks start specializing ? The 10Mb network would be less decentralized, slower, and more expensive to run with 10 times the needed bandwidth and disk space to keep track of hundreds of people betting their $1. Most blocks would have a lot of low value transactions with small or zero fees. The 1 Mb network on the other hand would handle all the serious money flow with less overhead. |
|
|
|
So if you had assets on each chain or the fork, residing at the same respective addresses, you would have to spend the simultaneously to avoid getting ripped off on the one of the chains? I guess it would be a race down to the millisecond. Someone would have software and a high speed connection tapping into both networks and attempting to take advantage of the smallest delay.
I suppose if this is true there would still be a way around it. Send the coin to a different address that you own on each chain, wait for it to clear, wait a few blocks to make sure you're on the respective "main chains", then proceed as usual, all new transactions on each network would reference an output that doesn't exist on the other. |
|
|
|
Correct. That's comforting... Nothing.  Well, thanks for explaining. |
|
|
|
You need consensus if you want to implement a "forking" change without actually causing the blockchain to fork into two incompatible systems. If you actually WANT to cause the blockchain to fork into two incompatible systems, you only need a single miner willing to mine the forked blockchain (although the more distributed the mining hash power is, the more secure your minority fork will be) So, as long as 2 people want for a 1MB fork to exist, there's nothing to prevent it ? To transmit a transaction, you need specific outputs received at an address to spend. This means that bitcoins that were received prior to the fork will be spendable on both forks, while bitcoins that are received after the fork will only be spendable on the fork where they are received.
I meant, say I have an output that exists on the pre-split part of both block chains, and I spend it on one network, sending it to someone else. What's to prevent that person from rebroadcasting that tx on the other network as well ? |
|
|
|
|
I agree. I've been thinking about this, here's what I'm at right now,
As long as the block chain *does* fork, everyone's coin also forks with it, right ? so people can just sell their coin on one chain to buy more on the other if they want to. Everyone is satisfied.
Two problems I can think of though,
1- what if the fork doesn't happen for some reason ? I don't know what would prevent it from happening but people on other threads are saying it needs "miner consensus". I would appreciate it if someone can explain this to me.
2- This could be a silly question, but is there something to prevent someone from taking transactions from one chain and rebroadcasting them on the other ?
|
|
|
|
|
