Transaction

a8b019eebb9c7effb84e3cea8a2b2c2614fb470e86f209f233cb72a2e287aa95
Timestamp (utc)
2024-04-02 16:56:22
Fee Paid
0.00000035 BSV
(
0.01132515 BSV
-
0.01132480 BSV
)
Fee Rate
10.08 sat/KB
Version
1
Confirmations
95,560
Size Stats
3,471 B

2 Outputs

Total Output:
0.01132480 BSV
  • j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM’ <div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=632.msg6650#msg6650">Quote from: RHorning on July 30, 2010, 02:13:27 PM</a></div><div class="quote"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=632.msg6636#msg6636">Quote from: martin on July 30, 2010, 11:37:59 AM</a></div><div class="quote">The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is half the size of the hand built layout!</div><br/>I realize that you are evangelizing for protocol buffers (and you seem to be doing a very good job of it too, I might add), but I will challenge that hand built data layouts are always bad.<br/><br/>Still, I hope this does give some food for thought and on a practical basis any improvement in the network protocol that shaves off a few bytes is always better.&nbsp; This doesn't seem to sacrifice too much in terms of the overhead either.&nbsp; More significantly, you are calling attention to an area of efficiency that needs to be addressed and is very helpful to the project.&nbsp; Thank you for doing that.&nbsp; I'm hoping to get caught up to where you are at now on this protocol business.<br/></div><br/>They're not always bad. However, if you put in so much effort that your hand built packet was smaller than a protocol buffer then you're probably putting too much effort into a micro optimisation <img alt="Wink" border="0" src="/static/img/emoticons/wink.gif"/><br/><br/>I'll be happy to help anyone catch up with the protocol buffers. If someone is willing to work with me I'd even work on a patch, I have very little C++ experience so I can't do it alone unfortunately.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=632.msg6656#msg6656">Quote from: gavinandresen on July 30, 2010, 02:28:23 PM</a></div><div class="quote">I think using protocol buffers as the serialization format is a good idea, but I don't think just switching to protocol buffers "buys" enough to be worth the effort (at least not now, when transaction volume is low).</div><br/>I would disagree, protocol buffers are smaller which is nice, but it's not their main advantage - they're forwards compatible which is a hugely important thing in a p2p network, they're also something which can easily be used in many languages, which make implementing new clients in new languages easier, which in my opinion is vital for bitcoin.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=632.msg6664#msg6664">Quote from: jgarzik on July 30, 2010, 03:47:33 PM</a></div><div class="quote">FYI, it is pointless to make a packet smaller than 60 bytes -- the minimum size of an Ethernet packet.&nbsp; Packets are padded up to 60 bytes, if they are smaller.<br/></div><br/>Indeed, but the version packet is probably the smallest packet of all the ones sent, so we'll gain more elsewhere. Also, keep an eye on the main point. The fact that protocol buffers are smaller is a nice aside to the fact that they're Forwards compatible and make bitcoin portable between languages.</div> text/html
    https://whatsonchain.com/tx/a8b019eebb9c7effb84e3cea8a2b2c2614fb470e86f209f233cb72a2e287aa95