Great posts from Mike and Gavin in this thread. There's indeed no reason to panic over "too much centralization". Actually, setting an arbitrary limit (or an arbitrary formula to set the limit) is the very definition of "central planning", while letting it get spontaneously set is the very definition of "decentralized order".

Also, having fewer participants in a market because these participants are good enough to keep aspiring competitors at bay is not a bad thing. The problem arises when barriers of entry are artificial (legal, bureaucratic etc), not when they're part of the business itself. Barriers of entry as part of the business means that the current market's participants are so advanced that everybody else wanting to enter will have to get at least as good as the current participants for a start.


That's cool. Please core devs, consider studying what other hard fork changes would be interesting to put in, because we risk hitting the 1Mb limit quite soon.

Come on, don't be ridiculous. I've drunk raw milk all my childhood and I never had "food poisoning". You just boil it before drinking and you're good to go. You should also consider that it spoils much faster, like bread (when I was a child, we used to buy bread and milk at the same time at the bakery, for the day).
I've actually drunk milk that had just left the cow directly to my glass a couple times and didn't have any issues either.


Impressive.
You know what I just found out? If you buy 10 lottery tickets, you're 10x more likely to win the prize!! 


 

I have this feeling too. But then again, there's no such a thing as a free lunch, so how are these 50GB going to be payed for? I suppose that, as for everything else "for free" on the web, it's going to be payed via advertising. But then again, if his advertisers use traditional payment vehicles, what's to stop the financial blockade?

If only Mega was large enough to convince some major web advertisers to start dealing in Bitcoin....  


I believe these companies should start looking into what it takes to handle their clients pay rolls (is that the English term for the process of paying your employees?).
Like, allowing employees to choose to receive, say, 10% of their salaries in Bitcoin. Then automatically tunneling part of the Bitcoin revenue the company has into Bitcoin salaries for their employees, making less exchanges against fiat and thus saving on fees for its client.
Also, these Bitcoin-specialized companies could handle the legal challenges, if any, that paying salaries in Bitcoin would represent.

I think that would speed up Bitcoin usage quite a bit.

I agree, but I also agree with hazek in the sense that it's not cool to turn off new comers. So, maybe we should not direct them immediately to bitcoin-qt on bitcoin.org... maybe we should make sure they see a list of available clients before downloading any?

I don't know Erik personally, but from his posts/writings, I don't believe he'd ever use the state to enforce a monopoly to his benefit.

Don't the receivers of an unconfirmed transaction also try to keep it alive by rebroadcasting?

Considering these transactions have ~600 outputs, it's likely that some of its receivers did get it.

I thought this behavior had already been implemented in bitcoind. I might be wrong though, can't find it on github.

Well, AFAIK it has two buttons, a low-resolution monochromatic screen, and probably a processor weaker than that of any smartphone. Smartphones have wifi, 3G support, GPS, colored touchscreen with higher resolution, powerful battery etc. There's also the Raspberry Pi: a much more powerful hardware for one quarter of that amount. (OK, I do realize the Raspberry Pi is exceptional in terms of cost/benefits, so this comparison might not be the fairest)

I also understand this won't be produced industrially in China, so we can expect a higher price. But 100€ just seem too much, that's all.

Apparently it did.

As I said to OP, you may attempt to send the "locked money" to yourself, and pay a large transaction fee in the process. Theoretically the whole unconfirmed chain should be analyzed together by miners. (the fee would be used to pay for all of them).
I suppose something like 0,1 BTC as fee is already quite large.

But if you're not in a hurry, just wait.

Ouch, that seems a little expensive. I mean, can't you buy old smartphones with that amount? Or perhaps second-hand netbooks that you could format and turn into an offline wallet.

Do you control any of the outputs?

I think that if you initiate a transaction from any of the outputs, and put a juicy fee on it, miners will combine the two when analyzing its fee/priority ratio. That might speed things up.

These are two unrelated things. Bloom filter is pretty much what you describe: a protocol for full nodes to serve lightweight nodes only the transactions that concern them, plus some false positives for privacy reasons.

The index pruning changed the main transaction index in bitcoind, now it only stores unspent transactions, what makes it much smaller, and thus synchronizing with the network now requires much less I/O. Keep in mind this is just the index, the full blockchain content is still stored.

They only have 1 input though. I thought many inputs was the biggest problem in what concerns verification time.
Actually, if this transaction was paying 0,011 in fees, wouldn't it be better to include it instead of 22 tx of 1kb paying 0,0005 each, in what concerns propagation time? Since the latter would have at least 22 different inputs to be validated.
EDIT: Dumb me, outputs have to be inserted in the transaction index, and that's likely to take more time than validating inputs. Ignore what I said above.

But... doesn't that mean that people were treating a time-locked transaction as normal unconfirmed transaction? They should not be treated as the same thing, that's the actual problem.

That was not exactly my question (I meant time-locked tx after their time locking expires) but never mind, I got an answer in the other thread. Thanks,

What does "disabled" means?
Does it means that bitcoind gives you no way to deal with nLockTime, but if some miner accepts, relays and mines them, his blocks will be accepted?

That's what I feared. You're seriously killing nLockTime for good?

Such feature can be really useful. Think inheritance for instance. How would you implement inheritance in a "bank" which uses multi-signature? You die, all your money dies with you?
Even for password regeneration... suppose you run a multisig bank in BTC, and you don't really trust all your clients to never forget their passwords (people do often forget/lose their passwords, and I bet that in some jurisdictions you would be forced to give your client a way to retrieve their money even if he forgot his password). Using nLockTime would be just great for this. You periodically transfer the money to a cold storage address the bank fully controls. While the client is logging in, you periodically reverse that transaction and generates a new one. If your client ever forgets his password for good, you'd just need to positively identify him (docs etc) and ask him to wait like 3 months or something to have his coins back.

Anyways. This is a powerful feature. The fact that's not yet exploited doesn't mean otherwise: multisig itself is not really exploited so far, and I don't think you'd say that feature is "not important enough".

Thank you all for this development. This version is a major one for scalability, with bloom filters and the pruned index.


Could somebody point me to some clarification on what exactly does this means?
Because, AFAIK, time locked transactions should be reversible, up until the block they are supposed to be included. That's the whole point of time locking, isn't it?

Actually, if the money supply is constant, the average salary would decrease only if the workforce increases. Giving the world's demographic trend, it wouldn't be impossible for the opposite to start happening in many places a few decades from now.