|
Whether or not your pulls get accepted depends on a rough consensus of the devs. Some of them have a bit more pull than the others, but there isn't like a formal voting process.
If you are submitting pulls, you'll get emails from github when people comment on it. Pay attention to those, the people making them are giving advice earned through hard experience. Address their concerns when you can, and be prepared to defend your choices.
Also start hanging out in #bitcoin-dev on IRC. It can be very helpful to start conversations about your pull, particularly with the people that have commented on it. Be polite, and keep in mind that they can be busy, even if you can't see it.
|
|
|
|
|
You should really get the financial statements and releases marked as free articles so that people can read more than a few of them each week.
Interesting IPO, by the way. It was pretty obvious which guys had done their math up front, but I wasn't expecting it to get anywhere near 1.03177.
|
|
|
|
Running bitcoind, the service behind qt is the simplest valuable contribution to the network.
Perfect, thanks for your suggestion. Using the bitcoind service is definitely the right way to go (didn't know this, as I was normally using the windows Qt client). I guess I should disable the default 8332 port (and open 8333), right? Also because I've to specify username/pass for that configuration, as this is unknown to user "Anonymous". My goal is to be a "supernode" for relaying blocks and transactions, and clients can use my server to download the blockchain. Could you guys give me a few hints regarding the configuration? Also regarding the fact this server is directly connected to the internet and has IPv4 & IPv6 available. Besides that, under the Windows client I'm often facing I'm not getting higher than 8 connected clients, of course I not want this for this "supernode" (the server used should be able of 1000+ connections). Any idea's regards to that issue, as using UPnP doesn't make sence (as it's directly connected to the internet)? edit the source code to allow more set a decent password, like 4o3@OJdmXZLF:M4 l23jO$:J343$OJCMZXLK:OIDPWJA and 8332 doesn't need to be disabled. there are some programs you might use where you'd want to have your rpc port open. change the port # if the password itself doesnt make you feel safe. 8333 needs to be open if you want to accept outgoing connections edit your ethernet settings to accomodate a thousand people sending mostly small bits of data If you don't need RPC, disable it. If you do need RPC, but only internally, block the RPC port at your firewall and specify only your internal IPs in the bitcoin.conf. If you need RPC from the internet, use a good password and SSL. |
|
|
|
So it's effectively destroying some bitcoins.
Correct. This is one of the many places where bitcoins can be destroyed, and have been destroyed in the past. I'm not aware of any ongoing issues with this. |
|
|
|
You're way more knowledgeable than me, so I gotta ask. How do transaction fees reach the dedicated miners?
Each block is allowed a single transaction without an input, which the miner normally directs to a key they know, effectively their reward for finding that block. The size of that magic transaction is limited to not more than the sum of the fees (which are just the differences between the outputs and inputs of each individual transaction) plus the subsidy. Do you mean a miner may produce a valid block with total reward less than fee+basic_reward? Yes, and a few of them are in the block chain. From main.cpp, CBlock::ConnectBlock() : if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
return false;
Also in main.cpp, GetBlockValue() is a simple function: int64 static GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees;
}
|
|
|
|
|
Yes, a RAM drive is WAY faster even than SSD. It works even better if you do your IBD from another machine with a RAM drive.
|
|
|
|
The only way to "equally distribute" inflation is to give the new money to each holder of the current money according to how much money they already hold. And what would be the point in that?
Even that wouldn't be equitable. You would also have to adjust all prices and contracts, taking into account that the marginal utility of money relative to other goods will vary from individual to individual, and that the existing contracts may already have taken into account a greater or lesser expectation of change in the money supply over time. In short, absolutely equitable manipulation of the money supply is an impossible goal. The necessary information simply isn't available, even if you had the power to make those changes. If you updated all paper, coins, account balances, bills, contracts, books, etc, etc, etc at the same time, then the marginal utility of money relative to other goods would be unchanged by proportion. There would be a tiny temporary effect if you didn't update people's memories at the same time. But say that you could... It shows that perfect uniform inflation or deflation (however impractical in reality) would have no effect on anything at all. Which means that any effect that inflation (in reality) has is purely caused by unfairness. |
|
|
|
Is there a way to register watched addresses in the standard client?
Not yet. There is a pull request implementing bloom filters that should make that easy to implement. Or, could 'listunspent' be extended to take any non-wallet address as an optional parameter?
No. The reference implementation doesn't keep a master map of all addresses to unspent transaction outputs, and adding such an index for the small number of services that need to look up arbitrary addresses doesn't make sense. I'd suggest you -blocknotify and the getblock() RPC call to maintain your own index of address --> unspent txout. Even getblock is used, it only returns the txid, and gettransaction does not show the tx if is a non-wallet id. What should I do? Also, is there an ETC for the support of "watch-only addresses"? getrawtransaction will return non-wallet transaction, and you can decode the output with decoderawtransaction |
|
|
|
It doesn't make sense to have the boards fully populated and then add the ASICs. You'd have to reflow the boards twice, and there's no reason for that. Maybe Friedcat will confirm, but I would guess that they had the PCBs and stencil ready to go, and will now fully populate the boards. This would be similar to Avalon, where they designed the PCB and tested it with simulated signals prior to the arrival of the ASICs.
This, reflow. Boards with surface mount devices are rarely (never?) half-made. And sadly, if the board has small packages, it can be extremely difficult to crank one out by hand. The QFN 40 package they showed is nearly impossible to do by hand. Watch this video. Note that the board they are actually working on is totally bare, regardless of what they say about kapton tape. One thing that they can do just to validate the chip is to build a second board design with sockets. ZIF sockets for MLP packages like the QFN 40 are expensive, like hundreds of dollars each expensive. Unless they spent thousands on sockets, the blip from them testing will be lost in the poisson noise that dominates all of our short range hash speed estimates. Building a one or two chip socketed board seems prudent, and I suspect that they did. But of course, I have no more information than anyone else here. |
|
|
|
|
Meh. The price always goes up by about 30 cents on/around January 9th, 2013.
|
|
|
|
|
My understanding is that getting a program to run in sleep mode is a contradiction. Sleep mode is the mode in which programs to not run. DRAM refresh is reduced to the bare minimum and the CPU is deactivated until a hardware signal awakens it.
If you meant "when it leaves sleep mode", you'll need to have a program that watches for the SystemEvents.PowerModeChanged event, and then triggers whatever you need to do. Such a utility may already exist.
|
|
|
|
|
Longer answer.
Sending bitcoins requires two parts, one public and one private. The public part is the transaction that you want to redeem. The private part is the key that corresponds to the pubkey (or hash) embedded in that transaction. (These can all be multiple, but I'm going to try to keep using the singular words)
While your node is downloading blocks, it compares each transaction in each block against the list of keys it has in the wallet. Matches get copied into the wallet.dat file. It can either match because the output pubkey hash belongs to one of your keys, making that transaction a credit, and thus a spendable coin, or because an input is signed using one of your keys, making that a debit, and making it an unspendable coin (unspendable because it was already spent). The client shows you a balance by adding these up, but the concept of a balance does not exist in the system.
If you back up your wallet, and then send money to one of the addresses in that wallet while the backup is offline, when you go to recover it, that transaction won't be in the wallet, and you'll need to wait for the chain to download. Not necessarily the whole chain, just far enough to include the block you need. The same thing can happen if the transaction you need gets corrupted or some other strange thing happens.
|
|
|
|
|
It is only optional if the wallet.dat file already contains the transaction that you want to redeem.
|
|
|
|
I'm working on some Bitcoin-related software and had a few questions... FYI, I'm using C++ and C#...
1) Where can I find information/guidelines/tutorials for connecting to the Bitcoin network?
2) What's the easiest way to get the current mining difficulty from the network?
3) Is there a simple open-source BTC client written in C# I can have a look at and dissect?
4) Are their any "best practices" articles about programming for Bitcoin?
More information would be very useful when answering you. For example, in question 1, are you asking what it takes to make a program that talks to other bitcoin nodes using the p2p protocol? If so, the network information can be found here. Actually getting connected isn't too bad. You connect the socket, go through the version/verack handshake, and you are on. After that, it is just a matter of not doing anything that make the other side think it needs to disconnect you. For #2, "the network" doesn't know the difficulty. Each node knows it, but there is no point in communicating it over the p2p socket, so there is no message for it. However, if you grab the latest block from a node, that block header will have a target field, which you can use to calculate the difficulty. Being sure that a given block is the "latest block" is not trivial. Vastly easier is to just run a node somewhere, and use the getmininginfo RPC call. #3 Not that I'm aware of. The good news is that the reference client is open source. Even better, it is also Free Software (MIT license). The bad news is that it is C++. #4 changes dramatically depending on what you really mean by "programming for Bitcoin". If you are writing wallet/node software, the best practice (or only practice, really) is to go through the reference client with a microscope and faithfully recreate every wart, wrinkle and bug that you find in it. If you are just looking to hook some stuff up using RPC, best practices will be vastly different, since the node you are RPCing to already manages the burden of validation and correctness. In that case, the best practice is to use strings to represent amounts.  |
|
|
|
|
ASICMINER 10 shares @ 0.1 BTC each
|
|
|
|
I offer this in hopes that it helps someone find a way to think about bitcoin's inner workings in a way that is useful to them. There are no addresses. There are no balances. Bitcoin is a chain/mesh of transactions. Those transactions go by many different names, sometimes "inputs" or "outputs", sometimes "vins" or "vouts", sometimes "coins". I like to think of them as "coins", but it requires special metaphors. Your wallet is a collection of "coins", each of which has a specific value. To complicate things, sometimes we think of the unit that the value is expressed in as "coins" too, but try not to do that for a little while. When you want to spend, you select a bunch of your "coins" such that their value is equal or greater than the amount you want to spend. You then prove that you "own" those coins by signing them* , and you bundle them together and specify one or more outputs, each with a specific value. Think of it like melting a bag of "coins" of different values and minting them into a new bag of "coins", with the network checking to make sure that you don't try to make the value of the output bag more than the value of the input bag. Of course, these aren't real "coins", there isn't a thing being acted upon. These are abstractions built upon abstractions. * Technical note, typically the signature is calculated based on a subset of the entire event (the transaction), rather than just signing the input by itself. This is because you usually care more about where the spend is going than where it came from. |
|
|
|
|
This system seems to rely on origin information in messages, which the bitcoin network does not have. In the algorithm, as I read it, their messages include node IDs, and a node de-prioritizes peers when they get a message from that peer via another peer. I stopped reading shortly after I figured that detail out, so it might also require message timestamps (if it doesn't, you could add them and then tweak the algorithm for faster convergence).
Bitcoin messages are anonymous and (mostly) timeless. I don't see either of those changing any time soon, particularly since network efficiency is neither a problem nor a goal for us.
|
|
|
|
I wish I could see some actual math reasons on why politicians are so damn scared of paying off their debt but to me it seems like the only reasoning they have for not paying off their debts is ideological neo-keynesian bullshit where they want to keep inflation going as much as possible to keep the never ending lending up from what I know anyway.
Well... If you are interested in a serious understanding of how it works today, google Steve Keen and read a bunch of his blog posts, lectures and papers. The important words to be looking for are "credit impulse". Short version: Investment causes production causes consumption. It can be no other way, because eating an apple can never happen before the apple tree grows, and the tree can never grow before it is planted. In the same way, a computer came from a factory, and the factory had to be built. But, under keynesianism, we've shifted the way we do our accounting so that consumption is primary. GDP, for example, is a measure of consumption (spending), rather than a measure of production or investment. So, when spending slows, all of our accounting shows that the end of the world is coming. When consumer spending slows, the government must step in to prevent the end of the world. And governments don't have assets, they borrow. |
|
|
|
|
Show Posts
