I have an Adobe signing key and I paid for the key, there is no per-document charge for my key.
That's probably because you always sign with the same certificate. The company I work for has to sign in the name of other people actually, so, after authentication, they generate a "minute-certificate", used only to sign the document (it expires quickly). That certificate carries the name of the client. And to generate that certificate, you gotta pay 15 cents of euro IIRC. But even if there was one, there is nothing inherently wrong with that,
As there's nothing inherently wrong with charging a 4% fee for conducting a payment either. Yet, here are we trying to make something better.  |
|
|
|
Intersango has no interest in doing business with people who threaten litigation without a good faith effort to resolve the problem first.
He opened a ticket and immediately threatened us.
That is completely unacceptable behaviour.
So, you're claiming that what's written in OP is not correct? Because according to OP, he said he'd be "seeking legal advice", what's not a threat of litigation. And, also according to OP, that only happened 5 days after the ticket being opened, not "immediately". |
|
|
|
I'm on the "let there be no fixed maximum block size" side of the debate right now.
he, the "lead developer" is on the same side I am, nice.  I think we should let miners decide on the maximum size of blocks that they'll build on.
How difficult would it be to implement it on bitcoind right now, without touching the 1Mb hard limit? I mean the multiple limits and tolerance levels idea. Miners using bitcoind would be able to set in config file a list of value pairs. One value would be a size limit, the other the amount of blocks longer a chain breaking that limit would have to be in order to you to accept building on top of it. Do you see what I'm saying? That could be done right now on bitcoind, with the sole condition that anything above 1Mb will be rejected no matter what. |
|
|
|
Adobe's Acrobat/PDF document signing PKI is an example of one that appears to work and be well-managed.
Well, it works, yes... but it is expensive! I work for a company that among other things has a system that does digital signatures for official documents. They are required to pay 0€15 for each signature they issue, not to mention the enormous costs for being able to issue these signatures in the first place. And that's paying exclusively for Adobe's "recognition". Adobe does't actually do anything, they have absolutely no extra cost when these signatures are issued. But if you want their recognition, open your pockets! I hope that this implementation for bitcoin is done in such a way that more competition in the "authority market" is available, so that prices are not so high. |
|
|
|
Mr H[censored]. has substantially edited the responses from staff. The actual response reads. Your transfer was executed.
You are now banned from Intersango.
This is a notice of no-trespass covering all Intersango LTD properties including but not limited to intersango.com and all it's sub-domains.
Goodbye Mr H[censored].
As this means the transfer was executed on the 30th he will likely not receive the transfer until Monday. So... why did you ban him? Did he try to steal from you or something? Or that's just how you deal with customer's complaints? |
|
|
|
You can't really do this for arbitrary scripts. This works because of the ECDSA multiplication properties that are used in all the other "crypto tricks" throughout Bitcoin. And if you go back to online-signing keys, then I think the whole exercise is negated: the whole point of this is so that the signing keys are not on the same system that is distributing the addresses. Without that property, I'm not sure what we're gaining over SSL.
The security level may be the same of SSL, but there should be a way for a device like Trezor to safely attribute an address to a humanly recognizable name. Otherwise all its security will be gone the day that some hacker manages to code a trojan capable of tricking Trezor and the user's browser at the same time, displaying at both interfaces an address that belongs to the attacker. I'd very much like it to be extensible to arbitrary addresses because I think multisig is quite important. I'm not saying this clever thing with ECDSA multipliers shouldn't be done, on the contrary, it's quite cool actually, but it doesn't cover all possible cases. |
|
|
|
There was some debate in that thread about it... If it's P2SH, you have to distribute the individual keys that make up the P2SH script and let the user create the P2SH script after they verify all the public keys (and we need to adopt a universal convention of ordering public keys lexicographically in P2SH scripts). It kind of defeats the purpose of P2SH, but at least you still get the space-savings of P2SH in the pruned blockchain.
That sounds complicate. The client application would need to know how the script is supposed to be built. And the server won't necessarily own all keys in a multisig... It's not ideal, but it would work as long as all the keys are signed by the the same trusted authority. If you're talking about arbitrary scripts... good luck with that one! I think you should consider making your system capable of signing arbitrary addresses too. Even if for that case it means having an online signing key. I realize that an online signing key can be compromised if the server itself is compromised, but well, it's harder than compromising users' machines and putting the MiM there. We should encourage the use of multisig and eventually other advanced features provided by scripting. |
|
|
|
In my scheme, that was similarly described by thanke, you create a root deterministic wallet, and give out just the public key, but not the chain code. You sign that with an offline signing key (this is the key difference here... with SSL the server must hold the signing key online, in this scheme the signature happens once, offline). Then the server doesn't distribute addresses, it distributes the root public key (with a verifiable signature) and a multiplier. The user's software recognizes the signature and then multiplies the public key by the multiplier and sends money to that address. (the multiplier fits right into BIP 32, Ileft, and doesn't give away the chain code so the address chain is still kept private).
That's quite clever! But how would it work for addresses that represent a script? |
|
|
|
2) The economics of providing for network security when block inclusion is free and inflation has dwindled
For (2), I feel like there's a factor I never see mentioned. In the short run (12+ years), the block rewards are more than enough to incentivize mining, especially as we're moving to a world where the variable cost (electricity) of mining is plummeting. Over that same timeframe, the cost of ASICs should also plummet to the marginal cost of production at the same time Moore's law is increasing their power. Hashing power is going to be cheap. Very cheap. Hashing power being cheap is not relevant to the security of the network since it would be equally cheap to an attacker. It's the total amount of resources employed by honest miners relative to those of an eventual attacker that actually matter. |
|
|
|
If your words are true, this deserves more attention. I'd suggest you trying to get whitelisted and then post in a board more closely watched by mods, like the Scam Accusation one. Something more than your words will be requested as proof though. |
|
|
|
Changing this limit needs to be discussed now, before we start hitting it.
This has been discussed for a while. I used to support the idea of an algorithm to recalculate the limit, as it's done for the difficulty. But currently I just think miners should be able to create their own limits together with multiple "tolerance levels", like "I won't accept chains containing blocks larger than X unless it's already N blocks deeper than mine". Each miner should set their own limits. That would push towards a consensus. Miners with limits too different than the average would end up losing work. The point is that like this the consensus is achieved through "spontaneous order" (decentralized), and not via a top-down decision. That said, I do have the feeling that this change will only be scheduled once we start hitting the limit. |
|
|
|
*bitmarket: complètement gratuit? Je n'ai rien trouvé sur des frais éventuels
Si je me rappelle bien bitmarket.eu fonctionne comme bitcoinary. Il ne garde pas l'argent des clients, tout ce qu'il fait c'est mettre en contact les gens qui veulent échanger. Voilà pourquoi ils peuvent se permettre d'être gratuits. |
|
|
|
How would the future look? 5000 transactions every second at 0.00001 Bitcoin perhaps?
5k tps is quite high. According to this page, Visa itself process 2k tps. Plus, bitcoins can be traded without the blockchain. You may think of the blockchain as a "clearing house". Nobody can predict how much transaction fees will be paying in the future. We can assume it will be lower than CCs. Also whats to stop everyone just paying 0 and thus destroying the entire network?
Miners are free not to include a transaction in the block they mine. The transaction fee is a kind of tip to the miner that includes your transaction. |
|
|
|
Adding a CC surcharge to the 9.5%-10% sales tax in California is sure to cause some noise. Well, maybe not. People are sheep.
It doesn't make sense adding a "surcharge". It makes sense decreasing the prices of items bought with cash. Plus, if merchants are really free to set the discount as much as they want, I'd say that many would also include this sale tax percentage as a discount for cash purchases.  |
|
|
|
Obs: Botei senhas do tipo ''Cavalo69Vaca44Ponei99b1l2k3''
Cada um tem sua maneira de memorizar senhas, mas em geral acho mais fácil memorizar frases do que combinações como essa acima. Na linha do correct horse battery sttaple  Hoje brute-force tá fora de questão.
Calma lá. Força bruta sobre uma chave pública, um endereço bitcoin, ou qualquer coisa com uma alta entropia, de fato é fora de questão, e não é de hoje. Mas senhas não necessariamente têm alta entropia. E se eu tenho em mãos um arquivo criptografado com senha, vou poder fazer um ataque de força bruta na velocidade máxima que minha máquina aguentar. Algo como a senha Tr0ub4dor&3 do exemplo acima não levaria muito tempo pra quebrar, por exemplo. |
|
|
|
MultiBit uses the blockchain, it's just significantly smaller for reasons I can't remember. Anyways, your right, MultiBit should be in the poll.
It's significantly smaller because it only stores the block headers, which are tiny. Currently it downloads the entire blocks (but downloading isn't the hardest part, storing them in an indexed database is). As soon as bloom filters are implemented, bitcoinj will be capable of only downloading the transactions that concerns the client. |
|
|
|
Exactly how does having complete anarchy deal with corruption ?
Err... by making it irrelevant, since corrupts can't control you through force any longer? Or, putting it another way, by internalizing corruption costs. Organizations that allow corruption and those voluntarily related to them will be the ones paying the costs of such corruption. Those unrelated to the such organizations are not touched by it. In a monopoly like we live now, you cannot choose to cut your relations with the monopolist. Btw, I'd argue that corruption is far from being the greatest issue we face. Actually, quite frequently, corruption is what saves people. In many situations, the ruthless application of the law would bring much worse consequences. For example, being able to bribe a corrupt cop in order not to go to jail for a joint is definitely better than actually having the law respected. I wonder how many business would have already been shut down if it weren't for corrupt public servants... Brazil for example would have no brothels if it weren't for corrupt cops! |
|
|
|
I don't think there is a real advantage to using bloom filters over Electrum servers.
If you are a bloom filter client, the bitcoind nodes you are talking to can hide some transactions to you, just like Electrum servers.
p2p bootstrap would be interesting though, to download the headers; that's something we will probably do.
The advantage is the p2p context. You don't depend on a server that could be compromised, it's harder to spy on you etc. |
|
|
|
This is not true.
An Electrum server can indeed forget tell you about money you received, but it cannot tell you that you received money when you actually didn't.
This is because the Electrum client verifies all the transactions reported by the server, using SPV.
Ah ok, I was not aware of that. Thanks for the clarification. So, wait... that means Electrum clients also download the block headers, like BitcoinJ... What's the difference between Electrum and a BitcoinJ (SPV) client configured to connect to a single server? I suppose Electrum tells its server the entire lists of address the client possess, so that the server only transmit relevant transactions together with the relevant chunks of the merkle tree, is that it? Would you consider making it possible for Electrum to behave like an actual SPV client (with p2p bootstrap) once Bloom filters are implemented on bitcoind? Meaning, those who want to keep relying on a single server stay as they are, and those that prefer p2p go SPV... |
|
|
|
I wouldn't go around recommending Mega as a secure storage solution yet because it is so new, and it appears to be an LEX magnet so people are going to try to be snooping on it.. Also it appears to be horrible for backups since they haven't rolled out password recovery yet to my knowledge.
Good points. I've been using Wuala for a while now, it hasn't disappointed me so far. And they accept bitcoins. ;-) |
|
|
|
|
Show Posts
