Robert Backhaus [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-12-05 to 2013-07-09
💬 Posted a total of 10 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 17:04:21

- reply

📅 Original date posted:2013-07-08
📝 Original message:But... Multibit is Java. Java's security problems has made it an instant
uninstall item on windows PCs for about a year now. Java exploits are a
dime a dozen.
Yes, you can reduce some of the problems by manually disabling the browser
plugin, but how many users will do that?
Recommending a fast SPV client as a first wallet - yes, of course.
Recommending users open such a huge attack interface on their computers by
installing Java - No go. Until Multibit is provided as a compiled binary
without a Java dependency, it is DOA.
On 1 July 2013 02:39, Gary Rowe <g.rowe at froot.co.uk> wrote:
> I've beefed up the supporting documentation for the website to make it
> more accessible for developers who wish to contribute. It's a Java
> application serving HTML.
>
> It can be found here: https://github.com/jim618/multibit-website
>
>
> On 30 June 2013 16:19, Jim <jim618 at fastmail.co.uk> wrote:
>
>> Yeah "email jim' was never going to work so I have
>> bumped up MultiBit support (a bit) by:
>>
>> + having a dedicated Support page on the website
>> https://multibit.org/support.html
>> It has fixes and support notes for the most common gotchas.
>> + the in-app help also now has a 'Support' section with
>> "Troubleshooting' and the commonest gotchas.
>> I've also written more help to cover as much as possible.
>> + Failing that people are directed first to bitcoin.stackchange.com
>> (I have a notification set up for the 'multibit' keyword.
>> + Then finally users are directed to the github issues to search
>> existing or raise a new issue. Gary and Tim often chip in on there to
>> close
>> issues down as well as me.
>>
>>
>>
>> On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote:
>> > Sounds like we have consensus, Saivann, shall we do it?
>> >
>> > I'm also going to ask Theymos again to relax the newbie restrictions
>> > for the alt client forums. It's probably too hard to get support at
>> > the moment and "email jim" doesn't scale at all.
>> >
>> > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <
>> gavinandresen at gmail.com>
>> > wrote:
>> > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended
>> > > desktop wallet app. I think most users will be happier with it.
>> > >
>> > > If I'm wrong, it is easy to change back.
>> > >
>> > >
>> ------------------------------------------------------------------------------
>> > > This SF.net email is sponsored by Windows:
>> > >
>> > > Build for Windows Store.
>> > >
>> > > http://p.sf.net/sfu/windows-dev2dev
>> > > _______________________________________________
>> > > Bitcoin-development mailing list
>> > > Bitcoin-development at lists.sourceforge.net
>> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>> >
>> ------------------------------------------------------------------------------
>> > This SF.net email is sponsored by Windows:
>> >
>> > Build for Windows Store.
>> >
>> > http://p.sf.net/sfu/windows-dev2dev
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>> --
>> https://multibit.org Money, reinvented
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> 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/20130709/e45170a6/attachment.html>

2023-06-07 17:02:25

- reply

📅 Original date posted:2013-05-25
📝 Original message:Here is the link to the FreeBSD build system 'port' that I am planning to
get committed when 0.8.2 is released. Any comments appreciated.
The Makefile mostly just applies the users request for GIU/QR/UPNP. The
major change is using the external port for leveldb. The files directory
contains 5 patches - 2 that add boost-crypto to LIBS because we still need
that until boost is updated, one that patches the build to use that
external leveldb, and 2 minor fixes that are needed to build. I have got
branches ready for pullreqs on those minor fixes - I'll double check them
and make pullreqs this evening.
Again, any comments very welcome.
The files are available at
https://redports.org/browser/robbak/net-p2p/bitcoin
Thanks,
Robert Backhaus.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130525/deacdb6e/attachment.html>

2023-06-07 17:02:19

- reply

📅 Original date posted:2013-05-21
📝 Original message:Not at all - ACK from me, fwiw. Any attempt at a double spend should be
shouted from the housetops.
What Miners should do with that is still up for debate, it seems. My
opinion is that they should hold on and attempt to confirm the first,
letting it go only if a conflicting transaction is mined elsewhere. (Let
your Yes mean Yes...) But I understand the contrary arguments.
On 21 May 2013 17:04, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, May 20, 2013 at 9:39 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > I'm very much in favor of double-spend propagation across the network.
>
> Absolutely.
>
> (to the list:) Is there anyone who is not? (assuming that it doesn't
> allow arbitrary traffic multiplication, which is easily solved)
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_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/20130521/bf2601af/attachment.html>

2023-06-07 17:02:17

- reply

📅 Original date posted:2013-05-21
📝 Original message:That's good - what I had taken away from the replace-by-fee discussions was
that it was finally decided.
My opinion is that we should be doing what we can to make 0-confs as
reliable as possible - which will always be 'not very', but a solid system
to notify on attempted double-spends is a good start.
I'd like to know how Peter Todd's experiment with the 2BTC reward has gone.
On 21 May 2013 13:27, Mike Hearn <mike at plan99.net> wrote:
> Indeed, that has been proposed but it's a dumb idea and I'm very sceptical
> it will go anywhere. Certainly no decision was made. The arguments for it
> are based on some quite faulty thinking about economics. Double spend
> notifications have been proposed a long time ago, I believe Matt has
> indicated some interest in implementing them and that is the right way to
> go.
> On 20 May 2013 18:57, "Pieter Wuille" <pieter.wuille at gmail.com> wrote:
>
>> On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus <robbak at robbak.com>
>> wrote:
>> > So the decision has been made to make 0-conf double spends trivial, so
>> no
>> > one will ever trust 0-confs. If a later transaction appears with a
>> larger
>> > fee, it will be considered to be the valid one, and the first one
>> dropped,
>> > as long as the first one has not been confirmed. This makes undoing a
>> > mistaken transaction possible.
>>
>> This has been suggested, but I know of no such decision having been made.
>>
>> --
>> Pieter
>>
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt!
>> http://p.sf.net/sfu/newrelic_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/20130521/860b94b0/attachment.html>

2023-06-07 17:02:15

- reply

📅 Original date posted:2013-05-20
📝 Original message:Personally, I agree, but a different decision has been made by the main
devs.
The issue is this: consider two transactions in the unconfirmed pool. One
transaction has 2BTC input, 1.5BTC to one address (the payment), .4995 to
another address (change) and .0005 standard fee. Another transaction
appears - Same input, 1BTC to one address, .999 to another, and .001 fee.
Which one would a miner include? On pure self interest, the second one,
because it has twice the fee. Anyway, the miner has no real way of knowing
which transaction was real, and which the fraudulent double-spend. The
network does not keep accurate timestamps, so it has no way of really
knowing which is first. A bit of artificial DDOS-type overload on the
recipient's system, and the real transaction could easily appear last.
So the decision has been made to make 0-conf double spends trivial, so no
one will ever trust 0-confs. If a later transaction appears with a larger
fee, it will be considered to be the valid one, and the first one dropped,
as long as the first one has not been confirmed. This makes undoing a
mistaken transaction possible.
So anyone needing 0-conf-like speed will have to make other arangements,
such as contracting with enough mining pool power to never drop their
transactions unless confirmed multiple times. Secure 0-confs is an
impossible target with blockchain cyrpto-currencies as the stand. Any ideas
on how to make them work are welcome, of course - as long as we haven't
heard them too many times before.
On 21 May 2013 10:45, Quinn Harris <btcdev at quinnharris.me> wrote:
> The current BitCoin implementation is subject to relatively easy double
> spend attack for 0 confirmation payments. Yet 0 confirmation payments
> are needed for typical in person transactions like most purchases at a
> local business.
>
> Notably, it is easy to transmit two transactions from the same output at
> the same time to different sets of nodes on the network by using two
> instances of bitcoind with same wallet file and a spend on each daemon
> initiated by RPC by some easy to implement code. If the first attempt
> to pay the merchant doesn't go through because they received the "wrong"
> transaction it could be quickly followed up with another initiated spend
> from a different output switching which daemon sends the transaction the
> merchant is expecting. This means an unsophisticated attacker can
> reliably get away with this attack and it would be worth while for small
> transactions. Given this, I would be reluctant to trust 0 confirmation
> transactions at all though I think many do in practice. Someone could
> write and publish a special daemon to execute this attack further
> reducing the cost.
>
> Right now a node will drop any second spend of the same output in the
> memory pool. After the first transaction has propagated through the
> network issuing a second double spend transaction isn't likely to be
> seen by a significant number of miners as most nodes especially non
> miner nodes will drop this transaction. Today, it is necessary to
> transmit both transactions on the network nearly simultaneously to
> reliably get away with this simple attack. If in this case, the
> receiving end is quickly notified of the double spend this attack
> becomes more more difficult to get away with.
>
> If the second transaction is relayed instead of being dropped to notify
> the receiving party of the double spend, most miners will receive both
> transactions and it is possible that some or even many of the miners
> would replace the first transaction with the second if it has a higher
> fee as it would be in their short term interest. This can happen some
> time after the first transaction has propagated through the network so
> the receiving end wouldn't get a timely notification of the double
> spend. Depending on the choices of the miners, this approach to double
> spend notification could exacerbate the very problem it was attempting
> to fix compared to the current implementation. While miners might
> continue to drop the second spends, the easy availability of the second
> spends would increase the short term reward for changing this policy.
>
> This problem can be fixed if instead of sending the second transaction a
> new double spend message is sent with proof of the double spend but not
> the complete transactions. This would allow the receiving end to be
> quickly notified of a double spend while in no way increase the chance
> over the current implementation that a double spend would be successful.
>
> The proof of the double spend would include the scriptSig (input) from
> the original transactions and the hashes from the "simplified"
> transaction used by OP_CHECKSIG of the scriptPubKey (output) but not the
> entire transaction. This is the hash computed by the SignatureHash
> function in script.cpp. The double spend notification message should
> contain proofs of both signed transaction spending the same output
> ordered by hash to produce a canonical proof for a specific two
> transactions. To reduce DOS potential, the proof should not be relayed
> unless one of the original transactions has been received to ensure
> there is some commitment to the block chain and different double spend
> proofs of the same output should not be relayed. The forwarding of
> transactions should remain exactly the same as it is now where the
> second transaction is dropped but a double spend message is transmitted
> if appropriate.
>
> The existing block chain needs to be checked to make sure the proof of
> double spend couldn't have been derived from the block chain and a
> single spend in the memory pool. This could happen if there was already
> an identical transaction in the block chain. This would typically only
> happen if someone was paying someone else the same amount they had
> before and neither side changed addresses. In this case double spend
> detection wouldn't be reliable as it could be generated by anyone, but
> both the sending and receiving client could detect this situation and
> warn the user.
>
> It would still be possible for an attacker to send the second
> transaction directly to powerful miners but this is a distinctly less
> viable attack than the current double spend attack.
>
> I would expect this double spend notification implementation to make
> double spends more costly than they are worth for most cases today that
> 0 confirmation acceptance is needed. That said over time this provision
> might become less effective. As the reward for each block mined
> decreases, transactions fees will become a more significant part of the
> mining reward accordingly increasing the incentive to replace
> transactions with higher fees. Today most BitCoin participants have a
> high expectation of significant future appreciation of BitCoins and
> recognize anything that brings into question the integrity of the system
> is likely to reduce that future value so they have a long term self
> interest to keep up the impression of integrity. As BitCoin becomes
> more establish this incentive will decrease.
>
> On the other hand, non mining nodes have no incentive to replace by
> fee. The continued increased capital costs of mining would likely
> increase the proportion of non mining nodes typically run by those with
> an incentive to assure integrity of the network such as merchants. But
> increasing transaction volume is likely to increase node costs which
> would push out non mining nodes with lower incentive more than mining
> nodes. Accordingly increasing block size would have a tendency to
> reduce the effectiveness of double spend notification. The primary
> point is there are multiple counteracting forces that make predicting
> the future effectiveness of double spend notification uncertain.
>
> I don't believe this necessary warrants conceding that we can not
> provide any protection from non trusted 0 confirmations transaction as a
> replace by fee implementation would do. But it would still be important
> to work towards more robust solutions notably various forms of 3rd party
> trust. This could be tamper resistant devices trusted to not duplicate
> spends, 3rd party certificates with proof the transaction was spent by
> the holder of the certificate or multi signature transactions on the
> block chain that must be signed by a trusted 3rd party to spend. I
> would expect it would take significantly longer for the companies and
> technologies to be built to implement this on a wide scale than adding
> double spend proof messages to the current implementation. In addition,
> there will likely always be some use cases where a 3rd party
> (centralization) is not viable.
>
> Should a BIP and pull request implementing a double spend notification
> as described be accepted?
>
> - Quinn
>
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_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/20130521/65a0710f/attachment.html>

2023-06-07 13:46:15

- reply

📅 Original date posted:2013-04-10
📝 Original message:That sounds workable. I take it that the P2SH address is not stored? I like
it that this denies the possibility of storing data in the block chain, but
does not block interesting uses like creating date stamps - You can still
store the 'fake P2SH' value whose checksum is secured by the blockchain.
On 10 April 2013 12:53, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> (1) Define a new address type, P2SH^2 like P2SH but is instead
> H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is
> a hash of a P2SH address.
>
> (2) Make a relay rule so that to relay a P2SH^2 you must include
> along the inner P2SH address. All nodes can trivially verify it by
> hashing it.
>
> (2a) If we find that miners mine P2SH^2 addresses where the P2SH
> wasn't relayed (e.g. they want the fees) we introduce a block
> discouragement rule where a block is discouraged if you receive it
> without receiving the P2SH^2 pre-images for it.
>
> With this minor change there is _no_ non-prunable location for users
> to cram data into except values. (and the inefficiency of cramming
> data into values is a strong deterrent in any case)
>
> The same thing could also be done for OP_RETURN PUSH value outputs
> used to link transactions to data. Make the data be a hash, outside of
> the txn include the preimage of the hash.
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> 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/20130410/f3916213/attachment.html>

2023-06-07 13:45:04

- reply

📅 Original date posted:2013-04-09
📝 Original message:The obvious problem is that if you can frame it as a valid address, you can
put what you want there. If you can make it pass the validation, miners
have no way of knowing it's not a valid address.
Of course, there is nothing new about this. I ran strings on the blockchain
and found all sorts of ascii rubbish right from the beginning.
On 9 April 2013 21:17, Jay F <jayf at outlook.com> wrote:
> On 4/9/2013 4:09 AM, Peter Todd wrote:
> > On Tue, Apr 09, 2013 at 12:42:12PM +0200, Mike Hearn wrote:
> >> hack by changing the protocol. Nodes can serve up blocks encrypted
> under a
> >> random key. You only get the key when you finish the download. A
> blacklist
> > NAK
> >
> > Makes bringing up a new node dependent on other nodes having consistent
> > uptimes, particularly if you are on a low-bandwidth connection.
> >
> >> can apply to Bloom filtering such that transactions which are known to
> be
> >> "abusive" require you to fully download the block rather than select the
> >> transactions with a filter. This means that people can still access the
> > NAK
> >
> > No blacklists
> >
> It depends on how clever the spammers get encoding stuff. If law
> enforcement forensic tools can pull a jpeg header + child porn out of
> the blockchain, then there's a problem that needs mitigation.
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> 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/20130409/81a373d3/attachment.html>

2023-06-07 13:31:54

- reply

📅 Original date posted:2013-02-09
📝 Original message:I have done test builds on FreeBSD.
Clean builds using gcc and clang, building both the qt gui and the command
line daemon, and the tests run clean as well. The qt gui runs, and cleanly
reindexed and caught up. I have no problems to report.
I am not doing any adjustments apart from applying the needed changes to
the include directory statements.
On 9 February 2013 16:10, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>
> On 9 Feb 2013 00:50, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> > Then before final release (or rc2, if that is needed) pull #2286 and
> > create and pull a patch to fix the windows non-determinism problem.
>
> #2243 should fix that, I think.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> 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/20130209/bd8aa490/attachment.html>

2023-06-07 12:46:27

- reply

📅 Original date posted:2012-12-05
📝 Original message:On 5 December 2012 19:43, Gary Rowe <g.rowe at froot.co.uk> wrote:
> I would like to chime on on the user experience of the SPV client (in
> particular MultiBit).
>
> Without exception, everyone that I have introduced Bitcoin (which is a lot
> of people) have expected an "instant-on" experience. It has to clobber
> PayPal and credit cards or people won't give it a second look, let alone a
> second chance. SPV clients deliver on that expectation.
>
> Once the user has the great initial "wow!" moment then their interest in
> Bitcoin is reinforced and they tend to explore further, particularly into
> the economic theory behind it. Many decide to install the full node out of
> a sense of community contribution to the security of the network.
>
> Having a hybrid mode of SPV first then full node second should be
> something that a user has control over - it is their computing resources we
> are using after all and Bitcoin should not be perceived as a drain.
Hybrid SPV sounds like a good idea to me. Allows it to work out-of-the-box,
then slowly gets up-to-speed with the full network - working low priority,
or even not at all, if it detects a slow system or network link.
Another idea is always distributing the client with a checkpoint that is
only days old, then starting by pulling in more recent blocks, so it can
transact. Following that, it will pull in progressively older blocks as
time permits.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121205/c358248c/attachment.html>