Addy Yeow [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-05-06 to 2014-07-30
💬 Posted a total of 9 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:24:37

- reply

📅 Original date posted:2014-07-30
📝 Original message:I believe the requests Jeff is seeing came from my crawler although anyone
could be running it (https://github.com/ayeowch/bitnodes) since there is no
IP address in the log to confirm the source of the requests.
This is a sample log of an actual request from my crawler at 148.251.238.178
:
*2014-07-30 22:43:54 receive version message: /getaddr.bitnodes.io:0.1/:
version 70001, blocks=313244, us=X.X.X.X:8333, them=0.0.0.0:0
<http://0.0.0.0:0>, peer=148.251.238.178:47635*
Currently, the crawler takes a full snapshot of the network of reachable
nodes as soon as it is done with previous snapshot. I want to be able to
diff between the snapshots to get the join and leave nodes periodically.
Each full snapshot is taken on average between 3 to 4 minutes hence the
requests that you see from the crawler every 3 to 4 minutes.
I have a task in my schedule (
https://github.com/ayeowch/bitnodes/wiki/Schedule#crawlpypingpy) to improve
upon this method by skipping a new connection with currently reachable
nodes while still being able to perform the diff.
On Wed, Jul 30, 2014 at 11:22 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Seeing this on one of my public nodes:
> 2014-07-30 13:13:26 receive version message:
> /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169,
> us=162.219.2.72:8333, peer=11847
> 2014-07-30 13:13:33 receive version message:
> /getaddr.bitnodes.io:0.1/: version 70001, blocks=290000,
> us=162.219.2.72:8333, peer=11848
> 2014-07-30 13:14:21 receive version message:
> /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169,
> us=162.219.2.72:8333, peer=11849
>
> That is abusive, taking up public slots. There is no reason to
> connect so rapidly to the same node.
>
> Other seeders are also rapidly reconnect'ers, though the time window
> is slightly more wide:
> 2014-07-30 13:09:35 receive version message: /bitcoinseeder:0.01/:
> version 60000, blocks=230000, us=162.219.2.72:8333, peer=11843
> 2014-07-30 13:12:42 receive version message: /bitcoinseeder:0.01/:
> version 60000, blocks=230000, us=162.219.2.72:8333, peer=11846
>
> The version message helpfully tells me my own IP address but not theirs ;p
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140731/aed03683/attachment.html>

2023-06-07 15:16:11

- reply

📅 Original date posted:2014-03-26
📝 Original message:Hi Mike,
That was because I had to restart the crawler for update. This disconnects
the crawler from all reachable nodes temporarily and it will take about 15
minutes (3 snapshots) before the crawler stabilize again. I will look into
annotating these drops with a note.
Cheers,
Addy
On Thu, Mar 27, 2014 at 12:07 AM, Mike Hearn <mike at plan99.net> wrote:
> Hey Addy,
>
> I am seeing a big drop in reachable nodes on
> http://getaddr.bitnodes.io/dashboard/ starting from about March 25th
> 7:20pm and coming back 9:35pm. Is this a glitch in the monitoring system or
> did some real network event happen then?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/77d802c0/attachment.html>

2023-06-07 15:09:51

- reply

📅 Original date posted:2013-11-22
📝 Original message:Hi Mike,
I am glad you are still following up with Bitnodes. The recent spike in
nodes count should probably be taken with a grain of salt; run #231 (
http://getaddr.bitnodes.io/231/) does appear artificial to me, i.e.
potentially bogus nodes being added. I am still working on a more in depth
analysis on the data.
There are quite some TODOs for the project at the moment for the next
couple of months. I have included propagation data as well into the list.
Cheers,
Addy
On Fri, Nov 22, 2013 at 1:47 AM, Mike Hearn <mike at plan99.net> wrote:
> Thanks. By the way, your bitnodes site is excellent. Thanks for doing
> that. If you're in the mood for extending it, it'd be great to gather and
> chart data on block and tx propagation times.
>
> Do you think the recent explosion in running nodes is real, or due to some
> kind of custom experimental thing?
>
>
> On Thu, Nov 21, 2013 at 2:55 PM, Addy Yeow <ayeowch at gmail.com> wrote:
>
>> Try https://bitcointalk.org/index.php?action=profile;u=19897?
>>
>>
>>
>>
>> On Fri, Nov 22, 2013 at 12:48 AM, Mike Hearn <mike at plan99.net> wrote:
>>
>>> I added some additional logging to my node and ran it for a few days.
>>> There's a pull req open for my extra logging, it is quite trivial. Here's
>>> what it looks like:
>>>
>>> 2013-11-21 13:41:04 AcceptToMemoryPool: 5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>>> 2d1bbcc2bf64dfcb57a2f0180b2607a48a34de4422c446929b26b190083bbfe7 (poolsz
>>> 2087)
>>> 2013-11-21 13:41:05 AcceptToMemoryPool: 198.12.127.2:29057/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>>> 28bb94978bdaa224faeafa95d03a0c4f5743396d6f592469c5ac2b64184ac716 (poolsz
>>> 2088)
>>> 2013-11-21 13:41:06 ERROR: AcceptToMemoryPool : nonstandard transaction:
>>> dust
>>> 2013-11-21 13:41:06
>>> 42323d9553e4c592d27765dc3ef9152c186cb7d67b08d783d72974a56085032d from
>>> 82.68.68.254:39232 /Satoshi:0.8.1/ was not accepted into the memory
>>> pool: dust
>>> 2013-11-21 13:41:06 AcceptToMemoryPool: 198.12.127.2:29057/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>>> 2fdb19e5e87d518b7b6bb7371d547a5f60c2bb056ba4522190460f0bc41b51fb (poolsz
>>> 2089)
>>> 2013-11-21 13:41:08 AcceptToMemoryPool: 5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>>> 52c8ed6a48f89d48b1152b67ac0b718a7aadb5f9a0c70c18b9b2fed058ca3323 (poolsz
>>> 2090)
>>> 2013-11-21 13:41:08 AcceptToMemoryPool: 198.12.127.2:29057/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>>> 980bbdbd4a6b365fa6f13fb5247eb6cb1e54847e490c3b7c3026d1548fb9efc6 (poolsz
>>> 2091)
>>> 2013-11-21 13:41:08 AcceptToMemoryPool: 64.120.253.194:60896/Satoshi:0.8.99/Gangnam Style:2.0/ : accepted
>>> 03f79c611bbdc1afa7afa67eb0bbd4d8bc86a730a7066622e2709ae506e61e0f (poolsz
>>> 2092)
>>> 2013-11-21 13:41:10 AcceptToMemoryPool: 5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>>> af8096ad637af1ca022a5146e07cf1fc6bfbec877935f9e114b279fcfe26c06d (poolsz
>>> 2093)
>>> 2013-11-21 13:41:10 AcceptToMemoryPool: 5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>>> 751c2415d058d45ca602fdf1b6490edb6e57fc718e914d628c11b17e25aac834 (poolsz
>>> 2094)
>>>
>>>
>>>
>>> Despite that I have 87 connections from regular nodes, virtually all
>>> transactions seen by my node are being announced by this modified software,
>>> which appears to run on several different machines.
>>>
>>> I am wondering if anyone out there knows/owns these nodes and if they
>>> are relaying transactions without checking their validity. That seems the
>>> most likely reason for how they are always able to win the race to be the
>>> first to announce to my node.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Shape the Mobile Experience: Free Subscription
>>> Software experts and developers: Be at the forefront of tech innovation.
>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>> now.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> 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/20131122/b7408390/attachment.html>

2023-06-07 15:09:51

- reply

📅 Original date posted:2013-11-21
📝 Original message:Try https://bitcointalk.org/index.php?action=profile;u=19897?
On Fri, Nov 22, 2013 at 12:48 AM, Mike Hearn <mike at plan99.net> wrote:
> I added some additional logging to my node and ran it for a few days.
> There's a pull req open for my extra logging, it is quite trivial. Here's
> what it looks like:
>
> 2013-11-21 13:41:04 AcceptToMemoryPool: 5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
> 2d1bbcc2bf64dfcb57a2f0180b2607a48a34de4422c446929b26b190083bbfe7 (poolsz
> 2087)
> 2013-11-21 13:41:05 AcceptToMemoryPool: 198.12.127.2:29057/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
> 28bb94978bdaa224faeafa95d03a0c4f5743396d6f592469c5ac2b64184ac716 (poolsz
> 2088)
> 2013-11-21 13:41:06 ERROR: AcceptToMemoryPool : nonstandard transaction:
> dust
> 2013-11-21 13:41:06
> 42323d9553e4c592d27765dc3ef9152c186cb7d67b08d783d72974a56085032d from
> 82.68.68.254:39232 /Satoshi:0.8.1/ was not accepted into the memory pool:
> dust
> 2013-11-21 13:41:06 AcceptToMemoryPool: 198.12.127.2:29057/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
> 2fdb19e5e87d518b7b6bb7371d547a5f60c2bb056ba4522190460f0bc41b51fb (poolsz
> 2089)
> 2013-11-21 13:41:08 AcceptToMemoryPool: 5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
> 52c8ed6a48f89d48b1152b67ac0b718a7aadb5f9a0c70c18b9b2fed058ca3323 (poolsz
> 2090)
> 2013-11-21 13:41:08 AcceptToMemoryPool: 198.12.127.2:29057/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
> 980bbdbd4a6b365fa6f13fb5247eb6cb1e54847e490c3b7c3026d1548fb9efc6 (poolsz
> 2091)
> 2013-11-21 13:41:08 AcceptToMemoryPool: 64.120.253.194:60896/Satoshi:0.8.99/Gangnam Style:2.0/ : accepted
> 03f79c611bbdc1afa7afa67eb0bbd4d8bc86a730a7066622e2709ae506e61e0f (poolsz
> 2092)
> 2013-11-21 13:41:10 AcceptToMemoryPool: 5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
> af8096ad637af1ca022a5146e07cf1fc6bfbec877935f9e114b279fcfe26c06d (poolsz
> 2093)
> 2013-11-21 13:41:10 AcceptToMemoryPool: 5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
> 751c2415d058d45ca602fdf1b6490edb6e57fc718e914d628c11b17e25aac834 (poolsz
> 2094)
>
>
>
> Despite that I have 87 connections from regular nodes, virtually all
> transactions seen by my node are being announced by this modified software,
> which appears to run on several different machines.
>
> I am wondering if anyone out there knows/owns these nodes and if they are
> relaying transactions without checking their validity. That seems the most
> likely reason for how they are always able to win the race to be the first
> to announce to my node.
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20131122/73033547/attachment.html>

2023-06-07 15:03:44

- reply

📅 Original date posted:2013-06-20
📝 Original message:I personally don't treat the relay field as optional, i.e. it is there as
0x01 if it is set. Otherwise, it is simply a trailing zero byte. Hence, the
right way of reading the packet as with any network packet is to first
retrieve the header information, get the actual payload length, then parse
the payload accordingly. I can also choose to include 0x00 for my relay
field in my outgoing packet and reflect that accordingly in my length field
in the header.
On Thu, Jun 20, 2013 at 4:20 PM, Turkey Breast <turkeybreast at yahoo.com>wrote:
> I never said that Bitcoin message field lengths should always be the same.
> But before this change they certainly were constant per protocol version.
> All I'm saying is that optional lengths shouldn't be used (a field exists
> or not) and for every field change, the protocol version should be upgraded.
>
> Now that fRelayTxes is part of the protocol, the version number should be
> upgraded to reflect this fact.
>
> ------------------------------
> *From:* Mike Hearn <mike at plan99.net>
> *To:* Paul Lyon <pmlyon at hotmail.ca>
> *Cc:* Turkey Breast <turkeybreast at yahoo.com>; "
> bitcoin-development at lists.sourceforge.net" <
> bitcoin-development at lists.sourceforge.net>
> *Sent:* Wednesday, June 19, 2013 3:20 PM
> *Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
>
> If you want to criticise the Bitcoin protocol for sloppyness, the variable
> length of some messages isn't where I'd start.
>
> Note that ping has the same issue, its length has changed over time to
> include the nonce.
>
> If your parser can't handle that kind of thing, you need to fix it. The
> protocol has always worked that way.
>
>
>
> On Wed, Jun 19, 2013 at 3:03 PM, Paul Lyon <pmlyon at hotmail.ca> wrote:
>
> I’m also running into this exact same issue with my parser, now I
> understand why the relay field behavior I was seeing doesn’t match the wiki.
>
> So to parse a version message, you can’t rely on the protocol version? You
> have to know how long the payload is, and then parse the message
> accordingly? I agree with Turkey Breast, this seems a bit sloppy to me.
>
> Paul
>
> P.S. I’ve never used a dev mailing list before and I want to get involved
> with the Bitcoin dev community, so let me know if I’m horribly violating
> any mailing list etiquette. 😊
>
> *From:* Mike Hearn
> *Sent:* ‎Wednesday‎, ‎June‎ ‎19‎, ‎2013 ‎7‎:‎43‎ ‎AM
> *To:* Turkey Breast
> *Cc:* bitcoin-development at lists.sourceforge.net
>
> Bitcoin-Qt on master does send it now although it doesn't affect anything,
> but as old pre-filtering versions will continue to exist, you'll always
> have to be able to deserialize version messages without it.
>
> Bitcoin version messages have always had variable length, look at how the
> code is written in main.cpp. If you didn't experience issues until now all
> it means is that no sufficiently old nodes were talking to yours.
>
> The standard does not say it should appear. Read it again - BIP 37 says
> about the new version message field:
> If false then broadcast transactions will not be announced until a
> filter{load,add,clear} command is received. *If missing or true*, no
> change in protocol behaviour occurs.
>
>
> On Wed, Jun 19, 2013 at 12:33 PM, Turkey Breast <turkeybreast at yahoo.com>wrote:
>
> It's a problem if you work with iterators to deserialize the byte stream.
> Even failing that, it's just sloppy programming. What happens in the future
> when new fields are added to the version message? It's not a big deal to
> say that this protocol version has X number of fields, that (higher)
> protocol version message has X + N number of fields. Deterministic number
> of fields per protocol version is sensical and how Bitcoin has been for a
> long time.
>
> And yes, it was a problem for me that caused a lot of confusion why this
> byte didn't exist in many version messages despite the standard saying it
> should and the code in bitcoind indicating it should. Nowhere was this
> written. It doesn't help other implementations to have an unclear behaviour
> that depends on some magic from one implementation.
>
> ------------------------------
> *From:* Mike Hearn <mike at plan99.net>
> *To:* Turkey Breast <turkeybreast at yahoo.com>
> *Cc:* "bitcoin-development at lists.sourceforge.net" <
> bitcoin-development at lists.sourceforge.net>
> *Sent:* Wednesday, June 19, 2013 11:39 AM
>
> *Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
>
> It has to be optional because old clients don't send it, obviously.
>
> Why is this even an issue? There's no problem with variable length
> messages in any codebase that I'm aware of. Is this solving some actual
> problem?
>
>
> On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast <turkeybreast at yahoo.com>wrote:
>
> That's me. I never said to make all messages fixed length. I said to make
> a fixed number of fields per protocol. So given a protocol version number,
> you know the number of fields in a message. This is not only easier for
> parsing messages, but just good practice. I don't see why a 1 byte flag
> needs to be optional anyway.
>
> ------------------------------
> *From:* Mike Hearn <mike at plan99.net>
> *To:* Turkey Breast <turkeybreast at yahoo.com>
> *Cc:* Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> *Sent:* Tuesday, June 18, 2013 9:48 PM
> *Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
>
> It's not a bug (although there was recently a change to make bitcoind/qt
> always send this field anyway).
>
> I don't know where Amir is going with BIP 60. Version messages have always
> been variable length. There's nothing inherent in the Bitcoin protocol that
> says all messages are fixed length, indeed, tx messages are allowed to have
> arbitrary data appended after them that gets relayed.
>
>
> On Tue, Jun 18, 2013 at 7:45 PM, Turkey Breast <turkeybreast at yahoo.com>wrote:
>
> See this BIP. I'm not sure if this is a bug or what, but it would be good
> if messages always had a fixed number of fields per protocol version.
>
> https://en.bitcoin.it/wiki/BIP_0060#Code_Updates
>
> This BIP details everything that needs to be done and proposes a protocol
> upgrade.
>
>
> ------------------------------------------------------------------------------
> This SF.net <http://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
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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/20130620/0683b160/attachment.html>

2023-06-07 15:02:04

- reply

📅 Original date posted:2013-05-16
📝 Original message:Is the number representing the count for the client nodes?
I was curious of the count myself earlier this week and started to
traverse down the network using getaddr message starting from seed
nodes and found upward to 57k nodes running protocol >= 70001 with
timestamp no older than 24 hours.
On Thu, May 16, 2013 at 8:48 PM, <bitcoingrant at gmx.com> wrote:
> our estimates: ~8000
>
>
>
> ----- Original Message -----
>
> From: Addy Yeow
>
> Sent: 05/16/13 06:27 AM
>
> To: bitcoingrant at gmx.com
>
> Subject: Re: [Bitcoin-development] Modularizing Bitcoin
>
>
>
>> Such developments would significantly strengthen the system.
>> Modularization would make cancer attacks less likely and increase the node
>> count, which, currently, is fairly low.
>
> Do we know for certain or at least a rough figure of the node count in
> the network?
>

2023-06-07 15:02:02

- reply

📅 Original date posted:2013-05-16
📝 Original message:> Such developments would significantly strengthen the system. Modularization would make cancer attacks less likely and increase the node count, which, currently, is fairly low.
Do we know for certain or at least a rough figure of the node count in
the network?
On Thu, May 16, 2013 at 8:02 PM, <bitcoingrant at gmx.com> wrote:
> One of the primary upcoming priorities for bitcoin’s infrastructure, beyond
> the bloom filter, will be the continued modularization of the system.
>
> Here at the Bitcoin Grant, we would like to jump start this development with
> a financial incentive and initiate an ongoing conversation on how we can
> work together towards developing a smarter, more efficient system of
> tomorrow, today.
>
> Up for grabs: 500 bitcoins or $500,000; whichever is greater.
>
> Taking on a project of this scope is a highly intensive, technical
> undertaking and we believe excellent developers should be compensated as
> such, especially when it comes to open source projects.
>
> One of the main goals will be to separate the wallet from the node, as we
> have already done with mining. This way, the wallet, which will only hold
> private keys and create transactions, would pass transactions directly to a
> relay node, based on the bloom filter. Meanwhile, the block node will
> maintain the block chain and validate and relay new blocks.
>
> Such developments would significantly strengthen the system. Modularization
> would make cancer attacks less likely and increase the node count, which,
> currently, is fairly low.
>
> This is by no means is a feature request, merely ideas as to initiate a
> discussion. We welcome any feedback or suggestions. And of course, let us
> know if you would like to contribute to this project by submiting a grant
> proposal.
>
> http://bitcoingrant.org
>
>
>
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:01:31

- reply

📅 Original date posted:2013-05-08
📝 Original message:Hi list,
Can someone explain why do we have 32-bit and 64-bit timestamp fields
instead of all being 64-bit?
https://en.bitcoin.it/wiki/Protocol_specification
Cheers,
Addy

2023-06-07 15:01:15

- reply

📅 Original date posted:2013-05-06
📝 Original message:>From https://en.bitcoin.it/wiki/Protocol_specification#version, is the
relay field (bool/1 byte) required in all version packets coming from
client with protocol version >= 70001?

2023-06-07 14:56:43

- reply

2023-06-07 14:56:24

- reply