Technically, why wouldn't it be secure enough to just - let's say - save 1000 blocks? One transaction is considered to be valid after 6 following blocks (confirmations). So when a new block is created, the first block can be deleted. Ok, now where I am thinking: We need to save all adresses with a positive balance, right? And as input of a transaction we need the last output. So we need to save every adress with a positive balance with the last transaction, in which the adress served as output.
Actually something kinda similar to this idea is also in discussion on this board for more than half a year now - called "ultimate blockchain compression" or "ultraprune". With this, one would create a set of all unspent outputs so far and a way to verify that this set is actually really the correct one for a certain block height. One then only would need the chain headers (a handful MB), the set of unspent transaction outputs (currently ~170 MB afaik) and all full blocks since the last set was created to update this set to the most current state. Once a new set gets released, you verify its integrity and after a few blocks discard the old set and the content of the blocks leading up to the new set. Currently this however has not been finalized and will probably for quite some time be just an extension (and to have a way to verify these sets, one also needs miners who put checksums of these sets into blocks), not part of the official client I guess. |
|
|
|
In any case one XBT by the above defintion is already worth more than one JPY and has been so for a while.
You can also compare it to XAU or XPT, then things look VERY differently. I like the idea though, as it might allow for coexistence of 1 BTC = 100 000 000 Satoshis and 1 XBT = 100 000 Satoshis. On the other hand it might confuse people who hear the "21 million cap" story and then see that there will be 21 billion XBT. Has anyone actually already inquired at SIX or at the Bitcoin foundation about their next steps regarding this? |
|
|
|
If they were called bids, then I would assume that I could increase my bid at any time - which would actually be pretty cool. If I'm not seeing my 0.0005 BTC "bid" getting through in 30 minutes or so and I'm getting kind of frustrated, I could double or triple my bid to increase the likelihood of it going through in the next few minutes.
Create a double spend transaction with the same inputs and outputs, but a different "confirmation urgency bid" Currently most clients in the network will block/not relay this second transaction though. |
|
|
|
The newly generated coins go to many address only Luke-Jr's old pool does that.
Not true, but what do the generated coins have to do with the address creating the satoshi transactions? Have these transactions been broadcasted to the network or are they appearing in this block out of the blue? The second option might be an indication that these were generated by either the miner or somebody close to the pool/with a deal with the pool. |
|
|
|
|
As far as I know something like this does not yet exist and yes, imho this is a far more pressing issue than MAX_BLOCK_SIZE.
There might be problems for services that allow 0-confirmation transactions to already gain some kind of access/benefit if you implement a "currently pending transactions" screen with a "cancel" buttin next to each one - and also there might be some flooding issues if you can just create and withdraw transactions at will...
A solution might be to drop unconfirmed transactions out of the memorypool after 1008 blocks (~1 week) automatically and after 6 blocks (~1 hour) upon explicit request. Until then other clients will see other transactions with the same input(s) as a double spend and not relay them. I don't know if this should be a hard rule though, seems rather like a "nice thing to do" rule of thumb towards people who get a transaction stuck in limbo.
|
|
|
|
The newly generated coins go to many address only Luke-Jr's old pool does that.
Nope, p2pool does that too... you can however easily check on eligius' stats and p2pool's stats if the block and/or payout addresses show up there. |
|
|
|
|
Hm, sounds interesting...
I can help with german translations, depending on how you do the translation stuff actually (transifex etc. is fine, editing source code too but typing in escape sequences for every umlaut (i.e. ÜÄÖ) isn't).
Also please take care to not create bitdust (=practically unspendable outputs) with these games. Hourly bets might also be a bit tough, as there are regularly times where there's more than 1 hour between two blocks.
|
|
|
|
|
1.5 BTC for each of my 4 shares to my address (available upon request) and I will sign any paper digitally, physically and/or with a shoe on my head that I will never ever claim any of these shares.
|
|
|
|
|
Hm, could be a miner trying to spread FUD by padding blocks with their own transactions?
As the block is ~500kB large, at the very least the miner has decided to change a few rules in their bitcoind.
|
|
|
|
|
Oh btw. it works/compiles like a charm on Arch Linux, so no worries about needing Ubuntu (you don't even specify which release anyways...).
Now back to solving my Hash160 issues... :-/
|
|
|
|
Keep your bitching/personal problems with forum members to meta or Off-Topic please...  The amount of people who know what's best for Bitcoin's future is TOO DAMN HIGH in this forum already! |
|
|
|
|
As far as I understand it, one can with a header chain, most recent "unspent-tx tree" and all full blocks since the last unspent-tx block also emulate the behaviour of a full client.
Maybe call it a "semi slim" client, that discards all block contents once a new merge-mined superblock comes in? This would be good enough for a lot of people who don't want to do blockchain analysis, but for example want to offer bloom filters to lightweight clients.
The benefit would be that there is only the very small growing block header files, a few (depending on miner adoption) full blocks + a huge unspent-tx block to be stored to provide services to lightweight clients or to even mine, not all full blocks.
Edit: There would be 2 header chains to be stored as far as I understand, one for Bitcoin and one for unspent-tx-treecoin.
|
|
|
|
[...] buy Bhutan, Kick out central bankers and any oppressive governments that may exist[...]
You have ZERO clue about Bhutan apparently! It's a great country and looking down on them with disrespect or mockery won't get you any friends there. I'm not sure if it is even smart to consider this option (trying to get BTC by convincing Bhutan to adopt Bitcoin) though, X (international) symbols anyways would make more sense for Bitcoin, and BTC can still stay as "inofficial" abbreviation, just like YEN. |
|
|
|
|
What's the best way of moving some EUR on a SEPA account to you guys into USD, ideally without an MtGox account in the course of next week? Sell SEPA-EUR for MtGox codes (as long as they still exist...) somewhere here? Trade on Bitstamp to BTC, transfer BTC and trade back to USD on Bitfinex (depending on delays there's quite some exchange rate risk + more fees)? Do a private one time deal with you guys (France = SEPA, Hong Kong isn't... or for example letting me redeem some BitStamp codes for USD)?
I know you want to incorporate soon, but probably not tomorrow...
|
|
|
|
|
Hm, could be the case - I didn't reboot between runs + recompilation.
|
|
|
|
|
Oh, and for some measurements:
With larger hash maps: SimpleStats in ~850s
With smaller hash maps (WANT_DENSE commented out): SimpleStats in ~350s
Still a lot of time, but not too shabby for a little atom machine.
|
|
|
|
Code (Python 2.7): import hashlib
passphrase = ""
hash160 = hashlib.new('ripemd160')
hash160.update(hashlib.sha256(passphrase).digest())
print hash160.hexdigest() #<-- b472a266d0bd89c13706a4132ccfb16f7c3b9fcb
print hashlib.sha256(passphrase).hexdigest() #<-- e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
I want to perform steps 2+3 from https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addressesThe hexdigest of the sha256 hash is the correct one for an empty input. According to https://bitcointools.appspot.com/?s=&r=1 hash160 however should be b5bd079c4d57cc7fc28ecf8213a6b791625b8183, not the one I came up with. https://github.com/weex/addrgen/blob/master/addrgen.py from line 71 on does exactly the same thing I do here (just outputting the digest, not hexdigest) and does call the result from this "hash160" later in the code. Where/what is my error?! |
|
|
|
|
Well, you can look at the price of GPU instances on Amazon for estimates, if you're looking for float-heavy computations in CUDA. Doing the stuff privately would be probably cheaper (no datacenter etc.) but still it gives an estimate.
|
|
|
|
|
You could count how many operations 1 "hash" needs and then extrapolate from MH/s numbers...
One problem is, that with specialized hardware you'd get insanely high efficiency (meaning a lot more operations on Bitcoin relevant work) but you wouldn't be able to use this for anything else. Also monitoring something down to the instruction level is not trivial with modern CPUs which do all kinds of pre-computation, caching of results, instruction sets that do complex operations in one step etc.
One of the closest measurements could be that for example my CPU uses in full load 100W, electricity costs me 10€-cents per kWh, so I could let it run for max. 10 hours (assuming I have the space, cooling and hardware for free) if you pay me 1 €. You could then benchmark whatever you want to run (e.g. Bitcoin mining) on that CPU and work your way from there.
From difficulty you can derive the average hash rate of the past ~2 weeks. With this number you can then (as you know the amount of coins generated + fees paid, as well as the exchange rate to GBP or USD) calculate how much ALL miners earn each day and how much 1 MH/s earns each day. Then you can see how much MH/s different hardware can calculate and see how high/low electricity rates need to be to break even.
|
|
|
|
|
Nope, as I would do the feats that were attributed to a brave Linux hacker as a Windows user, not as a Linux user. Anyways, this is actually besides the point.
The issue that transactions that spend from two addresses do not 100% mean that these addresses are controlled by the same person or entity is something more interesting than whether I manage to compile OpenSSL etc. under Windows.
Especially that constant cries to import private keys here and there might make it tough in the future to even analyze transactions at all.
I also can't think of any 100% sure ways to overcome this problem of people sharing inputs to fool software like this - maybe creating address pools and then looking for suspicious overlaps might be a solution. E.g. 500 transactions each in 2 sets of coupled addresses, then suddenly for a single transaction they bond (even though the "simulated wallet" containing both sets would contain better fitting outputs?) and then they start transacting on their own again never mixing coins... Also transaction timestamps could give indications about users (and adding a second set that has so far completely different transaction patterns might indicate someone trying to mix coins).
|
|
|
|
|
Show Posts
