mbde at bitwatch.co [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 18:09:12

- reply

📅 Original date posted:2018-01-04
📝 Original message:Hi guys,
there are several ways to embed arbitrary data into the blockchain, and
this is used by several meta-protocols. Most protocols at this point use
OP_RETURN scripts for this.
To disincentivize the use of other and more harmful methods to embed
data into the chain, in particular via P2SH, I propose to raise the
default datacarriersize to 220 byte, so it becomes the "cheapest" way of
embedding data into the chain.
The following graph shows the relation between transaction sizes and
payload sizes: http://i.imgur.com/VAGZWBK.png
Embedding data with bare-multisig and P2SH can be cheaper in terms of
effective transaction size, compared to OP_RETURN with a payload limit
of 80 byte. Both methods of embedding data, via bare-multisig and P2SH,
were heavily used by the major two meta-protocols on top of Bitcoin:
Omni and Counterparty, but both protocols started to use OP_RETRUN data
embedding a long time ago.
However, currently token sends are usually done one by one, each with a
single transaction, and this is a heavy burden for the whole network,
e.g. when an exchange sends out withdrawals.
We have solutions for "multi-sends with multi-inputs" and also
considered moving destinations into the payload for token sends, but we
need more space, otherwise this solution is limited to very few recipients.
I therefore propose to raise the default datacarriersize to 220 byte or
higher and I'd be happy to provide a pull request doing so, if this gets
positive feedback.
- dexx

2023-06-07 18:09:12

- reply

📅 Original date posted:2018-01-04
📝 Original message:To add some information about the relevance of this:
During December 2017 there were roughly 210.000 Omni Layer transactions,
with more than 12.000 transactions on peak days, and the numbers are
growing.
I assume there is a similar number of Counterparty transactions, which
most likely benefit from additional payload space, too.
mbde--- via bitcoin-dev wrote:
> Hi guys,
>
> there are several ways to embed arbitrary data into the blockchain, and
> this is used by several meta-protocols. Most protocols at this point use
> OP_RETURN scripts for this.
>
> To disincentivize the use of other and more harmful methods to embed
> data into the chain, in particular via P2SH, I propose to raise the
> default datacarriersize to 220 byte, so it becomes the "cheapest" way of
> embedding data into the chain.
>
> The following graph shows the relation between transaction sizes and
> payload sizes: http://i.imgur.com/VAGZWBK.png
>
> Embedding data with bare-multisig and P2SH can be cheaper in terms of
> effective transaction size, compared to OP_RETURN with a payload limit
> of 80 byte. Both methods of embedding data, via bare-multisig and P2SH,
> were heavily used by the major two meta-protocols on top of Bitcoin:
> Omni and Counterparty, but both protocols started to use OP_RETRUN data
> embedding a long time ago.
>
> However, currently token sends are usually done one by one, each with a
> single transaction, and this is a heavy burden for the whole network,
> e.g. when an exchange sends out withdrawals.
>
> We have solutions for "multi-sends with multi-inputs" and also
> considered moving destinations into the payload for token sends, but we
> need more space, otherwise this solution is limited to very few recipients.
>
> I therefore propose to raise the default datacarriersize to 220 byte or
> higher and I'd be happy to provide a pull request doing so, if this gets
> positive feedback.
>
> - dexx
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:29:16

- reply

📅 Original date posted:2015-02-01
📝 Original message:> This video demonstrates how HSBC uses a security token to verify
transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE.
Since it's not very widely used outside of Austria and Germany, this may
be interesting for some: there is a second factor scheme called
"cardTAN" or "chipTAN" where authentication codes are generated on a
device which is not specifically linked to an accout. When
authenticating an online banking transaction the process is as follows:
http://i.imgur.com/eWsffsp.jpg
1. Insert bank card into TAN generator
2. Scan flickering code on screen with the device's photodetector
3. Confirm amount to transfer and recipient on the generator
4. Finalize online banking transaction by entering a challenge-response
generated by the device
https://www.youtube.com/watch?v=5gyBC9irTsM&t=22s
http://en.wikipedia.org/wiki/Transaction_authentication_number#chipTAN_.2F_cardTAN
-------- Original Message --------
*Subject: *[Bitcoin-development] Proposal to address Bitcoin malware
*From: *Brian Erdelyi <brian.erdelyi at gmail.com>
*To: *bitcoin-development at lists.sourceforge.net
*Date: *Sat, 31 Jan 2015 18:15:53 -0400
> Hello all,
>
> The number of incidents involving malware targeting bitcoin users
> continues to rise. One category of virus I find particularly nasty is
> when the bitcoin address you are trying to send money to is modified
> before the transaction is signed and recorded in the block chain.
> This behaviour allows the malware to evade two-factor authentication
> by becoming active only when the bitcoin address is entered. This is
> very similar to how man-in-the-browser malware attack online banking
> websites.
>
> Out of band transaction verification/signing is one method used with
> online banking to help protect against this. This can be done in a
> variety of ways with SMS, voice, mobile app or even security tokens.
> This video demonstrates how HSBC uses a security token to verify
> transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE.
>
> Many Bitcoin wallets and services already use Open Authentication
> (OATH) based one-time passwords (OTP). Is there any interest (or
> existing work) in in the Bitcoin community adopting the OATH
> Challenge-Response Algorithm (OCRA) for verifying transactions?
>
> I know there are other forms of malware, however, I want to get
> thoughts on this approach as it would involve the use of a decimal
> representation of the bitcoin address (depending on particular
> application). In the HSBC example (see YouTube video above), this was
> the last 8 digits of the recipient’s account number. Would it make
> sense to convert a bitcoin address to decimal and then truncate to 8
> digits for this purpose? I understand that truncating the number in
> some way only increases the likelihood for collisions… however, would
> this still be practical or could the malware generate a rogue bitcoin
> address that would produce the same 8 digits of the legitimate bitcoin
> address?
>
> Brian Erdelyi
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:29:16

- reply

2023-06-07 15:26:39

- reply

📅 Original date posted:2014-10-20
📝 Original message:This is just a guess, but I can imagine sipa's address index branch
might be more suitable for an use case where information about any
address is required - jmcorgan continued to maintain a usually somewhat
up-to-date version:
https://github.com/jmcorgan/bitcoin/tree/addrindex
As for balance queries, that's not possible out of the box and I have my
own branch for this with a few other RPC calls that are noted in the README:
https://github.com/dexX7/bitcoin/tree/master-addrindex-extended
When using the original, you need to ensure a transaction is part of the
main chain and wasn't orphaned. If you consider using my branch, please
consider it twice and review the changes first.
-------- Original Message --------
*Subject: *Re: [Bitcoin-development] About watch-only addresses
*From: *Warren Togami Jr. <wtogami at gmail.com>
*To: *Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
*Date: *Mon, 20 Oct 2014 12:37:40 -1000
> https://bitcointalk.org/index.php?topic=320695
> I made a branch of Bitcoin 0.9.3 plus backports including watch-only
> and a huge pile of patches cleaning it up from the master branch. It
> seems to work fine although it is not heavily tested. I suppose if
> you use ONLY for watch-only it can't be harmful? Dunno.
>
> Warren
>
> On Sat, Oct 18, 2014 at 12:13 AM, Wladimir <laanwj at gmail.com
> <mailto:laanwj at gmail.com>> wrote:
>
> On Fri, Oct 17, 2014 at 10:36 PM, Flavien Charlon
> <flavien.charlon at coinprism.com
> <mailto:flavien.charlon at coinprism.com>> wrote:
> > Hi,
> >
> > What is the status of watch-only addresses in Bitcoin Core? Is
> it merged in
> > master and usable? Is there documentation on how to add a
> watch-only address
> > through RPC.
>
> It has been merged. There is the "importaddress" RPC call, which works
> the same as "importprivkey" except that you a pass it an address.
>
> > Also, I believe that is going towards the 0.10 release, is there
> a rough ETA
> > for a release candidate?
>
> Yes - aim is in a few months, probably by the end of the year.
>
> AFAIK there are no nightly builds at this moment. Warren Togami was
> building them for a while (at http://nightly.bitcoin.it/) but he
> stopped some time around June.
>
> It's not recommended to use master without at least a little bit of
> development/debugging experience of yourself (to trace down problems
> when they appear), so it's best to build it yourself if you're going
> to test day-to-day development versions.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push
> notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
> _______________________________________________
> 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/20141021/135f5891/attachment.html>

2023-06-07 15:25:09

- reply

📅 Original date posted:2014-08-10
📝 Original message:Hello all,
I'm currently synchronizing a new node and right now, at a progress of a
height of 197'324 blocks, I count in my debug.log an aweful amount of
38'447 orphaned blocks which is about 19.5 %.
It has been I while since I watched the synchronization process closely,
but this number seems pretty high to me.
I'm wondering about the following: would it be possible for a malicious
party to generate chains of blocks with low difficulity which are not
part of the main chain to slow down the sync process?
Build and version information:
https://github.com/jmcorgan/bitcoin/tree/026686c7de76dfde6fcacfc3d667fb3418a946a7
(sipa/jmcorgan address index)
Rebased with:
https://github.com/bitcoin/bitcoin/tree/94e1b9e05b96e4fe639e5b07b7a53ea216170962
(almost up-to-date mainline)
Compressed debug.log attached:
https://www.dropbox.com/s/uvtd91xiwmdmun7/debug.7z?m=
(filesize: 7.67 MB, uncompressed: 41.3 MB)

2023-06-07 15:24:29

- reply

📅 Original date posted:2014-07-27
📝 Original message:These website list Tor nodes by bandwidth:
http://torstatus.blutmagie.de/index.php
https://torstatus.rueckgr.at/index.php?SR=Bandwidth&SO=Desc
And the details reveal it's a port 8333 only exit node:
http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124
blockchain.info has some records about the related IP going back to the
end of this May:
https://blockchain.info/ip-address/5.9.93.101?offset=300
-------- Original Message --------
Subject: Re: [Bitcoin-development] Abnormally Large Tor node accepting
only Bitcoin traffic
From: Michael Wozniak <mw at osfda.org>
To: Gregory Maxwell <gmaxwell at gmail.com>
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>, alex at stamos.org
Date: Sun, 27 Jul 2014 22:49:11 -0400
> It’s in my logs:
>
> 2014-07-28 02:00:24 receive version message: /Satoshi:0.9.2/: version 70002, blocks=302684, us=******:8333, them=0.0.0.0:0, peer=5.9.93.101:33928
>
>
> On Jul 27, 2014, at 10:45 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
>> On Sun, Jul 27, 2014 at 7:40 PM, Peter Todd <pete at petertodd.org> wrote:
>>> Anyway, just goes to show that we need to implement better incoming
>>> connection limiting. gmaxwell has a good scheme with interactive
>>> proof-of-memory - where's your latest writeup?
>>
>> Or its a complete snipe hunt, I'm unable to find any nodes with it
>> connected to them. Does anyone here have any?
>>
>> Last discussion on the measures for anti-global-resource-consumption
>> was at https://bitcointalk.org/index.php?topic=310323.0 but it hasn't
>> seemed to be a huge issue such that adding more protocol surface area
>> was justified.
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>