ABISprotocol hat: on
regarding:
stuff not getting into blockchain in a day's time,
microdonations not facilitated as much as they could be,
that would be:
very bad
much news
such fail
Seriously, that would not be so good.
Hope I made you laugh a bit
vendor hat: on BitPay sure would like
clarification, I am not a doge dev. It was intended just as a joke, to
make you laugh.
regarding pull requests improving these issues I am under the impression
that the developers will take care of what needs to be taken care of in
that regard. Am presently in collaboration on a bitcoin project
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We rebroadcast incoming transactions without fees at several nodes,
including bc.info, to keep them in mempools.
On 01/17/2014 10:04 PM, Mark Friedenbach wrote:
CPFP is *extremely* important. People have lost money because this
feature is missing.
On 01/18/2014 03:05 AM, Wladimir wrote:
On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla
ABISprotocol hat: on
regarding:
stuff not getting into blockchain in a day's time,
microdonations not facilitated as much as they could be,
Please point to your pull requests
On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote:
On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman jer...@taplink.co wrote:
Choosing how many bits to put in the prefix may be difficult, particularly
if transaction load changes dramatically over time. 0 or 1 bits may be
just
Like any other mechanism that puts extra data in the blockchain, the
sender pays the fees.
This mechanism is to improve privacy for static addresses (donation
links on websites and so on). I personally don't think it will be used
nearly as much as BIP0032 or the payment protocol (both of which
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner etothe...@gmail.com wrote:
Isn't there a much faster asymmetric scheme that we can use? I've heard
people talk about ed25519, though I'm not sure it can be used for encryption.
Doing ECDH with our curve is within a factor of ~2 of the fastest
On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman jer...@taplink.co wrote:
In the case where payment is being sent only to Q1, and Q2 is for discovery
only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20
byte vs 32 bytes in the OP_RETURN, and of course faster
There's a reason why luke-jr's pull request for CPfP remains open.
There is general agreement that it appears to be useful. CPfP works
to close the mismatch between how bitcoin transaction fees are
attached by the sender, versus modern economic situations where the
receiver is willing to pay a
9 matches
Mail list logo
