Petr Praus [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-02-08 to 2013-06-06
💬 Posted a total of 6 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:02:56

- reply

📅 Original date posted:2013-06-05
📝 Original message:BitcoinJ is storing parsed blocks (not the whole chunks of bytes) in H2, an
embedded SQL database for Java.
On 5 June 2013 19:53, Marko Otbalkana <marko.otbalkana at gmail.com> wrote:
> Could anyone point me to work/project(s) related to storing the block
> chain in a database, like PostgreSQL, MySQL? How about any tools that can
> read the block chain from the Satoshi client and convert it into different
> formats?
>
> Thanks,
> -Marko
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130605/26287145/attachment.html>

2023-06-07 15:01:25

- reply

📅 Original date posted:2013-05-07
📝 Original message:I think it's worth noting that quite a large portion of Linux users
probably get the mainline Bitcoin client from the packages. I think Bitcoin
package maintainers are doing mostly a pretty good job :)
On 6 May 2013 18:13, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, May 6, 2013 at 3:51 PM, Adam Back <adam at cypherspace.org> wrote:
> > Maybe I could hack a pool to co-opt it into my netsplit and do the work
> for
> > me, or segment enough of the network to have some miners in it, and they
> do
> > the work.
>
> Or you can just let it mine honestly and take the Bitcoins. This is
> fast (doesn't require weeks of them somehow not noticing that they're
> isolated), and yields the values I listed as 'costs' if you would have
> otherwise been able to use it to mine the difficulty down to 1. Cost
> is just as much foregone income from the alternative attack you could
> have done instead.
>
> > nor even topological, nor even
> > particularly long-lived.
>
> At least for attacks that drive the difficulty down it does.
>
> If you want to talk about abusing a pool or creating a partition in
> order to create short reorgs— I agree, those don't have to be long
> lived and you can find many messages where I've written on that
> subject.
>
> It's inconsiderate to propose one attack and when I respond to it
> changing the attack out from under me. :( I would have responded
> entirely differently if you'd proposed people segmenting the network
> and creating short reorgs instead of mining the difficulty down.
>
> > Do you know if there is any downwards limit on difficulty? I know it
> takes
> > going slow for a long and noticeable time, but I am just curious on the
> > theoretical limit.
>
> Every 2016 blocks can at most lower the difficulty by a factor of 4,
> thats where the log4 (number of 2016 groups needed) and 4^n (factor in
> cost reduction for each group) come from in the formulas I gave
> previously.
>
> > I dont see the signatures.
>
>
> http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256SUMS.asc/download
>
> The signatures can't be inside the tarball because they sign the tarball.
>
> Seems like the website redesign managed to hide the signatures pretty
> good. They're in the release announcements in any case, but that
> should be fixed. Even when they were prominently placed, practically
> no one checked them. As a result they are mostly security theater in
> practice :(, — so— unfortunately, is SSL: there are many CA's who will
> give anyone a cert with your name on it who can give them a couple
> hundred bucks and MITM HTTP (not HTTPS!) between the CA's
> authentication server and your webserver. Bitcoin.org is hosted by
> github, even if it had SSL and even if the CA infrastructure weren't a
> joke, the number of ways to compromise that hosting enviroment would
> IMO make SSL mostly a false sense of security.
>
> The gpg signatures and gitian downloader signatures provide good
> security if actually used, solving the "getting people to use them"
> problem is an open question.
>
> And I agree, this stuff is a bigger issue than many other things like
> mining the difficulty down.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130506/39286b04/attachment.html>

2023-06-07 14:56:36

- reply

2023-06-07 11:42:33

- reply

📅 Original date posted:2013-04-01
📝 Original message:An attacker would have to find a collision between two specific pieces of
code - his malicious code and a useful innoculous code that would be
accepted as pull request. This is the second, much harder case in the
birthday problem. When people talk about SHA-1 being broken they actually
mean the first case in the birthday problem - find any two arbitrary values
that hash to the same value. So, no I don't think it's a feasible attack
vector any time soon.
Besides, with that kind of hashing power, it might be more feasible to
cause problems in the chain by e.g. constantly splitting it.
On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> I was just looking at:
>
> https://bitcointalk.org/index.php?topic=4571.0
>
> I'm just curious if there is a possible attack vector here based on the
> fact that git uses the relatively week SHA1
>
> Could a seemingly innocuous pull request generate another file with a
> backdoor/nonce combination that slips under the radar?
>
> Apologies if this has come up before ...
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130401/8f2483a3/attachment.html>

2023-06-07 11:31:08

- reply

📅 Original date posted:2013-02-14
📝 Original message:Ah, I missed this, thanks.
On 13 February 2013 15:49, Jorge Timón <jtimonmv at gmail.com> wrote:
> Well, if it's even possible to trade across "chains" with Ripple (and
> I don't know of any reason shouldn't be), you will have to wait to the
> release of the full node (validator) code, for now only a javascript
> web client is open sourced. But it seems they at least have plans for
> contracts judging from the wiki:
>
> https://ripple.com/wiki/Contracts
>
>
> On 2/13/13, Petr Praus <petr at praus.net> wrote:
> > Jorge, thanks for bitcoinx tip, I didn't know about it and it's certainly
> > related. I'll have a closer look
> > Regarding Ripple, I tried it but as far as I can tell, it doesn't have
> any
> > contract enforcement (by technical means) built in.
> >
> >
> > On 11 February 2013 05:03, Jorge Timón <jtimonmv at gmail.com> wrote:
> >
> >> Hi, you may be interested in a couple of related projects.
> >>
> >> Colored coins uses satoshis to represent smart property, shares, IOUs
> >> of another currency...Colored coins can be atomically traded for
> >> bitcoin. If you implement the trade across chains contract they would
> >> also be tradeable for another chain currencies like namecoin or
> >> freicoin.
> >>
> >> http://www.bitcoinx.org/
> >>
> >> Ripple is a concept by which people that trust each other on a network
> >> are able to pay with IOUs transitively. It has a new p2p
> >> implementation that is still on development. The new implementation
> >> is very similar to bitcoin in certain senses but it has no mining.
> >> Bitcoin IOUs can be traded there.
> >>
> >> https://ripple.com/
> >>
> >> Good luck with the implementation, this is a good feature to have,
> >> even if it's not on the main client.
> >>
> >>
> >> On 2/8/13, Petr Praus <petr at praus.net> wrote:
> >> > Hi,
> >> >
> >> > I intend to implement trading across chains in a P2P manner (as
> >> > described
> >> > by Mike Hearn in
> >> > https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
> ).
> >> > Note, this is indended more as an alternative chain development, I
> >> > don't
> >> > have any plans for merging it back into main client (not because I
> >> > don't
> >> > want to, but because I think it wouldn't be accepted). Before I dive
> >> > into
> >> > it, I thought it might be a good idea to ask here if the community has
> >> any
> >> > useful ideas or comments on this topic?
> >> >
> >> > Thanks to Gary Rowe I know about Open
> >> > Transactions<https://github.com/FellowTraveler/Open-Transactions>.
> >> > They can do "multicurrency trading" too, but it's objectives are quite
> >> > ambitious and I'm looking at making relatively small changes in the
> >> > mainline Bitcoin client rather than diving into something entirely
> new.
> >> >
> >> > A little background on why am I doing this, can be found
> >> > here<
> https://groups.google.com/d/topic/bitcoinj/lmVSF8yaJHk/discussion>.
> >> > In short it's part of research towards my Master's thesis (more
> >> precisely,
> >> > an excuse to hack on Bitcoin and sell it as research :)) which should
> >> > be
> >> > about multicurrency (alternative chains) in Bitcoin.
> >> >
> >> > Thanks,
> >> > Petr
> >> >
> >> > PS: I hope I'm not too off topic here, but
> >> > this<https://bitcointalk.org/index.php?topic=15527.0> thread
> >> > indicates it should be fine to post alternative development questions
> >> > on
> >> > this.
> >> >
> >>
> >>
> >> --
> >> Jorge Timón
> >>
> >> http://freico.in/
> >> http://archive.ripple-project.org/
> >>
> >
>
>
> --
> Jorge Timón
>
> http://freico.in/
> http://archive.ripple-project.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130214/fabe60ea/attachment.html>

2023-06-07 11:31:01

- reply

📅 Original date posted:2013-02-13
📝 Original message:Jorge, thanks for bitcoinx tip, I didn't know about it and it's certainly
related. I'll have a closer look
Regarding Ripple, I tried it but as far as I can tell, it doesn't have any
contract enforcement (by technical means) built in.
On 11 February 2013 05:03, Jorge Timón <jtimonmv at gmail.com> wrote:
> Hi, you may be interested in a couple of related projects.
>
> Colored coins uses satoshis to represent smart property, shares, IOUs
> of another currency...Colored coins can be atomically traded for
> bitcoin. If you implement the trade across chains contract they would
> also be tradeable for another chain currencies like namecoin or
> freicoin.
>
> http://www.bitcoinx.org/
>
> Ripple is a concept by which people that trust each other on a network
> are able to pay with IOUs transitively. It has a new p2p
> implementation that is still on development. The new implementation
> is very similar to bitcoin in certain senses but it has no mining.
> Bitcoin IOUs can be traded there.
>
> https://ripple.com/
>
> Good luck with the implementation, this is a good feature to have,
> even if it's not on the main client.
>
>
> On 2/8/13, Petr Praus <petr at praus.net> wrote:
> > Hi,
> >
> > I intend to implement trading across chains in a P2P manner (as described
> > by Mike Hearn in
> > https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains).
> > Note, this is indended more as an alternative chain development, I don't
> > have any plans for merging it back into main client (not because I don't
> > want to, but because I think it wouldn't be accepted). Before I dive into
> > it, I thought it might be a good idea to ask here if the community has
> any
> > useful ideas or comments on this topic?
> >
> > Thanks to Gary Rowe I know about Open
> > Transactions<https://github.com/FellowTraveler/Open-Transactions>.
> > They can do "multicurrency trading" too, but it's objectives are quite
> > ambitious and I'm looking at making relatively small changes in the
> > mainline Bitcoin client rather than diving into something entirely new.
> >
> > A little background on why am I doing this, can be found
> > here<https://groups.google.com/d/topic/bitcoinj/lmVSF8yaJHk/discussion>.
> > In short it's part of research towards my Master's thesis (more
> precisely,
> > an excuse to hack on Bitcoin and sell it as research :)) which should be
> > about multicurrency (alternative chains) in Bitcoin.
> >
> > Thanks,
> > Petr
> >
> > PS: I hope I'm not too off topic here, but
> > this<https://bitcointalk.org/index.php?topic=15527.0> thread
> > indicates it should be fine to post alternative development questions on
> > this.
> >
>
>
> --
> Jorge Timón
>
> http://freico.in/
> http://archive.ripple-project.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130213/ff7b335a/attachment.html>

2023-06-07 11:30:54

- reply

📅 Original date posted:2013-02-08
📝 Original message:Hi,
I intend to implement trading across chains in a P2P manner (as described
by Mike Hearn in
https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains).
Note, this is indended more as an alternative chain development, I don't
have any plans for merging it back into main client (not because I don't
want to, but because I think it wouldn't be accepted). Before I dive into
it, I thought it might be a good idea to ask here if the community has any
useful ideas or comments on this topic?
Thanks to Gary Rowe I know about Open
Transactions<https://github.com/FellowTraveler/Open-Transactions>.
They can do "multicurrency trading" too, but it's objectives are quite
ambitious and I'm looking at making relatively small changes in the
mainline Bitcoin client rather than diving into something entirely new.
A little background on why am I doing this, can be found
here<https://groups.google.com/d/topic/bitcoinj/lmVSF8yaJHk/discussion>.
In short it's part of research towards my Master's thesis (more precisely,
an excuse to hack on Bitcoin and sell it as research :)) which should be
about multicurrency (alternative chains) in Bitcoin.
Thanks,
Petr
PS: I hope I'm not too off topic here, but
this<https://bitcointalk.org/index.php?topic=15527.0> thread
indicates it should be fine to post alternative development questions on
this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130207/a3d922f8/attachment.html>