On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes ho...@hozed.org 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
-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
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 is
On 28 February 2014 14:42, Warren Togami Jr. wtog...@gmail.com 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
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
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
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
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
17 matches
Mail list logo
