|
I think he was just using XCP as a synonym for Counterparty. Has that been posted/published elsewhere?
I'm not clear on the Grid NFC token. What is it from a user's perspective?
|
|
|
|
Like it or not, requiring users to run vulnerable software is bad.
Like it or not, everyone is using vulnerable software. Everyone. Have you ever seen an invulnerable software ? I would like to know. No one should be running a system that is susceptible to a published security vulnerability if they can help it. That's common sense. # glsa-check -t all
This system is not affected by any of the listed GLSAs
# I'm disappointed that security isn't a higher priority here. Just because nothing is 100% secure doesn't mean it's OK to require users to install software with published security vulnerabilities. |
|
|
|
I suppose I'm trying to understand the reasons not to issue a third-party token.
Just need to be patient, if you have read our latest dev update it explains there when we expect the wallet to be ready. I think it's because the Factom devs want to avoid the usual pump-and-dump games that go on around here, not to mention an ethical commitment about not letting it be traded while the product is still vapourware. Sooner or later the tokens will be on the market and then they are susceptible to pumping and dumping. Not releasing a third-party token can't prevent it. And to say they can be sold but not traded while the product is vapor is nonsensical. |
|
|
|
|
Try going outside. Or at least take a breath.
Even if those 13 security vulnerabilities only pertain to running untrusted code as you say (you've obviously investigated each one: nice), what if an ARM+NRS user makes that vulnerable JDK their system JDK and runs a browser? Like it or not, requiring users to run vulnerable software is bad.
|
|
|
|
These security bugs are talking about running malicious untrusted code on JVM that can breach JVM's builtin security.
Once again: It sounds like you have already carefully gone over each of the 13 vulnerabilities
|
|
|
|
|
Like it or not, this is a real concern. Take Argentina for example. That's a country where BTC is beginning to make good inroads against the pathetic Argentinian peso. If it gets to the point (hopefully) where anyone in that country with money has that money in BTC, anyone there could be robbed of it quite easily. If someone has cash under their mattress and a thief finds out about it, they could be robbed. But here we have a potential situation where everyone has "cash under their mattress" in the form of BTC and so everyone can easily be robbed. This can't happen to anywhere near the same degree with money in the bank.
BTW, I'm not talking about stealing someone's cell phone for the BTC contained therein, I'm talking about armed home invasion.
|
|
|
|
|
Maybe it's more like Ripple and Stellar than Bitcoin?
|
|
|
|
The latest available there is 8u33 which has 13 security vulnerabilities currently (3 of them rated 10/10 for severity): http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19116/Oracle-JDK.htmlSo everyone running the latest NRS on an ARM device (Raspberry Pi, etc) is likely open to several severe security vulnerabilities. ARM users should be instructed to shut down their nodes until Oracle releases something newer than 8u40. NRS updates should have been delayed until a secure ARM binary is available from Oracle. This was not handled responsibly from a security standpoint. can't remember when jdk ever was bug free (like many other complex dev-stacks). however, since i am not a java coder but running an arm node, it would be helpfull if you could point me to a more concret security problem or better to a non theoretical attack vector, where running the arm node isn't secure. if this is a real world security problem it has to be adressed ofc. As you know, bugs aren't the issue, security vulnerabilities are, and it looks like 8u41 and higher are free of known security vulnerabilities. The latest version for x86 looks to be 8u45. Details on the vulnerabilities are accessible via this link: http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19116/Oracle-JDK.html |
|
|
|
|
I suppose I'm trying to understand the reasons not to issue a third-party token.
|
|
|
|
So Koinify is simply a non-transparent centralized service that does not use blockchain technology to record the "vouchers" it marks in its database in exchange for BTC?
Not sure what you mean by non-transparent though. It was a crowdfunding platform. Transparency is when you record something on a blockchain so everyone can verify that you've done what you say you've done. Non-transparency is when you record something in your own internal database and expect everyone to trust you. For Factom everything was recorded on the blockchain using Op_return so I guess that fits your transparent definition.  Koinify has recorded each investor's Factom balance on the BTC blockchain? Can you show me an example? I'm still puzzled as to why they didn't just issue Counterparty tokens. Here is all the info you need: http://explorer.chain.com/addresses/35gLt5EgB367enjSjyEDahhWWcy6p1MGf6#!address-getWe didn't choose to do an XCP or Omni asset because there was no need. Factoids will have their own wallet. Is a Factom balance visible at that address in the explorer? I can't find it. MaidSafe coins will have their own wallet too but they issued an Omni asset so investors could trade before the MaidSafe wallet and network are finalized. |
|
|
|
The latest available there is 8u33 which has 13 security vulnerabilities currently (3 of them rated 10/10 for severity): http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19116/Oracle-JDK.htmlSo everyone running the latest NRS on an ARM device (Raspberry Pi, etc) is likely open to several severe security vulnerabilities. ARM users should be instructed to shut down their nodes until Oracle releases something newer than 8u40. NRS updates should have been delayed until a secure ARM binary is available from Oracle. This was not handled responsibly from a security standpoint. |
|
|
|
I think not carrying a phone full of bitcoin goes along the same common sense line of not carrying a wallet full of cash. I don't see how this is a story. People get mugged all the time
I think he means that someone can break into your home and make you give him the bitcoins Yeah that's more like it. |
|
|
|
What is stopping me from modifying the Counterparty installation on my system to provide all of the same functionality without burning XCP?
The network effect. It would be a one person party that's implementing updates from the real dev team.  I'm still not clear on this. Let's say I'm a company that wants to create an interface for smart contracts. Why can't I modify the counterpartyd instance running on my server to execute smart contracts without burning XCP? As already answered: Network effect. The question is akin to asking why you can't modify the bitcoind instance running on your server to process transactions without debiting BTC, whilst you CAN do it, you will need to convince the super majority of users to agree that that's a good idea. XCP acts as a anti-spam token, and an economic reward, if you tried to create your fork you would really just end up switching it to an XCP alternative token to fulflll those functions. Your newly created tokens properties (distribution, adoption, upside potential of continuing to hold or hoard) would have to match or usurp the previous I can see how you would want to take advantage of the network effect with tokens since you might want to move them to a different instance of Counterwallet or to another Counterparty wallet, but would the same be true of smart contracts? Wouldn't all of my smart contracts execute on my server's instance of counterpartyd? "We're aiming for a generic platform that is agnostic to underlying distributed technology, so not only Bitcoin but Ripple, Ethereum, Hyperledger, and a proprietary stack built around Counterparty are all in play," he says. "We're also working on private blockchains and 'known' networks, as we think that might be a better application of the technology for some institutions. The idea with smart securities is that the battery comes included: to create contracts that can act on the blockchain autonomously, from issuance and corporate actions to decentralized secondary trading, clearing, settlement and transfer."
Smith says the early target is illiquid securities and funding activities — including both traditional venture-capital and crowdfunded private-equity transactions, as well as other applications like merchant banking, intercompany funding, and syndicated loans. The firm is already integrated into multiple tier-one banks' development programs and blockchain pilots. Many are focused on smaller use cases that don't already have processing intermediation in place, relying instead on spreadsheets and fax, and at least a few should be implemented by year's end.
Symbiont aren't alone, with many others in the space crossing over to blockchain work now, but Smith argues there are "maybe three or fewer firms" in the industry that have both the financial understanding and technical expertise to do it right.
"Most people entering now are trying to execute on things like how to 'tokenize' a security, on that plane of the learning curve, which we were doing two years ago," he says. "Though that's an interesting process, to us, the real value proposition in convincing an institution to rip out systems, and change protocols, must go well beyond that." I can't find this article online. Can you point me to it? |
|
|
|
|
This is something I've been concerned about for a while now. I just read about it happening for the first time recently. If someone knows you have BTC, they can easily rob you of it at gunpoint. I could see this happening a lot once the price goes nuts again.
|
|
|
|
What is stopping me from modifying the Counterparty installation on my system to provide all of the same functionality without burning XCP?
The network effect. It would be a one person party that's implementing updates from the real dev team. I'm still not clear on this. Let's say I'm a company that wants to create an interface for smart contracts. Why can't I modify the counterpartyd instance running on my server to execute smart contracts without burning XCP? |
|
|
|
If I'm not mistaken, the Oracle JDK is not open source and there are no ARM binaries available. How are people supposed to run NRS on the many (many!) available ARM devices such as the Raspberry Pi? |
|
|
|
So Koinify is simply a non-transparent centralized service that does not use blockchain technology to record the "vouchers" it marks in its database in exchange for BTC?
Not sure what you mean by non-transparent though. It was a crowdfunding platform. Transparency is when you record something on a blockchain so everyone can verify that you've done what you say you've done. Non-transparency is when you record something in your own internal database and expect everyone to trust you. For Factom everything was recorded on the blockchain using Op_return so I guess that fits your transparent definition. Koinify has recorded each investor's Factom balance on the BTC blockchain? Can you show me an example? I'm still puzzled as to why they didn't just issue Counterparty tokens. |
|
|
|
|
Show Posts
