Bitcoin Forum
June 16, 2024, 10:47:40 PM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Economy / Services / Re: I pay you to fix my PHP (MySQL error) :: 0.10 BTC bounty on: September 26, 2013, 01:17:14 PM
You need to check the value of $this->query = mysql_query(...) and if it indicates an error then print mysql_error() to see what went wrong.

You should also check the returns of mysql_connect() and mysql_select_db().

And I really hope you're using escape(). :-)
2  Bitcoin / Bitcoin Discussion / Re: What will happen when the 21M bitcoin will be minned on: September 24, 2013, 05:22:59 PM
So let me ask again, what will happen to the value of Bitcoin when There's no more Bitcoins to mine?  TIA

Mining rewards decline so gradually that any effect will occur long before the last satoshi is mined.

When the reward went from 50 to 25, what happened to the value as a result of that? Did it even matter?

I think the only way it matters is if mining is over-centralized and the fairness of the system is undermined.
3  Bitcoin / Bitcoin Discussion / Re: Coin melting: how hide transactions from network analysis on: September 24, 2013, 04:33:57 PM
If you have 1/4 of the hashpower today, you will try to remine (fork the chain) when there is a fee of 2R or 50BTC.  At 5% of hashrate, this gives a cutoff of 18x the reward for when it becomes possible to backtrack.  Traditionally we have always had a pool or two floating at around the 1/4 level.  Therefore when the fees approach ~ twice the reward (and they will eventually if the network stays alive) this will become a problem!  
 

I think you are right in all elements but may have slightly misstated this?   Would it be better stated that this will be an incentive problem whenever the fees+reward approach ~ twice the average fee+reward?  
It seems it is less of a problem of just fees>reward*2 which is expected to become very common indeed.

The assumption was that the average block's fees are much smaller than the mining reward. When the fees become more significant the calculation must include the expected value fees lost. Instead of F>2R, you'll be looking for F>2R+2F_avg. As R approaches zero this inequality becomes easier to satisfy.

We're probably still off by an R or an F here or there. And we haven't even discussed the scenario when R_1 = 2R_2 (when R_1 is the last block to receive 25BTC).
4  Bitcoin / Bitcoin Discussion / Re: Coin melting: how hide transactions from network analysis on: September 23, 2013, 02:43:08 AM
A solo miner (or a pool operator if they keep the fees) can use large transaction fees to avoid taint and network analysis. These algorithms must be updated to include transaction fees.

No, they can't. You just extend the taint-tracking through the newly minted coins (e.g. if you try to "melt" 75 BTC with the 25 BTC reward, then the resulting 100 BTC should be considered 75% tainted).

The taint-tracking and network analysis algorithms are the ones I'm referring to as needing updating. Not bitcoin itself.
5  Bitcoin / Bitcoin Discussion / Re: Coin melting: how hide transactions from network analysis on: September 22, 2013, 01:31:48 AM
Such melting can't be done safely by a small pool, coz a bigger pool can make an attempt to "remine" the block and collect the fees by itself.

Such a counterattack has a known benefit and a computable cost. There's the opportunity cost of spending hashing power on trying to orphan a block rather than confirm it.

Would the current block reward be the simple upper limit on "safe melting" or is it more complex than that? I think it would be significantly more than the block reward and it would depend on the attacking pool's mining probability. A pool with 5% of the global hashing power might improve their odds by trying to orphan a block (remining the non-broadcasted transactions for their fees) when it would provide over 40x the next block's reward otherwise.
6  Bitcoin / Bitcoin Discussion / Coin melting: how hide transactions from network analysis on: September 21, 2013, 02:58:40 PM
A solo miner (or a pool operator if they keep the fees) can use large transaction fees to avoid taint and network analysis. These algorithms must be updated to include transaction fees.

Re: 1CfsAiYaVfk12dnZpZALcRSP9jjWDk26FX - Stop making transactions!
Until I saw that the block was mined by a pool that pays out transaction fees I thought this would be somebody trying to hide transactions from network analysis.

You can mine a block containing transactions you haven't broadcast. So you can keep your own transaction fees, effectively transferring arbitrary sums to addresses where no actual transactions exist between sender and recipient.

There are plenty of miners with sufficient hashing power to solo mine and get a block every now and then.

blockchain.info seems to ignore transaction fees in its taint analysis. Are there any network analysis tools that treat mining fees as transactions?

"Coin melting" is awesome.
7  Bitcoin / Bitcoin Discussion / Re: 1CfsAiYaVfk12dnZpZALcRSP9jjWDk26FX - Stop making transactions! on: September 20, 2013, 09:21:47 PM
Until I saw that the block was mined by a pool that pays out transaction fees I thought this would be somebody trying to hide transactions from network analysis.

You can mine a block containing transactions you haven't broadcast. So you can keep your own transaction fees, effectively transferring arbitrary sums to addresses where no actual transactions exist between sender and recipient.

There are plenty of miners with sufficient hashing power to solo mine and get a block every now and then.

blockchain.info seems to ignore transaction fees in its taint analysis. Are there any network analysis tools that treat mining fees as transactions?
8  Bitcoin / Development & Technical Discussion / Re: BIP 0021 usability enhancement for paying tips in restaurant/bar conveniently on: September 10, 2013, 05:01:29 PM
As long as we're talking about URIs containing multiple recipients, why make it specific to tips?

See http://sourceforge.net/mailarchive/message.php?msg_id=30882263 for a more general sendmany URI pattern.

See https://github.com/skeltoac/bitcoin/tree/sendmany for bitcoin-qt patched to support the above pattern.
9  Other / Beginners & Help / Re: Get me out of here (I have a pull request to discuss) on: September 09, 2013, 01:04:53 AM
That's what I read. Just starting the clock is all.
10  Other / Beginners & Help / Get me out of here (I have a pull request to discuss) on: September 09, 2013, 12:58:52 AM
Chatted in IRC #bitcoin-dev a couple of weeks ago about BIP-0021 and making sendmany URIs. A few months back I brought it up in the mailing list but got no traction. Now I realize bitcointalk is the right place since others are proposing less-general solutions for the same problem. I have a working bitcoin-qt patch that accepts URIs with multiple recipients.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!