People in the Bitcoin community are sometimes resistant to the idea of using
the word credit as a unit of Bitcoin, because Bitcoin is not a credit-based
system.
However, given that the average person has close to no understanding of what
credit means, and probably no concern for the
What about 0 confirmation inputs?
Mightn't this make tiny spam transactions unsafely inexpensive?
On May 12, 2014, at 20:21, Peter Grigor pe...@grigor.ws wrote:
I propose the transaction fee should be calculated from a percentage of the
input amount divided by the confirmations of the
Unlikely. I doubt any significant portion of miners in china will continue to
mine on a china-specific chain, since it will certainly be outmined by
non-Chinese miners, and will be orphaned eventually.
More likely is that mining interests in china will make special arrangements to
circumvent
On Jun 24, 2014, at 10:32, slush sl...@centrum.cz wrote:
Sounds like marketing bullshit to me. It does not have even statistical
meaning; well, you can save a lot of satoshis, but nobody tell you that the
merchant cut you on BTC/USD exchange rate in tens of %.
People would also abuse
Ok, wanting structured data is a decent argument, but why this random arbitrary
case in particular? There are hundreds of fields like this that people might
want to use.
If we're going to support one random cosmetic field, we might as well support
them all with a generic structured data
On Jun 24, 2014, at 16:12, Gavin Andresen gavinandre...@gmail.com wrote:
It would be silly to add a generic stuff field inside a container format
that ALREADY has all the mechanisms necessary for forwards and backwards
extensibility.
I agree. It would be even sillier to start specifying
On Jun 25, 2014, at 10:15, slush sl...@centrum.cz wrote:
Good standard must be explicit as much as possible. Having million optional
fields with ambiguous meaning is even worse than not having these fields.
+1. BIP70 is important. We want to keep it very simple and generalized, or
there is
7 matches
Mail list logo
