In the US (and in many other countries) the word "bank" has specific legal meaning. It would be a good way to attract the wrong kind of attention from regulators. You are prohibited from even incorporating a company with the word "bank" in the name unless you registered bank due to the potential confusion it would lead to.
Also the client is more like a processing node in VISA network than a bank. Personally I would love to see the two aspects completely split; the processing node and the wallet/client. To be a node I don't need a client/wallet and to have a client I don't need a node on the same machine but currently those two independent functions are tightly integrated which is a pain for custom development.
I didn't know about legal issues it might cause. The analogy I had in mind was banks communicating with each other via SWIFT network to achieve settlement of balances each bank and account has. That's exactly what bitcoin nodes do. |
|
|
|
|
This might help alleviate some confusion people are having with blockchain download time.
It's not a small utility program to send and receive bitcoins as many newcomers might think.
It's a full-fledged Bitcoin Bank node with certain requirements for HDD space, processing power and security.
And then if they don't want their own bank they are free to choose lite clients or e-wallets.
What do you think? Having to maintain the blockchain is nothing compared to what's needed to have your own fiat bank, this should buy us some time.
|
|
|
|
What else can our FPGA mining boards be used for?
Mining Litecoins?  * interlagos puts on anti-flame helmet and runs away * |
|
|
|
... I will be adding a "MAX" button that will fill in the maximum remaining amount (total balance minus values you've already plugged in for other recipients and fee) ...
Great idea! This will simplify management of imported brain addresses one step further. |
|
|
|
Just use send-multi to spend the whole balance of that imported address. One output will be your desired destination address, another output will be your desired change address.
If you can forget to use send-multi from your brain wallet address, then you can equally forget to mark checkbox somewhere to use imported addresses only.
send-multi...? will this work? How to select the source address? forget checkbox: the "use imported addresses only" checkbox I have to set exactly once when I construct the wallet. It works! Create new armory wallet with just one imported address from your brain. That will be your source address as there aren't any others. When sending coins, add desired destination address first, then "add another recipient" and choose your second brain address as a change. EDIT: by the way, according to devs, you can even use your original source address as your change address that way, but I haven't tried it. EDIT2: the only drawback of send-multi is that you have to manually calculate the change balance so that the whole source is spent, but that's hardly an obstacle. EDIT3: from network perspective a regular transaction with change is a send-multi with two outputs, the only difference is that client forms it implicitly, but you can always make it explicit. Also if you need to send more coins than one particular address has, then import several addresses with enough balance and use the same send-multi to spend the whole balance of that wallet. |
|
|
|
So I just destroyed 10 BTC (by my own stupidity). This is what I did:
on a offline machine, I generated 10 private keys using a brainwallet scheme, importet them into a fresh armory wallet and put the addresses and a watch-only version of the wallet onto a usb stick.
I then sent 20 BTC to one of the addresses using an online machine.
Then I constructed a transaction using the watch-only wallet that would send 10 BTC to an external address, signed it using the offline machine and deleted the wallet on the offline machine (I wanted to test losing the machine)! I wrongly figured I'd be safe, because I could always regenerate the private keys using my brainwallet scheme. Stupid, stupid, stupid.
I totally didn't think of the fact that armory would send the 10 BTC change to a newly generated address. In fact, I didn't think of the 10 BTC change at all at that point... so I fucked up and the 10 is gone. Well, lesson learned.
I'd really like to use a brainwallet scheme that doesn't require me to safekeep anything physical (assuming I'm magically transported to some other location, totally naked, and I want my coins)
Is it possible to have armory send the change to one of the existing imported addresses instead of to a newly generated one? Maybe a special wallet type could be made up (imported addresses only)?
Just use send-multi to spend the whole balance of that imported address. One output will be your desired destination address, another output will be your desired change address. If you can forget to use send-multi from your brain wallet address, then you can equally forget to mark checkbox somewhere to use imported addresses only. EDIT: in UI send-multi is probably called something like "Add another recipient" |
|
|
|
My best guess is that trade in policy will only be unit for unit within a product category. Meaning you can only trade in 1 "old" single for 1 "new" single, 1 "old" minirig for 1 "new" minirig. And jalapenos will be sold without any trade ins. This way they will still be getting $$$ flow with every sale or trade in. Mark my words |
|
|
|
Oh, so you think that is the reason? I guess it's possible.
All it takes is one rich person investing a part of his wealth into Bitcoin.
That has apparently just happened at least to some extent if you look at what has been going on in Austria. What is going on in austria? This? https://bitcointalk.org/index.php?topic=85832.0 |
|
|
|
As Vladimir predicted, we now a have a small cup with handle at 6.5 and 25kBTC bid wall holding it, let's see how long we'll stay at this level. |
|
|
|
Problem solved...  What was it? We are curious! |
|
|
|
Bitcoin needs *more* transactions, not less.
Yep, the people complaining that their chain sync is taking too long are all wrong, they should be happy its slow. Don't get me wrong, I like natural growth, and I think it would be great if bitcoin's huge recent increase in chain size was all because we were getting new users or having increased liquidity in the market. But, sadly, thats not true. Even if we prevent the blockchain from growing completely right now, it won't make the experience of those users any better, they would still need to download 180000+ blocks. Any attempts to "improve" things a little bit in the current design would probably be a waste of time.EDIT: If there are more efficient ways to download and parse the existing blockchain I'm all for that! |
|
|
|
|
I think the only reasonable way to encourage sendmulti is to make it cost less in terms of fees compared to doing it separately, which as I understand how it works already, no?
|
|
|
|
It seems that the thing we're trying to discourage is automated transfers, and that would do that.
Not at all. Im trying to discourage high transaction load generated by sites with low userbase compared to that load. The userbase for SD seems to be proportional to the load they generate. Also will it affect MtGox if many users happen to withdraw from a single address in MtGox wallet? |
|
|
|
However for the end user it might create certain complications under specific circumstances. Imagine Alice accumulated some amount of coins from her signature address on this forum. She then decided to make a few payments and go to the party, so she sent a few transactions all from the same address in a short amount of time: one to bitmit, one to her friend and one to her mother she promised long time ago, then she shut down her computer and went partying. Now with these rules in place (considering 1 tx from 1 address per block) her last two transactions were lost and she wouldn't figure this out until after she starts her computer again to re-broadcast them, which might take a few days or until her mother calls and asks where is the money Yep. But thats why the actual tx/mempool is variable. I think 1 is probably too low for the reason you point out here. But I dont see many people needing more than 2-3 at maximum for any given use-case. A sane default, IMHO, would probably be around 3. I'm still concerned this will have more impact on legitimate users or small businesses who process their transactions manually than on high volume makers. New rules do not discourage the volume itself but using the same address in that volume. So the change seems to be targeted to the current implementation of SatoshiDice rather than being a more generic solution. Under new rules SatoshiDice will have to change that's for sure and there are two ways: 1) use sendmulti which is benevolent 2) use new addresses for each bet which is basically bypassing the new rule. They have already admitted that they want to be a good citizens and they will put efforts to implement sendmulti, so introducing new rules just for them (or rather against them) doesn't make much sense. On the other hand players which choose to be malevolent will simply bypass the new rule by using new addresses if they wish to. So is it really worth the time and effort, which otherwise could be spent on thinking about proper pruning solutions? |
|
|
|
You mentioned that the idea is to prevent these transactions to get to the miners in the first place. So I'm afraid that more transactions will get lost/stuck.
Also discouraging certain behavior by making certain transaction to get stuck/lost doesn't seem right. We already have complaints from users who have their transactions lost due to incorrect fees, this will only add to the problem.
You dont prevent it, you slow it. If you (as all existing nodes I know of do) reannounce your transactions, they will eventually get there. Ok that's the crucial part that I misunderstood. So indeed this will only slow but not prevent the transactions from propagating. However for the end user it might create certain complications under specific circumstances. Imagine Alice accumulated some amount of coins from her signature address on this forum. She then decided to make a few payments and go to the party, so she sent a few transactions all from the same address in a short amount of time: one to bitmit, one to her friend and one to her mother she promised long time ago, then she shut down her computer and went partying. Now with these rules in place (considering 1 tx from 1 address per block) her last two transactions were lost and she wouldn't figure this out until after she starts her computer again to re-broadcast them, which might take a few days or until her mother calls and asks where is the money |
|
|
|
Wouldn't this create more trouble for users/services who are unaware of this change?
They will have one more head ache to figure out why on Earth their transactions are not being propagated.
Because the rule requires people to upgrade their nodes, it would take a significant amount of time to begin effecting transactions. Thus there will be plenty of time for people to change off of their previous payment designs. Obviously such a change would be heavily announced. That's probably a bigger issue than the one we are trying to solve. Relying on the fact that people out there are always ready for any changes and announcements is a mistake. Would it be easy to follow these rules in a reliable way?
Say if I'm trying to play by the rules and the timing is a bit off my transaction will get stuck somewhere and I will have to use wallet tools to remove it.
The proposed rules do not block any transactions, they only effect the time it takes for transactions using the same address repeatedly to confirm. You mentioned that the idea is to prevent these transactions to get to the miners in the first place. So I'm afraid that more transactions will get lost/stuck. Also discouraging certain behavior by making certain transaction to get stuck/lost doesn't seem right. We already have complaints from users who have their transactions lost due to incorrect fees, this will only add to the problem. |
|
|
|
After thinking about this for a while I actually now believe it might be a good idea even long term. Since there is only as many transactions than can be put in the block, the rules might need to be in place for which transaction to include.
The question is do you Matt have a good understanding how to implement this prioritization and how to enforce these rules. I get the impression that miners are the ones deciding what transactions to mine. Can the rules be enforced in the protocol?
The idea suggested is this: Each user of bitcoin has the option to limit transactions involving a particular address to n/memory pool. ie I may say "I only want to ever have 1 transaction with any given address in my memory pool at any time." Thus, I would be rate-limiting each individual address to n per block, assuming they propagate through the network instantly faster than it takes to create a new block. The idea here is to keep high-volume address transactions from reaching miners in the first place, making them impossible to mine. Obviously people who wish to continue to use such volume addresses could peer directly with miners who accept such things but, again, that would require a level of effort much higher than simply using something like multisend. Wouldn't this create more trouble for users/services who are unaware of this change? They will have one more head ache to figure out why on Earth their transactions are not being propagated. Would it be easy to follow these rules in a reliable way? Say if I'm trying to play by the rules and the timing is a bit off my transaction will get stuck somewhere and I will have to use wallet tools to remove it. |
|
|
|
b) First, by definition short term solution is bad because the work to implement it would have to be thrown out the window soon enough.
The proposal isnt really that much of a short-term solution. It is designed to encourage users to not use more transactions than they need to. Though this is short-term for capping the chain, it should continue to drastically decrease overall chain volume even as that volume increases greatly. After thinking about this for a while I actually now believe it might be a good idea even long term. Since there is only as many transactions than can be put in the block, the rules might need to be in place for which transaction to include. The question is do you Matt have a good understanding how to implement this prioritization and how to enforce these rules. I get the impression that miners are the ones deciding what transactions to mine. Can the rules be enforced in the protocol? |
|
|
|
SatoshiDice seems to be a great way for core devs to get a taste of what it's like to handle a volume like this when bitcoin network starts to scale up and think of the solutions in advance.
And what is the solution they came up with? Kill the volume maker!
Doesn't sound good to me...
Stop. Thats not what I am suggesting, nor is this something that is being extensively discussed, I started this thread to see what the community would say in response. The goal is not to kill anyone or prevent them from using bitcoin for their use-case. Read the thread please. Sorry, but that's the impression I got because you also called them stupid and braindead. From the quote below it's seems they are also suffering from the same issue you mentioned, if "use transactions in a more conservative way" means avoiding multisend. They are a young service and hopefully they will work this out. I realize satoshidice is sometimes slow... but for the past few days I always had to wait at least five minutes before I even know if I won or not. Often times it's even longer.
Is this just me? Or that happens to others too?
Sorry, that was a database change I made. I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets. It should be much better now. I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us. |
|
|
|
|
SatoshiDice seems to be a great way for core devs to get a taste of what it's like to handle a volume like this when bitcoin network starts to scale up and think of the solutions in advance.
And what is the solution they came up with? Kill the volume maker!
Doesn't sound good to me...
|
|
|
|
|
Show Posts
