Accessing coin controle features from RPC API.

[cheako]

Hello,
  There seems to be a gap in feature set from the QT interface and backed bitcoind.  Are there any plans to merge these subroutines down to the backend?  Can developing non-UI enhancements into the QT interface be avoided in the future.

[1714722689]

1714722689

[1714722689]

1714722689

[1714722689]

1714722689

[EcuaMobi]

Hello,
  There seems to be a gap in feature set from the QT interface and backed bitcoind.  Are there any plans to merge these subroutines down to the backend?  Can developing non-UI enhancements into the QT interface be avoided in the future.

What features are missing? Are you talking about choosing the inputs of a transaction for example? You can use the command listunspent for that via RPC and then create the transaction, sign it and broadcast it.
Please include more details.

[cheako]

Hello,
  There seems to be a gap in feature set from the QT interface and backed bitcoind.  Are there any plans to merge these subroutines down to the backend?  Can developing non-UI enhancements into the QT interface be avoided in the future.

What features are missing? Are you talking about choosing the inputs of a transaction for example? You can use the command listunspent for that via RPC and then create the transaction, sign it and broadcast it.
Please include more details.

This obviously applies to anything in bitcoin-qt that's not...  Draw this table from listunspent or user clicks this so fill in RPC function call with information provided.

Any routines that mangle the info on the qt side should be merged back into the RPC, so that there is no loss of functionality on that end.  Once bitcoin-qt does more than reading and writing RPC the RPC *needlessly* suffers.  There is nothing to be gained from writing private functions, that are private until exported to a UI.  If any function is useful enough to export to a UI, then it's automatically useful to programmers as well.  However there seems to be someone who thinks otherwise.

Whatever functions and subroutines added to bitcoin-qt should be ported over so they are available as RPC calls.


So yes, the RPC is missing a send feature with advanced options relating to selecting a change address and specifying a list of inputs.  As well as Transaction fee handling, though there is a work around in that one can call setfee(estimatefee).  Said work around leaves something to be desired over the current UI.

In the UI listunspent is used to generate a table and the user checks off items from the table.  In RPC these checks may simply be a list of (TXID,OID) pairs.

[EcuaMobi]

I'm still not sure what you're saying.
All these features can be achieved via command line and all these commands can be accessed via RPC so the functionalities are available that way.
Are you asking for command shortcuts so things are as easy to code as using the UI? That's a lot to ask. That's not normally how command-line apps work.
RPC is intended to be used by programs/scripts so it needs to be flexible and have low-level methods. The script itself can implement the required logic.

[cheako]

I'm still not sure what you're saying.
All these features can be achieved via command line and all these commands can be accessed via RPC so the functionalities are available that way.
Are you asking for command shortcuts so things are as easy to code as using the UI? That's a lot to ask. That's not normally how command-line apps work.
RPC is intended to be used by programs/scripts so it needs to be flexible and have low-level methods. The script itself can implement the required logic.

Consider this, an application that uses xinput to drive the QT-client so as to gain access to the extra features it offers....  Ridiculous right!

If there is a good function or subroutine, then it should be exposed as an API extension...  Not buried away as part of a user interface.

[EcuaMobi]

I'm still not sure what you're saying.
All these features can be achieved via command line and all these commands can be accessed via RPC so the functionalities are available that way.
Are you asking for command shortcuts so things are as easy to code as using the UI? That's a lot to ask. That's not normally how command-line apps work.
RPC is intended to be used by programs/scripts so it needs to be flexible and have low-level methods. The script itself can implement the required logic.

Consider this, an application that uses xinput to drive the QT-client so as to gain access to the extra features it offers....  Ridiculous right!

If there is a good function or subroutine, then it should be exposed as an API extension...  Not buried away as part of a user interface.

What the UI does is listing all the unspent inputs, let the user choose which ones to spend and then create the transaction. Of course it can't do the whole process without user's intervention.
Exactly what part of that process do you want to be exposed via command line? What would be the logic to choose the inputs?

[grue]

I'm still not sure what you're saying.
All these features can be achieved via command line and all these commands can be accessed via RPC so the functionalities are available that way.
Are you asking for command shortcuts so things are as easy to code as using the UI? That's a lot to ask. That's not normally how command-line apps work.
RPC is intended to be used by programs/scripts so it needs to be flexible and have low-level methods. The script itself can implement the required logic.

Consider this, an application that uses xinput to drive the QT-client so as to gain access to the extra features it offers....  Ridiculous right!

If there is a good function or subroutine, then it should be exposed as an API extension...  Not buried away as part of a user interface.

Why do I have a feeling that you're just too incompetent/lazy to use the raw transactions API?

[cheako]

I'm still not sure what you're saying.
All these features can be achieved via command line and all these commands can be accessed via RPC so the functionalities are available that way.
Are you asking for command shortcuts so things are as easy to code as using the UI? That's a lot to ask. That's not normally how command-line apps work.
RPC is intended to be used by programs/scripts so it needs to be flexible and have low-level methods. The script itself can implement the required logic.

Consider this, an application that uses xinput to drive the QT-client so as to gain access to the extra features it offers....  Ridiculous right!

If there is a good function or subroutine, then it should be exposed as an API extension...  Not buried away as part of a user interface.

Why do I have a feeling that you're just too incompetent/lazy to use the raw transactions API?

I just don't want to maintain code that sucks and is all crappy.  Given the following a wrapper around a QT application might look sane and manageable.

Code:

sub btcpu {
    my $outputs = shift @_;
    my $trns    = $api->call( 'decoderawtransaction', shift @_ );
    my $txid    = $trns->{txid};
    my @vout    = @{ $trns->{vout} };
    while ( $_ = shift @vout ) {
        my $addr = $_->{scriptPubKey}->{addresses}->[0];
        push @{$outputs},
          {
            txid          => $txid,
            amount        => $_->{value},
            vout          => 0 + $_->{n},
            scriptPubKey  => $_->{scriptPubKey}->{hex},
            address       => $addr,
            confirmations => 0.0001,
          }
          if ( $addr eq work
            || $addr eq $exca->[0]
            || $addr eq $exca->[1]
            || $addr eq $exca->[2]
            || $addr eq $exca->[3]
            || $addr eq $exca->[4]
            || $addr eq $exca->[5]
            || 0 );
    }
}

sub createtransaction {
    my ( $opts, $cost, $invest, $price, $change ) = @_;
    my ( $rtx, $outputs ) = ( "", [] );
    if ( $cost > $price + (FEE) ) {
        $rtx = $_ = $api->call(
            'signrawtransaction',
            $api->call(
                'createrawtransaction',
                $opts,
                {
                    $invest => 0 + $price,
                    $change => 0 + $cost - $price - (FEE)
                }
            )
        )->{hex};
        btcpu( $outputs, $_ );
    }
    else {
        $rtx = $_ = $api->call(
            'signrawtransaction',
            $api->call(
                'createrawtransaction', $opts, { $invest => 0 + $price }
            )
        )->{hex};
        btcpu( $outputs, $_ );
    }
    return ( $rtx, $outputs );
}

sub gettarget {
    my $target = [ gettimeofday() ];
    $target->[0] += 2;    # 2 seconds from now.
    unless ($opt_f) {
        my $dt = DateTime->now();
        $dt->add( seconds => 3 );
        $dt->truncate( to => 'minute' );
        $dt->add( minutes => 1 );

        my $now = DateTime->now();
        die "Target time too far."
          if (
            DateTime->compare( $dt, $now ) != DateTime->compare(
                DateTime->from_object( object => $now )->add( minutes => 2 ),
                $dt
            )
          );
        $target = [ $dt->hires_epoch(), 24e4 ];
        clock_nanosleep( CLOCK_REALTIME,
            tv_interval( [ gettimeofday() ], $target ) * 1e9 - 12e9 )
          if ( DateTime->compare( $now->add( seconds => 13 ), $dt ) != 1 );
    }
    return $target;
}

sub getsocket {
    my $cl = new IO::Socket::SSL(
        PeerPort     => 'https',
        PeerHost     => '141.101.112.196',
        SSL_hostname => 'blockchain.info',
    );
    die "cannot connect to the server $!\n" unless $cl;
    $cl->blocking(0);
    $cl->autoflush(1);
    $cl->sockopt( TCP_NODELAY, 1 );
    return [ $cl, IO::Select->new($cl) ];
}

sub txspush {
    my ( $cl, $sel, $target ) = ( shift @_, shift @_, shift @_ );

    unless ($opt_f) {
        clock_nanosleep( CLOCK_REALTIME,
            max( 0, tv_interval( [ gettimeofday() ], $target ) * 1e9 - 1e6 ) );
        1 while ( [ gettimeofday() ]->[1] > 9e5 );
        1 while ( [ gettimeofday() ]->[1] <= 13e4 );
    }
    $opt_f = 1;
    foreach (@_) {
        $_ = Encode::encode_utf8($_);
        my $out = Encode::encode_utf8( sprintf( REQ, length($_) + 3, $_ ) );
        my $siz = length($out);
        my $off = 0;

        while ( $siz > $off ) {
            $sel->can_write();
            $off += $cl->syswrite( $out, $siz - $off, $off );
        }

        $sel->can_read();
        1 while ( $cl->sysread( my $a, 4096 ) );
    }

    $api->call( 'sendrawtransaction', $_ ) foreach (@_);
}

my $target = [ gettimeofday() ];
NEWTX: while ( my $bid = shift @bids ) {
    my $cost = 0;
    my @opts = ();
    while ( $_ = shift @unspent ) {
        $_->{vout}   += 0;
        $_->{amount} += 0;
        push @opts,
          {
            txid         => $_->{txid},
            vout         => $_->{vout},
            scriptPubKey => $_->{scriptPubKey}
          };
        $cost += $_->{amount};
        last
          if ( $cost >= $bid + FEE );
    }
    my @a = createtransaction(
        \@opts, $cost, $GAME,
        $cost <= $bid ? $cost - (FEE) < 0 ? $cost : $cost - (FEE) : $bid,
        $exca->[ $opt_r ? -1 : 0 ]
    );
    push @txs,         $a[0];
    push @nextunspent, @{ $a[1] };
    push @{$exca}, shift @{$exca}
      if ($opt_r);
    if ( $#unspent <= 0 ) {
        last
          if ( $#nextunspent <= 0 );
        @unspent     = @nextunspent;
        @nextunspent = ();
    }
}

[cheako]

I'm still not sure what you're saying.
All these features can be achieved via command line and all these commands can be accessed via RPC so the functionalities are available that way.
Are you asking for command shortcuts so things are as easy to code as using the UI? That's a lot to ask. That's not normally how command-line apps work.
RPC is intended to be used by programs/scripts so it needs to be flexible and have low-level methods. The script itself can implement the required logic.

Consider this, an application that uses xinput to drive the QT-client so as to gain access to the extra features it offers....  Ridiculous right!

If there is a good function or subroutine, then it should be exposed as an API extension...  Not buried away as part of a user interface.

What the UI does is listing all the unspent inputs, let the user choose which ones to spend and then create the transaction. Of course it can't do the whole process without user's intervention.

The JSON already does half of what you describe.  It's not entirely true that it would take a human operator to shift through the output to select what to use for the next step.  Whatever, say for the purpose of creating many different front-ends.

Exactly what part of that process do you want to be exposed via command line? What would be the logic to choose the inputs?

The parts that are done automatically, whatever code that exists as part of the QT client does not need to be locked away only to be accessible by human operators.

The logic intended to be used by human operators, can be represented as code, even without resorting to advanced AI.  There is already a few examples exposed via the existing API with sendtoaddress and such.

If users find they need finer control over the process, that's great.  Whatever control the average user needs is useful to the generic programmer.  It should be a simple matter to extend the RPC API for the generic programmer and once done the new API can be exported to users.  Building an advanced API as part of a front-end turns the  generic programmer into a second class citizen.

Exposing the interface as-is problematically serves both the QT and any other client.  The primitives should pass from user _through_ UI to backend.  If the UI has greater intelligence than offered by the RPC API it becomes a desirable target for building automation.

[dserrano5]

I just don't want to maintain code that sucks and is all crappy.  Given the following a wrapper around a QT application might look sane and manageable.

Code:

sub btcpu {
    my $outputs = shift @_;

So you speak Perl. That's good . Look here.

Not updated regarding the latest fee changes, well, we could get to that.

[cheako]

I just don't want to maintain code that sucks and is all crappy.  Given the following a wrapper around a QT application might look sane and manageable.

Code:

sub btcpu {
    my $outputs = shift @_;

So you speak Perl. That's good . Look here.

Not updated regarding the latest fee changes, well, we could get to that.

Are you truly content with reimplementing base functionality and keeping it in sync?