John Smith | 1 Sep 2011 04:11
Picon

Re: Bitcoin-qt ready for merging



Would it be possible to port some of the existing translations?

Well, the strings in the core can be reused one-on-one as the _ function is mapped to the Qt translation function.

And some of the UI texts probably can be reused as well, at least for a rough approximation.

The files will have to be converted, as Qt uses an XML-based format whereas Wx uses a line-based one. Also, Qt translations have a "context" (file/object) defined whereas in Wx the "msgid" is only the English text. Nah, nothing that a bit of Python hacking can't solve.

Though IMHO its not a huge deal if qt is merged without all the
translations as IMHO it should be merged soon and then not the default
release GUI until its in tree for a bit (like one release) and some
translations can be built up.

Exactly... if there is some time between Qt being merged and Wx being phased out, translations can be added. The Qt translation tool (Qt Linguist) is user friendly enough to be used by anyone.

>
> So IMO, it is ready to be merged.
IMHO it should be merged right after 0.4 is pushed.

Sounds fine with me,

JS

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Luke-Jr | 1 Sep 2011 04:13

Re: Bitcoin-qt ready for merging

On Wednesday, August 31, 2011 10:20:48 AM John Smith wrote:
> The project builds on Windows, MacOSX and Linux using qmake.

How do you set build options with qmake?

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
John Smith | 1 Sep 2011 04:32
Picon

Re: Bitcoin-qt ready for merging



On Thu, Sep 1, 2011 at 2:13 AM, Luke-Jr <luke <at> dashjr.org> wrote:
On Wednesday, August 31, 2011 10:20:48 AM John Smith wrote:
> The project builds on Windows, MacOSX and Linux using qmake.

How do you set build options with qmake?

You can put assignments on the commandline; for example,

qmake "CONFIG+=test" test.pro

Like in plain make, these variables can be used for conditionally enabling/disabling libraries or other options in the .pro file.

http://doc.qt.nokia.com/latest/qmake-manual.html

(reminds me that I still need to add the USE_UPNP option)

Note that qmake is a pretty simple tool, optimized for conveniently building Qt applications in a cross-platform way; it in no way compares to cmake/autotools or another "full" build system. But it's enough for building bitcoin-qt on the supported target architectures so that's good enough for me... For "bitcoind" and "bitcoin-wx" you probably want to keep around the makefile.

JS

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Gavin Andresen | 2 Sep 2011 22:12
Picon
Gravatar

Version 0.4 release candidate 1

Bitcoin version 0.4 release candidate 1 is ready for initial testing;
please grab the source from github and try to break it.

The big, visible change is wallet private key encryption, which is NOT
turned on by default.

The big, invisible change is a reworking of internal critical section
mutexes to fix some chronic problems with bitcoind becoming
unresponsive due to deadlocks.

git shortlog --no-merges v0.3.24..
 ... will give you all the changes.

Thanks to everybody who contributed patches, and sorry if your
favorite patch is not included.

--

-- 
--
Gavin Andresen

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
Rob Meijer | 2 Sep 2011 22:32
Picon
Picon
Favicon

Re: BitCoin and MinorFs/AppArmor

Given that there was not a single response to my post, I gather there is
no to little interest in an updated MinorFs that could be used by bitcoin
on systems that support AppArmor (Ubuntu and OpenSuse).

Nevertheless I've put down the initial set of specs for a rewrite of
MinorFs for if anyone would like to comment on them to make a future match
with Bitcoin more likely, I'm open to all sugestions:

http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2

On Fri, August 26, 2011 09:48, Rob Meijer wrote:
> A few years ago I wrote a least authority based set of filesystems named
> MinorFs that worked closely together with AppArmor (suse/ubuntu) to give '
> pseudo persistent processes' their own private but decomposable and
> delegatable piece of filesystem storage:
>
> http://www.linuxjournal.com/magazine/minorfs
> http://www.capibara.com/blog/2011/05/25/taming-mutable-state-for-file-systems/
>
> Currently there is only one perfect fit for MinorFs and that's the stack
> AppArmor/MinorFs/E-language-persistent-application. There are some close
> fits like running ssh without a passphrase (
> http://minorfs.polacanthus.net/wiki/Ssh_private_keys_without_passphrase )
> but these require lots of manual fiddling by the user to get working. The
> ssh trick would probably work with bitcoin, but as you can see from the
> link above, it would be rather cumbersome.
>
> I am trying to get specs together for rewriting MinorFs (in Python) in a
> way that would make it easy and natural for application developers that
> want their application to be able to protect user data (like bitcoin
> wallets) from mallware running under the same uid as that user.
>
> Currently minorfs granularity is hard fixed to that of the 'pseudo
> persistent process', and that granularity is determined as described in
> the following link:
>
> http://minorfs.polacanthus.net/wiki/Pseudo_persistent_process
>
> When using pseudo persistent processes, you basically end up with
> file-system storage that follows almost all of the modeling principles of
> the object capability model. This is great when designing a least
> authority program from scratch and writing it in the (object capability)
> e-language using its persistence facilities.
>
> Given however that I don't expect bitcoin, openssh, chrome, firefox, or
> any other application that would benefit from what MinorFs provides to be
> rewritten in E, it seems like the next version of MinorFs should give up
> on the purity of its least authority model, and take an approach that
> better suits common development languages and practices.
>
> With bitcoin being a project that could benefit most from what MinorFs has
> to offer, I would like to ask bitcoin developers to think about what
> attributes from the current granularity level (pseudo persistent process)
> should be kept, what attributes should be dropped, and what properties
> should be added to arrive at an 'id' that is the best fit for granularity
> of persistent private storage for bitcoin.
>
> I really want to accommodate bitcoin developer needs in this, so all input
> that helps me help you guys to get the next MinorFs version to accommodate
> your needs to a level that code to use MinorFs where available can be
> added to bitcoin, would be extremely welcome.
>
> Let me know what you think,
>
> Rob
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
Nils Schneider | 3 Sep 2011 00:05

Re: BitCoin and MinorFs/AppArmor

MinorFs sounds like an interesting concept and but wallet encryption
(already being tested and close to release) is a simpler solution for
end-users.

Would MinorFs help securing the wallet on a server, maybe even a
(insecure) VPS?

Can it work without changes to Bitcoin? If not, what is the minimal
amount of changes needed?

Is there any guarantee it will never corrupt the wallet?

What would be the proper way to do backups?

On 02.09.2011 22:32, Rob Meijer wrote:
> Given that there was not a single response to my post, I gather there is
> no to little interest in an updated MinorFs that could be used by bitcoin
> on systems that support AppArmor (Ubuntu and OpenSuse).
> 
> Nevertheless I've put down the initial set of specs for a rewrite of
> MinorFs for if anyone would like to comment on them to make a future match
> with Bitcoin more likely, I'm open to all sugestions:
> 
> http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2
> 
> On Fri, August 26, 2011 09:48, Rob Meijer wrote:
>> A few years ago I wrote a least authority based set of filesystems named
>> MinorFs that worked closely together with AppArmor (suse/ubuntu) to give '
>> pseudo persistent processes' their own private but decomposable and
>> delegatable piece of filesystem storage:
>>
>> http://www.linuxjournal.com/magazine/minorfs
>> http://www.capibara.com/blog/2011/05/25/taming-mutable-state-for-file-systems/
>>
>> Currently there is only one perfect fit for MinorFs and that's the stack
>> AppArmor/MinorFs/E-language-persistent-application. There are some close
>> fits like running ssh without a passphrase (
>> http://minorfs.polacanthus.net/wiki/Ssh_private_keys_without_passphrase )
>> but these require lots of manual fiddling by the user to get working. The
>> ssh trick would probably work with bitcoin, but as you can see from the
>> link above, it would be rather cumbersome.
>>
>> I am trying to get specs together for rewriting MinorFs (in Python) in a
>> way that would make it easy and natural for application developers that
>> want their application to be able to protect user data (like bitcoin
>> wallets) from mallware running under the same uid as that user.
>>
>> Currently minorfs granularity is hard fixed to that of the 'pseudo
>> persistent process', and that granularity is determined as described in
>> the following link:
>>
>> http://minorfs.polacanthus.net/wiki/Pseudo_persistent_process
>>
>> When using pseudo persistent processes, you basically end up with
>> file-system storage that follows almost all of the modeling principles of
>> the object capability model. This is great when designing a least
>> authority program from scratch and writing it in the (object capability)
>> e-language using its persistence facilities.
>>
>> Given however that I don't expect bitcoin, openssh, chrome, firefox, or
>> any other application that would benefit from what MinorFs provides to be
>> rewritten in E, it seems like the next version of MinorFs should give up
>> on the purity of its least authority model, and take an approach that
>> better suits common development languages and practices.
>>
>> With bitcoin being a project that could benefit most from what MinorFs has
>> to offer, I would like to ask bitcoin developers to think about what
>> attributes from the current granularity level (pseudo persistent process)
>> should be kept, what attributes should be dropped, and what properties
>> should be added to arrive at an 'id' that is the best fit for granularity
>> of persistent private storage for bitcoin.
>>
>> I really want to accommodate bitcoin developer needs in this, so all input
>> that helps me help you guys to get the next MinorFs version to accommodate
>> your needs to a level that code to use MinorFs where available can be
>> added to bitcoin, would be extremely welcome.
>>
>> Let me know what you think,
>>
>> Rob
>>
>>
>> ------------------------------------------------------------------------------
>> EMC VNX: the world's simplest storage, starting under $10K
>> The only unified storage solution that offers unified management
>> Up to 160% more powerful than alternatives and 25% more efficient.
>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better 
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
John Smith | 3 Sep 2011 09:04
Picon

Re: BitCoin and MinorFs/AppArmor


On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <capibara <at> xs4all.nl> wrote:
Given that there was not a single response to my post, I gather there is
no to little interest in an updated MinorFs that could be used by bitcoin
on systems that support AppArmor (Ubuntu and OpenSuse).

Oh yes there is interest. I meant to reply but haven't been able to put much energy in bitcoin development lately.

More strict privilege seperation between applications on a least-authority basis is something that Ubuntu is certainly going to need if they're serious with the app store thing (and want to keep up with Android and Macosx...).
 
This has been needed for a long time, and this would be useful for any private data managed by applications running as the same user (ssh, browsers, pgp, ...)

Wallet encryption is useful and necessary but no substitute for OS-level protection.


Nevertheless I've put down the initial set of specs for a rewrite of
MinorFs for if anyone would like to comment on them to make a future match
with Bitcoin more likely, I'm open to all sugestions:

http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2

You have to rewrite the entire thing from scratch?

This is probably blasphemy but: how can it be compared to the android model, with a UID per application/user, and thus layering the security on top of current UNIX/ACL permissions?  Is another FS really needed?

JS

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
John Smith | 3 Sep 2011 09:15
Picon

Re: Version 0.4 release candidate 1



On Fri, Sep 2, 2011 at 8:12 PM, Gavin Andresen <gavinandresen <at> gmail.com> wrote:
Bitcoin version 0.4 release candidate 1 is ready for initial testing;
please grab the source from github and try to break it.

The big, visible change is wallet private key encryption, which is NOT
turned on by default.

The big, invisible change is a reworking of internal critical section
mutexes to fix some chronic problems with bitcoind becoming
unresponsive due to deadlocks.

Great, congrats!

The mutex overhaul was badly needed. I'm glad to see the project move this fast in a sudden.

JS
 


------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Chris Double | 3 Sep 2011 15:52
Picon
Gravatar

Transaction limit size in CWallet::CreateTransaction

In CWallet::CreateTransaction there is a call to 'GetSerializeSize' on
line 979 (https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L979).
It looks like:

---------8<----------
unsigned int nBytes = ::GetSerializeSize(*(CTransaction*)&wtxNew, SER_NETWORK)
if (nBytes >= MAX_BLOCK_SIZE_GEN/5)
  return false;
dPriority /= nBytes;
---------8<----------

'wtxNew' is a CWalletTxn. So this gets the serialized size of the
transaction, including all the extra data held in the wallet for that
transaction, and uses that size for computation of priority. Is that
correct? Should it be only the size of the CTransaction* part of the
transaction that should be used?

It looks this was from the casting shenanigans but unless I'm
mistaken, that casting doesn't actually do anything. We get a pointer
to a CTransaction but then dereference it, so the template function
'GetSerializeSize' would get the most derived class, right?

So was the intent to use the CWalletTxn size, and the casting is
superfluous, or was it supposed to be the CTransaction* portion and
the cast is an incorrect way of doing that? Or am I suffering from
late night programmer syndrome and reading it wrong?

Chris.
--

-- 
http://www.bluishcoder.co.nz

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
Chris Double | 3 Sep 2011 16:16
Picon
Gravatar

Re: Transaction limit size in CWallet::CreateTransaction

On Sun, Sep 4, 2011 at 1:52 AM, Chris Double <chris.double <at> double.co.nz> wrote:
> So was the intent to use the CWalletTxn size, and the casting is
> superfluous, or was it supposed to be the CTransaction* portion and
> the cast is an incorrect way of doing that? Or am I suffering from
> late night programmer syndrome and reading it wrong?

After a discussion on #bitcoin-dev it is indeed the latter. I was
under the mistaken believe that the GetSerializeSize method in
CTransaction and CWalletTxn were virtual, which would result in the
behavior I was thinking of. But they're not so it works. Please
disregard!

Chris.
--

-- 
http://www.bluishcoder.co.nz

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev

Gmane