On 4/12/12, Jeff Garzik jgar...@exmulti.com wrote:
1. N = 1 or 2 or whatever the community prefers. Ideally enough time
for a third-tier miner, mining strange TXs, finds a block.
2. H1 = height of block chain, when a TX is received
3. H2 = H1 + (144 * N)
4. If block chain height reaches
On Sat, Apr 14, 2012 at 11:13 AM, Mike Hearn m...@plan99.net wrote:
So, to be specific... a A-B chain of transactions, that collectively
meet the network's fee requirements?
Yes.
ACK on the concept
Ideally the fee, if any, is market based and negotiated. Problem is... like
democracy, no
On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote:
Furthermore, many of these ideas -- like sending TX's directly to the
merchant -- involve far more direct payee-payer communication on the
part of the wallet client than is currently envisioned
Yes, though it's worth
On Sat, Apr 14, 2012 at 5:27 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote:
Some HTTP derivative would probably make life easier for mobile
payments and firewalled scenarios, and for client-merchant
communications, for instance.
On 2012 April 12 Thursday, Jeff Garzik wrote:
One of my From-Day-One complaints about bitcoin is that transactions
behavior could be far more deterministic (predictable), from a user
standpoint. Transactions in the current system can easily remain in
limbo forever.
One big step in making
It sounds OK as long as you exclude nLockTimed transactions.
That said, if you broadcast a transaction that does not meet the fee
rules, you should be able to notice that it wasn't accepted by your
peers immediately. Today it's painful because the protocol isn't very
chatty - in bitcoinj I plan
On Fri, Apr 13, 2012 at 6:04 AM, Mike Hearn m...@plan99.net wrote:
It sounds OK as long as you exclude nLockTimed transactions.
ACK, agreed
That said, if you broadcast a transaction that does not meet the fee
rules, you should be able to notice that it wasn't accepted by your
peers
My one big concern about this that users find a way to exploit this
behavior for themselves. If it's too easy for users to create tx they know
will get stuck and expire, it's no different than letting them cancel their
zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so
I
On Thu, Apr 12, 2012 at 3:19 PM, Alan Reiner etothe...@gmail.com wrote:
My one big concern about this that users find a way to exploit this behavior
for themselves. If it's too easy for users to create tx they know will get
stuck and expire, it's no different than letting them cancel their
9 matches
Mail list logo
