Do you really intend to convert the newly allocated pointer to an integer and then return it as a boolean?
Yes, believe it or not. I was in two minds as to whether or not this is a good idea or not, but for the dependencies I've used uint64_t instead of void * so that it is friendly with integer identifiers (These function prototypes are designed so that they can be implemented in different ways). But now I'm closer to using void * instead. What do others think? @MatthewLM
I think the work you're doing is awesome and I thank you for putting your skill and intelligence at work for the common good.
Thank you. |
|
|
|
|
Hi GMD1987. Thanks for trying it out. I make all warnings into errors to help spot problems (warnings easily go unnoticed otherwise). I didn't get this since I'm using 64-bit. I'm assuming the correct way to suppress this would be to use "-Wno-pointer-to-int-cast" so I'll add this to the makefile now.
testCBNetworkCommunicator is sometimes problematic. I'm going to go through all the tests and run them with valgrind to detect any problems I've missed so far.
|
|
|
|
cbitcoin now builds fully (In it's current state) on OSX and Linux Mint (tested). To build yourself and run the tests do this: git clone https://github.com/MatthewLM/cbitcoin.git
cd cbitcoin
./configure
make test |
|
|
|
|
If the transaction fees are changed to algorithmically follow the block space as I expect would be an alternative solution to this, what will happen is that bitcoin will become expensive enough for an alternative crypto-currency to arise. An alternative to bitcoin which is cheaper will succeed and bitcoin will fail. Thus the only way to keep bitcoin alive is to allow for more volume, such that demand can be satisfied.
If it does ever come to bitcoin reaching it's limits, then I would be one to support another crypto-currency, as it would then be needed. I think this could be a good thing as it provides an opportunity to improve upon the many flaws of bitcoin with something new.
|
|
|
|
|
For all those that hate PKI, explain a better solution.
|
|
|
|
|
I disagree with those that say this is bad since it breaks the trust of bitcoin. People who use bitcoin want to retain ownership and usability of their money and to be assured that the inflation rate wont differ. More space in blocks would be a benefit due to lower transaction fees. The integrity of people's bitcoins remains as was ever.
The problem is that the fork may not go seamlessly. If a fork is to be made as many issues as possible should be resolved. For instance, the block timestamp can be made a 64 bit integer as should always have been, so that this disturbance would be as seldom as possible.
Considerations must be made for how bitcoin can scale to much larger block sizes. I have mentioned before that when block sizes reach a point it will be beneficial to relay blocks in separated parts.
|
|
|
|
Props on your progress Matthew, and I applaud your listening ear. I've been keeping an eye on this project  Thanks. I've been ill over the last few days so I haven't made any progress in that time and I've got a lot of other work to do, but I'll try my best to continue at a reasonable pace from here onwards. |
|
|
|
It's coming along piece by piece. I'm currently improving some of the old code in preparation for writing the remaining network node code. Recently I completed the implementation of the full validator. If all goes well then I should have everything implemented (Not tested) by a couple of months, but I am quite busy with other things and I can't be sure of anything. Here is the new topic: https://bitcointalk.org/index.php?topic=123488.msg1457871#msg1457871People can watch the github repository to keep updated: https://github.com/MatthewLM/cbitcoin/ |
|
|
|
|
OK, since you aren't the only one to complain, I've changed the title.
|
|
|
|
No they do not remove the risk of fraud, Steve just clarified that they do not. And bitcoin does not have chargebacks. BitPay hasn't removed that, bitcoin has. The problem is with 0-conf transactions.
You're cute and all but I was talking about CC chargeback. I'm saying the promise of BitPay to merchants is to eliminate CC chargeback risks (by using an alternative payment system obviously). Of course you can accept BTC without BitPay, but not every internet merchant wants to know about Bitcoin, or understands it enough to feel comfortable accepting them themselves. Well, for sure BitPay might be useful for transfers to a bank account but I'm talking about merchants that want payment in bitcoin. Why use a middle-man when you can directly use bitcoin? Bit-Pay offers bitcoin transfers for 0.99%. BitPay has misrepresentation in their promotional material: "With Bitpay you can eliminate the risk of Fraud" This is false. You could say BitPay offers software solutions that do not exist elsewhere, but that is completely redundant as soon as anyone creates a open-source merchant software that suports bitcoin. |
|
|
|
What on earth is the point in that?
Convenience. It might not make sense to you, but it could make lots of sense for people who just want to sell stuff over the internet. Also you're taking the wrong perspective here, BitPay removes the risk of fraud, chargeback fraud, that's the promise. No they do not remove the risk of fraud, Steve just clarified that they do not. And bitcoin does not have chargebacks. BitPay hasn't removed that, bitcoin has. The problem is with 0-conf transactions. |
|
|
|
I just want to clarify some misconceptions about how BitPay processes transactions. We do not accept 0 confirmation transactions, we never have. We also only accept transactions that are immediately eligible for inclusion in a block. While our user experience is that an invoice is shown as paid right when someone sends payment, we only guarantee and credit a merchant's account after 6 confirmations (we have considered dropping that to 3 confirmations, but at the moment it is 6). Merchants do have the option of getting notified about a paid invoice immediately, after 1 confirmation, or only after BitPay guarantees payment. Depending on the nature of their business, a merchant may accept the risk of a double spend and deliver their product or service with zero confirmations. At some point in the future we will offer to cover that risk for transactions below a certain value and we'll begin to mitigate the risk via relationships with large miners and mining pools.
I thought part of your service was to remove the risk of fraud on behalf of the merchant. Merchants might want to use your service to receive payments through a bank account but I see no point for merchants to waste 0.99% on BitPay for bitcoin transfers. What on earth is the point in that? A pointless middle-man, and a waste of money. |
|
|
|
|
If you are to use a GPU, why not also use the CPU along side it? If time is important, then surely using as much processing power as is available is recommended. Understandably the are other considerations such as power usage and the operation of other programs on the same system.
At least you can take advantage of multiple CPU cores with multiple threads.
|
|
|
|
|
Why wont GPUs help much? Surely checking signatures in parallel would be an improvement?
|
|
|
|
Yeah, I never liked the word "anarchy" which loosely means "without ruler". I much prefer the term "autarchy" which means "self rule".
The problem with autarchy is that is can be confused with autarky. In fact, I do not pronounce them differently. It may also be confused with autocracy. If people use the word agora for market (αγορά), you could perhaps invent a word for "rule of the market": agorarchy? That would then be equivalent to anarcho-capitalism. |
|
|
|
Got a better word to describe the same principle?
anarchy - Bitcoin has no central authority and is run by autonomous peers in a peer to peer network You could have decentralised. |
|
|
|
|
I think it is definitely worth for full nodes to have some sort of safe mode triggered by detection of longer chains. It's simple enough and the problem becomes a disturbance in operation, rather than a problem of forking. And indeed mining software is most critically important when it comes to correct validation.
|
|
|
|
|
At least on the Mac version, the OpenSSL library is packaged with bitcoin. If it wasn't, that would be alarming.
|
|
|
|
|
Show Posts
