On 28 February 2014 14:42, Warren Togami Jr. wrote:
>
> https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d
>
> In one way in particular, the transaction fees per kilobyte completely
> failed to account for the actual cost to the network. If Bitcoin had
>
On 02/28/2014 07:25 PM, Mark Friedenbach wrote:
> Transaction fees are a DoS mitigating cost to the person making the
> transaction, but they are generally not paid to the people who
> actually incur costs in validating the blockchain. Actual transaction
> processing costs are an externality that i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Transaction fees are a DoS mitigating cost to the person making the
transaction, but they are generally not paid to the people who
actually incur costs in validating the blockchain. Actual transaction
processing costs are an externality that is complet
On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes wrote:
>
> Either the transaction fees are sufficient to pay the cost for whatever
> random junk anyone wants to put there, or they are not, and if they are
> not, then I suggest you re-think the fee structure rather than trying
> to pre-regulate
To each his own, but if I say "Please don't charge me for YOUR privacy
by putting junk like stealth addresses in the blockchain", I think I'd
get laughed out of most rooms.
Either the transaction fees are sufficient to pay the cost for whatever
random junk anyone wants to put there, or they are no
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
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
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.
18 matches
Mail list logo
