I understand, I just think that's not such a serious issue to motivate a change in the 10 min interval too. Instead, if relaying orphans becomes a normal practice, nodes would be able to see whether there's another branch in which their transactions don't exist. If your transaction is currently in all branches being mined, you're certain that you got your confirmation.
So, to counter the problem you raise, I think that relaying orphans is good enough. Why wouldn't it be?


There would be some variety, surely. In the blocks they produce themselves, miners will search to optimize the ratio (time to propagate / revenue in fees), while in blocks they receive from other miners, they would rather it be the smaller possible. These parameters are not the same for different miners, particularly the "time to propagate" one, as it strongly depends on how many connections you can keep established and on your bandwidth/network lag.

Plus, if there is an "global optimal max size", it's quite pretentious to claim you can come up with the "optimal formula" to calculate it. Even if you could, individual peers would never have all necessary data to feed to this formula, as it would have to take into consideration the hardware resources of all miners and the network as a whole. That's impracticable. Such maximum size must be established via a decentralized/spontaneous order. It's pretty much like economical central planning versus free markets actually.

Would it really? I've never seen any actual analysis, but I'd say that honest splits would mostly carry the same transactions, with the obvious exception of coinbase and "a few others". Has anyone ever done an analysis of how many transactions (in relative terms) are actually lost in a reorg and need to get reconfirmed?

Btw, interested nodes could attempt to download, and perhaps even relay, all sides of a split. If you see that your transaction is in all of them, you know it actually had its first confirmation for good. Relaying orphans sounds a less radical change than changing the 10m delay...

That's nice. Just don't forget to include total download time in the "time to verify", as well as any other I/O time. Bandwidth will be a significant bottleneck once blocks start getting larger.

EDIT: Oh, and of course, there must be tolerance levels too (if I'm X blocks behind the chain I once rejected, I'll give up and start building on top of it). You don't want to create that many chain forks!

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.


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.

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".

he, the "lead developer" is on the same side I am, nice.


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.

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.

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?

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.

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...


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.

That's quite clever!

But how would it work for addresses that represent a script?

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.

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.

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.

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.


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.

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. 

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




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.

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.

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!