[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[520Bit]

I have another error when I make an order:

Code:

c:\counterpartyd_build>counterpartyd order --source 1XXX --get-quantity 20 --get-asset BTC --give-quantity 200 --give-asset XCP --expiration 5000 --fee_required 0.01

c:\counterpartyd_build>echo off
Transaction (unsigned): 010000000191bc9ad6c118669cb9ef0425310793357f2d42d7e27ad6c040908b1210ce22520200000000ffffffff036c2a0000000000006751410424e0d192e25d4eea9ef8ba4f32d45a025d0aa80172c45580762f3d417b
6eb804d8d7f3e1ee43863a165ae507bbf67b15bf137ed0d5072f1334e489cb6368c14d2120434e5452505254590000000a000000000000000100000004a817c8000000000052ae6c2a0000000000006751410424e0d192e25d4eea9ef8ba4f32d45a025d
0aa80172c45580762f3d417b6eb804d8d7f3e1ee43863a165ae507bbf67b15bf137ed0d5072f1334e489cb6368c14d2116000000000000000077359400138800000000000f42400000000000000000000052ae95847402000000001976a914779835a784
adb00b7cc20357da16ad282c6ff88588ac00000000
Traceback (most recent call last):
  File "c:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 522, in <module>
    print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(unsigned_tx_hex))
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 382, in transmit
    if input('Confirm? (y/N) ') != 'y':
AttributeError: 'UnicodeOutput' object has no attribute 'errors'

How to fix the 'no attribute 'errors''?
My counterpartyd is up-to-date by the way.

Also posted here: https://forums.counterparty.co/index.php?topic=22.new#new

should be fixed, please update from git.

Thanks, it works now after update from git.

[1715029252]

1715029252

[1715029252]

1715029252

[1715029252]

1715029252

[rashley]

I'm trying to get counterpartyd up and running on Debian. I have bitcoind running and I am running counterpartyd server in the background but when I try to connect to it using counterpartyd market --give-asset=BTC, I get the following error and I've not been able to figure out how to resolve it.

Traceback (most recent call last):
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 509\
, in <module>
    util.database_check(db)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/util.py", line 64, in d\
atabase_check
    raise exceptions.DatabaseError('Counterparty database is behind Bitcoind. Is the\
 counterpartyd server running?')
lib.exceptions.DatabaseError: Counterparty database is behind Bitcoind. Is the count\
erpartyd server running?

Can someone give me some help with what to look for?

Thanks.

[rashley]

I'm trying to get counterpartyd up and running on Debian. I have bitcoind running and I am running counterpartyd server in the background but when I try to connect to it using counterpartyd market --give-asset=BTC, I get the following error and I've not been able to figure out how to resolve it.

Traceback (most recent call last):
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 509\
, in <module>
    util.database_check(db)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/util.py", line 64, in d\
atabase_check
    raise exceptions.DatabaseError('Counterparty database is behind Bitcoind. Is the\
 counterpartyd server running?')
lib.exceptions.DatabaseError: Counterparty database is behind Bitcoind. Is the count\
erpartyd server running?

Can someone give me some help with what to look for?

Thanks.

Has your counterpartyd server caught up to the most recent block?

Maybe not. I'll check that. That's a misleading error message if that is the problem.

[rioshock2]

It is possible to set two expire time ?

1) expire time for the order
2) expire time for the btcpay

Thks

I don't think that the btcpay expire time would ever need to float.

Why?

Because the time should be as low as possible, and the minimum time is the same across trades.

Thanks.  simpler is always better

[IamNotSure]

Got a lib.exceptions.BalanceError: Insufficient bitcoins although my balance is 0.01 BTC.
(vista x64 running from source)

C:\counterpartyd_build>C:\Python32\python.exe run.py send --source=xxxxxxxxx1 --destination=xxxxxxxxx2 --quantity
=100 --asset=XCP
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 495, i
n <module>
    quantity, args.asset, unsigned=args.unsigned)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\send.py", line 34, in crea
te
    return bitcoin.transaction(source, destination, config.DUST_SIZE, config.MIN
_FEE, data, unsigned=unsigned)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 359, in
transaction
    raise exceptions.BalanceError('Insufficient bitcoins at address {}. (Need {}
 BTC.)'.format(source, total_btc_out / config.UNIT))
lib.exceptions.BalanceError: Insufficient bitcoins at address xxxxxxxxx1. (Need 0.0003172 BTC.)

[Patel]

Got a lib.exceptions.BalanceError: Insufficient bitcoins although my balance is 0.01 BTC.
(vista x64 running from source)

C:\counterpartyd_build>C:\Python32\python.exe run.py send --source=xxxxxxxxx1 --destination=xxxxxxxxx2 --quantity
=100 --asset=XCP
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 495, i
n <module>
    quantity, args.asset, unsigned=args.unsigned)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\send.py", line 34, in crea
te
    return bitcoin.transaction(source, destination, config.DUST_SIZE, config.MIN
_FEE, data, unsigned=unsigned)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 359, in
transaction
    raise exceptions.BalanceError('Insufficient bitcoins at address {}. (Need {}
 BTC.)'.format(source, total_btc_out / config.UNIT))
lib.exceptions.BalanceError: Insufficient bitcoins at address xxxxxxxxx1. (Need 0.0003172 BTC.)

Make sure the coins are on the same address as your XCP address. Then do a rescan.

[520Bit]

I'm trying to get counterpartyd up and running on Debian. I have bitcoind running and I am running counterpartyd server in the background but when I try to connect to it using counterpartyd market --give-asset=BTC, I get the following error and I've not been able to figure out how to resolve it.

Traceback (most recent call last):
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 509\
, in <module>
    util.database_check(db)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/util.py", line 64, in d\
atabase_check
    raise exceptions.DatabaseError('Counterparty database is behind Bitcoind. Is the\
 counterpartyd server running?')
lib.exceptions.DatabaseError: Counterparty database is behind Bitcoind. Is the count\
erpartyd server running?

Can someone give me some help with what to look for?

Thanks.

You have to let counterpartyd server update to the latest bitcoin block.

[JahPowerBit]

Got a lib.exceptions.BalanceError: Insufficient bitcoins although my balance is 0.01 BTC.
(vista x64 running from source)

C:\counterpartyd_build>C:\Python32\python.exe run.py send --source=xxxxxxxxx1 --destination=xxxxxxxxx2 --quantity
=100 --asset=XCP
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 495, i
n <module>
    quantity, args.asset, unsigned=args.unsigned)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\send.py", line 34, in crea
te
    return bitcoin.transaction(source, destination, config.DUST_SIZE, config.MIN
_FEE, data, unsigned=unsigned)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 359, in
transaction
    raise exceptions.BalanceError('Insufficient bitcoins at address {}. (Need {}
 BTC.)'.format(source, total_btc_out / config.UNIT))
lib.exceptions.BalanceError: Insufficient bitcoins at address xxxxxxxxx1. (Need 0.0003172 BTC.)

try "bitcoind listunspent" to check.
and if it return nothing, try to set the date of your system. I got this error yesterday.

[520Bit]

Can we reuse the escrow BTCs after we finished an exchange? The BTC amount send to the escrow should be 0.0001086 or 0.0001086+0.0001086 BTCs.

https://blockchain.info/tx/7b80040a18c70f279ac32c7032e69c46aff50ee76398df7babf6f9039ed2561d

[IamNotSure]

Make sure the coins are on the same address as your XCP address. Then do a rescan.

Thanks guys, a reparse seems to have done the trick.

I've finally managed to make this work !!

[rashley]

Looks like I might have finally caught up with the blockchain. I tried to check on it but the process had crashed with this error.

Status: RESTART
Block: 284193
Send: 100.0 of asset XCP from 1FueYJfpS7Q92qHGGrbr5d4r5qn4Lz56To to 1KKPcuXvYkEqwjFRUWuDUFcLk3YQgXfVbQ (b5f95848...8fd4d9f3)
Traceback (most recent call last):
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 682, in <module>
    blocks.follow(db)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 534, in follow
    parse_block(db, block_index)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 64, in parse_block
    cancel.parse(db, tx, message)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/cancel.py", line 61, in parse
    util.credit(db, tx['source'], order['give_asset'], order['give_remaining'])
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/util.py", line 257, in credit
    assert asset != 'BTC' # Never BTC.
AssertionError

Any ideas here?

[520Bit]

Looks like I might have finally caught up with the blockchain. I tried to check on it but the process had crashed with this error.

Status: RESTART
Block: 284193
Send: 100.0 of asset XCP from 1FueYJfpS7Q92qHGGrbr5d4r5qn4Lz56To to 1KKPcuXvYkEqwjFRUWuDUFcLk3YQgXfVbQ (b5f95848...8fd4d9f3)
Traceback (most recent call last):
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 682, in <module>
    blocks.follow(db)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 534, in follow
    parse_block(db, block_index)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 64, in parse_block
    cancel.parse(db, tx, message)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/cancel.py", line 61, in parse
    util.credit(db, tx['source'], order['give_asset'], order['give_remaining'])
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/util.py", line 257, in credit
    assert asset != 'BTC' # Never BTC.
AssertionError

Any ideas here?

Reparse counterpartyd and try again.

[PhantomPhreak]

Looks like I might have finally caught up with the blockchain. I tried to check on it but the process had crashed with this error.

Status: RESTART
Block: 284193
Send: 100.0 of asset XCP from 1FueYJfpS7Q92qHGGrbr5d4r5qn4Lz56To to 1KKPcuXvYkEqwjFRUWuDUFcLk3YQgXfVbQ (b5f95848...8fd4d9f3)
Traceback (most recent call last):
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 682, in <module>
    blocks.follow(db)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 534, in follow
    parse_block(db, block_index)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 64, in parse_block
    cancel.parse(db, tx, message)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/cancel.py", line 61, in parse
    util.credit(db, tx['source'], order['give_asset'], order['give_remaining'])
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/util.py", line 257, in credit
    assert asset != 'BTC' # Never BTC.
AssertionError

Any ideas here?

Reparse counterpartyd and try again.

Actually, I believe the problem is that he's running an old version. 520bit, tell us what counterpartyd --version returns.

[rashley]

Looks like I might have finally caught up with the blockchain. I tried to check on it but the process had crashed with this error.

Status: RESTART
Block: 284193
Send: 100.0 of asset XCP from 1FueYJfpS7Q92qHGGrbr5d4r5qn4Lz56To to 1KKPcuXvYkEqwjFRUWuDUFcLk3YQgXfVbQ (b5f95848...8fd4d9f3)
Traceback (most recent call last):
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 682, in <module>
    blocks.follow(db)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 534, in follow
    parse_block(db, block_index)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 64, in parse_block
    cancel.parse(db, tx, message)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/cancel.py", line 61, in parse
    util.credit(db, tx['source'], order['give_asset'], order['give_remaining'])
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/util.py", line 257, in credit
    assert asset != 'BTC' # Never BTC.
AssertionError

Any ideas here?

Reparse counterpartyd and try again.

Actually, I believe the problem is that he's running an old version. 520bit, tell us what counterpartyd --version returns.

counterpartyd -V
counterpartyd v0.2

[rashley]

Looks like I might have finally caught up with the blockchain. I tried to check on it but the process had crashed with this error.

Status: RESTART
Block: 284193
Send: 100.0 of asset XCP from 1FueYJfpS7Q92qHGGrbr5d4r5qn4Lz56To to 1KKPcuXvYkEqwjFRUWuDUFcLk3YQgXfVbQ (b5f95848...8fd4d9f3)
Traceback (most recent call last):
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 682, in <module>
    blocks.follow(db)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 534, in follow
    parse_block(db, block_index)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 64, in parse_block
    cancel.parse(db, tx, message)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/cancel.py", line 61, in parse
    util.credit(db, tx['source'], order['give_asset'], order['give_remaining'])
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/util.py", line 257, in credit
    assert asset != 'BTC' # Never BTC.
AssertionError

Any ideas here?

Reparse counterpartyd and try again.

Actually, I believe the problem is that he's running an old version. 520bit, tell us what counterpartyd --version returns.

counterpartyd -V
counterpartyd v0.2

Did a git pull and I've restarted it. It's started parsing an older block so when it gets up to 284193, I'll have an answer.

[ewibit]

counterpartyd -V
counterpartyd v0.2

Code:

./counterpartyd.py -V
Traceback (most recent call last):
  File "./counterpartyd.py", line 14, in <module>
    from prettytable import PrettyTable
ImportError: No module named 'prettytable'

[MoneypakTrader.com]

EDIT: I forgot to mention the XCP escrow system would completely replace fee_provided and fee_required.

I agree the fee system should be removed, if transactions are included in a block, fees are irrelevant and wasteful. The obligation is on the BTCpay-er to ensure they get their transaction included in a block (i.e. pay 0.0001 fee). All other transactions should be frictionless with virtually ZERO fees.

Regarding fixing some of the current problems:
I'd suggest:
XCP/BTC orders can designate these new [optional] variables/fees:
1) [Optional] BTCpay lockin time in blocks as a variable for XCP orders:
****only BTC orders providing less than or equal to this time left are matchable.***
2) [Optional] BTC order lockin Fee per match(in XCP) (Ignored for first order match) allowed to be set by XCP orders (required fee) and BTC orders (maximum fee per match or match is ignored).
3) [Optional] Lockin Fees (XCP) paid by BTC orders to cover matches beyond the first. (with maximum lockin fee per match specified by BTC order in (2) above or no maximum if not set).

Secondary XCP order matches (beyond first match) are paid XCP from BTC orders (from (3) above) in exchange for the privilege of the lock in time received to do the BTCpay. Only btc orders designating a lockin fee ((2) above) more than or equal to the lockin fee required by the XCP orders ((2) above) are matchable IF the remaining lockin fees are sufficient to pay it and BTC order time to expiration is less than or equal to the lockin period specified ((1) above).


4) [optional] Minimum match amount (in XCP) as another option for BTC orders (to prevent BTCpay fee problems) since each match requires btcpay, only makes sense to let btc orders set minimum they are willing to btcpay for.

I.E. NO XCP required by BTC order for first BTC/XCP match, but optional market driven XCP requirements for additional matches.
This will help drive demand for XCP as well as fix this bug.

These changes should be incorporated so that older clients/orders will NOT match with orders that include the new variables to minimize the potential problems.

The only other serious proposal I see:

XCP seller options: --xcp-escrow-required-pct, --max-order-lock-time
XCP buyer options: --xcp-escrow-provided-pct, --min-expire-time

This solves:
1) sweeping of order book problem
2) XCP buyer doesn't get free option
3) XCP seller order won't get locked for a long period of time
4) XCP seller won't be able to hit buyer orders and set low expiration to collect escrowed XCP

This forces XCP orders to have their orders locked while receiving nothing unless the order is unpaid, flat payment for the lock time is more fair to the XCP order allowing them to customize the lock fee (larger for more lock time presumably).
The fees paid for the lock time should be immediately spendable by the XCP order giving the lock time, it could be a long time or short time as agreeable by the orders allowing a sort of options trading by default.
XCP buyers should be watching their order close to the expiration and they will either BTCpay or cancel orders to avoid paying for not enough lock time in the last few blocks. They should be able to cancel the unmatched order remainder and the matched orders will either be BTCpaid for or expire naturally (they paid for the lockin time, so no buthurt as the current situation allows).

The first order match to a btc order MUST ignore the lock fee in order to prevent clogging the order book around the trading range.
Yes, this will allow clearing the first XCP order above a certain price, but the fee paid to include a transaction in the blockchain is sufficient to justify this and this will add an element of strategy to the options trading and encourage more sophisticated traders onto the platform.

The BTC order MUST be allowed to skip small orders (per my proposal (4) above) to avoid inefficient trades unless the BTC order intends to BTCpay for such.

I see one potential problem with the XCP escrow solution: what do we do about honest XCP buyers who want to place limit orders?

Using my proposal, they simply set a fee for the lockin period, free market style solution.
If they are a primary match (the first match to a XCP buy), the fee is ignored (cost paid to include transaction in blockchain is considered sufficient). If it is a secondary match, they receive XCP immediately for providing the lockin period.

The remaining problems such as the excessive cost for XCP transactions should be addressed when possible.

Also, to prevent LONG initial load times (currently several hours to sync and will only grow longer), an initial DB should be added to the repository each month after agreed to be legit by a sufficient number of community members. This will be necessary in another month to prevent week long sync time for slower computers.

Can someone please link to the most current description of how the asset creation/fees work?

[rashley]

counterpartyd -V
counterpartyd v0.2

Code:

./counterpartyd.py -V
Traceback (most recent call last):
  File "./counterpartyd.py", line 14, in <module>
    from prettytable import PrettyTable
ImportError: No module named 'prettytable'

rashley@expo:~$ counterpartyd --version
counterpartyd v0.3
rashley@expo:~$ counterpartyd -V
counterpartyd v0.3

So the version was definitely bumped but the reparsing is going to take about a week. It's rolling along at about 10 sec per block and it has at least 6000 blocks to go.

[MoneypakTrader.com]

This forces XCP orders to have their orders locked while receiving nothing unless the order is unpaid, flat payment for the lock time is more fair to the XCP order allowing them to customize the lock fee (larger for more lock time presumably).

I considered having a flat XCP fee per order match as well, but I don't think the additional complexity is worth it. Having a flat XCP fee also shifts part of the burden to honest buyers. We don't want to discourage honest buyers by slapping fees on them if we can avoid it.

Additional complexity?
A) my proposal: 1) XCP transferred to XCP orders on any secondary order matches or 2) returned if no secondary order matches are made and BTC order completes, cancels, or expires.
vs.
B) your proposal: 1) XCP transfer to XCP order matches **if no btcpay is made** (requires parsing BTCpay and order matching) or 2) transferred back to btc order if no order matches are made or 3) transferred back to BTC order if matched and btcpayed **requires parsing btcpays and matches and comparing them**.
Which is more complex again?

"slapping fees on them" ? Burden on honest buyers? Did you read my proposal? no additional fees are required at all, it's all optional and the first match NEVER has a fee "slapped" on anyone regardless of the lowest XCP seller trying to clog the book with high fees which would cause a market anomaly in your proposal but not in mine.
With my proposal, Honest buyers can look at the order book and pick an XCP order that has the volume they want and trade in one transaction using the method I propose (using minimum xcp match amount variable), NO fees required aside from the already outrageous XCP protocol fees that are slapped on them that I want removed.

The combination of improvements I suggest allows the book clogging to be minimized (first order match fee is ignored since BTC order placement requires getting a block into the bitcoin blockchain which is a sufficient hurdle to allow at least one order match).

We don't want to burden honest XCP buyers who just want to buy 200-500 XCP without clearing numerous orders with costly escrows requiring 10 different BTCpays (or sacrificing all the escrow/fees), that's why the minimum volume I propose must be allowed as a variable (due to the excessive XCP protocol fees). Please read my proposal and understand how it all comes together to help everyone involved. I'll attach it at the bottom. Feel free to clarify your position if it can make more sense.

I agree with you that if the price moves by more than the XCP-escrow-required-pct during the lock time, then the buyer can take advantage by not paying for the order. But the sellers can compensate by just setting a higher xcp-escrow-required-pct to make the option value to the buyer so low that it's not worth his time to try this attack. Honest buyers won't care about a higher escrow-required-pct.

The fact is that the market uses an option style system that is currently available at no additional fee per match, allowing the order book to be cleared for a single fee that is to none of the parties benefit. Escrow doesn't compensate the XCP seller for the lockin period provided (if the option is exercised in this period) thus forcing a distortion in pricing since the BTC order has no reason to pay immediately if they intend to complete the purchase. Why not way for the remainder of the lock time just in case the offer becomes unattractive?
Setting prices/Paying for the options beyond the first ones (if the xcp seller chooses to charge a fee) allows more accurate pricing of the orders to price the lock time while compensating the BTC order for their time/effort in placing the order and describing the minimum XCP order matches they will btcpay for.

I predict if this system is put in place xcp-escrow-required-pct can safely be set to 0 anyway because trolls would lose interest in attacking a system that recovers quickly from their attack.

we might as well not improve the protocol if we're comfortable relying on others following rules outside the protocol to limit their behavior.
Regardless, I've described improvements that allow XCP to be bought for no XCP fee while not relying on trolls to not be trolls.

I agree the current fee system should be removed, if transactions are included in a block, fees are irrelevant and wasteful. The obligation is on the BTCpay-er to ensure they get their transaction included in a block (i.e. pay 0.0001 fee). All other transactions should be frictionless with virtually ZERO fees.

Regarding fixing some of the current problems:
I'd suggest:
XCP/BTC orders can designate these new [optional] variables/fees:
1) [Optional] BTCpay lockin time in blocks as a variable for XCP orders:
****only BTC orders providing less than or equal to this time left are matchable.***
2) [Optional] BTC order lockin Fee per match(in XCP) (Ignored for first order match) allowed to be set by XCP orders (required fee) and BTC orders (maximum fee per match or match is ignored).
3) [Optional] Lockin Fees (XCP) paid by BTC orders to cover matches beyond the first. (with maximum lockin fee per match specified by BTC order in (2) above or no maximum if not set).

Secondary XCP order matches (beyond first match) are paid XCP from BTC orders (from (3) above) in exchange for the privilege of the lock in time received to do the BTCpay. Only btc orders designating a lockin fee ((2) above) more than or equal to the lockin fee required by the XCP orders ((2) above) are matchable IF the remaining lockin fees are sufficient to pay it and BTC order time to expiration is less than or equal to the lockin period specified ((1) above).

4) [optional] Minimum match amount (in XCP) as another option for BTC orders (to prevent BTCpay fee problems) since each match requires btcpay, only makes sense to let btc orders set minimum they are willing to btcpay for.

I.E. NO XCP required by BTC order for first BTC/XCP match, but optional market driven XCP requirements for additional matches.
This will help drive demand for XCP as well as fix this bug.

These changes should be incorporated so that older clients/orders will NOT match with orders that include the new variables to minimize the potential problems.

Flat payment for the lock time is more fair to the XCP order allowing them to customize the lock fee (larger for more lock time presumably).
The fees paid for the lock time should be immediately spendable by the XCP order giving the lock time, it could be a long time or short time as agreeable by the orders allowing a sort of options trading by default.
XCP buyers should be watching their order close to the expiration and they will either BTCpay or cancel orders to avoid paying the lockin fees for not enough lock time during the last few blocks. They should be able to cancel the unmatched order remainder while the matched orders will either be BTCpaid for or expire naturally (they paid for the lockin time, so no buthurt as the current situation allows).

The first order match to a btc order MUST ignore the lock fee in order to prevent clogging the order book around the trading range with high lock fees. This increases market liquidity.
Yes, this will allow clearing the first XCP order (above a certain liquidity level using the minimum option I described), but the fee paid to include a transaction in the blockchain is sufficient to justify this *AND* this will add an element of strategy to the options trading to encourage more sophisticated traders onto the platform.

The BTC order MUST be allowed to skip small orders (per my proposal (4) above) to avoid inefficient trades unless the BTC order wants to BTCpay for such inefficient trades.

I see one potential problem with the XCP escrow solution: what do we do about honest XCP buyers who want to place limit orders?

Using my proposal, they simply set a fee for the lockin period and a minimum order match quantity, free market style solution.
For the primary match (the first match to a XCP buy), the fee is ignored (cost paid to include transaction in blockchain is considered sufficient). If it is a secondary match, they receive XCP immediately for providing the lockin period.

The remaining problems such as the excessive cost for XCP transactions should be addressed when possible.

Also, to prevent LONG initial load times (currently several hours to sync and will only grow longer), an initial DB should be added to the repository each month after agreed to be legit by a sufficient number of community members. This will be necessary in another month to prevent week long sync time for slower computers.

Can someone please link to the most current description of how the asset creation/fees work?

Improvement 5) Orders seeking to receive BTC should be allowed to direct match for the cost of the lockin fee specified according to (2) above, allowing a btc order to claim the order/lockin time by directly reserving it, this would facilitate directly buying the option/order they want regardless of position on the market list. This would be more honest about the options style trading that this platform requires (when BTC is involved).

[jimhsu]

Great discussion you guys are having right now. I'm incredibly busy and things just got even busier, so I won't be checking/replying to this thread for a few days. I think you guys can manage. :p