[Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent

[Amir Taaki]

Hi,

https://en.bitcoin.it/wiki/BIP_0014

Thanks to Gavin Andresen for proof reading and suggesting clarifications. 
Thanks to Patrick Strateman for suggesting the hierarchical format and pointing 
out some flaws of browser user-agents to me.

The timeline is written in the past tense since BIPs are meant to be readable 
in the future for explaining why we took certain decisions with bitcoin. A nice 
cache for future historians when bitcoin is ubiquitous ;)


The next version 0.6 should be the protocol version which becomes peeled off 
from the current client. There are still some changes migrating into the 
protocol that need to be finished.
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP 0001 now active

[Amir Taaki]

I put the status for BIP 0001 to active now. Let me know if there's any 
disagreements with this. I'm on Freenode under the nickname genjix
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Wallet encryption issue

[Alan Reiner]

Sorry guys, I just realized I should've posted this to the dev list 
first, before/instead of putting it on the forums.


   https://bitcointalk.org/index.php?topic=51474

*I still have some of my private keys in plaintext. *I would guess that 
BSDDB sometimes will "overwrite" data by just discarding a pointer to 
the old data, and writing the replacement to a new location within the 
file.  In that case, examining the file with a BSDDB library tool is not 
going to find this problem.  You'll have to examine the raw binary file 
as I did.  Instructions for verifying this problem are in the post.


Can someone please verify that this is a real problem?  (and should we 
maybe remove my post until there's a remediation plan?  This is problem 
the best kind of problem to disclose after it's fixed)

-Alan


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...

[Alan Reiner]

Michael, thanks for taking time to read the proposal.  Responses are 
inline, below.

I am not sure where you prefer the discussion on the content of the BIP - but 
now you get it here, but feel free to redirect...

Likes:
* inclusion of prevout txout scripts - could prove handy
* that it is a proposal to do this similarly on all clients
The txout scripts are not just handy, they /need/ to be included in the 
txin scripts for signing.  By putting them there already, the parser 
only has to blank out the others txins, add the hashcode, and pass it to 
the ECDSA code for signing (if you're not familar with OP_CHECKSIG, see 
my diagram here ).  I 
think this feature is *critical* to adoption, as it works for the most 
lightweight clients that might not even contain blockheaders -- 
everything you need to understand and sign the the transaction is 
included (except for the txin values).


For that reason, this doubles as a convenient way to do offline 
wallets/signing:  you don't have to keep transporting 700 MB of 
blockchain to the offline computer just so it can sign your transactions.

Dislikes:
* the format - I guess I would prefer a normal JSON format - where the scripts 
gets populated step by step. As for the scriptPubKey (now an awful name...) it 
would be easy to just add it to the JSON, or have the prevouts simply be the 
actual txouts instead of {hash,n}.
I see the benefit of JSON for dynamic information with lots of optional 
fields.  But this information is fairly static -- if there's extra 
information developers need for this process, it can be added.  I don't 
see a lot of variation in the amount/types of data to be included here.


The core benefit follows PGP messages:  compact, easy-to-identify, 
blocks of text, that can be included inline in an email as easily as it 
can be supplied as a file/attachment, and only requires code that's 
already available in a BTC developer toolbox.  I can even remove the 
numsigs counter, as it's easy enough to search for the END-TXDP line.  
Think about a non-developer opening a file and trying to identify it:  
JSON looks like code, this looks like... "BEGIN-TXDP---"  (now that 
I think about it, "BEGIN-TRANSACTION-9fj3fsQ" might be better...)

Comments:
* it is good to have this proposal, but I think that once we see ways to 
communicate it they could very well radically steer how a format should look. 
Take e.g. the discussion we had with Gavin yesterday, if we had chosen to move 
in that direction BIP0010 would had been useless. So perhaps a bit premature?

If we start talking about in-blockchain techniques, I agree with you.  
But If that idea is discarded, *all* out-of-band solutions are going to 
require encoding this exact information somehow.  I think offering this 
solution before developers start asking the question of how to do it is 
exactly what's needed.


-Alan

Cheers,

Michael


On 10/11/2011, at 04:00, Alan Reiner wrote:


The purpose of creating BIP 0010 now, is to encourage a standard that 
developers want to adopt, from the outset.  Every developer who is planning to 
touch multi-signature transactions, is going to have to solve the problem of 
multi-sig tx exchanges, eventually.  By offering an excellent solution before 
they've started asking the question, there's a good chance people will use it.  
 Hear me out...

Protocols get fragmented when there's multiple competing ways to do something, 
each having some advantages the others don't have.  This leads to developers 
with differing priorities picking different ones, or creating their own.   
However, I believe that the problem BIP 0010 seeks to solve is a fairly 
straightforward problem.  There's not a lot of variety in the solutions that 
could compete against it.  People just need a way to pass this data around, and 
they want it to be as convenient to use, and as easy to implement as possible.  
In that sense, I think BIP 0010 (or some future variant) is fairly optimal as a 
building block for higher-level protocols.

If anyone has ideas for why someone would want to create a competing idea to 
BIP 0010 (besides not being aware of it when they start), I'd like to discuss 
it.  I'm fairly confident that any such ideas could just be added to BIP 0010 
and thus reset the question of why anyone would need a competing idea.



On 11/09/2011 03:03 PM, Michael Grønager wrote:

My main concern when it comes to introducing other protocols is that they might 
never be standard (I think a great number of clients will emerge - and this 
would be a thing to compete on). If it is part of the p2p network it will be a 
seamless standard and easy for everyone to use, even across different clients. 
But I share your concern on the

/M


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___

Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...

[Michael Grønager]

Hi Alan,

I have now read BIP0010 - one first idea is: add a link to it on the wiki (or 
remove all bip links from the wiki... - we don't want two places for BIPs...)

I am not sure where you prefer the discussion on the content of the BIP - but 
now you get it here, but feel free to redirect...

Likes:
* inclusion of prevout txout scripts - could prove handy
* that it is a proposal to do this similarly on all clients

Dislikes:
* the format - I guess I would prefer a normal JSON format - where the scripts 
gets populated step by step. As for the scriptPubKey (now an awful name...) it 
would be easy to just add it to the JSON, or have the prevouts simply be the 
actual txouts instead of {hash,n}.

Comments:
* it is good to have this proposal, but I think that once we see ways to 
communicate it they could very well radically steer how a format should look. 
Take e.g. the discussion we had with Gavin yesterday, if we had chosen to move 
in that direction BIP0010 would had been useless. So perhaps a bit premature?

Cheers,

Michael



On 10/11/2011, at 04:00, Alan Reiner wrote:

> The purpose of creating BIP 0010 now, is to encourage a standard that 
> developers want to adopt, from the outset.  Every developer who is planning 
> to touch multi-signature transactions, is going to have to solve the problem 
> of multi-sig tx exchanges, eventually.  By offering an excellent solution 
> before they've started asking the question, there's a good chance people will 
> use it.   Hear me out...
> 
> Protocols get fragmented when there's multiple competing ways to do 
> something, each having some advantages the others don't have.  This leads to 
> developers with differing priorities picking different ones, or creating 
> their own.   However, I believe that the problem BIP 0010 seeks to solve is a 
> fairly straightforward problem.  There's not a lot of variety in the 
> solutions that could compete against it.  People just need a way to pass this 
> data around, and they want it to be as convenient to use, and as easy to 
> implement as possible.  In that sense, I think BIP 0010 (or some future 
> variant) is fairly optimal as a building block for higher-level protocols.  
> 
> If anyone has ideas for why someone would want to create a competing idea to 
> BIP 0010 (besides not being aware of it when they start), I'd like to discuss 
> it.  I'm fairly confident that any such ideas could just be added to BIP 0010 
> and thus reset the question of why anyone would need a competing idea.
> 
> 
> 
> On 11/09/2011 03:03 PM, Michael Grønager wrote:
>> My main concern when it comes to introducing other protocols is that they 
>> might never be standard (I think a great number of clients will emerge - and 
>> this would be a thing to compete on). If it is part of the p2p network it 
>> will be a seamless standard and easy for everyone to use, even across 
>> different clients. But I share your concern on the 
>> 
>> /M
>> 
> 
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: grona...@ceptacle.com


Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: grona...@ceptacle.com



--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development