Bitcoin Forum
June 29, 2022, 07:22:12 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Can't seem to build the version message correctly to talk to a bitcoin peer on: February 09, 2012, 11:56:01 PM
So I'm trying to learn more about the Bitcoin protocol, and I'm writing some code to try to talk with a Bitcoin instance as a peer. My problem is that Bitcoin won't respond to any of the messages I try to send.  Here's what I have:

An example of the raw "version" message I'm sending:
Code:
F9BEB4D976657273696F6E000000000055000000B4C3000001000000000000009E5A344F00000000010000000000000000000000000000000000FFFF7F000010208D010000000000000000000000000000000000FFFF7F00001061A8CB0170F938EC13C700D6880200

The above message broken apart:
Code:
Start    : F9 BE B4 D9
Command  : 76 65 72 73 69 6F 6E 00 00 00 00 00
Length   : 55 00 00 00
Checksum :
Payload  :
    Version          : B4 C3 00 00
    Services         : 01 00 00 00 00 00 00 00
    Timestamp        : 9E 5A 34 4F 00 00 00 00
    RecipientAddress :
        Services : 01 00 00 00 00 00 00 00
        Ip       : 00 00 00 00 00 00 00 00 00 00 FF FF 7F 00 00 10
        Port     : 20 8D
    SenderAddress    :
        Services : 01 00 00 00 00 00 00 00
        Ip       : 00 00 00 00 00 00 00 00 00 00 FF FF 7F 00 00 10
        Port     : 61 A8
    Nonce            : CB 01 70 F9 38 EC 13 C7
    SubVersion       : 00
    LastBlock        : D6 88 02 00


Here's what I get in the Bitcoin debug.log file:
Code:
accepted connection 127.0.0.1:63714
...
PROCESSMESSAGE MESSAGESTART NOT FOUND
...
socket no message in first 60 seconds, 1 0
disconnecting node 127.0.0.1:63714

"PROCESSMESSAGE MESSAGESTART NOT FOUND" comes from main.cpp around line 2342.
"socket no message in first 60 seconds" comes from net.cpp, right near the end.

I've tried to follow the spec as outlined here: https://en.bitcoin.it/wiki/Protocol_specification (particularly the "Message structure", "Network address" and "Version" sections), but when I send the message, I never get a response, and Bitcoin complains about the already mentioned errors (above) in the log file.

Any ideas as to what I'm doing wrong in building the message?
2  Bitcoin / Project Development / RFC -- Distributed Bitcoin Stock Exchange (DBSE) on: December 08, 2011, 08:42:19 PM
This is a "Request for Comment" (RFC) Concerning a Distributed Bitcoin Stock Exchange. (DBSE)

This is an early RFC, subject to revision and may change entirely.  It's definitely in the pre-half-backed stage. Please try to poke it full of holes so it can be improved.  Also try to simplify some of the transactions if possible.  I am by no means an expert and I need you to vet this or point out why it's impossible.

Goal: Design a distributed, peer-to-peer, blockchain-based, Bitcoin stock exchange.

Summary: The basis for this stock exchange would be a blockchain and TradeTokens ("TT").  Mining would produce TT in declining block subsidies, as well as transaction fees and forfeited "good faith deposits".  TT produced by mining are used to pay the transaction fees for all transactions, including creating and managing TickerSymbols, creating initial shares, buying and selling shares, creating and voting on motions, etc.  If someone wants to participate in the stock exchange without mining, they would presumably purchase TT from a miner.  While TT is used for fees, Bitcoin ("BTC") is used for all share purchases.  There is a built-in escrow system to enforce trades and ensure that the purchaser receives their shares and the seller receives their payment in BTC after each trade.


1. TradeTokens (TT)

Mining will produce TradeTokens ("TT"), which will be used to pay the transaction fees for:

  • Creating and managing a company listing (represented by a unique TickerSymbol) in the Distributed Bitcoin Stock Exchange ("DBSE").
  • Creating IPO shares to sell.
  • Submitting transactions to buy and sell shares (shares paid for in BTC)
  • Creating and voting on motions
  • Submitting transactions to pay dividends (dividends paid in BTC)


2. Block chain

  • Mining in the DBSE blockchain will produce a declining per-block subsidy in TradeTokens (TT).  The miner will also receive TT transaction fees for transactions included in the block and any forfeited "good faith deposits" (in TT as well).
  • Have relatively quick blocks, perhaps every 5 minutes? TBD.
  • TradeToken block subsidy would start at 1000 TT per block for the first block, and drop by 0.00019 TT for each following block.  With 5 minute blocks, this would take ~50 years until the block subsidy reaches 0. This could be redesigned to not be linear and work more like Bitcoin block subsidies as well.


3. Public and private keys

Public and private key pairs would be used to identify who owns TickerSymbols ("TS"), Shares, and TradeTokens.  The public key (technically a shorter address derived from it) will be known as a "DBSE Address", and the corresponding private key will be the "DBSE PrivKey".  Any of the three items--TickerSymbols, Shares, or TradeTokens-- can be associated to a given DBSE PrivKey, and are thus owned by the owner of that private key.

If needed, three separate types of public/private key pairs could be created with distinct looking public addresses: One for ticker symbols, one for shares/assets, and one for TradeTokens. TBD.


4. Creating a company

To create a company listing, you choose a TickerSymbol that does not already exist in the block chain (or has been released, see below), and submit it, along with a TT transaction fee and a public key ("DBSE Address") for which you hold the private key ("DBSE PrivKey").  To get started, you would then send a transaction to create the initial shares, then send another transaction to offer some or all of those shares for sale for BTC.  After that, any shareholder can create and vote on Motions, the TickerSymbol owner can pay dividends, anyone can buy or sell shares for BTC, all by submitting the appropriate transactions.


5. Transaction Fees

Fees will be optional in the protocol. A yet-to-be determined algorithm will be used in the official client for generating a transaction fee in TradeTokens for all transactions.  Perhaps something like (0.000001 * TOTAL_NUM_TRADETOKENS_IN_EXISTENCE).

The fee for creating shares would be relatively high.  The buy and sell fees relatively low.  The fee for cancelling a buy or sell order might be slightly higher than the buy and sell fees.

Miners would dictate transaction fees based on their policies for including transactions in blocks based on fees.  The default mining software should enforce small fees.


6. Good faith deposit

The good faith deposit along with the transaction fee (both paid in TT) discourages people from submitting frivolous transactions for purposes of spaming, disrupting the DBSE, or manipulating the market.  The good faith deposit would be much larger (10 or 20 times larger) than the transaction fee.  The good faith deposit would be required by the protocol for all buy or sell offers submitted.  It will be refunded for "legitimate" orders, where "legitimate" means the order was concluded or it's time period expired, as opposed to being cancelled.


7. Motions and voting

Anyone who owns at least one share of a given stock (TickerSymbol) can create a Motion concerning it, and all other stockholders can vote on it.  When submitting the Motion, an expiry date from 1 to 90 days is given.  When the expiry date is reached, the Motion is defined by the protocol as having passed if (a) at least 50% of stockholders have voted and at least 2/3 of votes are for the motion, OR (b) at least 1/3 of stockholders have voted and at least 3/4 of votes are for the motion.  These percentages can be discussed, but should then be hard-coded into the protocol.


8. Dividend payments

The TickerSymbol owner can submit a transaction to make a dividend payment. The payment is made in BTC, and is divided among all shareholders and distributed automatically to the BTC addresses that the shareholders specified when purchasing the shares.  The details of how the would function need to be determined, but could work similarly to the Escrow functionality for share purchases as described below.


9. Internal escrow

Example: Buying shares.  Bob has some TT and would like to buy some shares in a given stock.  He submits a TRADE_BUY transaction. He pays the TT transaction fee and the TT "good faith deposit".  A miner matches up Bob's buy request with Alice's previously submitted sell request.  The miner does some EC math on the BTC public keys that both Bob and Alice submitted with their transactions, to produce a payment address that can only be redeemed by combining the private keys that Bob and Alice hold.  The miner includes a TRADE_MATCH transaction in the blockchain with the calculated payment address. The miner receives Bob and Alice's combined "Fulfillment fees" for this service.  Bob's client software pays 100% of the total sale price into the generated BTC address.  Alice's client software confirms that the BTC is there and sends a TRADE_FULFILL transaction transferring the shares to Bob (the shares are sent to Bob's TT address included in the TRADE_BUY transaction).  A miner includes that transfer in the block chain and the shares now belong to Bob.  When Bob's client software confirms that Bob now has the shares, it submits a TRADE_CONCLUDE transaction to the block chain which contains the Bob's private key for the BTC address.  Alice's client software withdraws the BTC by combining Bob's private key with Alice's private key to produce the private key that redeems the funds.  After sending TRADE_CONCLUDE, Bob's client software also submits a SHARE_CHANGEDIVIDENDADDRESS transaction to change the dividend address for the shares from Alice's to his.

A possible problem here is that Bob could maliciously withhold his private key from Alice after he has the shares.  So he would have his shares and Alice wouldn't get paid.  Of course, Bob couldn't redeem the BTC either.  This could possibly be mitigated by finding a way for Bob to pay exactly 110% of the final price, and when he releases the 100% to Alice, the 10% overpayment gets released back to him.

Another question here is at what point during this process can it still be cancelled by other parties?  It cannot be cancelled after the TRADE_FULFILL transaction is sent.  If it was cancelled before TRADE_FULFILL, but after the buyer had sent the BTC, then the seller would have to send their private key to the buyer, so they could retrieve the BTC they deposited.


10. Client Software

The client software will read the block chain and maintain indexes to quickly find appropriate data.  Based on analyzing the transactions in the block change, the client should list all relevant data for the user. For example:

  • The client would show TickerSymbols owned by the user and how many shares exist for each. A Searchable list of all TickerSymbols. For any given ticker symbol, the client should list how many shares exist, how many shares are in buy or sell orders and their prices. List all shares owned, etc.
  • The client would scan the blockchain for dividend payments and list all dividends received for each stock. Dividend payments will already have been send directly to the owner's BTC address.
  • The client would show all Motions relevant to the shares you own.


11. High frequency trading

This would not support high frequency trading, however it would probably be possible to build a centralized exchange to support HFT that works on top of this distributed framework.


12. All Transaction Types

TICKERSYMBOL_CREATE
  • Parameters:
  • Fee
  • New TickerSymbol to attempt to create
  • Public key

Since you hold the corresponding private key, ("DBSE PrivKey") only you can manage this new TickerSymbol.

Known issue: How do we deal with the conflict if there are two transactions trying to create the same TickerSymbol at the same time (they are trying to be included in the same block). Using a timestamp of when the transaction was first seen on the network would be subject to manipulation.  The solution would probably be to reject both (all) conflicting transactions, invalidating* them. The end user can resend them until one is included in a block before the other.

*Not sure how the invalidation would work.

TickerSymbol squatting would be mitigating by automatically releasing unused TickerSymbols after X blocks have been created. With 5 minute blocks, X might be 8064, which would be approximately four weeks.  "Unused" TickerSymbols would be defined as TickerSymbols that have been created, but shares have never been created for them, and X blocks have passed since the TickerSymbol was created.

SHARE_CREATE
  • Parameters:
  • Fee
  • TickerSymbol Private Key
  • Number of shares to create

Shares can only be created by the owner of the TickerSymbol DBSE PrivKey, and only if the current number of shares is zero (0) or if there is a successful Motion to create more shares.

The owner of the created shares will be the owner of the TickerSymbol DBSE PrivKey. After creation, some or all of the shares can be put on the market with TRADE_SELL.

TRADE_BUY
  • Parameters:
  • Fee
  • Fulfillment Fee (used to pay the miners for the additional transactions needed to complete the trade)
  • TickerSymbol of the shares to buy
  • Number of shares to buy
  • Maximum price to pay per share in BTC
  • TT "good faith deposit" calculated on the number of shares and share price
  • timeout after which this offer expires
  • TT Address for refunding the "good faith deposit"
  • BTC address to refund the unused part of the payment, if any
  • BTC address for receiving dividend payments from these shares
  • public BTC address to use for creating (along with a BTC address provided by the seller) the BTC address for payment to be sent to
  • TT address for the shares to be sent to

This is an *offer* to buy at this price. If the offer is cancelled before expiring, the "good faith deposit" is forfeited to the block subsidy payout address for the block the cancel transaction is in.  If the offer is successfully completed or if the expiry date is reached, the "good faith deposit" is refunded (via a refund request initiated by the owner). If no shares are available to buy at the price you specified (eg. someone buys them right before you do), the offer stands until expiring or being cancelled.

TRADE_SELL
  • Parameters:
  • Fee
  • Fulfillment Fee (used to pay the miners for the additional transactions needed to complete the trade)
  • TickerSymbol of the shares to sell
  • Number of shares to sell
  • Minimum price per share in BTC
  • TT "good faith deposit" calculated based on the number of shares and share price
  • timeout after which this offer expires
  • BTC address for payment.

This is an *offer* to sell at this price. If the offer is cancelled before expiring, the "good faith deposit" is forfeited to the block subsidy payout address for the block the cancel transaction is in.  If the offer is successfully completed or if the expiry date is reached, the "good faith deposit" is refunded (via a refund request initiated by the owner). If there are no standing offers buy at the price you specified (eg. someone sold the same shares as you, right before you), the offer stands until expiring or being cancelled.

TRADE_MATCH
  • Parameters:
  • Transaction Hash(es) for the buy or sell offer(s) being matched.

This is not a transaction sent by the client software.  This is a transaction generated by the mining software, when it finds two or more compatible sell/buy orders. Sell and buy orders do not have to executed all at once. An order can be exectuted in pieces.  A partically executed sell/buy order can still expire or be cancelled. If it expires, the full good faith deposit is refunded. If it is cancelled, a pro-rated part of the good faith deposit is refunded, based on the ratio of the number of shares bought/sold and the original number offered.  If one or more of the buy/sell orders are being completed fully, the TT refund (TRADE_GOODFAITHREFUND) for the good faith deposit is also initiated by the mining software.

TRADE_FULFILL
  • Parameters:
  • Fee
  • TickerSymbol for shares being sent
  • Number of shares to send
  • Recipient's TT address to send shares to
  • Original Buy order hash that this fulfills

TRADE_CONCLUDE
  • Parameters:
  • Fee
  • Original Buy order hash that this fulfills
  • Private key for seller to use to calculate the private key where the BTC funds are held

TRADE_CANCEL
  • Parameters:
  • Fee
  • Transaction Hash for the buy/sell offer to be cancelled
  • Private key used to create the original transaction. (to sign this transaction and prove this is the owner of the original transaction)

TRADE_GOODFAITHREFUND
  • Parameters:
  • Transaction Hash for the completed buy/sell offer that contains the good faith deposit to refund.

This is initiated by the miner when an order is completed.

TICKERSYMBOL_SYNONYMIZE
  • Parameters:
  • Fee
  • an array of TickerSymbols
  • sign with the Private Key for all TickerSymbols to prove you're the owner
  • set the preferred TickerSymbol.

This transaction would be a way to rename TickerSymbols.  First create a new ticker symbol, then submit a transaction with the old and new TickerSymbols and set which of them is the preferred TickerSymbol to use as its display name.

TICKERSYMBOL_CLOSE

 Have a transaction to "close" a TickerSymbol?

MOTION_CREATE
  • Parameters:
  • Fee
  • TickerSymbol
  • Title [50 chars]
  • Text [10000 chars]
  • Expiry [1 - 90 days]

This would generate a MotionHash which would be a unique hash representing this motion.  If the motion is for creating more shares, it would need an additional parameter specifying this and how many shares would be authorized to be created, to tie into the subsequent SHARE_CREATE transaction to actually create the shares.

MOTION_VOTE
  • Parameters:
  • Fee
  • MotionHash
  • Vote [yes/no]
  • Comment [200 chars]

DIVIDEND_NOTIFY
  • Parameters:
  • Fee
  • TickerSymbol that this payment is for
  • Total amount in BTC
  • Comment [200 chars]

This dividend transaction will notify the client that dividends have been paid.  As part of sending this transaction, the client would divvy up the dividends and send (using sendmany) the appropriate amount to the BTC address specified for each shareholder (specified when purchasing shares).  End users could also consolidate their dividend addresses by sending a SHARE_CHANGEDIVIDENDADDRESS transaction

SHARE_CHANGEDIVIDENDADDRESS
  • Parameters:
  • Fee
  • Public TT key for the shares to be changed
  • New BTC payout address
  • Signed with the private key corresponding to the shares to prove ownership


-----
END OF RFC
-----
3  Other / CPU/GPU Bitcoin mining hardware / 5970 on the way, would like recommendations (first timer) on: December 06, 2011, 07:51:02 PM
I've got a 5970 on the way.  I'm planning to put it in a computer I already have running Ubuntu 11.10.  What are your recommendations for:

- Overclocking
- What miner to use
- What pool to use
- Any other tweaks to the miner software to get more MH/s

This will be my first attempt at GPU mining. I'm approaching it as a hobby, and just want to see how many bitcoins I can get out of it.

Thanks.
4  Bitcoin / Development & Technical Discussion / Need a couple of TTC to test a potential bug. on: November 21, 2011, 08:09:26 PM
Not sure if this is the right place for this....

Can anyone send me a couple of testnet bitcoins? I think I see a possible bug with transactions and I'd like to test it.  Alternatively, is it possible to CPU mine on testnet and get a couple of coins without waiting forever?

Thanks.

Testnet Address: mpvtPqXwSepqcHuzExcJZs9CNVWedU37iw
5  Bitcoin / Project Development / On a decentralized bitcoin-based stock market... on: November 21, 2011, 07:30:09 PM
Let's discuss how a peer-to-peer, decentralized bitcoin-based stock exchange might be best implemented.

Anybody who has a company on GLBSE: if a new exchange opened up and promised to be more reliable, would you move your company there?
I'd like to hear the answer to this too.  An exchange with a much more intuitive interface could be made.
I think the effort should be put into a decentralized stock exchange, not another autonomous one.  One where the tickers, issues, portfolios, contracts, etc are all kept in a blockchain type system.  The entry nodes are merely market makers much like the real stock exchange, you could also route your orders through a preferred market maker etc.. Your portfolio, balance, etc is not actually stored on any of the sites, but in the blockchain unlocked only by your private key.  There is obvious logistics issues to work out here, but I think through the use of PKC and the blockchain system, it is all doable.

I really do love the GLBSE, but it obviously needs alot of work, and the centralization is a blatant problem especially given the politics involved.  However, I think the just like cryptocurrency we are in the infancy on this idea and the development of an idea like i stated above is more or less natural progression given what we know about p2p / decentralization and how it has been implemented in the cryptocurrency world.

I would love to get involved in such a project someday and would be willing to throw some resources at it.

I think the effort should be put into a decentralized stock exchange, not another autonomous one.  One where the tickers, issues, portfolios, contracts, etc are all kept in a blockchain type system.  The entry nodes are merely market makers much like the real stock exchange, you could also route your orders through a preferred market maker etc.. Your portfolio, balance, etc is not actually stored on any of the sites, but in the blockchain unlocked only by your private key.  There is obvious logistics issues to work out here, but I think through the use of PKC and the blockchain system, it is all doable.

For a decentralized stock exchange, one could consider basing it on Open-Transactions:

https://github.com/FellowTraveler/Open-Transactions
6  Bitcoin / Bitcoin Technical Support / GLBSE not working? on: November 21, 2011, 02:58:21 PM
When I enter my account, my balance just shows "loading...." but doesn't load.  When I click on portfolio, it just says "Refreshing..." but never shows my portfolio.  It was working correctly a few days ago. 

Anyone else experiencing this?
7  Economy / Trading Discussion / How to exchange USD for LR (LibertyReserve)? on: November 18, 2011, 10:57:17 PM
A.k.a. The fun but long-winded game of trying to buy BTC with USD. Smiley

My main question is what is the best way to buy LR with USD?  Best can be defined as "with the lowest fees and in a reasonable amount of time".  What services do you use to buy LibertyReserve?

Thanks!
8  Bitcoin / Development & Technical Discussion / An FPGA based SHA-256 Processor (whitepaper) on: November 15, 2011, 08:39:58 PM
http://www.ee.usyd.edu.au/people/philip.leong/UserFiles/File/papers/sha_fpl02.pdf (PDF warning)

Just ran across this. What do you make of it?
9  Other / Meta / Add an "Auctions" board under Market place and disallow editing posts there on: November 10, 2011, 10:22:20 PM
Auctions where people can edit their posts cause trouble...

https://bitcointalk.org/index.php?topic=50763.20
https://bitcointalk.org/index.php?topic=51512.0

If we had a separate forum for auctions where no one can edit their posts, it would help, methinks.  Wink
10  Bitcoin / Mining support / Is it worth it? -- mining with a Radeon 4550 on: November 06, 2011, 02:20:09 AM
A friend wanted to get rid of a used video card, asked if I wanted it, so I took it.  It's a Sapphire Radeon 4550, PCI-E, 512 MB DDR3.  I've got components sitting around, so I can slap together a box to put this card in.  According to the comparison chart, it would only produce about 7 Mhash/s.

My question-- Approx how many BTC might I mine in a day/week running it in a pool? / Would it be worth it?
11  Other / Beginners & Help / GUIMiner missing DLL problem -- "ImportError: DLL load failed" on: October 26, 2011, 09:17:54 PM
I installed GUIMiner (https://bitcointalk.org/index.php?topic=3878.0), set it up with my pool (http://mtred.com) and when I try to start mining, I get the following error:

Code:
2011-10-26 16:15:38: Running command: poclbm.exe user:pass@mtred.com:8337 --device=0 --platform=0 --verbose
2011-10-26 16:15:38: Listener for "MT Red" started
2011-10-26 16:15:39: Listener for "MT Red": Traceback (most recent call last):
2011-10-26 16:15:39: Listener for "MT Red": File "poclbm.py", line 3, in <module>
2011-10-26 16:15:39: Listener for "MT Red": File "BitcoinMiner.pyo", line 11, in <module>
2011-10-26 16:15:39: Listener for "MT Red": File "pyopencl\__init__.pyo", line 3, in <module>
2011-10-26 16:15:39: Listener for "MT Red": File "pyopencl\_cl.pyo", line 12, in <module>
2011-10-26 16:15:39: Listener for "MT Red": File "pyopencl\_cl.pyo", line 10, in __load
2011-10-26 16:15:39: Listener for "MT Red": ImportError: DLL load failed: The specified module could not be found.

I'm running Windows 7, if that matters.  Thanks in advance!
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!