My proof-of-concept patch was written for Bitcoin about a year ago; absolutely it could be integrated into Bitcoin Core. The only obstacle specific to Bitcoin is getting consensus.
As a software developer new to the bitcoin source I am really grateful for the work you have done in contributing to BTC and thanks for the reply. Do you refer to the consensus as an organisation level obstacle or it is a technology term related to the blockchain ... sorry for the silly question :-) and I just want to make sure I understood you correctly. |
|
|
|
|
Do you know if Peter Todd's OP_CHECKLOCKTIMEVERIFY will be ever integrated into the Bitcoin source or is it a VIACOIN specific design?
Should be such innovation considered for Bitcoin as well?
|
|
|
|
Yes this is right. The trustless system we talk here has nothing to do with two-generals problem. Communications have no problem, the problem is that how to prevent any node from doing bad things (i.e. steal coins).
Actually no, the "guarantor" is only involved in the act of sending coins, which is a "communication" in the context of the Two General's problem. The "guarantor" is being trusted to do arbitration between the sender and the mixer. Therefore, given the nature of 2-of-3 multisig transactions, the guarantor and the mixer can sign the transaction, and then refuse to sign the cancellation transaction, leaving the sender out of luck and out of funds. Even worse - the workflow is based on the txid and verifying the txid. Have we not learnt by now that the txid can change? How do you people not understand that this was the very thing that mtgox blamed for their destruction? In fact, if there was ever a clearer indication that the idiot "developer" that designed this system should stick to something less complicated, Satoshi Nakamoto himself wrote a seminal post in December 2010 explaining why this is a bad idea, so it's not like this is a novel and unknown thing: Transactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.
Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
This is not a trustless system, this is a trivially broken, fundamentally flawed system. Praising it as anything but an idiotic idea merely reduces your own credibility. Thanks for pointing out this. There are many of us, probably hundreds of developers as we speak are thinking to come up with an idea to implement a trustless system that does the job better than bitocoin. It's quite clear, is not easy to come up with a better system than bitcoin is. |
|
|
|
|
That's a really nice wallet. Congratulation for the great work.
|
|
|
|
|
This would be a technical question, what are the super nodes in the vericoin network terms of what they do, what is the role of a super node in the network?
|
|
|
|
Thanks, I appreciate the explanation, but I couldn't find any references to the nlocktime in this whitepaper and I am having problems with geting my head around this :-)) So does it mean, the green address provider perform the transaction, and then withdraw the fund from the transaction that was initiated with the nlocktime, and if the greeen address provider is out of business and the transaction was never performed then the nlocktime expires and the fund remains on the address? |
|
|
|
I have been trying to collect information and reading about the green addresses in the last few days. It seems to me that green addresses definitely could be a possible solution to speed up the transaction. I think one of the biggest problems with green addresses is that the user must have a deposit account and sufficient fund at the green address provider's system to move some money to the green address prior to the transaction and this money can be lost if there is a security breach like what happened at Mintpal not long time ago or something else goes terrible wrong and the green service provider is out of business.
The green address concept can be done in a trustless fashion using nlocktime txns. Could you explain briefly how a trustless green address with nlocktime would work please? It would be great to understand how the pieces fit together. I am sure that is an option, but I have just checked the nlocktime, I could be wrong but it seems to me that using nlocktime would delay the transaction and therefore increase the transaction acceptance time. Is that correct or I just misunderstand the whole thing again? :-)) |
|
|
|
|
I have been trying to collect information and reading about the green addresses in the last few days. It seems to me that green addresses definitely could be a possible solution to speed up the transaction. I think one of the biggest problems with green addresses is that the user must have a deposit account and sufficient fund at the green address provider's system to move some money to the green address prior to the transaction and this money can be lost if there is a security breach like what happened at Mintpal not long time ago or something else goes terrible wrong and the green service provider is out of business.
|
|
|
|
Could you help me understand how the checking of the transaction fee is an effective precaution?
There are 2 common reasons that a transaction might not confirm, and a double spender will have an opportunity to replace the transaction with a different one that pays himself instead of the merchant. 1. If a transaction does not include a sufficient transaction fee, then miners will not have enough incentive to include it in the blocks they are working on. After a few days, the network will forget about the transaction. The attacker will then have an opportunity to broadcast a replacement transaction that pays himself instead of the merchant. 2. If a transaction is not well propagated, then many nodes and miners will not have seen the transaction yet. This allows the attacker to immediately broadcast a replacement transaction to those nodes and miners and have a high probability that the replacement transaction will be confirmed instead of hte original one. Since nodes will refuse to relay transactions with small outputs, unless they include a sufficient fee, the attacker can reduce propagation by reducing the fee. If a miner includes a sufficient fee, then the transaction will be relayed by any node that sees the transaction, and there will be enough incentive to the miners for the transaction to become confirmed long before the network forgets about it. A merchant can further reduce their risk by maintaining direct connections to the largest mining pools and any pools or miners known to accept low priority free transactions, and rebroadcasting every 2 or 3 days any transactions that they have received that haven't been confirmed yet. This will refresh the transaction in the memory of the pools so they won't forget about the transaction, and will therefore prevent any replacement transaction from propagating to the pools and miners. If I understood correctly how the whole thing works, if someone want to perform a double spending with 10 BTC then including 0.001 BTC transaction fee is very minor cost comparing to the possible gain from the malicious double spending, so I guess the double spender would be happy to include the small transaction fees in many transactions.
That fee is far larger than necessary in most cases. The merchant would want to check the size of the transaction (in bytes, not in bitcoins), and then verify that a fee of at least 0.0001 BTC per kilobyte was paid. Since most transactions are less than a kilobyte in size, this means that in most cases the fee would only need to be 0.0001 BTC. Thanks for explaining, it make sense and I start to understand why the transaction fee is important in the process. |
|
|
|
Skycoin will use deltas from the trusted consensus nodes to set local system time and use NTP severs for verification.
Thanks for the update, your project and work is really exciting. Is it possible you would share some details on how the trusted nodes will be configured, what is the criteria to be a trusted node and how the nodes will decide to accept a node as trusted node? |
|
|
|
I believe that Mycelium (android) wallet has a feature which checks recieved payments for a) a fee and b) propagation across the bitcoin network. if both of these are detected, the payment is labelled as 99% safe, even with 0 confirmations.
[Note, I have never used Mycelium wallet so my description might be a bit off]
I understand checking the fee and propagation is sufficient to look up the transaction, but such check doesn't prevent double spending or does it? I could be wrong, but I think to prevent double spending would need more validation. A well propagated transaction with a proper fee is very difficult to cancel. It isn't impossible, but it is beyond the risk threshold of most businesses. This is what most people forget when they claim "Bitcoins will never be trusted for quick, in-person transactions!" Businesses already accept a certain amount of risk when dealing in conventional payments: cash could be counterfeit, credit cards could be stolen, customer could be pulling some other kind of elaborate scam. There is much less risk involved in accepting bitcoins before their first confirmation as long as certain simple precautions are taken (i.e. verifying the proper fee was included). Could you help me understand how the checking of the transaction fee is an effective precaution? If I understood correctly how the whole thing works, if someone want to perform a double spending with 10 BTC then including 0.001 BTC transaction fee is very minor cost comparing to the possible gain from the malicious double spending, so I guess the double spender would be happy to include the small transaction fees in many transactions. Anyway, you are absolutely right, Bitcoin is probably a lot safer than conventional payment methods. |
|
|
|
|
Thanks for all inputs about the green address. I am trying to collect all information about it that's available on the net and understand how it works. It seems green addresses are definitely a possible solution to speed up transaction processing.
|
|
|
|
Great, thanks for both replies, they are really useful. I think having fast transaction processing is really crucial for Bitcoin to go mainstream and to be able to use Bitcoin on many more use cases (e.g. at a vending machine and no one wants to wait 10 minutes at a vending machine). Is the green address concept supported by the bitcoin protocol? I am checking the source but unable to find any references of green address, on the other hand I can see at https://bitcointalk.org/index.php?topic=32818.0 that the concept was already discussed in 2011. |
|
|
|
I believe that Mycelium (android) wallet has a feature which checks recieved payments for a) a fee and b) propagation across the bitcoin network. if both of these are detected, the payment is labelled as 99% safe, even with 0 confirmations.
[Note, I have never used Mycelium wallet so my description might be a bit off]
I understand checking the fee and propagation is sufficient to look up the transaction, but such check doesn't prevent double spending or does it? I could be wrong, but I think to prevent double spending would need more validation. |
|
|
|
What you may be talking about is the possibility of accepting transactions as "pretty much valid" before the first confirmation since as Danny said the confirmation time cannot be changed. This is called accepting a transaction with zero confirmations.
There are ideas floating around for this. One example is that a third party would insure the transaction after a small amount of time but before the first confirmation. If the transaction turned out to be bad and you did not get your BTC then the third party insurance would pay you the BTC you lost due to the fact the transaction never confirmed. There would be a fee for this insurance and the better insurance companies would have methods to reduce their claims by studying the transaction to make sure it has a very good chance of getting confirmed.
Is that along the lines of what you are talking about?
Yes, absolutely I was talking about that, and as Danny has pointed out I misunderstood what confirmation means in this context. More precisely, I understood that the confirmation is possible only in after 10 minutes as the transaction must be included in a new block, so I should talk about speeding up transaction acceptance instead of speeding up confirmation. Thanks for the replies, all of you provided me with really useful info. Probably I should not make any comments when experienced hero members having brain storming about possible solutions, but I think both the insurance and centralized multi signature based solution could work. I think we all subscribed to the core concept of decentralization, but there are use cases when a centralized multi signature centralized wallet is perfectly acceptable. I think majority of bitcoin transactions aren't darknet related, most of the users wouldn't mind to compromise on decentralization and having a centralized multi signature wallet in order to be able perform quick transactions. |
|
|
|
It seems the market likes the ClearingHouse idea and that the dev is working on the decentralized app feature.
dev are hiring some talent people to help with the clearing house. I read that in the dev's blog. A new developer definitely speed up the development process and a quick release would be key as there are multiple projects working on the very same idea. |
|
|
|
Nope, not yet, but smart contracts are in the pipeline.......probably be up and running on NXT before Ethereum launches. https://nxtforum.org/smart-contracts/And while you're there, take a look at the rest of NXTs feature set..... IMHO: if (big if) Ethereum can deliver on everything they promise, Eth will be technically superior to NXT. But we are a very long way from seeing any code from Ethereum, even if they can deliver. I think this is going to work out like VHS vs Betamax: the superior tech will lose out to ease of use, market position, availability and lower entry costs...... Well, that's not quit the case as there are lot of codes available from Ethereum at their github repository, I have just compiled their cpp-ethereum project which is a quite impressive piece of proof of concept software. Having said that Ethereum is not as innovative as I thought it will be. Even Buterin says or admit that Ethereum like Bitcoin with a built in scripting language. Knowing that Bitcoin can execute scripts the innovation is not a massive breakthrough. I think you are absolutely right, we don't know whether the completed Ethereum solution will work and when that will be. NXT is definitely have a better position in the race. NXT is at least on the market with a proven and stable software. |
|
|
|
Hate to hijack this thread......but NXT.
Not sponsored by corporate thieves or incompetents, fully open source, up and running right now, capable of implementing pretty much anything Ethereum will be able to do.
Why throw your money at Goldman Sachs for vaporware and a promise when you could get in on a working system right now?
Sheesh, NXT has already placed 2 NXT based assets in the Coinmarketcap top 40 right now......and theres a lot more amazing stuff to come.
Is NXT support and capable to perform smart contracts? |
|
|
|
|
There are too many alt coins. If the new altcoins don't offer some extra functionality why don't just use Bitcoin?
|
|
|
|
|
These are really good points from Gavin, thanks!
The problem altcoins and new block-chain still have place in the digital currency scene as they address issues that bitcoin don't or do (or at least try to do) certain things more efficiently. Like shorter confirmation time or smart contracts.
|
|
|
|
|
Show Posts
