|
401
|
Bitcoin / Project Development / Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
|
on: November 15, 2012, 07:14:03 PM
|
I am currently studying Enterprise Development BA at the University of Huddersfield and I have a very exciting business idea for bitcoin that would make use of cbitcoin.
So... please don't take this the wrong way, but what's your prior experience creating and shipping high-quality software? I ask because re-implementing Bitcoin as a first "software-people-other-than-myself-are-going-to-use" project is a really bad idea, I don't see any list of previous work at the RocketHub page, and the 9,000 lines of code you've already written doesn't look like the work of somebody who has professional software development experience (e.g. no makefile/build system ...). Maybe you're a prodigy and will get it right the first time, but you're already at 'cbitcoin 2.0' because you weren't happy with how 'cbitcoin 1.0' was turning out. See the solidcoin/microcash saga for an example of how over-promising "1.0/2.0/3.0" releases destroys confidence. And maybe you CAN point to some other successful software you wrote and shipped when you were 17, in which case I'll shut up and leave you alone. |
|
|
|
|
406
|
Bitcoin / Bitcoin Discussion / Re: Bitcoins at the British Museum
|
on: November 06, 2012, 09:34:23 PM
|
Needless to say, sending funds to the coin has no possible positive outcome and only one possible negative outcome: it encourages them to take it off display. So please don't do it.
+1 : most organizations won't appreciate getting random bitcoin donations, it is a headache for them to figure out how to handle them properly (and they will get pretty grumpy if they spend a couple hundred dollars worth of staff time to deal with less than that in bitcoin donations). |
|
|
|
|
409
|
Bitcoin / Development & Technical Discussion / Re: Help wanted: Mac developer with OSX 10.5
|
on: November 06, 2012, 02:49:29 AM
|
|
Ummm....
.... yeah.
Sorry, but tweaking and recompiling my macports boost to support OSX 10.5, which is not longer being supported by Apple (or Chrome or several other popular projects) just isn't very high on my TODO list.
Figuring out why it used to work is even lower on my list.
Perhaps you can convince people that you're trustworthy, and release a 10.5-compiled binary yourself.
|
|
|
|
|
411
|
Bitcoin / Bitcoin Discussion / Re: [ANN] Bitcoin Foundation
|
on: November 02, 2012, 08:28:23 PM
|
But why not let non-members read about the useful work the foundation is doing rather than restricting read access and adding fuel to the fire about non-transparency, an insider cabal etc.
Because Foundation members posting on the forum may not want the entire world to know that they are Foundation members with a quick Google search-- there is a privacy issue. Somebody could sign up as a member and then try to screen-scrape and republish everything somewhere, so members should assume that whatever they say will eventually be public. And the membership might still decide that read-only for non-members is the right thing to do-- I agree that it could be a good way to attract new members, if the quality of conversation is high. In related news: Foundation board members will be blogging regularly at https://bitcoinfoundation.org/blog/(RSS feed: https://bitcoinfoundation.org/blog/?feed=rss ) |
|
|
|
|
413
|
Bitcoin / Development & Technical Discussion / Re: Transaction options for bitcoind
|
on: November 02, 2012, 06:10:52 PM
|
The relevant settings and their default values for recent versions of bitcoind are: Maximum size, in bytes, of blocks you create:
blockmaxsize=250000
How many bytes of the block should be dedicated to high-priority transactions,
included regardless of the fees they pay
blockprioritysize=27000
Minimum block size you want to create; block will be filled with free transactions
until there are no more or the block reaches this size:
blockminsize=0
Fee-per-kilobyte amount (in BTC) considered the same as "free"
Be careful setting this: if you set it to zero then
a transaction spammer can cheaply fill blocks using
1-satoshi-fee transactions. It should be set above the real
cost to you of processing a transaction.
mintxfee=0.0005
So if you set blockprioritysize=0, you will only accept fee-paying transactions. If you only want to accept 500 or so transactions, set the blocksize to 500 * average transaction size (400 bytes or so) = 200000 The rules for filling up the block are: First, take the highest priority transactions (regardless of fee) and fill up the block to blockprioritysize. (if blockprioritysize is zero, then this step does not apply) Then, take the highest fee-per-kilobyte transactions and continue filling the block until either you run out of transactions with a fee-per-kilobyte greater than mintxfee or the block would be larger than blockmaxsize. Finally: the rules are likely to change again fairly soon so that groups of related transactions are considered together ("child pays for parent", so customers can send zero-fee transactions to merchants, who can create a child transaction with a fee when they need the transaction to be confirmed). |
|
|
|
|
416
|
Bitcoin / Project Development / Re: Bitcoin committee!
|
on: October 30, 2012, 03:46:12 PM
|
|
The first thing your committee should do is come up with a better name.
There is a reason the phrase "designed by committee" is one of the worst things you can say about a project.
And if your committee can't agree on a better name... then you're doomed before you start.
|
|
|
|
|
419
|
Bitcoin / Development & Technical Discussion / Re: is this a Satoshi client bug in an old transaction ?
|
on: October 27, 2012, 07:41:37 PM
|
I think the protocol should not be defined by a particular implementation, even if that one was written by Satoshi.
Okey dokey. Reality is that the protocol IS defined by Satoshi's implementation. This isn't like HTML where the worst thing that happens if two implementations disagree about the spec you get different looking web pages. Our worst case is much worse (if two popular implementations disagree then we potentially wind up with a blockchain split, and, essentially, two different currencies). We need help creating tests to make sure different implementations agree on the rules; as you re-implement the protocol please set aside some time to think about that and help! |
|
|
|
|
420
|
Bitcoin / Development & Technical Discussion / Re: SHA-256 broken, collisions found... Bitcoin then?
|
on: October 27, 2012, 07:14:12 PM
|
...On the other hand, if it (MD5) was used in bitcoin transactions, those transactions would still be totally safe, for at least a few more years, because all of the attacks require conditions that can't be met in the bitcoin system.
I think that is a good thought experiment: If you replaced all uses of SHA256 in Bitcoin with MD5, what attacks would be possible? (please check my work, I am not an expert on hash collisions) Well, to generate a collision: ...the attacker needs to generate ... a 128-byte block of data, aligned on a 64-byte boundary that can be changed freely by the collision-finding algorithm.
Block hashing would be safe, for now; the block header that is hashed is only 80 bytes long, much less than the 128 bytes of wiggle room needed to find a collision. I believe an attacker could easily produce two different non-standard transactions that hashed to the same txid. That would be a disaster, they could split the blockchain and/or double-spend by broadcasting one version of the transaction to half the network and the other to the other half of the network. To split the chain the attacker would mine a block containing the 'poison' transaction hash, and then broadcast two versions of the same block, containing the two different-but-same-hash transactions. Half the network would think that block contains 't1', and half 't2'. Everything would be just fine until the attacker spent the outputs of t1 and/or t2... then Bad Things would happen. Double-hashing doesn't help at all: If HASH(t1) == HASH(t2) then HASH(HASH(t1)) == HASH(HASH(t2))
I do agree with everybody who points out that SHA256 isn't close to being broken. If it does ever start to get close, then I'm sure we could figure out a backwards-compatible fixes and phase them in (something like "a block's coinbase transaction must include a SHA3-based transaction merkle root", create a new version of OP_CHECKSIG that used SHA3, roll out a new alert system that used SHA3, etc). |
|
|
|
|
Show Posts
