 Show Posts
|
|
Pages: [1] 2 »
|
|
Is there anyway to easily encrypt the private keys from armory before writing them on paper? I would feel much safer if they were password protected.
And any word from Armory about LTC support? lol happened while i was writing my post
|
|
|
|
|
rwyPZKyKGFpXnhkfAXMb4W3QiAw5zpxG97
|
|
|
|
2) The interlinking still makes me nervous even with the instant IOU cancelling out possibility. I'd like to see an example of this with say 3 of us users. For example, Barclays is the most connected company in the world so what can we do if we wanted to get rid of them?
I'm not quite sure I follow you. You decide who you trust to hold money for you. If you don't trust someone to hold money for you, just drop their trust to zero and add trust for others. Is there anyway to set a fractional amount of trust, for example trust someone at 50% face value of their IOUs? The biggest problem I see is if you hold good money (trustworthy IOUs) in your ripple, quick acting people (or people running smart scripts) who you trust will quickly swap out this good money for their not so good IOUs example situation: A holds $100 of mtgox IOU (assume very trustworthy) A has acquaintances B1 to B100 who A doesn't know very well, maybe from a forum, so only trusts them with $1 each As soon as $100 mtgox IOU hits A's account, B's scripts quickly notice and swap their own IOUs for part of this mtgox IOU Now A has $100 in $1 IOUs from B1 to B100 which may only be worth $50 |
|
|
|
|
I don't think there will ever be enough support to make these changes in namecoin, we should start creating a proposal for a new coin.
features i want to see:
btc merged mining
ssl support
auction system for names
For the auction, trying to create a brand new name should create a period of a couple days where others can make bids, if no bids the name is granted at the minimum price. Make a certain % of each bid nonrefundable to prevent people from bidding up the cost for spite. Require each new bid to be 5-10% higher than the current highest, allow people to add to their bids, and reset the auction timer each time there is a new high bid.
For renewals, in addition to or instead of having a timer (6m - 1y), let auctions be triggered if a certain amount of coins are pledged (coins made unusable until the next auction is completed then returned to pledger), maybe set around 10x the amount the name went for last time. Again maybe make some % of this pledge nonrefundable.
Create domain root authority for the new coin, allow each name owner to upload an ssl key to the blockchain that is under that root authority, lobby the browsers to get this root authority packaged with install or place it under a root authority already included in browsers.
|
|
|
|
|
Can nTimeLock and multisig be used to create a 2 of 3 transaction where one of the sigs can't be used before block N?
This could be used to create a wallet payment service: 1 key held by wallet service, 1 key held by user, 1 key that can be used in 1000 blocks printed out and held by user for insurance in case wallet service disappears
But before this time is up the wallet payment service can be sure this account cannot be double spent, so its can be used to pay instantly for things like ATM withdrawal based on the reputation of the wallet payment service.
|
|
|
|
|
I wouldn't worry about instant withdrawals from arbitrary bitcoin address, those people are going to have to wait. Instant withdrawals would be for people that have wallet accounts with the ATM provider, or maybe even networks of trusted wallet services.
|
|
|
|
With MintChip there is no blockchain. There is no central ledger (centralized or decentralized).
Why do you think this? I thought the description made it pretty clear there is a central clearinghouse for all transactions. Your money is not on the chip, the chip is just an account# and keys to spend. The balance is recorded in the central clearinghouse. The devices are just able to check that transactions are signed by the certificate authority without having to ask the clearinghouse themselves, basically it means the business you are transacting with can give you a receipt that proves they sent/received the money.
Well three possible outcomes:
a) they crash and burn because it honestly is a real difficulty problem.
b) they figure it out and we copy them.
c) they figure it out but we can't copy them so we buy BTC with MintChips.
Honestly I think a is going to happen but any of the three is a win.
c Western Union currently does this, they make it clear to banks any money sent to them is nonrefundable (they are large enough to negotiate such an arrangement unlike other smaller processors and thus banks have serious limits on how much they allow you to send to western union and probably more sensitive fraud detection) or they require you to hand money over in person. There is no reason why a government could not tell banks in its country that any money sent to mintchip cannot be reversed, and leave it to the bank to decide how much they want to risk. |
|
|
|
|
This is a good thing for bitcoin. Canada's backing will put MintChip into many stores as a payment option. Exchange between MintChip and Bitcoin will be easier than any other fiat currency with its irrevocable electronic transactions, anyone will be able to start an exchange without having to rely on paypal or other processors. Essentially we could end up with a system like:
MintChip = checking account
Bitcoin = savings account
|
|
|
|
|
The best thing a billionaire could do would be to buy into companies (or use companies they already have large investments in) and convince them to add bitcoin to their payment/withdraw methods. A few midlevel online retailers accepting bitcoins could make a huge difference. Also another area would be companies that buy/sell online ads, imagine an ad network that could pay out hourly/daily with no chargebacks.
|
|
|
|
|
what happened to blockexplorer.sytes.net? are there any litecoin blockexplorers currently online?
|
|
|
|
|
All wallets get kept on a server at your home that handles keys & generates transactions and communicates with your online server, ssh connection between home server and online server. The only bandwidth used is online server sending requests for new addresses for deposits and withdrawal requests, and home server sending back addresses and signed transactions for online server to publish (or denial of request). An average home connection should be able to handle this even for a massive amount of transactions, lets say you have a very low 100kb/s total bandwidth and each transaction is 1KB total both ways you could still handle 750 withdrawals a minute at peak without queuing.
Along with other checks, home server could also keep its own ledger of customer accounts to detect if online server gets compromised and fraudulent withdrawal requests are being sent. The only downside is possible extended downtime (just delayed withdrawals, site would still be operational) if your power/connection goes out, but I'm sure you would still be at like 99.9%
|
|
|
|
If a major player offered to "buy out" all existing Litecoin only if 90% of all accounted for coins were included, would you sell at least 90% of you holdings? I would like to see someone try this just to see if a big company could outperform Bitcoin with even an arguably superior code.
but how are you going to stop us from joining LTC2 (some fork of the chain presale) after we sell? |
|
|
|
What is LiquidCoin?
https://bitcointalk.org/index.php?topic=60026.0it has some interesting features: fixed difficulty, block reward decreases 4% every 1000 blocks then stays at 1 so it will inflate slowly forever. plus a large percentage of coins will be passed out in the next few months so it will be one of the first currencies we get to see mature. vircurex is trading it currently, but i'd like to see it on btc-e where there can be a decent volume. |
|
|
|
|
could you add LiquidCoin to your exchange?
|
|
|
|
|
theres another way to reach dollar parity, just offer to buy all solidcoins at $1
|
|
|
|
My pool is closed now. I have been discovered 2M of pre-mined coins in the second block. Rucoin it's a SCAM, and I don't want support It.
at least open your site back up so i can withdraw my coins |
|
|
|
A system such that if a miner can include multiple transactions from the same address, with the same previous_output, that would overdraw the address, the entire balance of the address is set to zero and the coins are passed back out. Maybe something like 5% to the miner who finds it, then 1% to the next 95 blocks (make it less likely for coins to passed back to attacker). Would this incentivize miners to do tricks with fees that are harmful to the health of the network? Currently, if you don't include enough fees in a transaction for the big miners to pick it up you have to wait for the old transaction to be forgotten and resend it with the same prevouts. If miners can steal coins that are double-spent in this way, they may have an incentive to deliberately delay transactions in the hope that the sender resorts to resending with larger fees, allowing them to steal the coins. have transactions also include a block number they expire by, then if you send a transaction that does not go through you know how long to wait before resending. |
|
|
|
Upd: Also we have to figure out what to do if a transaction has multiple inputs, and only one of them is a double-spend. Confiscate everything from this tx? Or just the amount from the double-spended input? Maybe something like 5% to the miner who finds it, then 1% to the next 95 blocks (make it less likely for coins to passed back to attacker). What is the reasoning behind this? How would the coins be passed back to the attacker? For a transaction that is already in the block chain when an overdrawing transaction shows up, if it is less than n blocks old reverse the transaction, zero the address, pass back out. Merchants wait n blocks before confirmation. If n was 3 it would force an attacker to have a fork that is at least 3 high before the transactions are made public to have a profitable double spend, and anything less will result in the loss of coins. Sure, exactly my thinking, with setting a block count limit. Except for the "pass back out" thing again, what is that? I'd say confiscate everything, the amount promised is always going to be bigger than what is currently at the address. Now with multiple inputs, where not all of them overdraw, I can't really see where a regular user would be hurt by it so you might as well confiscate them too just to increase the risk of double spending. When an attack is happening the attacker will have control of a lot of mining resources, so if they decide to abandon the attack they can use this mining power to try to reclaim the confiscated bitcoins. So if they have 30% of the network and it all goes to the next block, they have a 30% discount to their double spend penalty. By staggering the payouts it would require sustained mining power over a longer period of time, making receiving their confiscated bitcoins even more expensive. Also when the increased block payments are known in advance, it gives incentive for legitimate miners to come online and help strengthen the network. |
|
|
|
|
A system such that if a miner can include multiple transactions from the same address, with the same previous_output, that would overdraw the address, the entire balance of the address is set to zero and the coins are passed back out. Maybe something like 5% to the miner who finds it, then 1% to the next 95 blocks (make it less likely for coins to passed back to attacker).
For a transaction that is already in the block chain when an overdrawing transaction shows up, if it is less than n blocks old reverse the transaction, zero the address, pass back out. Merchants wait n blocks before confirmation. If n was 3 it would force an attacker to have a fork that is at least 3 high before the transactions are made public to have a profitable double spend, and anything less will result in the loss of coins.
|
|
|
|
If all you're trying to do is have users sign off on which they think is the "most correct" blockchain, I think it'd be easier to just have accounts signing hashes of blocks they think are correct, and distributing those hashes separately, rather than trying to embed them in the blockchain somehow.
I like this idea, would it be possible to distribute these signed hashes through the client protocol, similar to how tx are shared? |
|
|
|
|
