Bitcoin Forum
May 11, 2024, 11:19:48 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  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 »
141  Other / Off-topic / Re: Thinking about naming my baby girl Bitcoin.. (due in 3 weeks) on: January 07, 2014, 10:05:14 PM
Almost everyone I've ever met is called 'hey'.
142  Bitcoin / Development & Technical Discussion / Re: How do I crawl through the block chain? on: January 06, 2014, 06:31:25 PM
John's documentation is awesome. I have been following it and building my own parser

Ha! This stuff is infectious isn't it?
143  Bitcoin / Development & Technical Discussion / Re: How do I crawl through the block chain? on: January 06, 2014, 06:30:32 PM
Interesting timing for me! About a week ago I decided I was finally going to start learning about all the code underneath the bitcoin protocol and software. Except I wasn't going to actually examine any code (I don't know much C++), I was going to read lots of technical articles and write my own code from the bottom up. Also I was going to do it in Python. Which I had not yet learned. Why? "Because it's there".

So anyway a week later I've read the Satoshi paper, the protocol-rules and protocol-spec docs on the wiki, that very helpful '285 bytes that changed the world', and this: http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/ . Plus I've learned some python. And here's what I've got to show for it:

Code:
#!/usr/bin/python
from time import ctime

def behex(x):
   "Converts the given little-endian slice of bytes into big-endian hex digits"
   return x[::-1].encode('hex')

def varint(x):
   """Converts the bytes-slice to a list: first number is the number of bytes"""
   """the varint takes up. Second number is the actual int value. Recommend"""
   """only passing 9 bytes to this function, but extras will be ignored"""
   a = int(x[0].encode('hex'), 16)
   if a < 253: return (1, a)
   elif a == 253: return (3, int(behex(x[1:3]), 16))
   elif a == 254: return (5, int(behex(x[1:5]), 16))
   elif a == 255: return (9, int(behex(x[1:9]), 16))

class TrInput:
   """A single input in a single transaction. We create it from a slice"""
"""of bytes, but do NOT make assumptions about where it ends. We"""
"""infer that from script length, and further bytes are ignored."""
def __init__(self, data):
self.hash = data[0:32] ; self.index = data[32:36]
(off1, scrlen) = varint(data[36:45])
off1 = off1 + 36 ; off2 = off1 + scrlen ; self.size = off2 + 4
self.script = data[off1:off2] ; self.seqnum = data[off2:self.size]

class TrOutput:
"""A single output in a single transaction. We create it from a slice"""
"""of bytes, but do NOT make assumptions about where it ends. We """
"""infer that from script length, and further bytes are ignored."""
def __init__(self, data):
self.satval = data[0:8] ; (offset, scrlen) = varint(data[8:17])
offset = offset + 8 ; self.size = offset + scrlen
self.script = data[offset:self.size]

class Transaction:
"""Data is a slice of bytes, should start with version"""
"""but can end anywhere, excess bytes are ignored."""
def __init__(self, data):
self.version = int(behex(data[0:4]), 16)
(off1, ninps) = varint(data[4:13]) ; off1 = off1 + 4 ; self.inp = []
for i in range(ninps):
self.inp.append(TrInput(data[off1:]))
off1 = off1 + self.inp[i].size
(off2, nouts) = varint(data[off1:off1+9])
off2 = off2 + off1 ; self.out = []
for i in range(nouts):
self.out.append(TrOutput(data[off2:]))
off2 = off2 + self.out[i].size
self.size = off2 + 4 ; self.locktime = behex(data[off2:self.size])

class Block:
def __init__(self, blkdata):
self.size = len(blkdata) ; self.version = int(behex(blkdata[0:4]), 16)
self.prevhash = blkdata[4:36] ; self.merkle = blkdata[36:68]
self.tstamp = int(behex(blkdata[68:72]), 16)
self.target = behex(blkdata[72:76])
self.nonce = behex(blkdata[76:80])
(offset, self.ntrans) = varint(blkdata[80:89])
offset = offset + 80 ; self.trans = []
for i in range(self.ntrans):
self.trans.append(Transaction(blkdata[offset:]))
offset = offset + self.trans[i].size

def checkmagicbytes(fname):
"Reads 4 bytes from current position in file, checks they're 'magic'"
x = fname.read(4) # why can't I ';' these two lines? (and next two)
if len(x) == 0: return 0 # ???
y = int(behex(x), 16)
if y != 0xD9B4BEF9: return 0
return 1

def target2diff(t):
"Converts the target in 4-byte hexstring form into difficulty (float)"
# MAY not agree with diff given in block explorer for high diffs - check!
i1 = int(t, 16) ; i2 = float(2**(248 - i1/(2**21)))/(i1 % (2**24))
return i2 * 65535/65536 # I THINK that fudge factor fixes things...

bn = 0 ; fn = 0 ; chain = []
while True:
fname = "/home/chris/.bitcoin/blocks/blk{:0=5}.dat".format(fn)
try: bcfile = open(fname,"rb")
except IOError: break
while checkmagicbytes(bcfile): # issue about two failure modes!
bkdata = bcfile.read(int(behex(bcfile.read(4)),16))
chain.append(Block(bkdata)) ; bn = bn + 1
if bn > 100000: break # just for memory purposes for now
fn = fn + 1 ; bcfile.close()
if bn > 100000: break # ditto

bn = bn - 1 ; fn = fn - 1 ; print "Chain ends: block", bn, "file", fn
opt = int(raw_input("Enter a block number:"))
while opt <= bn:
print "Version:", chain[opt].version
print "Prev hash:", behex(chain[opt].prevhash)
print "Merkle root:", behex(chain[opt].merkle)
print "Timestamp:", ctime(chain[opt].tstamp)
print "Difficulty:", target2diff(chain[opt].target)
print "Nonce:", chain[opt].nonce
trs = chain[opt].trans ; n = chain[opt].ntrans
print "# of transactions:", n, "size:", chain[opt].size
for t in range(n):
print "Transaction", t, "Version", trs[t].version,
print "Locktime", trs[t].locktime ; ni = len(trs[t].inp)
# input and output data still needs to be presented readably...
for i in range(ni):
inp = trs[t].inp[i]
print "Input:", i
print "Hash:", inp.hash
print "Index:", inp.index
print "Script:", inp.script
print "Seqnum:", inp.seqnum
no = len(trs[t].out)
for o in range(no):
out = trs[t].out[i]
print "Output:", o
print "Value:", out.satval
print "Script:", out.script
opt = int(raw_input("Enter another block number:"))


Feel free to use it, and any constructive comments/help/tips most welcome. It doesn't do too much. You need the blockchain as downloaded by the official client, it'll read the first 100000 blocks (or more if you remove the brakes, but then be careful about your memory filling up). Then you can enter a block height number and see what's in it. The next things on my to-do list are (a) understand the scripts in the inputs and outputs, (b) shove SHA256 stuff in so I can compute block hashes, merkle roots, transaction ids etc, and (c) use all that to validate the blockchain (at least the strictly linear version - no forks for me yet). Then I guess (d) - work out the most compact way of storing the relevant info from the first n blocks (where, say, n=current block height - a few hundred) in memory. I think they call this 'pruning'.

And I've only NOW started reading John Ratcliff's 'code suppository'  Grin. It looks good!
144  Bitcoin / Bitcoin Discussion / Re: Has anyone here ever actually received an anonymous donation? on: January 05, 2014, 11:24:55 PM
I have received a few satoshis here and there into addresses that were on the blockchain because I'd spent from them at least once. It wasn't just the addy I have in my signature, but others too. I think this is a fairly well known tactic - somebody wants to link up addresses to get an idea of who owns which address. So they 'spam' the addresses each with a very small amount. Then the recipient *might* post on bitcointalk, "OMG who gave me amount x at address y on date z thank you lol!" and now the sender has made the blockchain just a little less anonymous than it had been before. But even if they don't, as soon as they spend some btc, that little donation likely gets swept up with a bunch of other inputs and now we all know that those inputs are (almost certainly) owned by the same person. Anonymity and therefore privacy are eroded either way.

Not that I mind. Thanks for the coins and I'll just make sure to be more careful about which inputs I link up in my transactions. And/or run 'em through a mixer.


145  Economy / Speculation / Re: So it's 2014, and NOTHING happened on: January 03, 2014, 12:56:52 PM
Holy fuck it's already THE THIRD!! Come on Bitcoin, get off your arse. *pant, pant*
146  Bitcoin / Bitcoin Discussion / Re: This is REALLY BAD news for Bitcoin on: January 03, 2014, 12:48:46 PM
Maybe this is a stupid question. But if some day the encryption bitcoin uses was cracked ,  couldn't the devlopers just switch to a different encryption ?

Or as years go on even if the current standards aren't cracked , would it be possible to switch to newer standards to always stay "ahead of the game" so to speak?

Sorry if it's a silly question, I don't know much about this area.

No, it's not a silly question, and broadly speaking the answer is YES, the standards can be changed to stay ahead of the game. I believe it would require a so-called 'hard-fork' which is bitcoin-speak for 'we'd better damn well have most people on board with this or it'll get ugly', but it's pretty clear everyone WOULD be okay with it.

But as several people have explained before, even a fully working quantum computer wouldn't pose an immediate threat to SHA256. Long before it did, we could simply move to SHA512. Basically, 2^256 is such a huuuuuuuuuuuuuuuuuuuuge number, that even its square root is still huuuuuuuuge enough.

The trolling here is not of course in the Washington Post, but in the OP's interpretation of their article. In fact even the attempt at misdirecting the blame is clumsy. OP, you're a really third-rate troll.
147  Bitcoin / Bitcoin Discussion / Re: Vanity Genning someone's address? on: January 03, 2014, 12:43:33 PM
I'll be much more scared if I see even a single Satoshi going OUT of that address!
148  Other / Beginners & Help / Re: Help needed : New to Ubuntu, no idea how to install Bitcoin on: January 02, 2014, 10:52:11 PM
Sorry to raise this zombie, but I too am trying to install the 'official' (well not counting multibit) client on Lubuntu and not getting anywhere.

'apt-get install bitcoin-qt' simply tells me that it is unable to locate the package bitcoin-qt.
Weirdly, I did manage to get bitcoind with 'apt-get install bitcoind' successfully.


Oops. It turns out that after adding the bitcoin ppa repository thingy, but before installing bitcoin-qt, you have to run 'apt-get update'!  Embarrassed



Actually, since all I want to do is download blockchain files, if I can do that with bitcoind I'd be grateful if someone could tell me exactly what to put on the command line. Also I have a 1.1GB blk0001.dat file (and accompanying index file) from mid-2012, so how could I successfully explain to bitcoind that I want it to start from that (saves some downloading).
149  Bitcoin / Bitcoin Discussion / Re: NSA can rob peoples BTC wallet in new devices such as the iphone on: December 31, 2013, 10:39:43 AM
Any of the many intercepted devices can exploit and steal your Bitcoins through the NSA and people who figure out the backdoors.

You forgot to write "ATTACH KEYWORDS: NSA, exploit, bitcoin, chart, proof, evidence" on the end of this. How can we possibly believe you if you don't instruct us to imagine that you've supplied proof and evidence?


Also, have you had a chat with the forum member called "Actor_Tom_Truong"? I think you'd get on really well. Once you'd each figured out that the other wasn't a member of the Illuminati, you could tell us all how you did it so we can improve our infiltration of the world's banking and political systems. Shit, did I just type that out loud?  Embarrassed
150  Other / Politics & Society / Re: Devil worshipers cult Illuminati greatest achievements on: December 31, 2013, 10:36:16 AM
Do you ever read any replies people make to your posts?


No, I do not read replies written by Illuminati members.

How do you know who is an Illuminati member and who isn't?
151  Economy / Speculation / Re: [Bitcoin Future Price Formula] Published by italian Bitcointalk member! on: December 30, 2013, 09:13:24 PM
I don't know Italian, but I do know maths, and a bit about fitting curves to data in particular. As far as I can see the author has simply assumed a power-law relationship between I(number of addresses) and P(price). In other words P=k*I^n, where k and n are constants to be found by data mining. He has done this in the standard way, by finding the best-fit line you get on a log-log plot. He gets n~=2.26 and k~=e^-26 (incidentally you may as well just give k as a very small number, there's no benefit in putting it in terms of e).

It's interesting but I don't know if it has much predictive power. But kudos for putting some maths into this stuff, we don't see enough of that in price speculation threads.
152  Other / Off-topic / Re: Fukushima disaster to destroy BITCOIN on: December 30, 2013, 09:02:44 PM
ATTACH KEYWORDS: fukushima, disaster, bitcoin, chart, proof, evidence

Well, I'm convinced. It's a sort of 'Jedi Mind Trick' for the informatics age, isn't it?
153  Bitcoin / Bitcoin Discussion / Re: What are the most convincing arguments against Bitcoin? on: December 30, 2013, 03:04:45 PM

Bitcoins are not under great threat by the develpment of a practical quantum computer.  They're not magic, Bitcoin is fairly resistant to quantum brute forcing already, and can be upgraded if the threat proves real.

On what facts do you base that?

the wiki for quantum computing very clearly states:

Quote
Besides factorization and discrete logarithms, quantum algorithms offering a more than polynomial speedup over the best known classical algorithm have been found for several problems,[19] including the simulation of quantum physical processes from chemistry and solid state physics, the approximation of Jones polynomials, and solving Pell's equation. No mathematical proof has been found that shows that an equally fast classical algorithm cannot be discovered, although this is considered unlikely. For some problems, quantum computers offer a polynomial speedup. The most well-known example of this is quantum database search, which can be solved by Grover's algorithm using quadratically fewer queries to the database than are required by classical algorithms. In this case the advantage is provable. Several other examples of provable quantum speedups for query problems have subsequently been discovered, such as for finding collisions in two-to-one functions and evaluating NAND trees.

Consider a problem that has these four properties:

    The only way to solve it is to guess answers repeatedly and check them,
    The number of possible answers to check is the same as the number of inputs,
    Every possible answer takes the same amount of time to check, and
    There are no clues about which answers might be better: generating possibilities randomly is just as good as checking them in some special order.

An example of this is a password cracker that attempts to guess the password for an encrypted file (assuming that the password has a maximum possible length).

For problems with all four properties, the time for a quantum computer to solve this will be proportional to the square root of the number of inputs. That can be a very large speedup, reducing some problems from years to seconds. It can be used to attack symmetric ciphers such as Triple DES and AES by attempting to guess the secret key.

As far as i know SHA is one of the algorithms that is threatened by this. Show me what magical special defense system bitcoin has against this potential threath plz. Tongue

The number of inputs to check is exponential in the size of the input string. So if the input strings are n bits long, we need time of order O(2^n) to 'crack' SHA2 (any variant) on a classical computer. IIUC a quantum computer then reduces this time to O(sqrt(2^n)) which is the same as saying O(2^(n/2)). This is nothing to worry about with the bitcoin protocols (either the mining algo or the key finding algo) as the square root of an exceedingly long time is still an exceedingly long time.

Worst case scenario if it WAS a problem (which it isn't) - we double the length of all bitstrings on which we want SHA2 to act - e.g. we could just switch from SHA256 to SHA512 - and now the quantum computer takes as long to break SHA512 as the classical computer took to break SHA256.
154  Bitcoin / Bitcoin Discussion / Re: Bitcoin emBassy, Tel Aviv, Israel on: December 30, 2013, 02:54:03 PM
Congrats to the OP. Hope it takes off big time.

And Honeypot and Marcellus make such a lovely couple. Especially on my... list.
155  Bitcoin / Bitcoin Discussion / Re: When was "mining" term first used? on: December 30, 2013, 02:49:43 PM
I meant "mining" in the context of bitcoin, obviously...

Then you answered yourself. It was first used by Satoshi in his whitepaper (unless of course it was used earlier, by him or others, in those newsgroup postings).

Strictly speaking he said it was 'addition to the supply' that was 'analogous to mining', but objecting on those grounds seems to me to be semantic hair-splitting.
156  Other / Politics & Society / Re: Devil worshipers cult Illuminati greatest achievements on: December 29, 2013, 08:21:25 PM
Do you ever read any replies people make to your posts?
157  Bitcoin / Bitcoin Discussion / Re: Does Bitcoin really need to *Replace* Fiat? on: December 29, 2013, 07:54:21 PM
Well I'm convinced.
158  Other / Off-topic / Re: REPTILIAN LIZARD CREATURE FOUND ON BITCOIN VIDEO? FAST FORWARD TO 2:38 on: December 28, 2013, 10:02:25 AM
A reptilian lizard creature, you say? Well, thank god at least it wasn't a mammalian or avian lizard creature.  Roll Eyes
159  Bitcoin / Bitcoin Discussion / Re: What are the most convincing arguments against Bitcoin? on: December 24, 2013, 01:03:18 PM
It's to do with the blocksize limit - currently all blocks can only hold a maximum of 1MB of data. I'm told by smarter people that it would require a hard fork to remove or otherwise change this limit. Given average time to generate a block as 10 min, and a minimum transaction size of ... whatever-it-is bytes, that works out to 7 transactions per second.

If the blocksize limit were increased, or removed altogether, we'd get the blockchain increasing at an even faster rate than it already is, but that may or may not be a problem depending on how storage hardware develops, and how drastically we implement 'pruning' solutions or lightweight clients. I'm told there are also economic reasons why a limited block size might be a good idea but I don't know what those are.
160  Bitcoin / Development & Technical Discussion / Re: Wallet Safekeeping - Best Practices on: December 24, 2013, 12:09:58 PM
You could also use deterministic wallets that generate a bunch of pseudorandom addresses from a random key. This is how electrum does it and I like their approach very much. You can just store a 12-word passphrase in your safe, or even just in your brain if you're careful (but brain+safe+completely separate USB keys somewhere is best).
Of course you have to be careful about how you're going to generate the random key for those. But I find dice work very nicely!
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 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!