Sad that for such a new piece of technology, we're already struggling to maintain backward compatibility with older hacks.
I think users with older clients, holders of older bitcoins quite appreciate the struggle to maintain backwards compat. Nobody wants to wake up in the morning, to discover that their money is unspendable outside of a required upgrade. |
|
|
|
Up is down, left is right. That's all I hear. All check and balances that we needed, we had until 2 days ago.
Before: Gavin and other lead devs could have been funded by shady unknown, undisclosed -- or, more realistically, non-shady but unpredictable -- sources. After: Gavin and other devs may be funded by known, disclosed, predictable sources. |
|
|
|
Has hazek edited any other non-hazek post in this thread? If yes, what were the edits?
Has hazek ever edited any older posts of the following people: Gavin, me, satoshi?
Is there an audit trail of moderator post edits?
that's quite serious. i suggest to open a thread in the meta forum https://bitcointalk.org/index.php?board=24.0Already opened a thread in the Staff forum (which might not be visible to non-moderators). |
|
|
|
Has hazek edited any of your other posts?
Has hazek edited any of my posts?
Has hazek edited any of satoshi's old posts?
Maybe you should read someone's replies to accusations before judging people?  None of the replies answered any of the above, specific questions. It seems that hazek's intentions were good, whereas Gavin is simply spreading FUD by selectively pulling things out of context.
Yes there was an explanation, possibly innocent. It was good that he responded -- thanks! I agree the intentions may have been innocent, but it does not look good as a critic, to edit the post of those on whom you are critical. I remain curious about the following unanswered questions: Has hazek edited any other non-hazek post in this thread? If yes, what were the edits? Has hazek ever edited any older posts of the following people: Gavin, me, satoshi? Is there an audit trail of moderator post edits? |
|
|
|
After playing some satoshidice I had a lot of 'dust' in my wallet. I made a transaction that combined a bunch of 0.00000001 outputs with some old large outputs in an attempt to tidy up my wallet a little. The satoshi client determined that no fee was required, and so sent the transaction without a fee.
The miners seem to disagree. The transaction isn't getting into blocks. I expect if I wait long enough it will happen, but I'm wondering whether there's any way to cancel the transaction and send it again with a fee this time.
Right now the answer is lame: wait a while. If you don't see it confirmed, hope that it is forgotten by miners and network and initiate manual wallet coin recovery. Double-spend with additional fees, and hope that works. There is a proposal on bitcoin-devel for giving transactions a defined lifetime in the "memory pool", after which they are ejected. Since the bitcoin client has designed from Day One to periodically resend unconfirmed transactions, this should increase the probability that you can cancel/update a transaction. |
|
|
|
I looked at the build steps for the official client and ran home screaming to mommy.
Really? $ cd bitcoin/src
$ make -f makefile.unix
Perhaps with optional build-openssl and build-bdb steps first, if your distro does not provide.  If your OS makes it more difficult, get a better OS ;p |
|
|
|
But a bigger point is simply... please please please do not encode data inside pubkeys. Use OP_DROP or another visible solution. In-pubkey makes it really difficult to detect and manage, for those of us trying to help the blockchain software Err, it isn't "data inside pubkey", it is pubkey itself. I.e. if serialized pubkey matches pubkey associated with a certain color then this TXO might be of that color. I really do not understand what's difficult about comparing two pieces of binary data. You can use something as dumb as grep to detect potentially colored TXOs. Are you talking about valid ECDSA keys, or random garbage stored as a guaranteed-to-fail pubkey? |
|
|
|
I raise the point because that is precisely what distributed bonds proposes, with its financial P2P network and financial hashmap. I feel like a simpler and a bit more centralized solution would offer 95% of joy for 5% of effort. I haven't analyzed it thoroughly, though, so I can be very wrong here... But still, I would prefer seeing something simple up and running to waiting for a perfect solution to be built. Oh, I completely agreed with you Centralized solutions are easier, and still provide plenty of value. However, given real world experience in this community, such exchanges also have a nearly 100% chance of (a) getting DDoS'd and (b) getting attacked by determined, knowledgeable thieves. That is why decentralized, open-review systems are preferred. |
|
|
|
Surprising that mining has not yet moved away from difficulty-1 mining.
what is the significance? Same payout, less server <-> miner traffic. |
|
|
|
First, you edited my OP and broke all of the links changing .org to .com.
Then you sent me a PM asking if it would be ok to move this thread to Service Discussion. WTF? If discussion of the Foundation isn't a good topic for the main Discussion forum what is?
Woah. That is a significant abuse of moderator power. Has hazek edited any of your other posts? Has hazek edited any of my posts? Has hazek edited any of satoshi's old posts? Editing another's posts is far worse than deletion, when it comes to abuse of moderator powers. That is misrepresenting someone else's identity. Edit: Yes, Gavin should have signed his post with PGP, to more easily spot things like this. |
|
|
|
No, that is the opposite of elegant: it adds blockchain bloat that is difficult to recognize or avoid or prune. It is elegant in solving a problem with accidents. It isn't efficient, yes. But OP_DROP adds some bloat too. Any added data, OP_DROP or fake-pubkey or whatever, typically requires two parties to agree to maintain the format of the in-chain metadata. But a bigger point is simply... please please please do not encode data inside pubkeys. Use OP_DROP or another visible solution. In-pubkey makes it really difficult to detect and manage, for those of us trying to help the blockchain software |
|
|
|
Imagine you want to have a million private currencies... So you need to add a million of hashes to each block... This simply won't work.
Incorrect. You misunderstand how merged mining already works. You add one (1) merged mining merkle root to the block, covering all merge-mined currencies. Each currency is an entry in the merkle tree. That can then scale to a billion private currencies, without bloating the block. Merged mining is obviously far more scalable than any solution that requires blockchain bloat, however minimal. The downside is that you cannot have atomic transfers between a smartcoin holder, and a payment holder. |
|
|
|
The other goal is preventing forks in the Bitcoin network, and designing changes. The foundation ensures its the authority by paying for development.
No, the foundation ensures it is one of many paying for development. (if nobody else pays anyone else, then, yes, it is the only one paying) Anyone can - Join the dev team
- Hire your own dev team
and participate in the open source process. That is why we make it so easy to fork the code: easy software replacement and easy dev replacement. |
|
|
|
Fully decentralized would mean any two users may meet at any time, and there is an efficient method of advertising (bids, asks) and meeting in the middle (transacting). Um, maybe. It depends on how you define "decentralized". But, of course, there is a whole spectrum of solutions from a handful of large providers to full p2p with millions of nodes. (Which I would call 'distributed', maybe.) Somewhere in the middle there is a federation of order book providers with a significant number of members. I would liken them to mining pool operators (which are numerous), thus it might be "decentralized enough" for Bitcoin crowd's taste. Full p2p would be cool, but it has numerous problems. I raise the point because that is precisely what distributed bonds proposes, with its financial P2P network and financial hashmap. |
|
|
|
Bitcoin Foundation web down. Let's all enjoy the flavour of the centralization. Now imagine a newcomer army complaining about the impossibility of enjoying their foundation membership special fees in the Mtgox. Or yelling they abandon bitcoin because they can't download the "official" bitcoin client and they don't trust any other. These comments are just plain stupid and pure FUD. Just like Bitcoin.org today, the Foundation will surely not just instruct people to use the official client. That would be ridiculous these days when we have so many excellent wallets. It was understandable before but not anymore. Absolutely. As gavin said, To take one example, I don't want to be the centralized decision-maker who
figures out who should or should not be on the bitcoin-press mailing list that
is on the bitcoin.org homepage any more.The bitcoin.org homepage is already moving in the direction of multi-client, in fact: http://bitcoin.org/clients.html Hopefully there is a better process for choosing the default client on the main page (or simply those front-page links get removed). We want to make as much of the facilities as possible decentralized. |
|
|
|
1) you assert that "Bounties fail. KickStarter-like provides unpredictable bursts. Anonymous donations are a beer-money tiny trickle. Self-supporting through for-profit ventures steals developer focus and introduces clear, direct conflicts of interest "
I disagree. Has Gavin tried the bounties route? Has he tried a kickstarter like fundraising? No. You merely assert those methods or some other method doesn't work.
It is simple observation. The self-supporting route was already tried. Bounties continually fail on this forum, as well as outside. I have personally paid over 15,000 BTC of my own money in bounties, to juice the bitcoin economy. Have you? For KickStarter, every single example is a single burst of money. That is by definition not a predictable stream of income, year after year. Any sane developer trying to support a family will prefer a predictable income. Put on your thinking cap (and take off the tin foil one). 2) you identified a danger and instead of offering a service and letting the market decide whether it wants/needs it, you have self imposed yourself over all users without them having a choice while telling us that this is the only way it could have been done - again a mere assertion.
A group of free individuals created a voluntary organization. The free market did decide. The world is full of example where free-market, profit seeking companies get together in a neutral, members-based trade organization for topics of mutual interest. 3) you keep pointing out I can start my own solution and yet I would need to persuade the lead dev and his team to join me without whom my foundation's relevancy would be non existent which you know damn well but refuse to acknowledge.
No, this is open source, free market -- instead of whining you could do something. If there is a critical mass of people who dislike the Bitcoin Foundation, band together and propose alternate or matching funding. Then propose your own development funding scheme. Or fund your own team of developers, independent of BF. It seems if the dev team were rational economic actors, a proposal of - Let BF fund 50%
- Let hazek's foundation fund 50%
- Therefore, no one entity can claim >51% control over funding
could be economically in their interests (more diverse funding sources) and placate some of the bitcoin forum critics. You are, therefore, assuming failure when in fact there are many possibilities for a do-er. The community will follow a good idea, especially right now, before the supposed BF-led drones take over. Yes Bitcoin development might be facing a freight train, but no your solution isn't the only solution and isn't the best solution and yet you forced us to swallow it no matter what the consequences while making it virtually impossible to compete.
1) BF is a voluntary organization. You are forced to swallow nothing. 2) The challenge is, as always: provide a better solution. |
|
|
|
Just use OpenSSL for bignum and move on. OpenSSL is a giant pain in the ass to build. My preference for a repository is that everything compile by just pushing a button. No external dependencies (especially "wget", ick). It should not be necessary to install anything else. No python, no separate repositories, etc... I'm surprised by this. I mean, openssl might be hard to use and to link, but what's the alternative exactly? Reinventing the wheel each time you do some code with cryptography? Yeah, it is silly and not realistic for any large software, because your maintenance effort scales up to involve tracking $N third party repos for security fixes and other updates. When Fedora or SuSE Linux distros push out zero-day fixes for OpenSSL or zlib, for example, your project remains vulnerable. |
|
|
|
If you think all three operators are assholes, you can run your own exchange software: there is almost no barrier for entry. Your exchange will be just as good as any other in terms of security and compatibility. Your only challenge is to attract users to get some market depth.
Yes, agreed. I believe this means that exchange is fully decentralized. And colored coins are important here because they are the substrate which guarantees security and universal recognition of asset ownership.
Fully decentralized would mean any two users may meet at any time, and there is an efficient method of advertising (bids, asks) and meeting in the middle (transacting). Creating your own exchange, due to lower barrier of entry, simply means it is less centralized. As you can see with, e.g. MtGox, being able to start your own exchange does not imply lack of defacto centralization. |
|
|
|
Despite these and other theoretical ways to trace I'm not aware of an example of anyone provably tracking stolen funds to date. Anyone?
Well, it is trivial to watch stolen coins move through the blockchain. You don't know who has them etc. |
|
|
|
|
Show Posts
