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 wrote:
> 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 obv
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 mine
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 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 multis
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 not
Sure, no objection to that.
On Mon, Feb 24, 2014 at 5:12 PM, Jeremy Spilman wrote:
> On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OP_RETURN outputs are provably unspendable *and* not included in the
UTXO set, so they're not dust (the client makes this check and handles
TX_NULL_DATA outputs separately).
On 02/24/2014 10:13 AM, Tamas Blummer wrote:
> It costs at least 5430 satoshi
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 ser
On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik 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 to 40 bytes
but does
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 seamles
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 wrote:
>
> And if this is not abused, these kind of tran
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 ser
Given our standardization on 128-bit security / 256-bit primitives, I
can't think of any crypto related data payload which requires more than
40 bytes. Even DER encoded compressed public keys will fit in there. A
signature won't fit, but why would you need one in there?
There's no need to design f
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 wrote:
> An update in forthcoming 0.9 release includes a change to make
> O
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
--
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 wrote:
>
> On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik wrote:
>
>> A common IRC proposal seems to lean towards reducing tha
On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik wrote:
> A common IRC proposal seems to lean towards reducing that from 80.
> I'll leave it to the crowd to argue about size from there. I do think
> regular transactions should have the ability to include some metadata.
>
I'd be in favor of bringing
Not really -- a MasterCoin transaction or JPEG
On Mon, Feb 24, 2014 at 11:16 AM, Pieter Wuille wrote:
> On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik wrote:
>
>> I do think
>> regular transactions should have the ability to include some metadata.
>
> and
>
>> 2) Endorsement of chain data storage.
(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 wrote:
> On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik wrote:
>
>> I do think
>> regular transactions should have the ability to in
On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik 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 each other.
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, perc
21 matches
Mail list logo
