Dave Scotese [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-03 📝 Original message:It would be a shame to ...

📅 Original date posted:2016-03-03
📝 Original message:It would be a shame to prohibit someone from rewarding whoever mines their
transaction. A good example would be a transaction designed to record some
information which is damning to powerful authorities, sort of like the
service cryptograffiti offers. When we try to protect others by
prohibiting behavior we think is foolish, we may save some fools, but at
the same time, we hurt the best of us.

On Thu, Mar 3, 2016 at 7:36 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> There's an absurd fee (non-consensus) check already. Maybe that check can
> be improved, but probably the wallet layer is more appropriate for this.
> On Mar 3, 2016 16:23, "Henning Kopp via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi,
>> I think there is no need to do a hardfork for this. Rather it should
>> be implemented as a safety-mechanism in the client. Perhaps a warning
>> can pop up, if one of your conditions A) or B) is met.
>>
>> All the best
>> Henning Kopp
>>
>>
>> On Thu, Mar 03, 2016 at 05:02:11AM -0800, Alice Wonder via bitcoin-dev
>> wrote:
>> > I think the next hard fork should require a safety rule for TX fees.
>> >
>> >
>> https://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1eb0a9388ed08
>> >
>> > 15 BTC TX fee for < 7 BTC of outputs.
>> >
>> > Probably either a typo or client bug.
>> >
>> > My guess is the user was using a client that does not adjust TX fee, and
>> > needed to manually set it in order to get the TX in the block sooner,
>> and
>> > meant 15 mBTC or something.
>> >
>> > I suggest that either :
>> >
>> > A) TX fee may not be larger than sum of outputs
>> > B) TX fee per byte may not be larger than 4X largest fee per byte in
>> > previous block
>> >
>> > Either of those would have prevented this TX from going into a block.
>> >
>> > Many people I know are scared of bitcoin, that they will make a TX and
>> make
>> > a mistake they can't undo.
>> >
>> > Adding protections may help give confidence and there is precedence to
>> doing
>> > things to prevent typo blunders - a public address has a four byte
>> checksum
>> > to reduce the odds of a typo.
>> >
>> > This kind of mistake is rare, so a fix could be included in the coming
>> HF
>> > for the possible July 2017 block increase.
>> >
>> > Thank you for your time.
>> >
>> > Alice Wonder
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>> --
>> Henning Kopp
>> Institute of Distributed Systems
>> Ulm University, Germany
>>
>> Office: O27 - 3402
>> Phone: +49 731 50-24138
>> Web: http://www.uni-ulm.de/in/vs/~kopp
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com>; and Meme Racing
<http://www.memeracing.net>; (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>; which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>;.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160303/970dc2e2/attachment.html>;