Search content
Sort by
Showing 20 of 48 results by trilli0n
Re: How to Prevent a 51% attack: Multiple PoW algorithms + PoS ???????
EDIT: improved based on suggestions of XertroV
To me it seems that the fundamental problem is that the entire block reward (coinbase + fees) is going to a single miner. Note I'm using the word "miner" in the strict sense of the word, i.e., the entity which decides what transactions to put in a block and gets to distribute the reward, i.e., a mining pool operator.
A solution therefore might be to have multiple PoWs and multiple rewards per block, for instance three (that's quite an arbitrary number, perhaps five would work better, but for the sake of the example I'll go with three PoWs per block).
A way to split up the PoWs could be as follows. Let there be PoW1, PoW2 and PoW3. Any one PoW is valid for only a subset of transactions (1/3 of all transactions in the case of three PoWs). However the miner must not know in advance to which subset of transactions it is searching a solution for. So, each miner selects all transactions from the mempool just as-is, and includes transactions to distribute the block reward. If a miner finds a solution (a nonce), then it is broadcast so other miners know that a PoW has been completed, so they can switch to other PoWs that have not yet been found.
The miner that finds the final PoW can broadcast the block. The protocol enforces that the first miner that broadcasts a solution locks in the reward for that PoW. This as an incentive for a miner to immediately broadcast a solution once it finds it. If two or more miners broadcast a solution for a PoW at the same time, the protocol may randomly choose one.
It must be impossible for a miner to know which transactions its PoW is going to be valid for. Therefore, establishing the set of transactions approved by each PoW should be done as late as possible, so only when the block is finalized by the miner that found the last missing PoW and includes all PoWs in the block and broadcasts it. The mapping between a PoW and a set of transactions should be random, deterministic and impossible to manipulate. Since the exact value of a nonce is impossible to manipulate, the mapping should somehow be derived from it. Also, the transaction inputs and outputs can not be manipulated by the miner, so these are also useful. We could take the hash mod 3 of such immutable property of the transaction plus the final nonce, rendering 0, 1 or 2 for each transaction. So hash(tx_property, final_nonce) %3 gives 0, 1 or 2 for each transaction, which in turn dictates if a transaction belongs to PoW1, 2 or 3. This way, a PoW controls only 1/3 of all transactions.
Example
Suppose the miner that found PoW1 included transactions 1, 2, 3, 5, the miner that found PoW2 included 1, 2, 3, 4, 5, 6 and the miner that found PoW3 included 1, 2, 5. Suppose as well, after applying hash(tx_property, final_nonce) %3 to each transaction, it turns out that PoW1 is valid for tx 1, 2, PoW2 is valid for 3, 4 and PoW3 is valid for 5, 6. The set of valid transactions will then be 1, 2 (PoW1), 3, 4 (PoW2) and 5 (PoW3). Transaction 6 is not included in the block as valid, since it belongs to PoW3, and PoW3 did not include transaction 6.
The effect of this will be that controlling > 50% of the network hash rate is not enough to consistently control all transactions. Increasing the number of PoWs per block from three to five reduces the number of transactions under the control of a single large miner even further. Of course, for a large enough share all of hash power, the miner will again be able to control all blocks, but this number will be 80% for five PoWs, plus that it can never be sure it finds the PoW for a malicious self-inserted transaction before another miner, as it can not predict which set of transactions the PoW it finds is valid for. This reduces the ability to abuse its mining power.
To me it seems that the fundamental problem is that the entire block reward (coinbase + fees) is going to a single miner. Note I'm using the word "miner" in the strict sense of the word, i.e., the entity which decides what transactions to put in a block and gets to distribute the reward, i.e., a mining pool operator.
A solution therefore might be to have multiple PoWs and multiple rewards per block, for instance three (that's quite an arbitrary number, perhaps five would work better, but for the sake of the example I'll go with three PoWs per block).
A way to split up the PoWs could be as follows. Let there be PoW1, PoW2 and PoW3. Any one PoW is valid for only a subset of transactions (1/3 of all transactions in the case of three PoWs). However the miner must not know in advance to which subset of transactions it is searching a solution for. So, each miner selects all transactions from the mempool just as-is, and includes transactions to distribute the block reward. If a miner finds a solution (a nonce), then it is broadcast so other miners know that a PoW has been completed, so they can switch to other PoWs that have not yet been found.
The miner that finds the final PoW can broadcast the block. The protocol enforces that the first miner that broadcasts a solution locks in the reward for that PoW. This as an incentive for a miner to immediately broadcast a solution once it finds it. If two or more miners broadcast a solution for a PoW at the same time, the protocol may randomly choose one.
It must be impossible for a miner to know which transactions its PoW is going to be valid for. Therefore, establishing the set of transactions approved by each PoW should be done as late as possible, so only when the block is finalized by the miner that found the last missing PoW and includes all PoWs in the block and broadcasts it. The mapping between a PoW and a set of transactions should be random, deterministic and impossible to manipulate. Since the exact value of a nonce is impossible to manipulate, the mapping should somehow be derived from it. Also, the transaction inputs and outputs can not be manipulated by the miner, so these are also useful. We could take the hash mod 3 of such immutable property of the transaction plus the final nonce, rendering 0, 1 or 2 for each transaction. So hash(tx_property, final_nonce) %3 gives 0, 1 or 2 for each transaction, which in turn dictates if a transaction belongs to PoW1, 2 or 3. This way, a PoW controls only 1/3 of all transactions.
Example
Suppose the miner that found PoW1 included transactions 1, 2, 3, 5, the miner that found PoW2 included 1, 2, 3, 4, 5, 6 and the miner that found PoW3 included 1, 2, 5. Suppose as well, after applying hash(tx_property, final_nonce) %3 to each transaction, it turns out that PoW1 is valid for tx 1, 2, PoW2 is valid for 3, 4 and PoW3 is valid for 5, 6. The set of valid transactions will then be 1, 2 (PoW1), 3, 4 (PoW2) and 5 (PoW3). Transaction 6 is not included in the block as valid, since it belongs to PoW3, and PoW3 did not include transaction 6.
The effect of this will be that controlling > 50% of the network hash rate is not enough to consistently control all transactions. Increasing the number of PoWs per block from three to five reduces the number of transactions under the control of a single large miner even further. Of course, for a large enough share all of hash power, the miner will again be able to control all blocks, but this number will be 80% for five PoWs, plus that it can never be sure it finds the PoW for a malicious self-inserted transaction before another miner, as it can not predict which set of transactions the PoW it finds is valid for. This reduces the ability to abuse its mining power.
I see one advantage in this setup, and several weaknesses.
Advantage: The ability to send fiat currency quickly to anywhere in the world assuming you have a network of 'fiat bankers'.
Advantage: The ability to send fiat currency quickly to anywhere in the world assuming you have a network of 'fiat bankers'.
For sending and receiving funds, the fiat bankers network has no function. The fiat bankers only come into play when putting fiat on or removing fiat from the block chain. As an incentive, they can ask a fee for these transfers.
Quote
Weaknesses: The Bitcoin protocol was brilliantly designed to solve the problem of incentive to secure the network, with the reward being some of the value from the network. By unlinking the two, there is no incentive for securing the network (mining).
The incentive is still there: transaction fees that the miners, or rather: hashers receive when solving a block. This is equal to the situation that bitcoin will be in when all bitcoins are mined.
Quote
The other weakness is that you have security risk with the fiat bankers which you may solve, but it is very similar to the risk that exchanges pose at the moment.
Yes. But there are many ways to mitigate these risks, just as regular banks mitigate these risk: FDIC insurance, for instance, and traditional regulation. Also consider that regular banks require a much higher level of trust than a block chain based fiat bank would require.
Quote
The primary problem you seem to be solving is the volatility, and that can be solved more easily by having many exchanges like Coinbase, BTC-e, Bitstamp, and bitcoin ATMs.
If you don't want the volatility, hold fiat. When you need to send value -- Exchange to bitcoin, send, and let the receiver of the value decide whether to transfer back to fiat, or hold the value in bitcoin.
The fiat block chain transfers some of the advantages of bitcoin to fiat. For instance, the fiat on your address cannot be confiscated or frozen as it can when it sits in a bank account. In other words, a single person can no longer be singled out as a target to confiscation or account freezing. Also, it is more anonymous than a bank account if proper precautions are taken, just as with bitcoin in its current state.If you don't want the volatility, hold fiat. When you need to send value -- Exchange to bitcoin, send, and let the receiver of the value decide whether to transfer back to fiat, or hold the value in bitcoin.
Quote
Fiat and bitcoin (the currency/commodity) both have risk. Ignoring any security issues for the moment, fiat can be 'quantitatively eased' to a lower value (reduced purchasing power), while bitcoin currently has extreme volatility and the value goes up and down based on the news of the day.
Yes. This remains the main distinction between bitcoin and fiat, and which is my opinion bitcoin is superior to fiat as it can not be inflated. However, I find it interesting to note that some of the properties of bitcoin can be transferred to fiat as well.
The fiat blockchain enables full reserve banking. The units on the block chain are fully backed by the reserves in the safes of fiat bankers. Of course, everything depends on the honesty of the fiat banker. However, the current situation in banking is much worse. The current-day, traditional fiat banker keeps only a fraction of its deposits, the rest is loaned. If only a fraction of these loans default, the bank defaults and the depositors will lose their money for as far as it is not insured.
Full reserve banking with fiat using a block chain
Imagine a block chain acting as a ledger for a fiat currency such as USD or EUR. Fiat payments would be conducted analogously to cryptocurrency payments. Wallets would contain fiat money instead of cryptographic currencies. This post explores whether such a block chain can exist.
Rationale
Depending on its implementation, a fiat blockchain can inherit some of the properties from the bitcoin blockchain:
Of course, some Bitcoin advantages are not inherited, such as:
Implementation mock-up
In a fiat block chain, there is no mining, and no block reward. Rather, there will only be transaction hashers, and the hashers are motivated by transaction fees only.
A fiat block chain must be provably 100% backed by reserves with as little trust as possible. Every currency unit on the block chain must exist physically in a safe. Although a fractional reserve block chain is possible, it is not considered here. Due to the nature of fiat, a fully decentralized and trustless implementation is not possible. Here we will try to explore how a fiat block chain can be implemented with as little as possible compromises to the advantages which the decentralized and trustless model offers.
In order to get fiat currency units on the fiat block chain, fiat money must be deposited and stored physically with a fiat banker. The fiat banker is authorized to issue fiat currency units on the block chain at the address of the depositor. For instance, a deposit of USD 100 would be carried out as follows: the depositor hands over a physical USD 100 bill to the fiat banker. The fiat banker releases USD 100 on the block chain at the address of the depositor. The fiat banker stores the USD 100 bill in a safe.
To prevent the fiat banker from releasing fiat on the block chain for which no reserves are held, a method is proposed to ensure that the fiat is provably held by the fiat banker. Although trust can not be fully removed, it can be reduced significantly. Whether it can be reduced sufficiently to make a fiat block chain feasible remains an open question.
The fiat banker stores bank notes in a bank safe. In our method, only a single bank note size is stored, such as USD 100 or EUR 50 bills. Depositing fractions of the standard bank note size is not possible. The fiat banker will therefore physically store USD 100 or EUR 50 bills only. This will facilitate prove of reserves.
Every bill has a unique serial number printed on it. When a fiat banker releases fiat on the block chain, it must be done such that the serial number of the bank note, as well as a unique reference or ID of the fiat banker is also verifiably released. This allows the depositor to verify that his bank note is correctly released on the block chain, although it would have no consequences for the depositor if it were not. That is: the serial number is released, but not tied to the address of the depositor. The depositor receives currency units that can be freely spent in fractions just like a cryptocurrency. The serial number is on the block chain for reference, as it facilitates prove of reserves. The reference of ID of the fiat banker can be a number, but it is also released. Together, the block chain stores that a bank note with a certain serial number has been deposited with a fiat banker with a certain ID. Thus, the block chain stores the serial numbers of every physical bill that has been deposited for every fiat banker.
A fiat banker naturally also serves withdrawals of fiat. A holder of fiat on the block chain can withdraw his units on the block chain by visiting a fiat banker and exchanging his balance on the block chain for physical bank notes. In the simplest example, if USD 100 is to be withdrawn, the withdrawer visits the fiat banker and sends the USD 100 to the address of the fiat bank. The fiat bank then takes a physical USD 100 bill from its stock and hands it over to the withdrawer. However, the transaction is conducted such that the serial number of the bank note that must be returned by the fiat banker is determined randomly by the block chain. The withdrawer sends a special withdrawal transaction to the fiat banker. The block chain knows all the serial numbers of all previously deposited bank notes. The block chain randomly defines which bank note must be returned to the withdrawer. The fiat banker must retrieve the physical bank note as randomly determined by the block chain from the safe and hand it to the withdrawer.
This scheme makes it very difficult for a fiat banker to cheat. If the fiat banker would release bank notes on the block chain for which the physical notes do not exist, then this will become clear very quickly if withdrawers find that the fiat banker is not able to produce the bank notes with the serial numbers as demanded by the block chain. In fact, if the fiat banker fails to produce the bank notes as demanded by the block chain, it can no longer be trusted, and depositors should no longer deposit with this fiat banker.
A rogue fiat banker is able to fund an account on the block chain using serial numbers of bills that are not in his possession. Next, the rogue fiat banker can send his balance over to a honest fiat banker and receive physical bank notes in return for his unbacked balance. This will only be discovered as soon as anyone tries to withdraw fiat with the rogue fiat banker, at which point it would become clear that the rogue banker can not produce the bills with the serial numbers as demanded by the block chain. By then however it is already too late.
To mitigate such schemes, the fiat banker must have additional incentives to remain honest. This is an open point, although it can probably be resolved by legal means or by demanding fiat bankers to deposit an amount in escrow in order to be allowed to act as a fiat banker. Also, limits can be imposed on a fiat banker as to how much fiat can be put on the block chain, which in turn can depend on the type of legal measures or height of the deposit in escrow, or both.
Since a deposits and withdrawals are in units of a chosen bank note, fractional amounts can not be withdrawn. This is easy to circumvent, however. For instance, to withdraw a fractional amount, the withdrawer can add an amount to reach a multiple of the bank note amount. For instance, to withdraw USD 143, the withdrawer would send USD 143 to the address of the fiat banker, as well as hand him USD 57 in cash. The fiat banker then asks the block chain to release two USD 100 bank notes, and hands them to the withdrawer. Of course, the withdrawer is supposed to verify the serial numbers on the bank notes with the block chain generated numbers.
The idea of a fiat block chain presented here is very rudimentary and only serves as a jumping point for further exploration, or alternatively, dismissal.
Imagine a block chain acting as a ledger for a fiat currency such as USD or EUR. Fiat payments would be conducted analogously to cryptocurrency payments. Wallets would contain fiat money instead of cryptographic currencies. This post explores whether such a block chain can exist.
Rationale
Depending on its implementation, a fiat blockchain can inherit some of the properties from the bitcoin blockchain:
- Fiat in the blockchain cannot be confiscated by a central authority;
- Fiat in the blockchain cannot be frozen by a central authority;
- Cheap and convenient payments, also cross-border;
- Settlement of payments within max one hour;
- Pseudonimity;
- Difficult to trace;
- Balance total is protected by cryptography.
Of course, some Bitcoin advantages are not inherited, such as:
- Predictable and moderate inflation of the amount of currency units;
- Currency units are themselves valuable, whereas fiat currency units are a proxy for fiat, and must be backed by physical fiat to retain their value;
- Trustless, whereas a fiat blockchain requires some level of trust in fiat bankers.
Implementation mock-up
In a fiat block chain, there is no mining, and no block reward. Rather, there will only be transaction hashers, and the hashers are motivated by transaction fees only.
A fiat block chain must be provably 100% backed by reserves with as little trust as possible. Every currency unit on the block chain must exist physically in a safe. Although a fractional reserve block chain is possible, it is not considered here. Due to the nature of fiat, a fully decentralized and trustless implementation is not possible. Here we will try to explore how a fiat block chain can be implemented with as little as possible compromises to the advantages which the decentralized and trustless model offers.
In order to get fiat currency units on the fiat block chain, fiat money must be deposited and stored physically with a fiat banker. The fiat banker is authorized to issue fiat currency units on the block chain at the address of the depositor. For instance, a deposit of USD 100 would be carried out as follows: the depositor hands over a physical USD 100 bill to the fiat banker. The fiat banker releases USD 100 on the block chain at the address of the depositor. The fiat banker stores the USD 100 bill in a safe.
To prevent the fiat banker from releasing fiat on the block chain for which no reserves are held, a method is proposed to ensure that the fiat is provably held by the fiat banker. Although trust can not be fully removed, it can be reduced significantly. Whether it can be reduced sufficiently to make a fiat block chain feasible remains an open question.
The fiat banker stores bank notes in a bank safe. In our method, only a single bank note size is stored, such as USD 100 or EUR 50 bills. Depositing fractions of the standard bank note size is not possible. The fiat banker will therefore physically store USD 100 or EUR 50 bills only. This will facilitate prove of reserves.
Every bill has a unique serial number printed on it. When a fiat banker releases fiat on the block chain, it must be done such that the serial number of the bank note, as well as a unique reference or ID of the fiat banker is also verifiably released. This allows the depositor to verify that his bank note is correctly released on the block chain, although it would have no consequences for the depositor if it were not. That is: the serial number is released, but not tied to the address of the depositor. The depositor receives currency units that can be freely spent in fractions just like a cryptocurrency. The serial number is on the block chain for reference, as it facilitates prove of reserves. The reference of ID of the fiat banker can be a number, but it is also released. Together, the block chain stores that a bank note with a certain serial number has been deposited with a fiat banker with a certain ID. Thus, the block chain stores the serial numbers of every physical bill that has been deposited for every fiat banker.
A fiat banker naturally also serves withdrawals of fiat. A holder of fiat on the block chain can withdraw his units on the block chain by visiting a fiat banker and exchanging his balance on the block chain for physical bank notes. In the simplest example, if USD 100 is to be withdrawn, the withdrawer visits the fiat banker and sends the USD 100 to the address of the fiat bank. The fiat bank then takes a physical USD 100 bill from its stock and hands it over to the withdrawer. However, the transaction is conducted such that the serial number of the bank note that must be returned by the fiat banker is determined randomly by the block chain. The withdrawer sends a special withdrawal transaction to the fiat banker. The block chain knows all the serial numbers of all previously deposited bank notes. The block chain randomly defines which bank note must be returned to the withdrawer. The fiat banker must retrieve the physical bank note as randomly determined by the block chain from the safe and hand it to the withdrawer.
This scheme makes it very difficult for a fiat banker to cheat. If the fiat banker would release bank notes on the block chain for which the physical notes do not exist, then this will become clear very quickly if withdrawers find that the fiat banker is not able to produce the bank notes with the serial numbers as demanded by the block chain. In fact, if the fiat banker fails to produce the bank notes as demanded by the block chain, it can no longer be trusted, and depositors should no longer deposit with this fiat banker.
A rogue fiat banker is able to fund an account on the block chain using serial numbers of bills that are not in his possession. Next, the rogue fiat banker can send his balance over to a honest fiat banker and receive physical bank notes in return for his unbacked balance. This will only be discovered as soon as anyone tries to withdraw fiat with the rogue fiat banker, at which point it would become clear that the rogue banker can not produce the bills with the serial numbers as demanded by the block chain. By then however it is already too late.
To mitigate such schemes, the fiat banker must have additional incentives to remain honest. This is an open point, although it can probably be resolved by legal means or by demanding fiat bankers to deposit an amount in escrow in order to be allowed to act as a fiat banker. Also, limits can be imposed on a fiat banker as to how much fiat can be put on the block chain, which in turn can depend on the type of legal measures or height of the deposit in escrow, or both.
Since a deposits and withdrawals are in units of a chosen bank note, fractional amounts can not be withdrawn. This is easy to circumvent, however. For instance, to withdraw a fractional amount, the withdrawer can add an amount to reach a multiple of the bank note amount. For instance, to withdraw USD 143, the withdrawer would send USD 143 to the address of the fiat banker, as well as hand him USD 57 in cash. The fiat banker then asks the block chain to release two USD 100 bank notes, and hands them to the withdrawer. Of course, the withdrawer is supposed to verify the serial numbers on the bank notes with the block chain generated numbers.
The idea of a fiat block chain presented here is very rudimentary and only serves as a jumping point for further exploration, or alternatively, dismissal.
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
Agreed. "Proof of Reserves" or "Proof of Custody" we are working on at this moment. We can get proof from our custodian companies holding gold and have them share an update once a day. Thanks for sharing this. We're working on that process as of this writing.
How will this "Proof of Reserves" and "Proof of Custody" work?
Why would coin holders trust you are honestly relaying the PoR and PoC of the custodians?
How do we know that you didn't make a deal with the custodians to keep a fractional reserve in exchange for interest?
Why not have the custodians make the PoR and PoC public, so we don't have to trust you, but only the custodians?
But really, I'm the most curious about proof of reserve and proof of custody. How are the custodians going to proof they really have the gold they say they have?
That's crucial.
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
We don't hold any physical gold.
All gold is held at the Custodian company.I will add this question to the FAQ as well. Thank you!
We are working on delivering "Proof of Custody" which will include insurance against theft and custodian loss. These centralized features already exist with most precious metal custodian services. However, we do believe that this service can be decentralized as well: Custodian Drone Storage Machines!
All gold is held at the Custodian company.I will add this question to the FAQ as well. Thank you!
We are working on delivering "Proof of Custody" which will include insurance against theft and custodian loss. These centralized features already exist with most precious metal custodian services. However, we do believe that this service can be decentralized as well: Custodian Drone Storage Machines!
How will you prove that the custodian holds the gold to back every coin?
How does this insurance work? Will there be an independent insurance contract between the coin holder and an insurance company? Which insurance company?
Custodian Drone Storage Machines?
Re: [ANN] BITCOIN TANGIBLE TRUST: DIGITAL GOLD COINS ON COUNTERPARTY
http://bitcointangibletrust.com/wp-content/uploads/2014/03/Counterparty_slider-gold-bars.jpg
Our Mission:
We aim to be a physical gold custodian, digital gold asset issuer, and P2P decentralized exchange platform for our gold customers.
Will you the Counterparty Community help us in the following?
Our Mission:
We aim to be a physical gold custodian, digital gold asset issuer, and P2P decentralized exchange platform for our gold customers.
Will you the Counterparty Community help us in the following?
- Ask us any questions in this thread that we should address on our FAQ
- Tell us your thoughts about the issues you think are important to making this Counterparty startup a success.
Exciting! But the key questions are:
How do you prove you truly have the gold to back the coins?
How do we know you will not disappear overnight?
In other words: why would we trust you?
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
It isn't a matter of being unwilling. Although we are more familiar with the protocol, among only the three of us, we simply lack the man-power to do everything at once. It would not be possible to maintain the speed at which we are moving and also do a thorough bug check.
Moreover, it is not only the *amount* of time spent looking at the code, but the number of people who are looking at it. Even if one of us had the time to devote himself exclusively to reviewing the protocol, this wouldn't make extra eyes unnecessary.
Too bad then that making the protocol robust and secure is a second priority for the core devs.
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
But forget obligation, real reason to bail out is because if 80 BTC is lost it will mean massive bad press, it will devastate the project, hang over its head forever. People will never stop talking about it, do you think people can lost $60000 and not fight to get it back? Does not matter who is at fault or what is fair, "only get one chance to make a first impression" and most people will hear this story as their introduction to Counterparty
A bail-out will not make people stop talking about it. It is the second major fuck up at the protocol level within mere weeks after the end of the burn period and it's incredibly damaging. People are losing big sums of money. Redditors are linking to this thread and expect this to be mentioned in any serious discussion about counterparty for the oncoming months.
I do believe the devs did a brilliant job to create a piece of software that is the first to implement a DEx. Decentralization is the way to go and I applaud them for their courage and boldness to Just Do It. But I feel the project is rushed and released when not ready. A longer burn period would have been nice too, just to get more people involved.
It's nice that they want to work with an "auditor" to verify the code for bugs, but that really sounds they are either not willing or able to do a full code review themselves. Instead, they want to rely on some third party for the security of their code base. I think it's not the right way to go, and for me it fails to build any trust.
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
Just a friendly reminder that even billion dollar companies have critical security flaws:
Apple security flaw could allow hackers to beat encryption
Apple security flaw could allow hackers to beat encryption
Please stop it. Pointing at security flaws in other software does not make the ones in XCP any less severe. I saw you doing that on Reddit as well. It's as if you are saying that it's perfectly normal that people are losing money due to a gaping hole in the protocol and that all is fine and expected. It doesn't go down very well. Instead, why not admit that there is a serious issue and at the same time highlight that the devs are on top of it.
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
The market command was removed in an earlier update. For now, it's best to use blockscan in its place, as the GUIs emerge.
So the community is asked to trust prices published by a single, central website? I declare XCP is no longer decentralized at this point.
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
Was it mentioned if the hacker/white hat was going to return the BTC that they withdrew?
If they don't return that BTC, Poloniex would be out of pocket in a huge way.
I hope we can pull together an adequate bounty for the white hat such that they will return all BTC.
If they don't return that BTC, Poloniex would be out of pocket in a huge way.
I hope we can pull together an adequate bounty for the white hat such that they will return all BTC.
Does anyone know, what is market-rate for identifying a critical exploit these days? What are Google and some of the big tech companies paying, for example?
Maybe if we can offer the white hat a fair market rate or a little bit higher, then he she will feel fairly compensated and ultimately quite satisfied with the outcome, and as a community we will have a specific amount to target for our community fundraiser.
And how to establish this fair market rate? Put it on the DEx?
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
Was it mentioned if the hacker/white hat was going to return the BTC that they withdrew?
If they don't return that BTC, Poloniex would be out of pocket in a huge way.
I hope we can pull together an adequate bounty for the white hat such that they will return all BTC.
If they don't return that BTC, Poloniex would be out of pocket in a huge way.
I hope we can pull together an adequate bounty for the white hat such that they will return all BTC.
He said he would, but I haven't heard from him since he explained the vulnerability. My guess is he is waiting on the block chain rebuild to see where he stands with XCP.
If all the XCP gets returned to the Poloniex account, then the dump will stand, and he can keep the BTC. If not... then let's hope he returns it, and I'm going to have to roll back some trades.
Isn't this the Poloniex balance? Balance as seen v6.0:
c:\>counterpartyd balances 15vA2MJ4ESG3Rt1PVQ79D1LFMBBNtcSz1f
c:\>echo off
Balances
+-------+----------------+
| Asset | Amount |
+-------+----------------+
| BTC | 0.0 |
| XCP | 48154.78725249 |
+-------+----------------+
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
Attention: There's a typo in a recent commit to develop, so if you just pulled from that branch, pull again and get at least version 6.1. (It's not a protocol-level issue, so no reparsing or rebuilding is required.)
Did a pull but don't see the update (-V reports v6.0).EDIT: removed comment on code (github is for that).
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
The rules just changed, and troll orders shouldn't be a problem any more.
How? Is there a changelog?
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
Next step: trustless feeds.
How for instance create a trustless quotefeed for BTC/LTC?
Trustless = decentralized. So, build a feed publisher straight into counterpartyd somehow?
Any price of any asset or any outcome of any bet that is to be published fully automated and trustless inevitably must come from one or more electronically published sources. That's because the information has to be available to everyone and needs to be accessible algorithmically.
A price source can be some stream or even a web page. All peers can look up a price themselves and feed it to the network. A price should only be valid and published if for instance 2/3 of the processing power of the network is in agreement. (Else, no price should be published and any bets or trades depending on this feed should be unwinded. This however should be a rare event as most of the time all peers will be in agreement since the price source they use is hard-coded and the same for all. Processing power can be measured by some proof of work mechanism.)
Now the problem is reduced to finding trustless publisher. Who can be trusted to publish a truthful price? I think the answer is to pick prices from multiple sources. For instance, the price of LTC can be some weighted average of the price (time-weighted) taken from multiple exchanges. Exchanges may cooperate with Counterparty and publish a time weighted price of LTC on a web page every hour so all peers see the same price.
Similarly the price for Gold or any other asset can be hard-coded to be looked up hourly at several websites such as Yahoo, Kitco, Google Finance, Bloomberg etc. When in agreement sufficiently, it could be accepted as a valid quote and fed to the network. If peers are in agreement (2/3 rule) then the price becomes final and is published.
How for instance create a trustless quotefeed for BTC/LTC?
Trustless = decentralized. So, build a feed publisher straight into counterpartyd somehow?
Any price of any asset or any outcome of any bet that is to be published fully automated and trustless inevitably must come from one or more electronically published sources. That's because the information has to be available to everyone and needs to be accessible algorithmically.
A price source can be some stream or even a web page. All peers can look up a price themselves and feed it to the network. A price should only be valid and published if for instance 2/3 of the processing power of the network is in agreement. (Else, no price should be published and any bets or trades depending on this feed should be unwinded. This however should be a rare event as most of the time all peers will be in agreement since the price source they use is hard-coded and the same for all. Processing power can be measured by some proof of work mechanism.)
Now the problem is reduced to finding trustless publisher. Who can be trusted to publish a truthful price? I think the answer is to pick prices from multiple sources. For instance, the price of LTC can be some weighted average of the price (time-weighted) taken from multiple exchanges. Exchanges may cooperate with Counterparty and publish a time weighted price of LTC on a web page every hour so all peers see the same price.
Similarly the price for Gold or any other asset can be hard-coded to be looked up hourly at several websites such as Yahoo, Kitco, Google Finance, Bloomberg etc. When in agreement sufficiently, it could be accepted as a valid quote and fed to the network. If peers are in agreement (2/3 rule) then the price becomes final and is published.
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
ATTN PhantomPhreak - I left you a PM concerning the reimbursement of invalid orders caused by the order matching cq. rounding issue.
Thanks
Thanks
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
Oh SHEESH
Tx Source Buy Sell Price Expiration F_Req F_Prov Remarks
3256 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1000 XCP 1.320 BTC 0.00132 BTC/XCP (4713|5000) 0 0.0001 Invalid: cancelled
Don't tell me my cancellation of this order did not work either, and that lost 1.320 BTC!
PhantomPhreak, can you please have a look? Now I REALLY start to get more than a little worried. We're talking about serious money now. Did the cancellation also send my btc into a black hole? Tell me it isn't so...
Tx Source Buy Sell Price Expiration F_Req F_Prov Remarks
3256 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1000 XCP 1.320 BTC 0.00132 BTC/XCP (4713|5000) 0 0.0001 Invalid: cancelled
Don't tell me my cancellation of this order did not work either, and that lost 1.320 BTC!
PhantomPhreak, can you please have a look? Now I REALLY start to get more than a little worried. We're talking about serious money now. Did the cancellation also send my btc into a black hole? Tell me it isn't so...
Those who are investing in a project should do their due diligence. We made no secret about the state of the code; if you read the "Announcement" thread, you would have seen the following disclaimer:
The code being released here is of alpha-quality and under heavy development. You should expect to encounter significant bugs when using it. It is even possible that a bug might cause you might lose some money. The Counterparty team will do everything in its power to prevent this from happening, but this technology is very new, and the implementation is not yet well-tested. In particular, we may at some point have to change the Counterparty protocol in a not backwards-compatible way, if such a change is necessary to fix a bad bug or an exploit. As always, don't invest more than you can afford to lose.
Nevertheless, we have decided to compensate users for this bug, given its peculiar nature. We are all, however, extremely busy, and so if we don't get back to you right away, rest assured it is not because we are not "sticking to our promise", but because we are, among other things, trying to make sure that fewer serious bugs pop up in the future.
Thank you for your patience.
Sure, noted, but...
The Counterparty Team is looking to pay someone to do marketing
We have been contacted by several members of the community who are interested in helping out with Counterparty's marketing. It seems to us incongruous with Counterparty's 'project principles' to choose somebody without first telling the entire community that we are looking to pay someone to do PR for Counterparty. For now, we will be paying our marketer month-to-month (in XCP and BTC). We will start considering people now, and will stop considering them within three days (i.e. by to February 9); we will make our decision within seven days (i.e. by February 13), but reserve the right to decide
any time before then.
We have been contacted by several members of the community who are interested in helping out with Counterparty's marketing. It seems to us incongruous with Counterparty's 'project principles' to choose somebody without first telling the entire community that we are looking to pay someone to do PR for Counterparty. For now, we will be paying our marketer month-to-month (in XCP and BTC). We will start considering people now, and will stop considering them within three days (i.e. by to February 9); we will make our decision within seven days (i.e. by February 13), but reserve the right to decide
any time before then.
Are you sure now is a good time to market this "alpha quality software, under heavy development"? Why not wait a bit and let the platform proof its stability first before it's invaded by hundreds or even thousands of users? I really don't get this, you're risking the entire platform. Again a bug like this with 100 times the number of users, and XCP is dead.
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
CP Team,
What are the expected next stage milestones for the XCP platform and currency (by concept and appx target dates)? for example: friendly to use client, the next version of the decentralized exchange? what's more after that? can you briefly describe plans? it will also be great for the "spreading the word" aspect. Thanks
What are the expected next stage milestones for the XCP platform and currency (by concept and appx target dates)? for example: friendly to use client, the next version of the decentralized exchange? what's more after that? can you briefly describe plans? it will also be great for the "spreading the word" aspect. Thanks
Spread the word now, and you'll kill the platform. It's clearly still very immature. It seems I lost over a thousand USD already, poof into a black hole due to bugs. This software really needs to be way more stable and proof it's stable. The bugs where btc just disappear into the void, while reporting my wallet as having the order happily filled simply indicates that core parts of the software are not reliable. You don't want to announce it to the big public at this point, you really don't.
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
Oh SHEESH
Tx Source Buy Sell Price Expiration F_Req F_Prov Remarks
3256 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1000 XCP 1.320 BTC 0.00132 BTC/XCP (4713|5000) 0 0.0001 Invalid: cancelled
Don't tell me my cancellation of this order did not work either, and that lost 1.320 BTC!
PhantomPhreak, can you please have a look? Now I REALLY start to get more than a little worried. We're talking about serious money now. Did the cancellation also send my btc into a black hole? Tell me it isn't so...
Tx Source Buy Sell Price Expiration F_Req F_Prov Remarks
3256 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1000 XCP 1.320 BTC 0.00132 BTC/XCP (4713|5000) 0 0.0001 Invalid: cancelled
Don't tell me my cancellation of this order did not work either, and that lost 1.320 BTC!
PhantomPhreak, can you please have a look? Now I REALLY start to get more than a little worried. We're talking about serious money now. Did the cancellation also send my btc into a black hole? Tell me it isn't so...