An update in forthcoming 0.9 release includes a change to make
OP_RETURN standard, permitted a small amount of metadata to be
attached to a transaction:
https://github.com/bitcoin/bitcoin/pull/2738
There was always going to be some level of controversy attached to
this. However, some issues,
On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik jgar...@bitpay.com wrote:
I do think
regular transactions should have the ability to include some metadata.
and
2) Endorsement of chain data storage.
Nothing could be further from the truth.
These two statements are in direct contradiction with
(fscking 'send' hotkey in GMail)
Not really - a MasterCoin or JPEG image transaction is not a regular
transaction.
On Mon, Feb 24, 2014 at 11:16 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik jgar...@bitpay.com wrote:
I do think
regular
Not really -- a MasterCoin transaction or JPEG
On Mon, Feb 24, 2014 at 11:16 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik jgar...@bitpay.com wrote:
I do think
regular transactions should have the ability to include some metadata.
and
2)
40 bytes is small enough to never require an OP_PUSHDATA1, too, which will
make writing the OP_RETURN-as-standard BIP simpler.
On Mon, Feb 24, 2014 at 11:39 AM, Wladimir laa...@gmail.com wrote:
On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik jgar...@bitpay.com wrote:
A common IRC proposal
On 02/24/2014 05:45 PM, Gavin Andresen wrote:
40 bytes is small enough to never require an OP_PUSHDATA1, too
So are 75 bytes. (I'm not trying to push anything. Just saying ...)
--
Best Regards / S pozdravom,
Pavol Rusnak st...@gk2.sk
This PR reduces the size to 40 bytes:
https://github.com/bitcoin/bitcoin/pull/3737
(Note - this is not intended to close the discussion... please do keep
sending in feedback)
On Mon, Feb 24, 2014 at 11:03 AM, Jeff Garzik jgar...@bitpay.com wrote:
An update in forthcoming 0.9 release includes a
Mike,
Just want to follow up with you and the community in general regarding the
BIP0070 extension for recurring billing. At this point we have a working
prototype that we checked-in in our fork of bitcoinj
(https://github.com/killbill/bitcoinj). We tested it by extending the php
'payment
It costs at least 5430 satoshis to create an output at the moment.
Is the same spam limit applied if the script is OP_RETURN?
If not, I would be concerned od opening a cheap spam.
Tamas Blummer
On Mon, Feb 24, 2014 at 11:39 AM, Wladimir laa...@gmail.com wrote:
And if this is not abused,
Mark Friedenbach wrote:
What follows is a proposed BIP for human-friendly base-32
serialization with error correction encoding.
...
2. Automatic correction of up to 1 transcription error per 31 coded
digits (130 bits of payload data). For a 256-bit hash or secret key,
this enables seamless
On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik jgar...@bitpay.com wrote:
This PR reduces the size to 40 bytes:
https://github.com/bitcoin/bitcoin/pull/3737
Just quickly GLANCED at it, but if I understand correctly how the template
matching code works, that will change max size of the data to
Setting aside all security benefits (which the user can obviously choose to
implement or ignore), a major benefit here is being able to have multiple
wallets use the same blockchain process. I have 3 different bitcoind
processes running on the same server to utilize multiple wallets. Using
them
Sure, no objection to that.
On Mon, Feb 24, 2014 at 5:12 PM, Jeremy Spilman jer...@taplink.co wrote:
On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik jgar...@bitpay.com wrote:
This PR reduces the size to 40 bytes:
https://github.com/bitcoin/bitcoin/pull/3737
Just quickly GLANCED at it, but
Regarding 80 bytes vs smaller: The objectives should be that if you are
determined to put some extra data in the blockchain, OP_RETURN should be
the superior alternative. if a user can include more data with less fees
using a multisig TX, then this will happen.
eventually dust-limit rules will
On Monday, February 24, 2014 11:06:30 PM Andreas Petersson wrote:
Regarding 80 bytes vs smaller: The objectives should be that if you are
determined to put some extra data in the blockchain, OP_RETURN should be
the superior alternative. if a user can include more data with less fees
using a
On Mon, Feb 24, 2014 at 3:06 PM, Andreas Petersson andr...@petersson.at wrote:
Regarding 80 bytes vs smaller: The objectives should be that if you are
determined to put some extra data in the blockchain, OP_RETURN should be
the superior alternative. if a user can include more data with less
So, just to be clear, we're adding, say, a memory limited mempool or
something prior to release so this fee drop doesn't open up an obvious
low-risk DDoS exploit right? As we all know, the network bandwidth
DoS attack mitigation strategy relies on transactions we accept to
mempools getting
I quite agree with Peter, anything that can be exploited will be exploited,
just like malleability was.
On Tue, Feb 25, 2014 at 10:11 AM, Peter Todd p...@petertodd.org wrote:
So, just to be clear, we're adding, say, a memory limited mempool or
something prior to release so this fee drop
18 matches
Mail list logo
