Well, taking you at your word, I'll say this much, before you buy $1m worth of bitcoin with your dad's money (if you end up deciding to actually do this), you better be goddamn sure you know how to secure bitcoins.
I currently have some BTCs in coinbase that I bought with my own money. Is it not secure? I still don't quite understand the concept of putting it in a "wallet" that resides in your harddrive.... I feel like that is more risky. What if the file accidentally gets deleted or my computer crashes? Taking you at your word...this won't end well. Even if the price of bitcoin does rise in 2014. |
|
|
|
Added warning for secret phrases < 30 symbols.
This may help some, but it is worth noting that human brains are notoriously poor at generating enough entropy for a good brainwallet passphrase. Bitcoin lore already has too many stories of brainwallets drained by attackers running dictionary attacks. I've seen discussions here, on reddit, on on blogs that provide proof-of-concept code showing how attackers can maintain a local copy of a blockchain and execute a dictionary attack while entirely offline. The operating assumption (for Bitcoin) is that these attacks are underway and increasingly sophisticated. Presumably, the same kind of attack could be tailored to the Nxt Java client here, particularly once the source code is released. If the value of Nxt rises, Nxt brainwallets would become a more tempting target for any attackers that have already honed their skills on cracking bitcoin brainwallets in the past. Unlike Bitcoin, Nxt presently relies solely on brainwallets as the means of user authentication. There is no "cold storage" alternative offered. I see this security model as a vulnerability, and as future PR problem hurting mainstream adoption if Nxt coin heists do start happening. Brainwallets are surprisingly tough to get right for the unsophisticated user. |
|
|
|
Added extra transaction validation (@hacker: attempt ur trick again)
What is this change? |
|
|
|
All Capital raised in this or any of our future offerings will not be accessible directly by the Company looking for Capital. It is placed in Escrow and will only be distributed as needed by the Company to pay for expenses. A company will need to provide proof of what the money is used for and where the money is going. Only after verification, Funds are released only for the expenses specified, while the other funds are still kept in escrow. We will not just provide access to the Capital raised through Havelock Investments directly to the companies. They must show which phase of development they are at in order to receive applicable funds. The same way a Construction Loan works, only in provable stages.
In the event the Company is no longer able to continue operations, for whatever reason, the remaining funds in the escrow account will be refunded to the Unit Holders equally.
Thank you,
Havelock Investments
Havelock, is this a policy change that will be in effect for all future IPOs, or just this one? Why did you choose to implement it now, on this particular IPO? This raises new issues regarding Havelock's transparency and reliability. Investors and issuers both will have new long-term counterparty risks if Havelock itself is going to control the private keys to these large capital sums. Or are the the capital funds going to be controlled by some third party and be "escrowed" from Havelock itself as well? (Doesn't sound like it from the wording above). |
|
|
|
Gentlemen:
[...]
Gentlemen, thank you for your comments and time.
[...]
All the bitcoin investors in this thread are male?  So, is the 7C game itself for men only, or just the investment opportunity? |
|
|
|
You linked Primecoin (XPM) exchanges, but the OP is asking about Ripples (XRP). |
|
|
|
difficulty atm is 1.000000 ?
Yes, it is. There is probably a 4x limit on difficulty increase each interval (I didn't check), otherwise it would have gone up more. Blocks are pouring in much faster than every 2.5 minutes, so expect the difficulty to rise again at block 14112. |
|
|
|
My plan is to construct a 2 of 4 backup. - One paper in my house
- Second one as a digital file, encrypted with TrueCrypt and uploaded to Google Drive (protected by 2FA)
- Third paper with my parents
- Fourth paper attached to my last will
With this scheme I am always able to reconstruct my own wallets without external help, although it's still very hard for anyone to get their hands on more than one backup. I am protected from a fire destroying my house and my family can access my funds in case I die. Copies of the last will kept where? |
|
|
|
I'm just not 100% confident that the backups will be the same as the final version. I know it creates a frustrating dynamic, because I need people to help test the backups, but I have to tell them not to rely on them yet.
When will you decide this? I would love to use the m-of-n paper backup. Have you decided this now? M-of-N backups are available in the current testing release Yes, but the quoted statement from etotheipi suggested the possibility that the fragmented-backup format might yet change between testing version and release version. That ambiguity hasn't been removed by a clear statement, although it seems unlikely that the format is going to change given how close we are to release of a new non-testing version. |
|
|
|
176 shares left as of now. Well you can still get all 1320 shares! Just bid an extra .01! |
|
|
|
I think perhaps it is time to convert more of our BTC to MSC. I'd rather have MSC in a rainy day fund than BTC anyway. As you say, giving away BTC attacts people more interested in BTC, and I'd rather the foundation hold MSC than BTC. Here's my crazy proposal: 1) Keep only the 1000 BTC we've already moved into offline wallets 2) Use the remainder of our BTC to purchase MSC over the next few months on the distributed exchange 3) Pay all future bounties exclusively in MSC 4) Keep half of our MSC money for a rainy day and/or future distributed bounty system 5) If our rainy day fund becomes excessive, we can always vote to lower the ratio later I realize that this would potentially make all of our existing investors absurdly wealthy, but, well, the stated purpose of the Mastercoin Foundation is to serve the holders of Mastercoins, and I'm having a hard time seeing this course of action as anything but a huge positive for them, as long as we do it transparently and over a long enough period of time that nobody who wants to sell to us is left out. Also, MSC prices would probably go up to the point where I'd sell 1% and quit my job to work on MSC, which I hope would also be in the best interests of our investors.  Brutal honesty: As an Exodus investor I love the idea, BUT.. it really gives me a weird feeling. Could this not be easily misrepresented as a huge pump and dump by outsiders and contrarian? This proposal gives me a horrible feeling. This is too large of a deal to leave up to the board members. I'd prefer to take is slowly and delay and decision until we can vote on it. Or vote on alternative proposals. I believe a balance between msc and btc holdings can be found and potentially "managed", ie actively balancing a 50/50 position between btc/msc. Likewise. Is the purpose of the Foundation really just to "serve the holders of Mastercoins", or is it something broader such as shepherding the protocol so that it gets developed and adopted? This proposal might accomplish the former by bumping up the market price of Mastercoins in the short term, but I think it sacrifices the latter. It seems shortsighted as a bounty structure moving forward. Right now in the main Mastercoin thread there is a parallel discussion about how devs with spouses/kids/mortages find BTC bounties scary enough. Isn't shifting to pure MSC bounties -- an even more speculative form of remuneration -- counterproductive? Or, to put it another way: so many startups lack the kind of funding that the Foundation has acquired, by accident AND design, through its deep BTC reserves. Trading away too much of those BTC reserves for MSC is sort of like putting the Foundation back into the position of the disadvantaged startups that have to say: "sorry, can't pay you a real salary right now, but if we make it big some day your stock options will make you rich!" Whatever the actual motivations, the optics are just bad. This smells like a decision motivated by greed. |
|
|
|
BUY 2% Fee
1) Contact Jpmi1
2) Send BTC to provided bitcoin address
3) Provide jpmi1 with DTC address
4) Maximum wait for DTC from seller is 24 hours
SELL 2% Fee
1) Contact Jpmi1
2) Send DTC to provided Datacoin address
3) Provide jpmi1 with BTC address
4) Maximum wait for BTC from buyer is 24 hours
Note trades that fail will not be charged a fee.
Ambiguous. You are trying to offer an optional escrow service with a 2% fee? (That is how I interpret the green portion of the spreadsheet.) |
|
|
|
... I am actually in the process right now of upgrading my release process to include 10.04 and 12.04 installers by default. ... Will have a 10.04 offline bundle for you tomorrow morning In my search process I just noticed there is only 10.04 support until 2013/05. Are you sure you want to keep support on 10.04? One nice thing about 10.04 is that it will run on really old hardware, including non-PAE CPUs, which allows some otherwise obsolete machines to be used as the offline/cold storage piece of the Armory solution. (Devices like IBM ThinkPads from the Windows 98 and Windows 2000 era.) Because 12.04 switched over to using the PAE Linux kernel by default, it is non-trivial to get it to boot on a non-PAE CPU, so removing 10.04 support would probably, as a practical matter, reduce the universe of "spare" hardware that could be used for the Armory cold storage wallet. |
|
|
|
I would like to thank the academy and anyone else that sold low:)) I am in AM heaven with my new shares bought at .23
what?! .23? where - i want them He's trolling its called timestamped orderbook whistle Lol I deleted it when I saw AM1 timestamps then checked the charts haha Three AM1 shares really did sell for .2355 today. Check out: http://www.coinflow.co/chart/HAVELOCK/AM1at timestamp Nov 20, 22:20:45-22:20:59. |
|
|
|
How many chainsperday are you guys getting??? I'm at 160, but no coins yet at all for past 12 hours.
One Ubuntu virtual machine, running on 3 cores, currently reporting 378 chainsperday, with 13 blocks found in the last 12 hours. |
|
|
|
Please review our prospectus before purchasing any of the Fund's Units
Where can this prospectus be found? I am unable to find a link to it on the Havelock site. |
|
|
|
Can we still join in between now and January 3? I haven't really seen any clear definition of a deadline.
I'm waiting for the answer. BCNext reads this thread. Some changes in the plan: 1. Fundraising is over. That last 1 BTC, sent after the 2nd marking transaction, will be accepted but no more deposits should be made. 2. Nxt will be launched earlier than on the 3rd of January, right after the final test. 3. New Nxt users r supposed to be attracted by selling NXT and distributing via Nxt Faucet. 4. Messaging feature will be released later to avoid situation when somebody attempts to bloat the blockchain making it too huge for newcomers. BTW we need one more bootstrapping server, coz 2 servers is not enough.So, if I understand this correctly: 1) the main dev (BCNext) no longer posts directly to this thread but you purport to communicate with him and speak for him about the project, something we can't confirm, 2) the deadline for contributing BTC to acquire Nxt, which was originally described as being open until the genesis block was approved by the community sometimes at least a month from now, is now suddenly declared over with no advance warning; and 3) the BTC that were already sent to acquire Nxt, which the main dev (BCNext) promised earlier in this thread not to touch until the genesis block was generated, have now been moved. |
|
|
|
The slow confirmation times appear to be the result of one or more miners having adopted a policy of refusing to include more than one transaction per block. See here: http://btsblock.com/chain/ProtoSharesYpool (the largest pool) appears to be one the bad actors. If you compare block numbers from their stats page to the blockchain explorer, it looks like all of ypool's blocks are only including 1 transaction at most. Thus, everyone trying to send PTS through the network is having to wait until someone else (such as the beeeeer pool) find a block, at which point a bunch of transactions finally get included in a block. |
|
|
|
I'm not a miner but I just discovered this important thread. Excuse me if this has already been covered (thread now too long to read in full) but let me share my 2 satoshis:
I setup all my "converts" with the blockchain.info wallet on a smart phone. People just send and receive to the same address over and over and I can see all the money flows into and out of their account. You can't tell them to do anything different--they *think* they don't care, and besides it can't really be done on blockchain.info for mobile anyways. Most new users don't realize the potential for future privacy/security problems with address re-use.
I like Luke's idea because it would incentivize people like piuk to implement BIP32 for the main web wallet on blockchain.info. Users would just see a balance in their "spend" account and the fact that a new address is being created for each transaction would be invisible to them. This adds no complexity that I can see, but lots of privacy and security. It seems only a good thing.
Yup. That is the important part. Luke's patch can't FORCE anyone to use unique addresses however it can provide an incentive and if/when more of the hashpower implements it the incentive grows. Without any incentive we likely will be in the exact same situation a year from now. The current "lazy" static address use scenario is the easiest to implement. Privacy minded miners can push for this patch which provides an incentive to make the Bitcoin network more what they want it to be. Voting for change with hashpower.A key point, and a reminder of the sway that miners may ultimately hold over the future of bitcoin. Miners can switch to Eligius if they support this policy, and increase its network hash percentage, or switch away if they don't. Is this a harbinger of things to come...will we see more examples of political "policy" differences between how pools process transactions in the future? |
|
|
|
|
Show Posts
