profile
viewpoint
Peter Todd petertodd Toronto https://petertodd.org Applied Cryptography Consultant (what the cool kids call 'blockchain tech')

petertodd/checklocktimeverify-demos 42

CHECKLOCKTIMEVERIFY (BIP65) Demos

petertodd/bitcoin 14

Bitcoin integration/staging tree

petertodd/blockpop 11

Proof-of-publication with the blockchain

petertodd/bitcoin-reading-list 7

a reading list for learning to program Bitcoin transactions

petertodd/bips 6

Bitcoin Improvement Proposals

petertodd/64-bit-counter 2

A 64-bit non-volatile counter fed by a 64mhz source.

petertodd/64-bit-counter.elec 2

64-bit-counter - Electronics

petertodd/64-bit-counter.firm 2

64-bit-counter - Firmware

issue commentpetertodd/python-bitcoinlib

Implement miniscript

Formal spec for miniscript: https://github.com/dgpv/miniscript-alloy-spec

kanzure

comment created time in a few seconds

startedpetertodd/python-bitcoinlib

started time in 2 hours

startedpetertodd/python-bitcoinlib

started time in 14 hours

startedpetertodd/python-bitcoinlib

started time in a day

fork bo-work/python-bitcoinlib

Python3 library providing an easy interface to the Bitcoin data structures and protocol.

fork in 3 days

issue openedopentimestamps/javascript-opentimestamps

invalid array length Allocation failed

Getting this error when trying to hash a large file using ots-cli.js.cmd. node v12.18.3.

FATAL ERROR: invalid array length Allocation failed - JavaScript heap out of memory

created time in 4 days

startedpetertodd/python-bitcoinlib

started time in 4 days

startedpetertodd/python-bitcoinlib

started time in 5 days

startedpetertodd/python-bitcoinlib

started time in 6 days

CommitCommentEvent
CommitCommentEvent

startedpetertodd/python-bitcoinlib

started time in 6 days

issue openedpetertodd/dust-b-gone

Is dust b gone still existing

created time in 6 days

startedpetertodd/dust-b-gone

started time in 6 days

startedpetertodd/python-bitcoinlib

started time in 6 days

issue commentpetertodd/python-bitcoinlib

CTransaction.stream_deserialize allows flagbyte != 1

Hello, sorry got stuck on something else. I've followed your advice, used only markerflag, and just sent the pull request with the simple modifications.

isn't "x^=1" the same as "x = x^1" in python? I didn't test though, it just caught my eye

dgpv

comment created time in 7 days

PR opened petertodd/python-bitcoinlib

witness flagbyte errors

This allows the library to rise two errors:

  • flagbyte !=1 ( #220 )
  • flagbute == 1 but wit.is_null() ( #221 )

An invalid_tx is added with flagbyte 02 to test, that tx body is taken from a bitcoin core test tx, which also have values in the data, therefore test_transaction is modified to accept json_prevout with 4 elements (the value of the output being the 4th elem)

+29 -4

0 comment

3 changed files

pr created time in 7 days

fork ThomasRossi/python-bitcoinlib

Python3 library providing an easy interface to the Bitcoin data structures and protocol.

fork in 7 days

issue openedopentimestamps/opentimestamps-client

The code action to add imports is great and I use it all the time, but my interactions with it can sometimes be a little repetitive.

The code action to add imports is great and I use it all the time, but my interactions with it can sometimes be a little repetitive.

For example, if I use the type Int32 HLS suggests a litany of potential imports, but every time I use this name I want to import Data.Int from base. There are a host of these "defaults" and it would be great to inform HLS of these to avoid cluttering the code actions with options I'm never going to choose.

image

The defaults could be specified either as:

  • A name and the corresponding import statement, in the above example: ('Int32, "import Data.Int")
  • Just a module name Data.Int with the meaning of, if this exists at all in the suggestions, don't suggest anything else

On a similar topic, it would be nice to specify "canonical" imports for types, for example I'm sure that despite Int32 being reexported from Foreign, Foreign.Safe, GHC.Int and UnliftIO.Foreign, nobody ever imports it from those modules (specifically, i.e. not with an open import). Does HLS have information at code-action generation time on the provenance of the symbols in the imports it's suggesting? In the above example this would present the import options from Data.Int and the Vulkan imports (assuming the user hasn't specified a canonical import for Vulkan.Core10.CommandBufferBuilding.ClearColorValue.Int32, in which case that canonical module would be returned).

I'm not sure that having a built in list of these default would be sensible, especially when alternative preludes get involved, but it would be nice to have some configuration that users could opt into easily to avoid people duplicating large amounts of the specifications in their configs.

Other motivating examples:

  • Anything from Data.Traversable, Data.Foldable, Data.Maybe. Basically any import from base which doesn't gobble up common names.
  • I quite often like: import Data.Text (Text); import Data.Text qualified as T (would have to present the options for Data.Text.Lazy too for when the user wants that)
    • Similarly for import Data.Vector(Vector); import Data.Vector qualified as V

Originally posted by @expipiplus1 in https://github.com/haskell/haskell-language-server/issues/605

created time in 7 days

issue openedrust-lang/wg-allocators

Rename `AllocRef` to `Allocator` and `alloc` to `allocate`

With rust-lang/rust#77187 we released AllocRef to the wild. It was pointed out, the names AllocRef and alloc are confusing sometimes. The main reason for this, is, that "alloc" is used as a verb and as a noun.

in https://github.com/rust-lang/rust/pull/77187#discussion_r511169783 @Aaron1011 noted, that:

[Box::alloc_ref] sounds like we're allocating a reference, not obtaining a reference to the allocator.

However, alloc_ref is the lowercased name of the Trait. @Amanieu also suggested, to rename it to Box::allocator, but the term allocator is never used anywhere, so I decided to stick with alloc_ref for now.

I think, it makes sense, to rename AllocRef to Allocator and (de)alloc to (de)allocate. The main reason for calling it AllocRef instead of Alloc was, that we wanted to express, that AllocRef should be a ZST or a reference to the actual allocator (not a reference to an "alloc" :wink: ). This however is also pointed out in the documentation and we don't expect many people to implement an allocator. A very minor downside is the longer name of Allocator and allocate, but it's way more clear, if you read those terms. The trait will also not be used often directly. In most cases, it will simply be passed to Box or Vec. So most people neither have to call allocate or deallocate, nor have to import Allocator into scope. They probably won't even care, how the allocator is implemented (ZST or reference) as long they can simply pass an allocator to those structs.

This proposal also includes renaming Box::alloc_ref to Box::allocator.

cc @Amanieu @Lokathor @Wodann @CAD97 @scottjmaddox @vertexclique

created time in 10 days

startedpetertodd/bitcoin.org

started time in 11 days

startedpetertodd/bitcoin

started time in 11 days

PR opened opentimestamps/java-opentimestamps

SLF4J support

This is based on the conversation over on opentimestamps/java-opentimestamps#48. I have migrated the project from using java.util.logging to SLF4J. This should make it easier for those depending on this library to control the logging that is coming out of the library.

There are some changes to how the CLI application needs to be built. Now when creating the OtsCli.jar it should be built with mvn install -P cli which will activate the CLI profile. This adds Logback Classic and a basic stdout log appender configuration to the CLI jar. This will allow log messages to be emitted on the command line.

All references to java.util.logging have now been removed with SLF4J as the preferred approach. Also the tests have a dependency on Logback Classic to ensure that the correct log message is output on one of the tests.

Remaining tasks

  • [ ] Test this with an existing application to make sure that the logging can be configured as required.
+152 -162

0 comment

31 changed files

pr created time in 11 days

startedpetertodd/python-bitcoinlib

started time in 11 days

issue closedpetertodd/python-bitcoinlib

How to query against all transactions involving a public key?

How do I query for all transactions involving the public key of a wallet?

Assume I have a running bitcoin node.

Thanks in advance, Vincent

closed time in 15 days

valexandersaulys

issue commentpetertodd/python-bitcoinlib

How to query against all transactions involving a public key?

Thank you for taking the time to reply with my newcomer question.

I will mark this issue closed.

valexandersaulys

comment created time in 15 days

issue commentpetertodd/python-bitcoinlib

How to query against all transactions involving a public key?

I figured if I had every block then that would be enough.

No. Bitcoin PR 14053 referenced in my previous message have link to discussions about that.

The bitcoinlib cannot abstract these commands into python for me? I can only issue them via RPC?

It wraps listunspent. But what you get is just an answer from listunpent processed and the components of the answer converted to library objects. The semantics is the same. No other list* commands are wrapped currently (the results will be returned directly as JSON for unwrapped commands, AFAIR)

valexandersaulys

comment created time in 15 days

issue commentpetertodd/python-bitcoinlib

How to query against all transactions involving a public key?

Was not aware that specific addresses needed to be tracked. I figured if I had every block then that would be enough.

The bitcoinlib cannot abstract these commands into python for me? I can only issue them via RPC?

On Tue, Nov 10, 2020, at 3:47 AM, Dmitry Petukhov wrote:

If you need the transactions associated with a wallet of your node (includeing watch-only addresses). then you can use rpc API to issue a listtransactions RPC command (and others, like listreceivedbyaddress).

If you need to get transactions associated with arbitrary address that is not tracked by your node, you'll need some sort of address index. Take a look at bitcoin/bitcoin#14053 https://github.com/bitcoin/bitcoin/pull/14053 and https://github.com/romanz/electrs

This question does not seem to be bitcoinlib-specific, as you could in principle resolve it just using command-line tools. I believe it is better to look for an answer for such questions at https://bitcoin.stackexchange.com/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/petertodd/python-bitcoinlib/issues/249#issuecomment-724555401, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB526IYUOK6ETI7MHGALG3TSPD4YJANCNFSM4TPXHL4Q.

valexandersaulys

comment created time in 15 days

issue commentpetertodd/python-bitcoinlib

How to query against all transactions involving a public key?

If you need the transactions associated with a wallet of your node (includeing watch-only addresses). then you can use rpc API to issue a listtransactions RPC command (and others, like listreceivedbyaddress).

If you need to get transactions associated with arbitrary address that is not tracked by your node, you'll need some sort of address index. Take a look at https://github.com/bitcoin/bitcoin/pull/14053 and https://github.com/romanz/electrs

This question does not seem to be bitcoinlib-specific, as you could in principle resolve it just using command-line tools. I believe it is better to look for an answer for such questions at https://bitcoin.stackexchange.com/

valexandersaulys

comment created time in 15 days

more