|
I can't imagine this being good at all for miners, as the cost of producing gold continues to rise as well. I was reading that miners needed between about $1,000 and $1,400 per ounce to break-even (net-profit). Gold is falling to the point that mining begins to become unprofitable for many miners.
If people are worried about central banks selling gold (Cyprus is only 14 tonnes), did they think about the production of gold that may reverse as unprofitable mining operations are closed? Gold production was about 2,700 tonnes in 2011.
So if the reason prices are down is due to this irrational fear of central banks selling, the pressure on production should create a floor around $1,000 and $1,400, as the loss in production will surely outweigh any central bank sales. It would depend on how stupid investors are, as well as how miners would precisely cope. At the end of the day, they need a minimum price of gold to make enough gross profit to cover their overheads.
But if the prices are manipulated (Almost certain, but to what extent I don't know), then who knows how far down gold can go.
It makes little sense to me why the possibility troubled countries may sell gold reserves would hit gold so much, and anyone that listens to Goldman Sachs is an idiot.
Can anyone else make much sense from this?
|
|
|
|
|
Yes, you understand me, nodes need to ensure the entire block is validated, and thus that the entire block is broadcast to the appropriate nodes. Miners could also include malicious transactions which force particular nodes to do all of the work.
If you took my idea, you could add metadata to the transactions. By metadata I mean data which is additional to the transactions but provides further information about that transaction. This data could include the location of transactions referenced by the inputs in the transaction, in the blockchain (ie. block hash and transaction index). Then nodes can fetch the required transactions if needed, so they can check the outputs/inputs. They can do this if there is a way of determining what nodes should own which transactions. This means there should be a consistent method in which nodes calculate which block segments to validate and store transactions for.
|
|
|
|
|
Yes, you are right. You would need the referenced outputs, which would cause problems. Yet I don't see how your idea solves this. If you are validating particular outputs through an identification system of some sort, then you would need to be given the inputs that spend the outputs you are watching. How do inputs can relayed to the appropriate nodes? Also how do you ensure that all the transactions are completely validated, including all of the inputs?
Splitting blocks by the merkle tree solves the last problem because there should be honest nodes covering the entire merkle tree, but then you have the problem of getting the outputs. There are problems to both ideas.
|
|
|
|
Have you reconsidered my proposal to split the blocks by the merkle tree and not by addresses and by some mechanism to identify non-address outputs? I've proposed a method for splitting blocks (though I need to update it). I think this proposal should come before the swarm client proposal as the first stage in achieving it and dealing with scalability issues that may arise: https://en.bitcoin.it/wiki/User:MatthewLM/ImprovedBlockRelayingProposalBy asking for, and relaying these "block segments", as I call them, you could validate the transactions in x-of-n segments. When you find an input referencing an output that does not exist, the node may then ask peers which own earlier segments in the block, if there is a an output. This is required because inputs can reference outputs in the same block, as long as the output comes earlier. The idea requires trust of other peers to function, though nodes can relay the invalid transaction reports they receive, so that these reports can propagate through the good nodes. The reports don't have to only come from the nodes which specifically look at that segment. And while it seems simple in theory, it will no doubt be problematic in practise, as I foretell. |
|
|
|
|
There is a gap in the market for a UK based exchange with free to very low cost bank transfers, and greater reliability, and of-course for other counties and in general considering Mtgox is not very good.
I don't want to use MtGox to buy or sell at the moment. I still can't get my head around how to do UK bank transfers and how much it will cost. I could hold cash in Mtgox and re-buy bitcoins later of-course but I don't feel secure with Mtgox with previous problems they have had and the general feeling of unprofessionalism I get with the website.
I thought there would have been more exchange competition.
For now I'll keep my bitcoins regardless and at some point I'll spend them within the bitcoin economy, where I can, which I think is the best thing I can do.
|
|
|
|
I had to share this.  Am I fine using the 0.8 to transact and is something this sort likely to happen in the future? Thanks!
It's only required for miners (Edit: They can use v0.8 under the default settings apparently), providing miners stick to the v0.7 compliant rules. |
|
|
|
Why smile?
The OP said don't bother with speculating, just buy low and sell high. In other words, don't bother speculating, just speculate. No, he said buy low and sell when you need fiat. More or less I meant that. Buy when it dips and sell when you need to, ie. Need to buy stuff. |
|
|
|
If Mt. Gox can keep it's shit together, up. It seems people stop buying when the lag hits, but people get scared about not knowing what's happening and sell to be on the safe side. I blame Gox for bringing us below $45 again.
I haven't experienced this myself but it seems many people were complaining yesterday, so this may have some element of truth in it. |
|
|
|
|
Somebody please make a decent exchange with free UK bank transfers. Bank transfers is where the costs become a joke.
|
|
|
|
|
I haven't got a clue. I'd rather just hold onto my bitcoins until I need to sell them. I'm hesitant to sell since intersango has lost a lot of liquidity and trust from people after the bitcoinica incident, and I don't like the idea of selling for GBP on any other exchange. I'm worried about ridiculous fees and security issues. I guess I can always store GBP on MtGox without a bank transfer and buy bitcoins back in the future. Yet I'm unsure as to if selling is a good idea regardless. Bitcoin is very volatile, so best to buy when on dips and then sell when you need to, rather than speculate, I think.
|
|
|
|
I don't understand why nobody donates to this, this is easily one of the most important developments in the Bitcoin world today.
Thanks very much to Matthew and keep up the good work!!
No problem and thank you. Though there have been people who have donated so far and I appreciate all donations very much. Anyone that has donated so far, as a small token of appreciation, can still be placed on the http://cbitcoin.com/donors.html page if they contact me with proof they own an address where the donation was sourced. |
|
|
|
|
Are you saying that practically all architectures have compilers that support the packed attribute?
There are the other three reasons to keep it the way it is.
|
|
|
|
Hello. I wish to thank everyone who has supported cbitcoin so far. I appreciate all donations and help very much. For those that are unaware, cbitcoin is a C bitcoin library in development which aims to make bitcoin development more accessible and easier, thus hopefully opening bitcoin to more innovation. Please see this topic for more information: https://bitcointalk.org/index.php?topic=123488.0The reason I am making this topic is because some people mentioned the usage of crowdsourcing websites for raising money for cbitcoin. I'm making this topic to notify that if you want to support this project with donations through Rockethub you have 8 days remaining to do. I thank K. Darien Freeheart and Patrick Levell who have donated so far via Rockethub, and all the people who have donated via bitcoin. You can donate here: http://www.rockethub.com/projects/11976-cbitcoin-developing-bitcoin-s-futureDon't be afraid if you do not wish to donate via Rockethub. You can still donate via bitcoin with the address: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9 and you can be listed on this page: http://cbitcoin.com/donors.html if you can prove you have donated. Thank you very much, Matthew Mitchell. |
|
|
|
|
OK Mike. I see four problems with this:
1. It's more confusing and counter-intuitive in my opinion, though different people may think differently of-course.
2. The way I do it works and is simple enough.
3. What about endianness?
4. What about compilers for embedded systems, which cbitcoin may (may being an important word) be suitable for in the future?
|
|
|
|
But the contents are unknown. Either an integer or a pointer could be used depending on the implementation. And any optimisations would be useless in this case.
No, you're doing something wrong if you're stuffing/casting pointers into integers like that. File descriptors and handles returned by the OS are different in every way from a pointer. Yes they are different than pointers, hence why I'm using a uint64_t that can hold all integers and all pointers. These functions that have uint64_t arguments are declared in the core library only as weakly linked prototypes. The functions are implemented outside this core library. These implementations can use integers or pointers. I could make assumptions such as that these implementations will only want to use integers for sockets, pointers for random number generators etc. but I feel better making so that people can implement them with integers or pointers as they choose up to 64 bits. From what I know this causes no problems. Any losses in optimisation would be too small to worry about. The only thing the core library that holds the integer representation does, is store that integer and pass it into functions that are implemented outside the library. These implementations will cast the integer into the appropriate type for that implementation. |
|
|
|
|
But the contents are unknown. Either an integer or a pointer could be used depending on the implementation. And any optimisations would be useless in this case.
|
|
|
|
Checking for malloc returning NULL is hardly going to slow down the code. Though saying it clutters up the code is a fair point. Learn about __attribute__((packed)) and bit fields. You can use a struct to overlay any arbitrary piece of memory.
I do not want to do this as it is bad for portability. I'm not going to use void * after-all as I just remembered the network code uses integers returned by socket(). Best keep it the way it was before. uint64_t can take any pointer or integer, so it's safest to just use that. Edit: The valgrind errors do correspond with the line numbers for me. |
|
|
|
Hello Mike and thank you for taking a look. Are you sure you want to try and write OOM-safe software? I know from experience that trying to handle NULL returns from malloc is insanely difficult to do correctly, almost no software these days even tries. Aborting the program if malloc returns NULL is invariably the right decision. I don't know about other systems but Linux has an OOM killer that makes checking malloc redundant anyway. However, I'm adding checks for the sake of better software regardless. It's not hard to add these checks. Testing them is more difficult. Handling OOM conditions is more important when you are dealing with embedded systems and various low memory environments, so if ever the ode was to be used for these applications it would become more useful. Also casting pointers to integers like that is likely to cause issues, which is why the compiler is warning you about it. The compiler is not warning about casting pointers to integers, it's warning about casting a pointer to an integer of a different size. This is not a problem in this case but it doesn't matter since I'm changing my code to use void * instead. Don't disable compiler warnings! They are there to help you. Warnings are not necessarily problems. I could perhaps use GCC diagnostic ignored on certain files to avoid making errors ignored for all files. The valgrind stack trace doesn't match the code on github, by the way, so if you're asking for help there you'd need to post one with fresh line numbers. OK I'll fix that. The code in that part of the file is very hard to read. I strongly recommend you use structs to avoid code like this:
// Checksum
memcpy(peer->sendingHeader + 20, toSend->checksum, 4);
+ 20 here is a magic number, it's not needed because the message headers have a predictable layout anyway so you could just cast the entire header to a struct and then use real identifiers. I'll add an enum for the offsets, but I can't use a struct since this data is to be passed through the network. Also, try to avoid redefining the language. Here:
// Need to send the header
if (NOT peer->messageSent) {
// Create header
peer->sendingHeader = malloc(24);
peer->messageSent looks like it's being treated as a boolean (i assume that NOT is defined to be !) but then later on it's treated as if it was an int. If it's a number it's better to write out the integer comparison explicitly. I have the habit of using !/NOT (I've used NOT since I always overlook !) to mean == 0. I can see why that may be misleading. It will take a while to convert all instances of that, but I'll add an issue on github to record that. |
|
|
|
These valgrind errors I'm getting are driving me mad: ==1886== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==1886== at 0x4E412CC: send (send.c:33)
==1886== by 0x54881B0: CBSocketSend (CBLibEventSockets.c:287)
==1886== by 0x506953D: CBNetworkCommunicatorOnCanSend (CBNetworkCommunicator.c:459)
==1886== by 0x5487F43: CBCanSend (CBLibEventSockets.c:235)
==1886== by 0x663454B: event_base_loop (event.c:1346)
==1886== by 0x5487B29: CBStartEventLoop (CBLibEventSockets.c:154)
==1886== by 0x4E39E99: start_thread (pthread_create.c:308)
==1886== Address 0x6f69774 is 20 bytes inside a block of size 24 alloc'd
==1886== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1886== by 0x506903B: CBNetworkCommunicatorOnCanSend (CBNetworkCommunicator.c:394)
==1886== by 0x5487F43: CBCanSend (CBLibEventSockets.c:235)
==1886== by 0x663454B: event_base_loop (event.c:1346)
==1886== by 0x5487B29: CBStartEventLoop (CBLibEventSockets.c:154)
==1886== by 0x4E39E99: start_thread (pthread_create.c:308)
==1886== Uninitialised value was created by a heap allocation
==1886== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1886== by 0x5067E55: CBNewNetworkCommunicator (CBNetworkCommunicator.c:30)
==1886== by 0x4022C2: main (testCBNetworkCommunicator.c:286)
==1886==
==1886== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==1886== at 0x4E412CC: send (send.c:33)
==1886== by 0x54881B0: CBSocketSend (CBLibEventSockets.c:287)
==1886== by 0x5069684: CBNetworkCommunicatorOnCanSend (CBNetworkCommunicator.c:480)
==1886== by 0x5487F43: CBCanSend (CBLibEventSockets.c:235)
==1886== by 0x663454B: event_base_loop (event.c:1346)
==1886== by 0x5487B29: CBStartEventLoop (CBLibEventSockets.c:154)
==1886== by 0x4E39E99: start_thread (pthread_create.c:308)
==1886== Address 0x6f6918a is 106 bytes inside a block of size 110 alloc'd
==1886== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1886== by 0x5061449: CBInitByteArrayOfSize (CBByteArray.c:133)
==1886== by 0x5061088: CBNewByteArrayOfSize (CBByteArray.c:48)
==1886== by 0x506C433: CBNetworkCommunicatorSendMessage (CBNetworkCommunicator.c:1307)
==1886== by 0x506882C: CBNetworkCommunicatorDidConnect (CBNetworkCommunicator.c:217)
==1886== by 0x5487E01: CBDidConnect (CBLibEventSockets.c:210)
==1886== by 0x663454B: event_base_loop (event.c:1346)
==1886== by 0x5487B29: CBStartEventLoop (CBLibEventSockets.c:154)
==1886== by 0x4E39E99: start_thread (pthread_create.c:308)
==1886== Uninitialised value was created by a heap allocation
==1886== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1886== by 0x5067E55: CBNewNetworkCommunicator (CBNetworkCommunicator.c:30)
==1886== by 0x4022C2: main (testCBNetworkCommunicator.c:286)
According to get_vbits, the checksum is not defined at https://github.com/MatthewLM/cbitcoin/blob/master/src/CBNetworkCommunicator.c#L457 |
|
|
|
|
Show Posts
