Before these ASIC companies showed up it was common consensus that a bitcoin ASIC would be very far down the road and that it would cost simply too much money and resources to do it.
Not true at all. It was a matter of "when, not if." Structured ASICs were pursued very early in bitcoin's life. ASIC was always expected as the next step. |
|
|
|
0-value output should be considered already spent for the purposes of pruning. Then how zero-valued input will be connected to zero-valued output? Or am I missing something and there are no zero-valued inputs? Pruning isn't immediate, some cooldown period will be given after an output is spent before it can be pruned. So a 0 output can be used as a 0 input before it is pruned. I don't know how well this fits with the contemporary implementation. ultraprune looks at the set of unspent outputs, zero value or not. There are some proposals to create certain transactions obviously impossible-to-spend, and therefore obviously pruneable immediately (or after some length of time). |
|
|
|
A voluntary organization has been organized to help provide resources to continue that work. Voluntary? What is voluntary by demanding to get paid for the providing of resources? *plonk* |
|
|
|
There is zero hard, technical evidence of anything supporting the trolls positions.
You know what's disturbing to me? That the opposing side are labeled "trolls". No matter which side you're on, which views you have, is that really indicative of honest debate? critic != troll There is a clear difference in this thread between honest criticism and paranoia unsupported by evidence. All the evidence to date is that the Gavin-led dev team encourages a more-decentralized ecosystem than even Satoshi did. A voluntary organization has been organized to help provide resources to continue that work. Absolutely there will be bugs and problems at startup. It is better to start, and fix those bugs, than to endlessly debate about what is the perfect form that satisfies everybody. |
|
|
|
I'm done responding to him, because a man will never understand what him getting his paycheck prevents him from understanding. And boy does Jeff want his untaxed continuously guaranteed paycheck.
See why hazek is a troll? I have self-selected myself out of the pay pool, as previously stated in the main BF thread: I'm quite happy with my day job as a kernel hacker, and don't forsee
leaving there; that makes me a "community dev" for example. (though
I'll certainly accept beer money donations and the like... see sig)Real world continues to disprove paranoid suspicions. Gavin has been doing hard work, the community clearly accepts and approves of it. If a voluntary organization makes that sustainable, that is positive for bitcoin. |
|
|
|
This is disingenuous at best. Of course one can claim they tried to learn how to ride a bike but hey failed, even if they made only one short attempt. But have they really tried?
Just because it didn't work with almost no effort doesn't mean it doesn't work.
Did not work even after paying 15,000 BTC of my own money. Facts and real world experience have disproven bounties as a way of funding anything approaching full time engineering salaries. Stop with the lies and manipulation. Clearly it does work: https://bitcointalk.org/index.php?topic=697.0You fail completely at logic (and economics). The cost of a one-time movie != on-going engineering costs The problem space is finding a way to fund ongoing engineering and testing. One time bursts of funds are not predictable nor sustainable. Try finding an example relevant to the problem. (hint: you can't) A rational economic actor prefers a stable, predictable income stream. |
|
|
|
This is disingenuous at best. Of course one can claim they tried to learn how to ride a bike but hey failed, even if they made only one short attempt. But have they really tried?
Just because it didn't work with almost no effort doesn't mean it doesn't work.
Did not work even after paying 15,000 BTC of my own money. Facts and real world experience have disproven bounties as a way of funding anything approaching full time engineering salaries. |
|
|
|
But still, we have to support them in coloring algorithm, right?
I don't see much point. I'm just calling nValue==0 invalid and moving on. |
|
|
|
If devs think something must be improved and want some money for their job they can perfectly claim a bounty here.
Edit to add:
A good bounty system in the forums not only get devs paid. It could prioritize users needs because they contribute in the bountys they need most.
Already disproven by reality. Bounties have been tried, and did not work. |
|
|
|
I've found a problem: it turns out that zero-valued outputs are possible in Bitcoin. Moreover, Mike Hearn wants to use them to represent bonds in a manner similar to colored coins: https://bitcointalk.org/index.php?topic=92421.0 (search for "zero-valued") So apparently we don't need even a single satoshi per colored coin, 0 works too. Although in that case it isn't subdivisible. I disagree with Mike, here, and am avoiding zero-value outputs in pybond. Here's why: - The reference client does not consider zero-valued outputs standard. Failing the is-standard check implies the transaction will not be relayed by many. Miners may also avoid the transaction for the same reason.
- nValue may be employed to efficiently hold multiple smartcoins, in a single output. For example, nValue==3 may imply you are holding 3 of the same type of smartcoin (bond).
- 1-satoshi outputs have an obvious cost. The fee requirement for relaying "dust spam" also adds to the cost. This economic signalling encourages conservation and reduces blockchain spam.
|
|
|
|
The fundamental premise is flawed... Bitcoin-the-network and bitcoin-the-source-code are no more centralized yesterday, than they will be tomorrow. You are accepting the troll propaganda to call anything that has happened in the past 30 days "centralization." Frankly, the trolls might even be pushing their agenda so hard, that they are creating a Cult Of Gavin Personality where none existed before. Satoshi's design always emphasized user freedom and decentralization of money and P2P network. And the client has stayed true to the Satoshi design. But even more than that, everything we've done has decreased centralization, as you can see in this post from theymos. The dev team practices are far more inclusive, open and decentralized than during Satoshi's tenure. If you look at actual practices employed by the dev team, there is clear, provable evidence of becoming less centralized, in the engineering department. |
|
|
|
1. The name "The Bitcoin Foundation" wrongly suggest that it is the central authority that controls Bitcoin.
[as mentioned before] this is a fair point, but really bike shedding at this juncture. What is a proven better DDoS protection service? 3. There is no safe way for people to have a vote in the Foundation without giving up their identities (which could prove fatal in case of Bitcoin users are declared terrorists, or government tries to confiscate Bitcoins from them).
An understandable criticism, but I think this is within the realm of member policy. 4. Lack of clear privacy policy. No mention about security of member's personal data (are the servers encrypted or whatever).
A fair criticism, AFAICS? 6. The organization is not for profit which means it can't go bankrupt should it provide a crappy service as long as big businesses are prepared to open their purse they can operate indefinitely. (a scary thought)
Bogus criticism: the foundation will disappear if its members dislike its actions. Thus there is a free-market economic feedback mechanism and members are the customers. Another, just like making it easy to fork the code, you can fork the foundation: there is no barrier to doing your own foundation, and doing it better. People will join the better foundation, even devs. True, though I don't see this as a problem. (optional) - The CEO of MtGox (with all the problems with anonymity, taint listing, AML shit, KYC shit and arbitrary account freezing in this exchanger) is a founder.
<shrug> All this is necessary to deal with USD and other fiat exchange. Don't hate the playa, hate the game ;p Every single large fiat exchange will behave in exactly the same manner. |
|
|
|
It's quite difficult to wage a war against good intentions. Best of luck to you if you think you're fighting the good fight.
Al it takes is to use reason and look at the facts. So far there's been little of that and a lot of trickery, falacies and ad hominems. Yes, on the troll side. If you are looking for simple facts, there are these: - There is not a single technical change to the protocol or reference client that may be highlighted as disliked/evil
- There are plenty of technically component people here who may fork the reference client, should any such change appears
- There are alternate client implementations, in various stages of completion
There is zero hard, technical evidence of anything supporting the trolls positions. There is zero evidence of anything beyond the dev team wanting to complete Satoshi's decentralized vision. |
|
|
|
And a lead dev who owns the git access
Fact check: that is incorrect on multiple levels. No one person "owns" git access... if that is even a concept. Multiple developers share git write access -- but that is completely irrelevant, because anyone can fork the git repo the moment a disliked commit appears. |
|
|
|
I don't deny the need. I just don't think the first solution we now have is the best or even a good one and what scares me the most is the inevitable inability of this community to ever replace it with a different one for the before stated reasons.
That is quite insulting to the large numbers of people on these forums who understand bitcoin, and have the ability to fork it at a moment's notice. |
|
|
|
Thanks (again) to socrates1024, pynode has switched to using the leveldb database, plus a flat file format for raw blockchain data. This database upgrade is wholly incompatible with the previous GDBM-based database. When signature checking is disabled, the entire blockchain may be downloaded in 34 minutes. When signature checking is enabled, the blockchain download process takes many hours (6-12), due to slowness of python. |
|
|
|
|
The dev team employs open verifiable processes, making it easy for anyone to fork the code -- or the development team -- and do a better job.
|
|
|
|
I don't see why would an American conference compete with a European one, provided there's some leeway between them. Bitcoin businesses would probably send someone to each. Asia should join too.
+1 Would love to see a conference in China, or Hong Kong. |
|
|
|
in main.cpp around line 2,411 in v0.7 we have: // The message start string is designed to be unlikely to occur in normal data.
// The characters are rarely used upper ASCII, not valid as UTF-8, and produce
// a large 4-byte int at any alignment.
unsigned char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };
What would happen to the blockchain if this was programmed in especially to confuse things? Would it cause a sync problem in the stream? This is known as a magic number. In bitcoin it performs two primary functions: 1) Guarantee two network nodes belong to the same network. 2) Guarantee blockchain file format matches the active network. It performs the secondary function of guaranteeing that we are always sync'd on message boundaries in the TCP stream. |
|
|
|
Is this the pybond project mentioned at the end of the State of the Coin 2012 slides?
That is one distributed bond effort, yes. There is no Official Blessed Distributed Bond effort; each developer just scratches their own itch. In pybond's case, I am writing a basic distributed bond implementation, with no pay-to-policy stuff, just to prove the basics work. So does it work? People willing to use command-line python script(s) can now issue bonds to each other and such? They will be able to soon, yes. "am writing" Right now the P2P network and DHT framework are being debugged. Once that works, it will be easy to hook up the rest. |
|
|
|
|
Show Posts
