Chris Double [ARCHIVE] / is on Nostr

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

- reply

📅 Original date posted:2013-09-30
📝 Original message:slush <slush at centrum.cz> writes:
> I observed this problem with version 0.8.2, but it is still happening with
> 0.8.5.
I see this as well with 0.8.2+. I don't see it on 0.8.1. I originally
hit the '4 keep alive thread limit' where four clients on the same
bitcoind would result in other clients not being able to connect. I
resolved that and still hit the RPC hanging issue. The most problem I've
had is using 'getwork' which I believe is going the wayside anyway.

2023-06-07 15:05:43

- reply

📅 Original date posted:2013-08-13
📝 Original message:On Sat, Aug 10, 2013 at 12:14 AM, Mike Hearn <mike at plan99.net> wrote:
> Oh, I forgot to make it clear - Chrome apps/extensions can make raw TCP
> socket connections:
>
> http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html
There's a Raw Sockets proposal at the W3C that provides TCP sockets:
<http://www.w3.org/2012/sysapps/raw-sockets/>
Firefox OS has an API that is being discussed as part of that:
<https://developer.mozilla.org/en-US/docs/WebAPI/TCP_Socket>
So there's a possibility of a standardized approach in the future.
Chris.
--
http://www.bluishcoder.co.nz

2023-06-07 15:02:35

- reply

📅 Original date posted:2013-05-31
📝 Original message:On Sat, Jun 1, 2013 at 11:29 AM, Wladimir <laanwj at gmail.com> wrote:
> Using zmq is a great fit for high-speed notifications such as this. Have you
> seen the pull request to integrate zmq directly into bitcoind, so that you
> don't even need -blocknotify?
>
> https://github.com/bitcoin/bitcoin/pull/2415
>
> If not: we could use some testing there!
I hadn't seen this, thanks! I've integrated zmq myself for block
notifications in bitcoin and the alt coins I use it on my bitparking
merge mining pool. I would love to see something official. I'll try
out the patch in the pull request.
Chris.
--
http://www.bluishcoder.co.nz

2023-06-07 15:02:34

- reply

📅 Original date posted:2013-05-31
📝 Original message:On Fri, May 31, 2013 at 11:56 PM, Rune Kjær Svendsen
<runesvend at gmail.com> wrote:
> I'm not quite so how to go about this.
As others have said, queuing outside of bitcoind is a better approach.
I use zeromq for this situation. blocknotify runs a program which uses
zeromq's pub/sub to queue and the application subscribes to this to
get notified of the data.
--
http://www.bluishcoder.co.nz

2023-06-07 02:53:12

- reply

📅 Original date posted:2011-12-30
🗒️ Summary of this message: OP_EVAL in Bitcoin scripting language adds expressive power, allowing for Turing completeness and implementation of SK-calculus using stack operations.
📝 Original message:On Fri, Dec 30, 2011 at 5:42 AM, <roconnor at theorem.ca> wrote:
> Basically OP_DUP lets you duplicate the code on the stack and that is the
> key to looping. I'm pretty sure from here we get get Turing completeness.
> Using the stack operations I expect you can implement the SK-calculus
> given an OP_EVAL that allows arbitrary depth.
>
> OP_EVAL adds dangerously expressive power to the scripting language.
If you look at the archives of the concatenative programming mailing
list [1] you'll see lots of examples of people creating stack
languages with minimal operations that exploit similar functionality
to reduce the required built in operations. The discussion on the list
is mostly about stack based languages where programs can be pushed on
the stack and executed (eg. Joy [2]/Factor/Some Forths).
I don't think the scripting engine in bitcoin has the ability to
concatenate, append or otherwise manipulate scripts on the stack to be
eval'd though does it?
[1] http://tech.groups.yahoo.com/group/concatenative
[2] http://tunes.org/~iepos/joy.html
Chris.
--
http://www.bluishcoder.co.nz

2023-06-07 02:20:51

- reply

📅 Original date posted:2011-09-03
🗒️ Summary of this message: A programmer discusses a mistake he made in casting and clarifies that the intended behavior was to use the CTransaction* portion.
📝 Original message:On Sun, Sep 4, 2011 at 1:52 AM, Chris Double <chris.double at double.co.nz> wrote:
> So was the intent to use the CWalletTxn size, and the casting is
> superfluous, or was it supposed to be the CTransaction* portion and
> the cast is an incorrect way of doing that? Or am I suffering from
> late night programmer syndrome and reading it wrong?
After a discussion on #bitcoin-dev it is indeed the latter. I was
under the mistaken believe that the GetSerializeSize method in
CTransaction and CWalletTxn were virtual, which would result in the
behavior I was thinking of. But they're not so it works. Please
disregard!
Chris.
--
http://www.bluishcoder.co.nz

2023-06-07 02:20:48

- reply

📅 Original date posted:2011-09-03
🗒️ Summary of this message: The Bitcoin code may be using the wrong size calculation for transaction priority due to casting shenanigans in CWallet::CreateTransaction.
📝 Original message:In CWallet::CreateTransaction there is a call to 'GetSerializeSize' on
line 979 (https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L979).
It looks like:
---------8<----------
unsigned int nBytes = ::GetSerializeSize(*(CTransaction*)&wtxNew, SER_NETWORK)
if (nBytes >= MAX_BLOCK_SIZE_GEN/5)
return false;
dPriority /= nBytes;
---------8<----------
'wtxNew' is a CWalletTxn. So this gets the serialized size of the
transaction, including all the extra data held in the wallet for that
transaction, and uses that size for computation of priority. Is that
correct? Should it be only the size of the CTransaction* part of the
transaction that should be used?
It looks this was from the casting shenanigans but unless I'm
mistaken, that casting doesn't actually do anything. We get a pointer
to a CTransaction but then dereference it, so the template function
'GetSerializeSize' would get the most derived class, right?
So was the intent to use the CWalletTxn size, and the casting is
superfluous, or was it supposed to be the CTransaction* portion and
the cast is an incorrect way of doing that? Or am I suffering from
late night programmer syndrome and reading it wrong?
Chris.
--
http://www.bluishcoder.co.nz