The collateral is BTS (for the 3rd time).
I don't accept BTS as having value. I don't accept doge coin either. I regard these assets as having no collateral, because I have no guarantee that I can exchange BTS for anything of value. |
|
|
|
Yes you are incorrect. BitShares is a decentralized exchange- it doesn't trade only IOUs as you are claiming, it trades assets that peg the value of their real world counterpart, also known as market pegged assets or bitassets. A gateway could issue their own IOU on bitshares and trade it 1:1 for bitUSD however. BUT the market pegged assets are not IOUs! These assets have collateral locked on the blockchain.
Hence, a bitUSD is a stablecoin with the properties of Bitcoin (i.e. lower counterparty risk), backed by BTS as collateral.
These market-pegged assets are pegged by whom exactly? Who takes the loss if the relative value of assets changes and then someone wants their asset back? If they cannot be restored to the real world from the block chain, then they are not two-way pegged. And a one-way pegged asset is indistinguishable from an IOU. Someone took the real-world asset and manipulated the block chain to create the "pegged" asset - but if he did not keep the real-world asset at some actual place in the real world where you can trade in your "pegged" asset to get it back, then your pegged asset does not have its value. This is just plain wrong. Market pegged assets like bitUSD, bitGOLD are a new type of asset... not user issued IOUs. Read more about them here: http://whatisbitusd.com/whitepaper/DANGER WILL ROBINSON!!! When someone tells you something is a new type of asset, there is a 99% chance they are trying to scam you! This has been true for thousands of years! We use these terms because the bitasset has the same buying power as the real world counterpart. AND it is not because someone is promising to redeem it as such (as with an IOU)! The value is frozen on the blockchain when a short order is matched to create the new bitasset. And technically the proper term is BitGOLD, BitUSD, etc.
If the same set of merchants who accept the real-world counterparts are willing to accept the bitasset on the same terms, then it has the same value. But they aren't. And they won't, because, as you admit, there is no one who is willing to exchange the bitasset for the real-world asset they value. Also, the "value" frozen on the block chain is measured in what units? Hint: There IS NO unit of value that does not constantly shift in its exchange rate relative to other units of value. Even if there were, there is no way anyone can guarantee that unit of value is retained, unless there is a way to exchange the bitasset for that asset -- which would mean that the real-world assets are, in fact, stored someplace where you can get them back. |
|
|
|
|
Okay, did that. Serialization and constructor calls were a heck of a thing to sort out, but now txOuts have a spendable time - a block height before which they cannot be spent. At this time it's only supported in raw RPC transactions - the wallet doesn't know boo about it except to not display them for its current balance until they are valid and not use them to try to make payments until they are valid. It always creates txouts that are not limited to a spendable time.
At this point I think I've provided ways to prevent most of the potential attacks on atomic cross-chain transfer, at least from my side.
But since I now have StakeTime and StakeBlock, I can't resist going ahead to implement a non-stupid implementation of Proof-of-Stake.
For the record, all implementations of Proof-of-Stake that I've seen so far are in fact stupid.
What I'm going to do is a PoW/TaPoS hybrid (that is, Proof-of-Work combined with Transactions as Proof of Stake). Who forms the block is determined by PoW. Each transaction 'stakes' a given block, and is not valid in any blockchain that forked before that block - making txOuts that exist before the fork into a finite resource that either supports one side of the fork, or cancels itself out by supporting both. Resolving the conflict between two block chain branches will depend on both the relative proof-of-work between the branches and the total amount of txouts created before and staked after the split. The stakers and the PoW miners will both get payments for securing the chain in the same proportion that their contributions to chain security are counted relative to each other.
I'm probably going to find dozens of bugs when I start testing this....
|
|
|
|
what if a wallet contains many small (~5k sat) payouts. how long will it take for them to have high enough priority?
last time i sent some of these coins to an exchange and it had low priority while i had 0.0001 fee included.
the coins were at least a week in my wallet before sending.
Um. A long time. If you want to consolidate them without paying fees, put 20 of them together with a 1+ bitcoin input that's aged for more than 200 days and have one or two outputs of more reasonable size. It may take a long-ish while to get a confirmation, as that'll be a big (in size) transaction and no-fee transactions propagate very slowly because they're rate-limited. Wait for that output (or those outputs) to age for a while, then rinse, repeat. |
|
|
|
If and when we reach the point where 95% of the blocks published in the last 1000 have the new block version number, then clients will start rejecting any blocks with the old block version number, and the fork will be enforced from that point onward whether the blocks formed are >1Mbyte or not. This is interesting. Is this really true? If we fork we will need to have mandatory >1MB blocks? Everything else will be orphaned? "Whether or not we do" means "We must do" in your language? Interesting. That ain't the way English works, unless you learned your language from Faux News. |
|
|
|
|
Okay, I thought about it. It is not just necessary for txOuts to have a spendable time, it is also necessary that people can see what the spendable time is without anyone having actually provided the script to spend it.
So I'm hacking an nSpendableHeight into txOuts. This will get serialized in the txOuts of each transaction and will permit transactions to have a minimum block height before which they cannot be spent. And importantly for auditable protocol, people can look at the block chain and see what that height is. I don't think a maximum spendable height is going to be necessary.
|
|
|
|
If and when we reach the point where 95% of the blocks published in the last 1000 have the new block version number
That is, if someone with commit access doesn't change the requirement to, say, 60%. Because good reasons and won't you think of the children. Why the hell would someone do that? Nobody wants a fork that can be attacked. We don't want it to happen until you and those who agree with you can be safely ignored. |
|
|
|
I haven't followed all the technical details but there was some pretty strong words about how the anti-fork brigade had a plan to attack the forked blockchain and it *seemed* reasonably scary what they were saying. Maybe it was overblown? Maybe some of those folks have come around now?
Nope. But not to worry; if a fork actually happens, they will have no wherewithal to attack the new chain. If miners like the idea, they publish the new block version number in their headers. If they don't, they don't, and no fork happens. If 75% of the blocks mined in the last 1000 have the new block version number, the miners are free to make a >1Mb block. But nobody has to. It could be quite some time before an actual >1Mb block and subsequent fork happens. Anyway if a fork does happen at that point, the people who want to "attack" the block chain have, by procedure, less than 25% of the hashing power. Which flatly isn't enough to have a noticeable effect on the new block chain. If and when we reach the point where 95% of the blocks published in the last 1000 have the new block version number, then clients will start rejecting any blocks with the old block version number, and the fork will be enforced from that point onward whether the blocks formed are >1Mbyte or not. And if the fork happens at that point, the "attackers" are left with 5% or less of the hashing power, and the threat of an attack is sort of like pointing an unloaded BB gun at an elephant. |
|
|
|
v0.10.0 doesn't speed up block propagation times. The header first protocol is to allow new nodes (or nodes rejoining the network) to find the longest chain quicker. New nodes can sync up headers first. Find the longest chain and then allows download missing blocks in parallel across multiple peers. This spreads out the load on the network and allows faster syncing times but it doesn't speed up mining at all. 'Headers first' isn't 'headers only', the next step is to download the block 'body' and that takes just as long.
Aw crap, I thought that headers-first applied to new blocks too. Looks like I gave it too much credit. Still, headers-first is an awesome improvement. It shortens the chain download time dramatically. |
|
|
|
The most provocative point is the one about miners constraining their block size; why do they do it? What advantage do they gain? Where can I learn more about header-first block transmission?
Up until v 0.10.0 (the most recent release) miners had a problem making their blocks too big because big blocks propagated across the networks more slowly. This meant that if two miners found a block at the same time or close to the same time, the one with the smaller block was more likely to reach more of the network faster, making the other block an orphan. Since an orphan block gets no block subsidy, the miners were looking at a situation where larger blocks actually reduced their profits measurably. But v 0.10.0 Introduces header-first block transmission, which means now miners that find a block can just transmit the header. And the headers are about the same size, so the orphan risk is now the same regardless of how full the block may be. It's also more efficient because the tx are already out there circulating - all the nodes have them in the mempool. Once the nodes get the header, they can build the block themselves - maybe requesting a few tx they don't already have from peers. There is also a slight issue with the Merkle trees, as Shorena pointed out: The merkle trees that bitcoin builds for its blocks have "steps" in size where they're most efficient (and most secure!) for a number of transactions which is a power of two. So some miners will build, say, a block of 128 transactions rather than 200, or 256 transactions rather than 310, first because if you can't fill the next power of 2, the bigger merkle tree is being used inefficiently and second because if you can't fill the next power of 2, then one side of the merkle tree is built from far fewer transactions and unbalanced, so it becomes potentially easier to analyze or predict. But no ways to attack anything we care about based on this imbalance have yet been identified. |
|
|
|
Does anyone else find it sad, a bit depressing, that this thread has once again devolved into conflicts of personalities instead of ideas?
(Raises hand) Me. I find it sad and depressing. I don't like the current proposal, it is a decent guess, but it doesn't solve the problem. It is a patch only. It takes tremendous hubris to imagine that anyone knows what will happen with Bitcoin transaction volumes in 20 years.
It doesn't try to project bitcoin transaction volumes for 20 years. What it's trying to project is what's the size of the biggest block that *won't* constitute a dangerous attack on the block chain for 20 years. IOW, if we wind up filling this size block at some point because of transaction volume, that's an interesting and sort of unexpected development. If we *don't* wind up needing this space for transaction volume, and some miner for inscrutable purposes chooses to publish blocks this size anyway, then these limits are expected to prevent such a miner from being a threat to the bitcoin system. What it's trying to project is what's the *capacity* for bandwidth for the next 20 years, not because this bandwidth will definitely all be needed for tx but because with this bandwidth will enable nodes to handle blocks this size if necessary without breaking under the strain. |
|
|
|
|
Well, there was already an nLockTime (minimum block/time for a tx to be valid). I added an nLastTime (maximum block/time for a tx to be valid), plus an nStakeTime and an nStakeBlock; nStakeTime is the height of a 'stake block' for the tx, and nStakeBlock is the last 32 bits of that block's ID. And I implemented functions IsAliveTx and IsStakedTx to check for these conditions being wrong, and hacked IsStandardTx to keep such tx out of the blocks, and IsValid to keep blocks containing such tx from being accepted in a blockchain.
So, you can have a tx that is valid only between block A and block B; you know for sure that it won't be included in any block before A, and you also know for sure that it won't be included in any block after B.
The idea with nStakeTime and nStakeBlock is that a tx is not valid in any chain other than one where the block at the named height has a hash whose last 32 bits matches the named nStakeBlock. And this means that if a bunch of related tx all stake the same block, you can guarantee that if any of a them disappears in a reorg, then ALL of them disappear in the same reorg. And that also puts in the infrastructure for proof-of-stake that doesn't suffer from the "nothing-at-stake" problem, although I have not implemented any PoS yet - and if/when I do it'll be a true hybrid where proof-of-work is still required to find blocks.
I have not implemented time-locked outputs yet; the more I think about it the more I'm certain that there is a better way to do it than by having another data field in the txout. Time-locked outputs and much more become possible if the scripting language has an op that pushes the current block height. Then the time-locked output becomes a P2SH output, where the script pushes the block height, compares it to a number that's already there, and returns true iff one is greater than the other.
This makes several ways to 'backstop' the cross-chain trading risks involving playing silly-buggers with block timing and reorgs.
But now I need to think hard about whether that new scripting op introduces new vulnerabilities and scams.
|
|
|
|
|
It's a mistake to think it's just the bursty rate of transactions that cause big backlogs occasionally; transactions are fairly steady most of the time compared to the block rate.
Sometimes it's a couple of hours until the next block, and sometimes it's about ten seconds until the next block.
The biggest backlogs usually happen when three or four blocks in a row have taken a long time to solve. Especially if they were found by miners who don't wanna build blocks more than a quarter-megabyte big, although that's much less a concern once header-first block transmission is solved.
But yeah, the transaction rate is very bursty. And once in a while you get a whole lot of transactions during a several-hour period where you get very few blocks.
|
|
|
|
|
The title for this thread should be "do humans use bitcoin?"
And the answer, well, is YES.
A nerd is a nerd, regardless of plumbing. Don't tell us what gender you are; just tell us what cool shit you hacked.
|
|
|
|
Password protect your wallet. Or save your coins on some trusted exchanger site.
The saving coins method is flawed. Everyone said inputs.io was legit and looked what happen  . One acid test of whether an exchanger should be "trusted" is if they have EVER accepted a bribe, or even openly charged a fee, to list an altcoin. It's not the only test you should be looking at but it's definitely one of them. If they are already known to be corrupt, don't trust them with your bitcoin keys. |
|
|
|
|
Yes, there was a guy named William Shakespear (or Shaxpur, or Shakspeer) contemporary to the time those plays were written. He was a grain merchant whose father was a glove maker. They can find that person's absolutely identified signature only on three documents, and he spelt it differently each time. I don't believe, and I most people whom I trust as knowledgeable in that field don't believe, he's the same person as the author. Once you've written a few hundred thousand words, I suppose you've probably settled on one spelling for your own name. Also, the records at Stratford, where that person was born and raised, do not show any indication that he ever attended as a student - and if you didn't go to one of those very few schools, at that time, you were unlikely learn to write at all.
So you get a bunch of people who think the author was Francis Bacon, and a bunch of people who think it was Edward de Vere, and a bunch of people who think something else.... And nobody's got any definitive evidence.
|
|
|
|
Mine was that people's idea of perfection can vary wildly. Or at least, that's my story and I'm sticking to it.  |
|
|
|
|
Perfect distribution would be achieved in an economy with a GINI of 1.0
But that ain't gonna happen. Last time I looked, the USA has a GINI of about 0.41.
Bitcoin's distribution is somewhere around GINI 0.86 IIRC.
|
|
|
|
I researched this and wrote about it today: This is from the 'cybernetic entomology' series from my own blog at http://dillingers.com/blog --- At the time it was discovered, this bug affected 37% of all HTTPS servers. The Apache web server using all but the very latest version of OpenSSL was the primary vulnerable server. At that time Apache was serving 58% of all web servers on the Internet, and more than half of these were vulnerable because they had not been updated with the most recent patch of OpenSSL.
Apache mod_ssl, in particular, made this even worse. Because it is computationally expensive to generate RSA keys, mod_ssl, by default, generates a single export-grade RSA key when the server starts up and then re-uses it for all the sessions served until the server shuts down. So an attacker obtaining a 512-bit RSA key could take the few hours to factor it, and the server that used that key would still be up — enabling the attacker to read and modify further traffic on the fly until it reboots.
The uptime for Apache servers running on stable operating systems can reach weeks or months. Essentially, they get started once after a kernel upgrade forces a reboot, and do not shut down until rebooting the machine for the next kernel upgrade or a hardware failure. So, having gotten the key once, an attacker could read and modify the traffic on that server for weeks.
The websites whitehouse.gov, nsa.gov, and fbi.gov (including the FBI anonymous tips website) were all among the sites whose servers were vulnerable, meaning that the buggy security decisions of decades before had resulted in a bug that reduced the security of the very same organizations that had made the decisions. Which goes to show that if you don’t get good decisions, at least you eventually get irony.
Web browsers afflicted included Internet Explorer on Windows, Chrome on MacOS and Android, Safari on MacOS and iOS, Opera on MacOS and Linux, as well as the stock browsers provided with Blackberry and Android devices. FREAK was short-lived after its public announcement, because the web servers afflicted could fix it by downloading a new version of OpenSSL already available, and security patches for the browsers started coming out just a few hours after the attack was announced.
|
|
|
|
Dude. That's a nice one. Seriously, cool hack. Now for extra credit, figure out how to make it work for systems that dare to change the format of the block header. Just kidding. If they're changing the format of the block header, they can figure it out on their own. |
|
|
|
|
Show Posts
