 Show Posts
|
|
Pages: « 1 [2] 3 4 »
|
|
Sounds like a great idea.
Would this MAIT be p2p? For example, you would use some API to send your transaction "to the MAIT". Do you mean that you would send it to a miner in the MAIT, who would then propagate to all the other MAIT members, but withhold it from other miners (not MAIT members) so that only the MAIT members would get the fees from it?
Also, when you say that a miner who breaks the rule can never be part of the alliance? How does the rest of the network know which miner mined the block? For example, if I'm part of the alliance, but I mine a block that includes a transaction which overwrites a MAIT-approved transaction and submit it through Tor, how do they know which (if any) MAIT members to kick because they broke the rules?
|
|
|
|
|
That's a good point. 2^32 is 4,294,967,296, so what happens if a pool with 4GH/s go through all possible nonces and none of the corresponding hashes are below the target?
|
|
|
|
You know I had one but sold it. Unfortunately that will not speed up block reindexing.
It won't? Dang. I really hoped buying a UPS would help the computer. Wouldn't it make the computer feel more secure in it's power supply and therefore go faster and not be scared of a distupred power supply or (god forbid) a power surge of 0.1 volts?  |
|
|
|
|
If all you have is dust, then you will use dust.
That sounded inspirational.
|
|
|
|
How about instead of rejecting the block when it doesn't have at least 50% of the unconfirmed transactions you know of, you just don't relay it?
Can of worms there. You would have a solved block discarded which contains dozens of transactions which people have been waiting on for a confirmation? Also, a spammer could immediately cripple the network by generating loads of new transactions. A few weeks ago I saw over 12,000 unconfirmed on blockchain.info, most were not legitimate. Only 2400 (on average) fit into the current block limit. Hmmm. I suppose so. |
|
|
|
Start with a string that's roughly what you want. Base 58 decode it. Delete the last 4 bytes, call the remaining bytes s. Hash s twice with SHA-256. The first four bytes of that are your checksum. Append the checksum to s and base 58 encode it.
Thanks! Worked for me. 12345678912345678912345678913HPoG2 Dang! Nearly one whole bitcoin in that address. Such a waste. Someone needs to make a quantum computer to figure out the private key and put that money to some use! x.x
There's even more in this one: 1111111111111111111114oLvT2 Some algorithms apparently think that the RIPEMD-160 of their public keys is zero... Tsk-tsk. |
|
|
|
As of Jan 03 2009, Satoshi mined the genesis block.
Congrats on your 1000th post! |
|
|
|
That address would actually take billions of years to generate, it's valid, but the creator most certainly doesn't have the private key for it. However, take a look at https://bitcointalk.org/index.php?topic=25804.0If you want to create an address exactly like that, sorry, I can't help you. I know I can't make one where I have the private key. I just want a public key that works, like him. (I mean just make a public key with the correct checksum)
|
|
|
|
|
We all know his address, right? 1BitcoinEaterAddressDontSendf59kuE
I want to make one of my own. (I mean just make a public key with the correct checksum)
How do I make the checksum work?
|
|
|
|
|
That looks like something which would need hardware implementation...
|
|
|
|
|
I think DannyHamilton is right. If a non-empty block is mined right now, then the time distance from now until the next non-empty block is (which will include your transaction), on average, 10 minutes. If an empty block is found in between, then it's still 10 minutes.
If a miner has just mined a block which includes your transaction, and is about to broadcast it, but then it receives an empty block, it doesn't say "Oh dang. Someone found a block. Now I have to wait another ten minutes until I'l allowed to mine another block. Better shut off the ASICs until then so I don't waste electricity" No. It just keeps on mining and will mine a block with your transaction much sooner than that (on average, because it's already been mining for a while).
|
|
|
|
|
How about instead of rejecting the block when it doesn't have at least 50% of the unconfirmed transactions you know of, you just don't relay it? Then you don't need 51% of the network to follow this new rule. Also, this rule may vary from node to node. Some nodes might have a ton of unconfirmed transactions they know about, so they reject a certain block that contains just under 50% of them, but the other nodes don't know about as many of those transactions, so they accept the block. (This is rather rare, though. The amount of unconfirmed transactions that each node knows about should equalize as transactions propagate) Those nodes could then fork the blockchain. Having it accept but just not relay those problematic blocks would solve that problem.
|
|
|
|
I think nodes/miners can have the power to reject such blocks that bother the whole system.
+1 |
|
|
|
Okay. The OP linked to a page which was all about timing attacks and how nodes used their time to verify blocks, and how to skew that. Then he suggested doing it while a fork was in progress. Which would accomplish absolutely nothing. It's a bag of facts with no purpose, this was why I said the moon wasn't made of cheese. You are not a llama, so where is my million dollars? One thing does not follow from the others. A bunch of truthful preconditions doesn't make the following text sensible. Then you said that this was confused, and said that node times were only used in "what it puts in it's own blocks", which wasn't correct (as you just agreed), which I then pointed out. No, my response was in context. For the purpose of the hard fork rule a node's time is irrelevant except for what it puts in its own blocks. The hard fork rule is evaluated only based on the data in the chain ("blocks with timestamps <X are only allowed to be <Y in size") not based on the receiving node's time. Oh. I see. You were referring to the hard fork rule and not to the linked page. I misunderstood, sorry. |
|
|
|
If it's not profitable to add a transaction, then it is time to stop mining completely.
Hmm. What if you already have a ton of transactions which will give you a lot in fees, but takes up the whole block? Then a big transaction with a small fee comes along. It wouldn't be profitable to add it, but you definitely should keep in mining for the reward... I think you should keep on mining even if a unprofitable transaction comes along. The cost to mine a block does not increase with additional transactions, so each transaction increases revenue without increasing cost.
Yes, but only if there's extra space leftover in the block. The cost to mine a block does not increase with additional transactions, so each transaction increases revenue without increasing cost. You're not accounting for orphan risk. Orphan risk is fairly constant, and I don't see how it would go up when you add new transactions. |
|
|
|
Also, is there an algorithm that can decide what the best thing to do would be when a new transaction arrives (add it to the block and maybe boot some other transactions off, or save for later)? I believe if you used the "greedy algorithm", you would need to just do the whole calculation over. Also, if it's not profitable to add a given transaction to the block now, will it ever become profitable to add it later? The only case I can think of when it would be profitable is when there is just a tiny bit of space left over and this is the only transaction that would fit.
|
|
|
|
Would it be possible to make it so you can tell it which transaction should be broadcasted to which node? |
|
|
|
Don't you just line them up in order of fee per kb, then put the largest fee per kb ones in the order they are?
That's the "greedy algorithm" that gmaxwell mentioned. There's apparently an optimal-er solution that's NP-HARD. Isn't the greedy algorithm the best though? Since you're trying to get the most money out of it? Apparently not, according to gmaxwell: A simple greedy fill in terms of fees per KB (profitablity) does pretty well so long as transactions are small relative to the block-size.
Actually "optimal" selection is NP-HARD. If you have an effectively infinite number of every kind (profitability) of transaction then you can use dynamic programming to optimally select the transactions. There is an approximation to the optimal solution which works by rounding off the profitability to varying precision in order to create a sub-problem which can be solved in polynomial time, and I believe there is some proof that doing this is optimal to within some factor of the rounding relative to the total profit. ... but really, no one will bother, a dumb greedy solution is almost certainly good enough.
I also thought that greedy would be best, but it makes sense that there is a better possibility sometimes. |
|
|
|
Don't you just line them up in order of fee per kb, then put the largest fee per kb ones in the order they are?
That's the "greedy algorithm" that gmaxwell mentioned. There's apparently an optimal-er solution that's NP-HARD. |
|
|
|
|
By a "greedy fill", does that mean that miners will add the transaction which has the most fees per kilobyte, but will still fit in the block?
On average, how much better will the NP-HARD algorithm be? Would it be worth the computation time?
Also, is there an algorithm that can decide what the best thing to do would be when a new transaction arrives (add it to the block and maybe boot some other transactions off, or save for later)? I believe if you used the "greedy algorithm", you would need to just do the whole calculation over. Also, if it's not profitable to add a given transaction to the block now, will it ever become profitable to add it later?The only case I can think of when it would be profitable is when there is just a tiny bit of space left over and this is the only transaction that would fit.
|
|
|
|
|
