Best Selling Option

[giant middle finger]

remember when we solved both the voter apathy and liquidiy and profitability and potential hostile takeover bid problems with one simple fix?

[xeroc]

Normal users cannot whitelist other users (you must be a lifetime member).

So this means a lifetime member can add other uses to their account's whitelist IIUC. But this only serves the purpose of broadcasting reputation/trust or whatever .. nothing technical comes with a user-whitelist, correct?

Except it restricts who can own a UIA.   
The Issuer of the UIA can name the accounts that are considered "whitelist authorities"  then "whitelist authorities"  can then mark all of the accounts they know.

Ok .. this would be the KCY/AML-service-provider feature then .. got it

[bytemaster]

Normal users cannot whitelist other users (you must be a lifetime member).

So this means a lifetime member can add other uses to their account's whitelist IIUC. But this only serves the purpose of broadcasting reputation/trust or whatever .. nothing technical comes with a user-whitelist, correct?

Except it restricts who can own a UIA.   
The Issuer of the UIA can name the accounts that are considered "whitelist authorities"  then "whitelist authorities"  can then mark all of the accounts they know.

[xeroc]

Normal users cannot whitelist other users (you must be a lifetime member).

So this means a lifetime member can add other uses to their account's whitelist IIUC. But this only serves the purpose of broadcasting reputation/trust or whatever .. nothing technical comes with a user-whitelist, correct?

[xeroc]

You are mistaken Xeroc.   Whitelist is only used for controlling who may own a particular UIA.  Normal users cannot whitelist other users (you must be a lifetime member).   The reason is that the white lists could quickly become a vector of attack when you consider potential long-term memory requirements of tracking it all.   This is a parameter the committee members can change, but is defaulting to only lifetime members can use whitelists.

Whitelist does not impact who you can send or receive funds from.  Though it should be possible for the wallet to flag operations that interact with a whitelisted or blacklisted account.

Thanks for the clarification ..

So a gateway can receive bitUSD even from those people that are not whitelisted ..

A gateway that trade USD : bitUSD can then not really make much use of whitelisting because they can receive bitUSD from anybody .. even those that are not verified ..
That leads to the need for gateways to force their customers to only use their validated (whitelisted or not) account when sending bitUSD to the gateway .. and they need to send back those funds from users that are not verified properly .. ok .. got it

[bytemaster]

Is it possible to have some sort of whitelist for users to specify trusted sources of funds?  So for example, two users that trust each other could whitelist one another to enable immediate transactions between them.  Whereas a transaction originating from an untrusted source might require additional blocks depending on preferences specified by the user.  Aside from trusting the other party or not, the size of the transaction would obviously be another factor and it seems that users should have the ability to determine how many blocks they want to wait based on a mix of factors.  Does this make sense?

Yes .. this is already available and should be used by gateways for withdrawals ..

transaction sources not in your white list or on your blacklist will be unable to send funds yourway

You are mistaken Xeroc.   Whitelist is only used for controlling who may own a particular UIA.  Normal users cannot whitelist other users (you must be a lifetime member).   The reason is that the white lists could quickly become a vector of attack when you consider potential long-term memory requirements of tracking it all.   This is a parameter the committee members can change, but is defaulting to only lifetime members can use whitelists.

Whitelist does not impact who you can send or receive funds from.  Though it should be possible for the wallet to flag operations that interact with a whitelisted or blacklisted account.

[xeroc]

Is it possible to have some sort of whitelist for users to specify trusted sources of funds?  So for example, two users that trust each other could whitelist one another to enable immediate transactions between them.  Whereas a transaction originating from an untrusted source might require additional blocks depending on preferences specified by the user.  Aside from trusting the other party or not, the size of the transaction would obviously be another factor and it seems that users should have the ability to determine how many blocks they want to wait based on a mix of factors.  Does this make sense?

Yes .. this is already available and should be used by gateways for withdrawals ..

transaction sources not in your white list or on your blacklist will be unable to send funds yourway

[tbone]

Is it possible to have some sort of whitelist for users to specify trusted sources of funds?  So for example, two users that trust each other could whitelist one another to enable immediate transactions between them.  Whereas a transaction originating from an untrusted source might require additional blocks depending on preferences specified by the user.  Aside from trusting the other party or not, the size of the transaction would obviously be another factor and it seems that users should have the ability to determine how many blocks they want to wait based on a mix of factors.  Does this make sense?

[xeroc]

Monster you are being intentionally difficult.   Just because a merchant can choose to trust all witnesses does not mean he has to.   Once the attack happened once everyone would move to requiring more than one confirmation.  You are effectively insisting that front doors are not secure because everyone leaves them unlocked.  As soon as there is a crime spree the doors will lock up.

On the contrary, I am describing a very real possibility. Simply assuming that if such an attack took place, everything will just work out for the best and magically adapt is naive. Better to have preventative measures in place a priori.

Moving forward, I propose that the blockchain (and RPC APIs) only show a transaction confirmed at 2 blocks deep minimum, not 1 as it is currently, as I have clearly demonstrated this is not safe.

In our documentation for exchanges we have recommended using the DELAYED node to delay 10 blocks before processing anything just to be safe.   

To clarify ... there is an extra binary that behaves like a full node, only connects to a trusted full node and delays all blocks y N blocks ..

[bytemaster]

Monster you are being intentionally difficult.   Just because a merchant can choose to trust all witnesses does not mean he has to.   Once the attack happened once everyone would move to requiring more than one confirmation.  You are effectively insisting that front doors are not secure because everyone leaves them unlocked.  As soon as there is a crime spree the doors will lock up.

On the contrary, I am describing a very real possibility. Simply assuming that if such an attack took place, everything will just work out for the best and magically adapt is naive. Better to have preventative measures in place a priori.

Moving forward, I propose that the blockchain (and RPC APIs) only show a transaction confirmed at 2 blocks deep minimum, not 1 as it is currently, as I have clearly demonstrated this is not safe.

In our documentation for exchanges we have recommended using the DELAYED node to delay 10 blocks before processing anything just to be safe.   

[liondani]

I propose that the blockchain (and RPC APIs) only show a transaction confirmed at 2 blocks deep minimum, not 1 as it is currently, as I have clearly demonstrated this is not safe.

as bytemaster stated/mentioned with this precaution you will be much safer with a near zero probability to get successful attacked!

[monsterer]

Monster you are being intentionally difficult.   Just because a merchant can choose to trust all witnesses does not mean he has to.   Once the attack happened once everyone would move to requiring more than one confirmation.  You are effectively insisting that front doors are not secure because everyone leaves them unlocked.  As soon as there is a crime spree the doors will lock up.

On the contrary, I am describing a very real possibility. Simply assuming that if such an attack took place, everything will just work out for the best and magically adapt is naive. Better to have preventative measures in place a priori.

Moving forward, I propose that the blockchain (and RPC APIs) only show a transaction confirmed at 2 blocks deep minimum, not 1 as it is currently, as I have clearly demonstrated this is not safe.

[sittingduck]

Monster you are being intentionally difficult.   Just because a merchant can choose to trust all witnesses does not mean he has to.   Once the attack happened once everyone would move to requiring more than one confirmation.  You are effectively insisting that front doors are not secure because everyone leaves them unlocked.  As soon as there is a crime spree the doors will lock up.


Sent from my iPhone using Tapatalk

[monsterer]

Four things you assume:

1. A merchant that accepts a block as final when there are 2 competing blocks
2. The witness is not publicly known and subject to legal action (they would be caught)
3. That if a witness was intentionally producing double blocks that the network participants wouldn't immediately require at least 2 blocks of confirmation.
4.  That merchants would irreversibly ship an item with one block of confirmation.

Like I said, any merchant is free to determine the risks involved and set their policy accordingly.  If the risk of an evil witness exists then a merchant will simply wait a few seconds and the risk will quickly approach 0.

1) Why wouldn't a merchant accept my block? The system will show the transaction as confirmed. The network won't even contain my other transaction at that time from his perspective
2) Who says block producers must be onymous?
3) It would be too late by then
4) Shapeshift.io/metaexchange/blocktrades.us/polonix - transactions are listed as 'confirmed' at 1 confirmation, nominally

[tonyk]

http://bytemaster.github.io/update/2015/09/29/Bitcoin-is-100x-less-secure-than-commonly-believed/

I am lowering my offer for doing the CEO on this peace to 5% of the links having my affiliate code.

In other words - good job!!! 

Which will of course means that the majority will find something very very wrong with this post. I do not know what exactly, but I am pretty   confident they will.