Bitcoin Forum
March 19, 2024, 04:22:05 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 »
1  Bitcoin / Development & Technical Discussion / Re: Why does "validateaddress" return TRUE for bitcoin addys in testnet? on: August 07, 2011, 07:40:41 PM
The theymos' post, 3 posts above is rather clear
It's for when we'll use a new kind of addresses, e.g. when we'll use addresses version 2, it would be useful to send coins to old addresses...

Also, testnet coins sent to bitcoin address are easily retrievable, I made a guide about that

Well sorry but it wasn't all that clear to me. A new address version would seem to need a lot more code than just <= version and it is a hypothetical future use as opposed to the implemented current use of the version byte

I understand how you can just switch wallets around to retrieve the "lost" coins but if the sent to address isn't yours it may not be as easy as you make it sound.
True they're "just" testnet coins lost, no big deal I suppose but I still found it inconvenient and it just seems like a simple fix and the objections are rather abstract/hypothetical.
2  Bitcoin / Development & Technical Discussion / Re: Why does "validateaddress" return TRUE for bitcoin addys in testnet? on: August 07, 2011, 07:17:37 PM
On testnet, mainnet addresses are basically "aliases" of their equivalent testnet addresses. Sending to 1KNHQ7513gVwJv5fG4ucsPgkdb5Ub9UzR6 is exactly the same as sending to mytEhA9yrhwC62ZGydszhJu5VagBZj2z7t. The only difference between these two addresses is the version and checksum: the public key hash is the same.

If you copy your wallet.dat from mainnet to testnet, your receiving addresses will all still be there: they will just have been changed to their "testnet" aliases. The associated mainnet versions will still work for transactions on testnet.

On testnet, there are actually 111 valid ways of expressing of every address. These are all the same:
1KNHQ7513gVwJv5fG4ucsPgkdb5Ub9UzR6
ihtPDNHkrxp8MDkHVEwMWxYG6LRMEvGhC
283VNKfaU3RgwnMqJuaFqeEKtbbN1Q5KFY
2XP6MRxsBDtZmDVvLKuaKmW7X6rJiSaZ9Z
2vihLYG9tQMSaee1MkEtotmu9c7FSBxg9a
3L4JKeZSbapKQ5n6PAaDJ23gn7NCD2x9V1
...

I understand that, I don't understand why this behavior is useful or desirable in any way. Couldn't we just say when running i testnet mode you need to use the 111 tagged version of the address. The others will generate an error. It seems to me it would prevent some mistakes sending testnet coins to limbo when we think we are sending mainnet coins.
3  Bitcoin / Development & Technical Discussion / testnet accepts main net addresses on: August 03, 2011, 07:48:38 AM
I find it is inexplicable and inconvenient to an extreme that the client running testnet accepts mainnet addresses. Could we please fix this. It is just a one line fix.

in base58.h: change line:
     return (nVersion <= ADDRESSVERSION);
to:
     return (nVersion == ADDRESSVERSION);

I don't see any practical reason for it to be the way it is. It is only an historical accident that it was named a version byte. It is not a version byte and has never been a version byte. If some day we do need/want to use it as a version byte we will need to rewrite the code in question anyway as I see it.

Meanwhile it is used as a net id byte for addresses and I think it is a mistake to use addresses from another net and the net id byte can be used to detect when you are trying to use an address with the wrong net and prevent your mistake.

Thank you.
4  Bitcoin / Wallet software / Re: Java Bitcoin Client on: July 04, 2011, 03:29:58 AM
If there is bitcoin java, does that mean there could be Bitcoin android?!

A FULL client on a mobile device seems unlikely for now for a few reasons.

1 communication costs. bitcoin is steadily sending and receiving data updates. It seems the mobile companies around here are going for higher data costs and fewer unlimited data plans (or none).

2 memory costs. the Satoshi bitcoin takes over 600 mb to run. Perhaps bitcoinj based client would be better, but how much better?

3 storage costs. Full block chain is currently 340mb, block chain index is another 150mb. wallet is variable size depending on activity. (I have one wallet over 1 gb.) Phones memory card or usb drive support make this go away but that leaves out a lot of phones.

4 battery life. with the constant communications related to point 1.

Of course all these are subject to change. in as little as 6 months it could all be a different story
5  Bitcoin / Pools / Re: Cooperative mining (2000GHash/s) on: July 04, 2011, 02:47:51 AM
Please implement that ntime shizzle...
About half my shares are rejected, and that's NOT A GOOD DEAL FOR ME!
I might have to find another pool if you wont...

half rejected is indeed bad. can you update more often perhaps.
6  Bitcoin / Mining software (miners) / Re: python OpenCL bitcoin miner on: July 04, 2011, 02:45:53 AM
Just installed on my 3rd Linux rig...wtf is wrong with the new display? It keeps making blank lines and such...could you bring back the old display please?

I suspect that is a bug in that new terminal window. I get it on many different programs.
7  Bitcoin / Bitcoin Discussion / Re: Bitcoin Block Explorer on: June 19, 2011, 01:48:38 PM
Is this the same method being used on you site?
  http://blockexplorer.com/q/totalbc

I hope you can consider providing these service to function as an early warning system for the bitcoin network.

It's not.

The value returned with the SQL is now actually less than the "ideal" number, as some miners have thrown away block reward BTC. I might make a /q page for it eventually, as the difference is interesting.

It only one block (#124724) that doesn't balance this way so far. He was intending to throw away 0.00000001 BTC but accidentally also dropped a fee of 0.01 BTC so he made 0.01000001 BTC in all disappear. Of course its not really any different effect than someone losing their wallet.dat file. The value is gone either way.
For reporting purposes it could be credited to a special "lost" account address.
8  Bitcoin / Bitcoin Discussion / Re: >432109 BTC sent to 1 address, block 130281 on: June 13, 2011, 11:27:36 PM
Imagine if they made a typo in the address and everything got lost. It would be very disruptive.

Almost any ordinary typo will be caught by the checksum in the address. The biggest danger in that vain would be copy and paste copying the wrong address from a list.
9  Bitcoin / Bitcoin Discussion / Re: Bitcoin Block Explorer on: May 28, 2011, 06:26:33 AM
How does what work?  Fractional reserve or auditing them with block explorer?

If you mean, how does one audit your addresses with block explorer, simply check the addresses that you have to make sure that there have been no transactions that you didn't do yourself and that the address balances add up to what you should have.  If you have more than what you should have, then the website is sharing accounts among users and tracking the individual values internally.  Which would allow the website owner to loan out portions of the pooled balance, much like how fractional reserve banks do now, since they don't actually keep your money on hand.  If there has been any transactions in or out of said accounts that you didn't perform, then that means the website owner is using member accounts to "float" his own activities.

EDIT:  Except I can't actually see all of the addresses used in my Mybitcoin.com account.  That's going to be something I need to ask for.

I don't think mybitcoin.com really works the way you think it does. I think it actually is just one big pool so far as bitcoin is concerned. mybitcoin.com then keeps its own database of accounts. afaik
10  Bitcoin / Development & Technical Discussion / Re: difficulty loss of significance error on: May 26, 2011, 11:23:19 PM
Name is not important, just lfm if you insist. Main point is to fix it. Interesting changes for "coding standards". I am not real good at following other people's styles that way.
11  Bitcoin / Mining / difficulty -> target calculator usefull for setting up some pools and stuff on: May 26, 2011, 11:12:57 PM
Diki was having trouble figuring out what target hex string to use to set up a giving difficulty for shares on his pool so I wrote this little difficulty calculator for him:


  bitcoin difficulty calculator

  accepts floating poind difficulty or
  hexadecimal target in either the long 256 bit form or
  the short compressed nBits form and

  displays the result in all three formats


 download portable C source and linux executable from :

  http://www3.telus.net/millerlf/diffcalc.tgz

have fun

12  Bitcoin / Development & Technical Discussion / difficulty loss of significance error on: May 26, 2011, 08:39:08 PM
Attached file is a diff -c patch for the loss of accuracy in the difficulty calculation. For instance any nBits compressed value from 0x1a44b800 thru 0x1a44b9ff will show as difficulty 244139.4816. This patch will more accurately convert the nBits compressed values to the double difficulty.

This will display any of the recent difficulty levels slightly differently though. Early difficulties and testnet difficulties are not large enough to trigger this bug.

None of the actual targets or compressed targets are changed, only the conversion to the floating point difficulty is changed and afaik it is only ever displayed, never converted back so the patch does not effect the target calculations, binary files, databases nor the binary protocol. only programs which use the floating point displayed value of the difficulty might be effected. (pools? I don't think so, but they may need a heads up about the change)

Code:
*** bitcoin-0.3.21/src/rpc.cpp  2011-04-20 16:08:01.000000000 -0600
--- bitcoin-0.3.21-test/src/rpc.cpp     2011-05-25 18:20:48.000000000 -0600
***************
*** 199,208 ****
      // minimum difficulty = 1.0.
      if (pindexBest == NULL)
          return 1.0;
!     int nShift = 256 - 32 - 31; // to fit in a uint
!     double dMinimum = (CBigNum().SetCompact(bnProofOfWorkLimit.GetCompact()) >> nShift).getuint();
!     double dCurrently = (CBigNum().SetCompact(pindexBest->nBits) >> nShift).getuint();
!     return dMinimum / dCurrently;
  }
 
  Value getdifficulty(const Array& params, bool fHelp)
--- 199,220 ----
      // minimum difficulty = 1.0.
      if (pindexBest == NULL)
          return 1.0;
!     int shift = (pindexBest->nBits >> 24) & 0xff;
!     double diff =
!         (double)0x0000ffff / (double)(pindexBest->nBits & 0x00ffffff);
!
!     if (shift < 29)
!         while (shift < 29) {
!           diff *= 256.0;
!           shift++;
!         }
!     else
!         while (shift > 29) {
!           diff /= 256.0;
!           shift--;
!         }
!
!     return diff;
  }
 
  Value getdifficulty(const Array& params, bool fHelp)
13  Bitcoin / Development & Technical Discussion / Re: Bitcoin smartcard Point of Sale terminal on: May 08, 2011, 04:12:26 AM
I dont see what this has to do with bitcoin, in fact it looks nothing like bitcoin.
14  Bitcoin / Mining software (miners) / Re: New demonstration CPU miner available on: April 11, 2011, 09:53:53 PM
I just noticed this - the date reads a month in the past in the CPU miner.  Is this a problem on my end?  My computer's date/time are set correct.
Actually it seems like an off-by-one error in the code. If memory serves me right (and it has been a few years since my last brush with C), tm_mon is zero-based, so the following diff should be applied to util.c:
Code:
--- cpuminer-git/util.c 2011-04-11 21:12:43.469374001 +0200
+++ cpuminer-compile/util.c     2011-04-11 21:22:49.149374000 +0200
@@ -80,7 +80,7 @@
                f = alloca(len);
                sprintf(f, "[%d-%02d-%02d %02d:%02d:%02d] %s\n",
                        tm.tm_year + 1900,
-                       tm.tm_mon,
+                       tm.tm_mon + 1,
                        tm.tm_mday,
                        tm.tm_hour,
                        tm.tm_min,


should just use strftime() instead! something like :

     strftime(f, len, "[%F %T]", &tm);

15  Bitcoin / Mining software (miners) / Re: New demonstration CPU miner available on: April 05, 2011, 05:57:11 AM
the "-algo cryptopp_asm32" just seg faults for me on linux 32bit, via C7 cpu.

It seems it dosen't even build on linux64 (hence the name)

Has anyone run this algo successfully?

16  Bitcoin / Mining / Re: UltraSPARC III @ 1200Mhz on: March 25, 2011, 09:55:37 PM

 This leads to a rate of 2.95M sha256 blocks/s, or 1.5Mhash/s.


Thats funny since it is exactly the same speed the VIA-C7 hashing engine achieves with bitcoin. ($67 including motherboard).
17  Bitcoin / Mining software (miners) / Re: New demonstration CPU miner available on: March 25, 2011, 09:49:27 PM
I'm having trouble getting decent speeds out of Jgarzik's miner on Ubuntu 10.10 (Phenom II X4 920). I'm only getting 125 kh/s per thread (4 threads), which drops to 50 kh/s with 4way enabled.

The same computer does 10+ mh/s using ufasoft's Win SSE2 miner.
Can someone please enlighten me as to how I can get the same performance under Linux.

try "-a 4way" command line switch
18  Bitcoin / Mining / Re: UltraSPARC III @ 1200Mhz on: March 24, 2011, 11:52:05 AM
Ok guys,
Question with bitcoins as reward for good info.

I have a Sun Fire V880 with 8 UltraSPARC III Cpus @ 1200mhz at my disposal. This thing is a beast. Surely there is a way for me to get some decent hashing going on with it?

I've noticed there's not really much of a port, or anything that's been moved over doesn't get decent speeds.

Can someone give me the hot tip on how I can start really utilising this machine?

It would be a large problem to port to this machine due to it being big endian. afaik bitocin has never been ported to big endian and I think Satoshi said some time ago that the bitcoin client was highly dependent on little endian architecture and unlikely to ever work on big endian.

Prehaps the java bitcoinj is better base to start with, not sure.

Not trying to start another flame war about what is better, just another design decision from early days of bitcoin that is a problem for you now.
19  Bitcoin / Development & Technical Discussion / Re: Via Padlock hardware acceleration on: March 15, 2011, 09:46:26 PM
Unfortunately, you are duplicated work.  This CPU miner supports VIA padlock: https://github.com/jgarzik/cpuminer

The main client does not need any CPU mining tweaks.  In fact, we discuss from time-to-time how to hide / disable / remove CPU mining from the main bitcoin client.

Ah, nice, google didn't find that.  BTW looking over the code it seems to suffer the IRQ bug I mentioned.  I think we have to loop over the xsha256 opcode, until (e)SI register is at the end of the input.  In case an interrupt happens, the instruction will finish somewhere midway through the computation and needs to be restarted with the esi/edi/ecx register value state it left.

the sha256 instruction will automaticlly restart after an interrupt much like any rep instruction. I am quite sure it is correct as is
20  Bitcoin / Development & Technical Discussion / Re: Block number from getwork on: March 03, 2011, 05:22:18 PM
I'm looking for a way to verify if the current getwork I'm on is from the current, or last block. Would I be able to do that by looking at "prev_block", and checking against a stored array of the "prev_block" from the previous two blocks?

Like, I have an array with the two last known prev_block values in it. If the prev_block value from the getwork matches the newest stored prev_block value, I know it's from the current block. If it matches the oldest prev_block value, it's from the block prior to the current. Correct?


You would need to get the hash of the current "top" block and compare it to prev-hash in the getwork block.
Pages: [1] 2 3 4 5 6 7 8 9 10 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!