Bitcoin Forum

Bitcoin => Bitcoin Technical Support => Topic started by: cheako on March 20, 2015, 09:06:26 PM



Title: Accessing coin controle features from RPC API.
Post by: cheako on March 20, 2015, 09:06:26 PM
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.


Title: Re: Accessing coin controle features from RPC API.
Post by: EcuaMobi on March 20, 2015, 09:41:56 PM
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.


Title: Re: Accessing coin controle features from RPC API.
Post by: cheako on March 21, 2015, 02:21:17 AM
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.


Title: Re: Accessing coin controle features from RPC API.
Post by: EcuaMobi on March 21, 2015, 12:50:09 PM
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.


Title: Re: Accessing coin controle features from RPC API.
Post by: cheako on March 22, 2015, 01:22:03 AM
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.



Title: Re: Accessing coin controle features from RPC API.
Post by: EcuaMobi on March 22, 2015, 03:24:54 AM
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?


Title: Re: Accessing coin controle features from RPC API.
Post by: grue on March 22, 2015, 03:32:12 AM
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?


Title: Re: Accessing coin controle features from RPC API.
Post by: cheako on March 22, 2015, 09:39:33 AM
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 = ();
    }
}


Title: Re: Accessing coin controle features from RPC API.
Post by: cheako on March 22, 2015, 10:09:18 AM
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.


Title: Re: Accessing coin controle features from RPC API.
Post by: dserrano5 on March 22, 2015, 10:10:28 AM
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 (https://bitcointalk.org/index.php?topic=166395.0).

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


Title: Re: Accessing coin controle features from RPC API.
Post by: cheako on March 24, 2015, 03:25:56 AM
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 (https://bitcointalk.org/index.php?topic=166395.0).

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?