Bitcoin Forum
April 19, 2014, 06:53:14 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 200
1  Bitcoin / Development & Technical Discussion / MOVED: attempted hack? let me know what you think on: Today at 12:05:50 AM
This topic has been moved to Technical Support.

https://bitcointalk.org/index.php?topic=576105.0
2  Bitcoin / Development & Technical Discussion / MOVED: Altcoin creation error on: April 18, 2014, 11:51:49 PM
This topic has been moved to Alternate cryptocurrencies.

https://bitcointalk.org/index.php?topic=576195.0
3  Bitcoin / Development & Technical Discussion / MOVED: What is proofOfWorkLimit? on: April 18, 2014, 04:16:22 PM
This topic has been moved to Alternate cryptocurrencies.

https://bitcointalk.org/index.php?topic=575605.0
4  Bitcoin / Development & Technical Discussion / MOVED: The block chain API hell on: April 18, 2014, 04:14:43 PM
This topic has been moved to Service Discussion.

https://bitcointalk.org/index.php?topic=575651.0
5  Bitcoin / Development & Technical Discussion / MOVED: Blockchain API on: April 17, 2014, 07:40:47 PM
This topic has been moved to Service Discussion.

https://bitcointalk.org/index.php?topic=574968.0
6  Bitcoin / Hardware / MOVED: [EUROPE] GridSeed Blade Miner - on: April 17, 2014, 04:36:36 PM
This topic has been moved to Computer hardware.

https://bitcointalk.org/index.php?topic=574534.0
7  Bitcoin / Hardware / MOVED: What is the most accurate ASIC miner Profit Calculator these days? on: April 17, 2014, 04:36:10 PM
This topic has been moved to Mining speculation.

https://bitcointalk.org/index.php?topic=574676.0
8  Bitcoin / Hardware / MOVED: Don't forget to oil your fan wells on: April 17, 2014, 04:35:52 PM
This topic has been moved to Off-topic.

https://bitcointalk.org/index.php?topic=574743.0
9  Bitcoin / Development & Technical Discussion / Re: Why is Difficulty exactly 1 until Dec 29th 2009? on: April 16, 2014, 11:07:19 PM
Because it should have been lower based on the hashrate, but the system imposes a minimum (which is the definition of difficulty 1).
10  Bitcoin / Development & Technical Discussion / Re: Testnet blockchain download taking forever on: April 16, 2014, 11:06:13 PM
Testnet difficulty is too high for cpu mining.
You can still get the 20 minute blocks from time to time.
11  Bitcoin / Development & Technical Discussion / Re: Decreasing the variance of block interval w/o decreasing the mean of interval on: April 16, 2014, 05:52:28 PM
As Maaku hints to, the a big reason Bitcoin has 10 minute blocks is because the variance is desirable. We need the variation in order to increase the allowed network radius/block processing time, the latency permitted for miners, and to control the incidence of long forks.  The only advantage to having lower variance without increasing the number of blocks would be reducing header traversal costs to link a block, but we know how to do secure header traversal now in logarithmic time in any case.

Progress freeness is also very important. You do not want to reward people super-linearly with their hashrate.
12  Bitcoin / Development & Technical Discussion / MOVED: PlS HELP - Issue Compiling Litecoin-QT 0.8.6.2 on OSX 10.9 (Macports, QT Creatr) on: April 16, 2014, 05:12:53 PM
This topic has been moved to Alternate cryptocurrencies.

https://bitcointalk.org/index.php?topic=434888.0
13  Bitcoin / Development & Technical Discussion / MOVED: Adaptive Pay per share on: April 15, 2014, 11:28:58 PM
This topic has been moved to Pools.

https://bitcointalk.org/index.php?topic=572197.0
14  Bitcoin / Pools / Re: Adaptive Pay per share on: April 15, 2014, 11:07:34 PM
Eligius' approach doesn't remove as much variance as it could, however.  The problem is that no miner has an actual expected return of the PPS rate because of blocks that fall out of the chain, withholding, etc. As a result miners who are mining when the pool is lucky get overpaid (full PPS), and ones mining when the pool is unlucky get underpaid (pool will never make it back to them).

The approach used by Eligius could be improved by measuring the difference between actual recent income in a window and PPS and coming up with an expected true reward coefficient C.  Then credit the share stack PPS*C, and credit in a second share stack PPS*(1-C), the second share stack is only ever paid in the unlikely event that the first share stack is paid completely.

But I'm not really sure if that payment mechanism really makes that much sense to continue developing simply because it requires a fair amount of storage and computation, and results in payments happening months or years later, which complicates key management.
15  Bitcoin / Development & Technical Discussion / MOVED: [ANN] andytoshi's coinjoin client on: April 15, 2014, 04:07:49 PM
This topic has been moved to Project Development.

https://bitcointalk.org/index.php?topic=432121.0
16  Bitcoin / Mining speculation / MOVED: Re: Will miners in USA be able to remain competitive due to huge tax burden? on: April 15, 2014, 04:06:59 PM
This topic has been moved to Alternate cryptocurrencies.

https://bitcointalk.org/index.php?topic=572010.0
17  Bitcoin / Development & Technical Discussion / Re: 51%-attack - Why exactly "51 percent"? on: April 15, 2014, 03:59:44 PM
Preventing an attacker from replacing the current blockchain with his alternative chain isn't the purpose of the checkpoints.  That's just a side effect of their existence.
Precisely. Checkpoints are there to prevent a number of dos attacks where we'd waste storage or resources on bogus forks which are never going to be better. They also allow for some optimizations, and also ensure that you can't successfully fool a node by isolating it from the start. There are other, better but more complicated, ways to address those issues, so I expect that they will eventually be removed from the reference client.
18  Bitcoin / Development & Technical Discussion / Re: Simple adjustment to prevent mining pools on: April 14, 2014, 10:19:27 PM
there is no need to prevent mining pools, let the free markets sort this out.
as bitcoin becomes more popular and pools start making more money running a pool will become a more lucrative business venture,
naturally more pools will be created and the hashing power will be more distributed between them.
I'm afraid you must not be very experienced with this ecosystem. There have been hundreds of pools created. Operating a pool, especially a small one, is not a business that has many barriers; and large pools have had revenue at times in excess of $100k/mo, so it's not like any more income is needed to justify running one.  Just having a choice of centralization does not result in Bitcoin being decenteralized, and the major reason you see consolidation in pools isn't because there aren't people running them but because pools do their job (reducing variance) when they are large.
19  Bitcoin / Development & Technical Discussion / Re: Simple adjustment to prevent mining pools on: April 14, 2014, 06:42:37 PM
It makes me see mining pools in a different light: possibly a necessity
Centralized pools are not, however. (P2Pool is an existence proof that there are other options)
20  Bitcoin / Development & Technical Discussion / Re: 0.9 Malleability Fix - what was changed on: April 14, 2014, 06:20:07 PM
But is this actually checked by isStandard()?
Can't be yet, a majority of transactions on the network still fail the check.

Quote
Is the plan to do it in 2 stages, first make the reference client only produce canonical signatures and then make non-canonical non-standard?
Sort of, the first stage is "get all widely used signers to only produce canonical signatures", which making the reference client do it is just the first step. I believe the latest bitcoinj does this now too.

Thanks for the reminder though, it's time to start the nagging engines.

Quote
I guess the problem is that old clients would have transactions rejected. 
In theory, miners could switch the signatures to canonical, but I assume that is discouraged.
Sort of a tough problem considering how poor wallets handle the change.


Quote
A transaction is non-standard if any of its signatures leave data on the stack?  That can't be checked without the input transaction.
We can't verify a transaction without the input since they're included in the signatures.
I thought we templaitized the signatures, but apparently we don't (sometimes it's hard to remember whats been implemented vs discussed).

Quote
I think that would give reasonable safety in practice.
Safety for what? I agree that it's reasonably fine against trouble making when the attacker gains little and the harm of a loss is small. But there are already substantial pools like ghash.io who have mined maliciously in order to rip people off.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 200
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!