2012/4/15 Jorge Timón :
> On 4/12/12, Jeff Garzik 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
On 4/12/12, Jeff Garzik 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 H2, and TX has
On 04/14/2012 10:20 PM, 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 remembering that t
On Sat, Apr 14, 2012 at 5:27 PM, Pieter Wuille 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.
>
> Have you ever
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 wo
On Sat, Apr 14, 2012 at 11:13 AM, Mike Hearn 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 matter
> So, to be specific... a A->B chain of transactions, that collectively
> meet the network's fee requirements?
Yes.
> Ideally the fee, if any, is market based and negotiated. Problem is... like
> democracy, no matter how ugly it is, people have trouble finding a
> better system :)
I think this i
On Fri, Apr 13, 2012 at 6:04 AM, Mike Hearn 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 immediately. Today it
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 to
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 m
On Thu, Apr 12, 2012 at 3:19 PM, Alan Reiner 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 zero-conf
> transact
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 se
Not sure whether this rises to the level of a BIP or not, as it is
largely an implementation change.
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 r
13 matches
Mail list logo
