Re: [Bitcoin-development] Fee drop

[naman naman]

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 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 mined, and the clearance rate of the new low-fee
> transactions is going to be pretty small; we've already had problems in
> the past with mempool growth in periods of high demand. Equally it
> should be obvious to people how you can create large groups of low-fee
> transactions, and then cheaply double-spend them with higher fee
> transactions to suck up network bandwidth - just like I raised for the
> equally foolish double-spend propagation pull-req.
>
> Of course, there's also the problem that we're basically lying to people
> about whether or not Bitcoin is a good medium for microtransactions.
> It's not. Saying otherwise by releasing software that has known and
> obvious DoS attack vulnerabilities that didn't exist in the previous
> version is irresponsible on multiple levels.
>
> --
> 'peter'[:-1]@petertodd.org
> b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2
>
>
> --
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Fee drop

[Peter Todd]

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 mined, and the clearance rate of the new low-fee
transactions is going to be pretty small; we've already had problems in
the past with mempool growth in periods of high demand. Equally it
should be obvious to people how you can create large groups of low-fee
transactions, and then cheaply double-spend them with higher fee
transactions to suck up network bandwidth - just like I raised for the
equally foolish double-spend propagation pull-req.

Of course, there's also the problem that we're basically lying to people
about whether or not Bitcoin is a good medium for microtransactions.
It's not. Saying otherwise by releasing software that has known and
obvious DoS attack vulnerabilities that didn't exist in the previous
version is irresponsible on multiple levels.

-- 
'peter'[:-1]@petertodd.org
b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2


signature.asc
Description: Digital signature
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Luke-Jr]

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 multisig TX, then this will happen.
> 
> eventually dust-limit rules will not be the deciding factor here, since
> i suspect block propagation times will have a stronger effect on
> effective fees. therefore a slightly larger payload than the biggest
> multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes.
> (this is my understanding of how large a 3-of-3 multisig tx can be, plus
> 1.5 bits encoded in the "n" parameter)

Perhaps I ought to redo my data carrier configuration option as a max size?

Luke

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Gregory Maxwell]

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 multisig TX, then this will happen.
>
> eventually dust-limit rules will not be the deciding factor here, since
> i suspect block propagation times will have a stronger effect on
> effective fees. therefore a slightly larger payload than the biggest
> multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes.
> (this is my understanding of how large a 3-of-3 multisig tx can be, plus
> 1.5 bits encoded in the "n" parameter)

At least there is no ambiguity that such usage is abusive. Adoption of
the practices matters too. Right now I've seen a lot of people
promoting data storage as a virtuous use, and gearing up to directly
store data when a commitment would work.

If it turns out that encouraging people to use hashes is a lost cause
it can always be further relaxed in the future, going the other way is
much harder.

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Andreas Petersson]

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 be the deciding factor here, since
i suspect block propagation times will have a stronger effect on
effective fees. therefore a slightly larger payload than the biggest
multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes.
(this is my understanding of how large a 3-of-3 multisig tx can be, plus
1.5 bits encoded in the "n" parameter)

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Jeff Garzik]

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 how the template
> matching code works, that will change max size of the  to 40 bytes but
> does not do anything to enforce most-efficient encoding.
>
>   else if (opcode2 == OP_SMALLDATA)
>   {
>   // small pushdata, <= MAX_OP_RETURN_RELAY bytes
>   if (vch1.size() > MAX_OP_RETURN_RELAY)
>  break;
>   }
>
> This code was a bit hard for me to parse since it's not actually requiring
> any data, just disallowing more than a certain number of bytes of data. So a
> bare OP_RETURN would be allowed as well, for whatever good that will do.
>
> If you want to strictly require no PUSHDATA, perhaps you could do:
>
>   else if (opcode2 == OP_SMALLDATA)
>   {
>   // small pushdata, <= MAX_OP_RETURN_RELAY bytes
>   if (opcode1 >= OP_PUSHDATA1 || vch1.size() > MAX_OP_RETURN_RELAY)
>  break;
>   }
>
> Thanks,
> Jeremy
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9

[Mark Friedenbach]

-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 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTC8lNAAoJEAdzVfsmodw4vpAP/1/wJFRq9x3rhETtUlS/3+F3
UrgBhfNDP7rq1P9wqZm20cssF0VcG+SVG94m/kH/H8cfJsjGB3/NW2IGxf9J6wOT
vWiGqz4b7lkh5nywBe0TK0smkqMFtyNAESX1WdJpdNLAd5OK/wj2X7Dl3/r7K9tk
SN1Oi4nlQD+GkbQBNeqf659BKlFAIYONl9SrPXvrEoSuTm0CjFLsST3Go3El0tyx
rLrApXCAR+iGs9bZONdkC3rRWGGa3V8HLNeCyBaLA7dsipnk2kMsjbrLB9NZU54L
Dz07e1oelFJErsbYKD+AQy3KiZ4+7dZRoi9FtPqlXtCGAObW0fi5Rm2HDzCG+iMU
f+6xgCCyyP++fET/EnJj1Jxjrn6suoAl2hjZLpaGgJ67lsxq5rqmXetID5X+cGRU
HX6Ar5+LIjRixfoCF3dJoZT0Ko1S0b58oRzyapwbB+2Fi0/G7ujEwErWE33ARXad
vTYznlAXG5YzIrjAJUF3PG3MlbaX4TWywJxRCMRcTQC7Ak+dP2cdOBuzvLdAsYXG
xcmqfl3ETH5xLxLWYnzNplTkt9ENs8UHrG0StWOyCg4+MG8yC/jPFp6qzRlAaZEv
vFsIPGD+jzftrqBQ1GgjbG8bofUYCMnYRKQtQ377GNw8s8wVASb8CxyI8yhXKpdv
zdCwIlvHM0A8CofmDDot
=6Jux
-END PGP SIGNATURE-

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Bitcoin Core trial balloon: splitting blockchain engine and wallet

[James Hartig]

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 serially isn't an option in my case. Also, peers can run the cheaper
process instead of having the wallet functionality which isn't even used.

On the security front, this doesn't seem to be any less secure and it gives
the user the flexibility to make it as secure as they feel comfortable. If
they want to run them both as the same user with no SELinux or file
protections (this isn't stopping or encouraging that) they're already doing
that now with bitcoind, albeit with possibly a larger attack surface.

Thanks,
--
James Hartig
Software Engineer @ Grooveshark.com
http://twitter.com/jameshartig





On Sat, Feb 22, 2014 at 1:53 AM, Wladimir  wrote:

>
> On Sat, Feb 22, 2014 at 2:09 AM, Dustin D. Trammell <
> dtramm...@dustintrammell.com> wrote:
>
>> On Fri, 2014-02-21 at 07:43 +0100, Wladimir wrote:
>> > The most straightforward way would be to run the blockchain daemon as
>> > a system service (with its own uid/gid and set of Apparmor/SELinux
>> > restrictions) and the wallet daemon as the user.
>>
>> This assumes you as a user have the rights to do so.  This would be
>> preferred, but in some cases may not be possible.  Perhaps it should be
>> optional?
>>
>
> No! I'm proposing that we force everyone to do it. Using all means
> necessary. There should be regular audits that everyone is running the
> software exactly in my configuration, and if not, a special task force will
> take care that spankings are carried out on the spot.
>
> Repeated offenders will lose their BitLicense.
> 
>
> Please stop kicking this dead horse. It was just a random idea. Maybe a
> way how Linux distributions could structure it, but it may or may not apply
> in your case. And that's fine, this is free software development, you can
> do whatever you want!
>
> Let's try to bring this discussion back to its original intention: for
> anyone that wants to concretely help this along, please help reviewing and
> testing the pull requests that jgarzik mentions.
>
> Wladimir
> BTW: All of those patches are helpful for monolithic-bitcoind as well as
> they (lay the groundwork for) speeding up block synchronization.
>
>
>
> --
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Jeremy Spilman]

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 not do anything to enforce most-efficient encoding.

   else if (opcode2 == OP_SMALLDATA)
   {
   // small pushdata, <= MAX_OP_RETURN_RELAY bytes
   if (vch1.size() > MAX_OP_RETURN_RELAY)
  break;
   }

This code was a bit hard for me to parse since it's not actually requiring  
any data, just disallowing more than a certain number of bytes of data. So  
a bare OP_RETURN would be allowed as well, for whatever good that will do.

If you want to strictly require no PUSHDATA, perhaps you could do:

   else if (opcode2 == OP_SMALLDATA)
   {
   // small pushdata, <= MAX_OP_RETURN_RELAY bytes
   if (opcode1 >= OP_PUSHDATA1 || vch1.size() > MAX_OP_RETURN_RELAY)
  break;
   }

Thanks,
Jeremy


--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Base-32 error correction coding

[Jim Paris]

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 recovery from up to two transcription errors so
> long as they occur in separate halves of the coded representation.

Can we do better than correcting single transcription errors?  I'd
imagine that transposition of two adjacent characters, or insertion or
deletion of a single character, would be very common.  At the very
least, a transposition could be corrected by interleaving the two
"halves of the coded representation", e.g.:

   ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB

insead of
   
   AAABBB

Jim

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9

[Tamas Blummer]

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 transactions become popular, and
> more space is really needed, the limit can always be increased in a future
> version.
> 
> Wladimir
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

[Stephane Brossier]

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 server' from Gavin which we also check-in in a fork 
(https://github.com/killbill/paymentrequest). I think it does not make much 
sense from our side to invest more efforts until we hear some feedbacks.

Once we agree/integrate any feedbacks you guys may have-- a proposal for next 
steps would be:
* Turn that into a actual BIP so as to detail how that works, 
* Write some more serious unit tests
* Merge back code into bitconj trunk

Down the line write the C++ code, but of course that would assume BIP0070 is 
also implemented in C++ as we rely on it.

I understand you guys may have more important matters to solve these days with 
the recent malleability issue, but i want to make it clear that we are waiting 
for feedbacks to make additional progress.

Thanks!

S.




On Feb 14, 2014, at 12:28 PM, Stephane Brossier  wrote:

> Kevin,
> 
> We did a second iteration on the prototype to implement subscription 
> cancellation and upgrade/downgrade. We checked in both the bitcoinj and php 
> server to be able to test it.
> We also worked on our side of the merchant implementation (Kill Bill) to feel 
> confident that the protocol will support advanced business cases. At this 
> point it is looking promising, but more work is needed to conclude.
> 
> We wanted to follow up on a few pervious points you raised:
> 
> > However, continuing to think about this even more, maybe the simple memo 
> > field along with an empty set of outputs is enough already.
> 
> From our merchant side (Kill Bill), we do indeed use this field to report 
> successes or errors. Maybe it would be useful to extend PaymentACK with a 
> boolean success field (so the wallet doesn't commit the transaction in case 
> of failures)?
> 
> > One high-level comment -- the wallet in this design doesn't have any way of 
> > knowing when the payments are supposed to end. I feel this is important to 
> > show to the user before they start their wallet polling infinitely.
> 
> We extended our RecurringPaymentDetails message to support this use case, as 
> it solves the problem of subscription changes and cancellations for free.
> 
> We introduced the concept of a subscription, referred to by a unique id (the 
> tuple merchant_id,subscription_id should be globally unique), which has 
> multiple contracts (RecurringPaymentContract). Besides payment bounds, each 
> contract has a validity period: generally, a subscription will have a unique 
> active contract at a given time and potentially one or more pending ones.
> 
> For example, say you are on the gold plan (1 BTC/mo.) and want to downgrade 
> to a bronze plan (0.5 BTC/mo.) at your next billing date. Wshen you click 
> "Downgrade" on the merchant site, you will update your wallet with two 
> contracts: the current valid one until your next billing date (for up to 1 
> BTC), and a pending one, starting at your next billing date (for up to 0.5 
> BTC/mo. and without an ending date).
> Upon cancellation of the bronze plan, the end date of the contract will be 
> updated and polling will stop eventually.
> 
> All of this contract metadata is returned to the wallet so the user can make 
> an informed decision.
> 
> 
> Thanks for your feedbacks!
> 
> S.
> 
> 
> On Feb 11, 2014, at 10:37 PM, Kevin Greene  wrote:
> 
>> Sending this again and truncating since apparently the message body was too 
>> long.
>> 
>> Thanks for humoring my questions!
>> 
>> >I think reporting such errors to the wallet would make complete sense. 
>> >However i am not clear why we would a separate url for that?
>> 
>> Hmm, thinking about this more, adding a simple status_code in PaymentRequest 
>> would be a much easier way to achieve this. However, continuing to think 
>> about this even more, maybe the simple memo field along with an empty set of 
>> outputs is enough already.
>> 
>> In bitcoinj, right now the code will throw a 
>> PaymentRequestException.InvalidOutputs exception if the set of outputs is 
>> empty with a message of "No Outputs". Because of that, there isn't a good 
>> way to tell the difference between a payment request that had no outputs and 
>> a payment request that had some invalid output(s).
>> 
>> Question to everyone:
>> How does bitcoin-qt handle a PaymentRequest with no outputs?
> 

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Mark Friedenbach]

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 for 64-byte hashes, and the 80-char line
length comparison is a good point. As an Engineer I'd want to have a
little more room as a 32-byte hash or EC point + 8 bytes identifying
prefix data is the bare minimum, but it is also very important that we
send a message: This is for payment related applications like stealth
addresses only. Don't burden everybody by putting your junk on the block
chain.

On 02/24/2014 08: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 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 it down to 40 for 0.9.
> 
> That'd be enough for <8 byte header/identifier><32 byte hash>.
> 
> 80, as the standard line length, is almost asking for "insert your
> graffiti message here". I also see no need for 64 bytes hashes such as
> SHA512 in the context of bitcoin, as that only offers 256-bit security
> (at most) in the first place.
> 
> And if this is not abused, these kind of transactions become popular,
> and more space is really needed, the limit can always be increased in a
> future version.
> 
> Wladimir
> 
> 
> --
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Jeff Garzik]

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
> 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, perceptions and questions are bubbling
> up, and it seemed fair to cover them on the list, not just IRC.
>
> 1) FAQ:  Why 80 bytes of data?  This is the leading programmer
> question, and it was not really documented well at all.  Simple
> answer:  2x SHA256 or 1x SHA512, plus some tiny bit of metadata.  Some
> schemes are of the nature "BOND" rather than just plain hash.
> 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.
>
> 2) Endorsement of chain data storage.  Listening to bitcoin conference
> corridor discussions, reading forum posts and the occasional article
> have over-simplified the situation to "core devs endorse data storage
> over blockchain!  let me start uploading my naughty movie collection!
> IM over blockchain, woo hoo!"
>
> Nothing could be further from the truth.  It's a way to make data
> /less damaging/, not an endorsement of data storage in chain as a good
> idea.  MasterCoin and other projects were doing -even worse- things,
> such as storing data in forever-unspendable TX outputs, bloating the
> UTXO for eternity.
>
> It seems reasonable to have a release note to this effect in the 0.9
> release announcement, IMO.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Pavol Rusnak]

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 

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Gavin Andresen]

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 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 it down to 40 for 0.9.
>
> That'd be enough for <8 byte header/identifier><32 byte hash>.
>
> 80, as the standard line length, is almost asking for "insert your
> graffiti message here". I also see no need for 64 bytes hashes such as
> SHA512 in the context of bitcoin, as that only offers 256-bit security (at
> most) in the first place.
>
> And if this is not abused, these kind of transactions become popular, and
> more space is really needed, the limit can always be increased in a future
> version.
>
> Wladimir
>



-- 
--
Gavin Andresen
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Wladimir]

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 it down to 40 for 0.9.

That'd be enough for <8 byte header/identifier><32 byte hash>.

80, as the standard line length, is almost asking for "insert your graffiti
message here". I also see no need for 64 bytes hashes such as SHA512 in the
context of bitcoin, as that only offers 256-bit security (at most) in the
first place.

And if this is not abused, these kind of transactions become popular, and
more space is really needed, the limit can always be increased in a future
version.

Wladimir
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Jeff Garzik]

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.
>>
>> Nothing could be further from the truth.
>
> These two statements are in direct contradiction with each other.
>
> --
> Pieter



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Jeff Garzik]

(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 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.
>
> --
> Pieter



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Pieter Wuille]

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.

-- 
Pieter

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Jeff Garzik]

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, perceptions and questions are bubbling
up, and it seemed fair to cover them on the list, not just IRC.

1) FAQ:  Why 80 bytes of data?  This is the leading programmer
question, and it was not really documented well at all.  Simple
answer:  2x SHA256 or 1x SHA512, plus some tiny bit of metadata.  Some
schemes are of the nature "BOND" rather than just plain hash.
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.

2) Endorsement of chain data storage.  Listening to bitcoin conference
corridor discussions, reading forum posts and the occasional article
have over-simplified the situation to "core devs endorse data storage
over blockchain!  let me start uploading my naughty movie collection!
IM over blockchain, woo hoo!"

Nothing could be further from the truth.  It's a way to make data
/less damaging/, not an endorsement of data storage in chain as a good
idea.  MasterCoin and other projects were doing -even worse- things,
such as storing data in forever-unspendable TX outputs, bloating the
UTXO for eternity.

It seems reasonable to have a release note to this effect in the 0.9
release announcement, IMO.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development