Bitcoin Forum
May 27, 2022, 12:01:19 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: Possible attack: Difficulty DoS on: May 14, 2011, 05:06:50 AM
this is a good thing; if a single person has enough power to do this, they have way more than 50% of collective hashing power in their control.  So, it would be unwise to continue to run bitcoin
2  Bitcoin / Development & Technical Discussion / Re: [RFC] Requirements for headers-only client? on: May 12, 2011, 01:59:44 AM
All this talk about neato-spiffy future hub-and-spoke supernodes-and-leaves architecture is great.

But I was kinda thinking of first solving the problem that anybody who just wants to download the client, get a few coins from a friend, and then spend them on something has to wait a very long time right now.  That doesn't require any re-architecting of the system or any new networking messages, and should make the "out of the box" bitcoin experience much better for lots of people.

And it is a step towards a future neato-spiffy Uber-efficient hyper++client.


Why would such a person need the entire blockchain?  There's already some hardcoded "checkpoints" in the code; such a person could just download the headers from a recent checkpoint.
3  Bitcoin / Development & Technical Discussion / Re: [PATCH] dumpprivkey and importprivkey RPC commands on: May 12, 2011, 01:54:25 AM
what need is there for dumping private keys?
4  Bitcoin / Bitcoin Discussion / Re: BitCoin and money laundering on: May 11, 2011, 07:17:27 PM
I think it is a valid concern. BitCoin can been seen as cash (anonymous) and is much more convenient to transact with... I'm pretty sure this will be one of the major argument used as soon as the governments will wake up. We better be ready with strong responses.

Isn't the response contained in what you just said?  Anything done with BC can be done with cash.   Despite the possibility of laundering, we've been able to live with cash.
5  Bitcoin / Bitcoin Discussion / Re: Announcing: BitLaundry -- decorrelated payment service on: May 11, 2011, 03:24:45 AM
This is the wrong way to do things.  The right way is to do it P2P, TOR-style.  Have n people rendezvous via TOR and together construct a transaction that takes as input, $X from each of them, and outputs $X-trans fee to n fresh bitcoin addresses.  To do this naiively, the n people would each tell each other their pairs (old addr, freshaddr), put them together in a transaction (randomize the order of outputs relative to order of inputs), and then all sign.  However, this is bad because you have told the other people that your new addr is linked to your old one.  The correct way is to use secure multiparty computation to generate the transaction in such a way that, in the end, all parties only learn the entire transaction (NOT which new addr corresponds to which old one).
Furthermore, if any subset of k the n people collude to break the others' anonymity, the best they can do is know that
the n-k output addresses not owned by them came from the n-k input addresses not known by them, but nothing more.
6  Bitcoin / Development & Technical Discussion / Re: Stopping an attacker who has >50% of the hashing power on: May 04, 2011, 09:27:17 PM
this is an absolutely terrible idea, in addition to the reasons gavin mentioned, because your "fix" has just actually allowed an attacker to take over the network with much less than 50%.  If your system means 95% of new clients cannot control the network, then 5% of old clients can.  So the 5% oldest miners just get together and collude to doublespend.
7  Economy / Trading Discussion / Re: MTGox vs mysterious Russia on: May 01, 2011, 08:08:12 AM
seems like this is a problem we'll all face.  would you mind posting what you're doing, provided it won't help btcex evade?

Can you post the list of IP so those of us who run other bitcoin-related websites can block them?

It's disappointing to know people like this have already found our community; particularly so when I use AWS and get charged per-usage
8  Bitcoin / Development & Technical Discussion / Target difficulty value, enough bits in nonce? on: April 19, 2011, 07:59:06 PM
What is the format of the target difficulty?

e.g. looking at a recent block

http://blockexplorer.com/block/0000000000009e3acd91fa2a9b330b7172ef039997b1207274553e4e3dab468e

The first 12 chars are 0, suggesting the current difficulty is first 6bytes 0 = 48 bits (maybe up to 3 more hidden in high order bits of that 9).

The block header has:
Difficulty?: 92 347.590952 ("Bits"?: 1b00b5ac)

how do I go from that difficulty value to the # of bits?


On the other hand, the nonce field is only 32 bits, so for most block headers, there is likely *no* nonce that hashes to first 48 bits zero, and the only reason a valid nonce is because something else in the header is changing to add more entropy (like added transactions changing the merkle root)

I'm hoping this is wrong, as this would be a really dumb bug and should be fixed immediately if it's the case (by making the nonce atleast the maximum difficulty ever, say 128 bits).  What am I missing?
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!