Bootstrapping a BitAsset

[Simeon II]

You can make the window a tad wider and the pay rate column will show up on the delegates tab where you can see them all.

Which window???

I see them only under 'Directory' and there is no such column there...

Is there a command?

blockchain_list_delegates lists only active one...

[bytemaster]

You can make the window a tad wider and the pay rate column will show up on the delegates tab where you can see them all.

[Simeon II]

We are putting more and more pressure on voting. What are the incentives to vote again?

I don't mind expecting delegates to provide price feeds because it's a simple task to do and is easy to verify they are doing it.  It requires similar competencies as writing blocks: reliably perform a simple task with great up-time.  Either they are doing it or they are not and it's easy to see which ones are.  So voting is easy and if a couple delegates are messing up it's not the end of the world because the others pick up the slack until they are removed.

I share your concern with regard to the "soft approach" as I think it is expecting a lot out of the voting process.  You are now expecting delegates to all make good "judgement calls" about selectively excluding transactions and then expecting voters to judge their judgement... this makes me nervous.

The incentives to vote are similar to shareholders of any company.  But voting in our system is easier; you can do it with a couple mouse clicks.  Info/data to make good decisions will be readily available.  (contrast this with people standing in line to vote in a presidential election, ostensibly the only incentive is the 1 in a million chance that you are the deciding vote between corrupt politician A vs corrupt politician B.)

I hope voting does not turn into full time job!

I don't think it will... I think people will only come out to vote when there is a problem and there is no reason for there to be problems all the time.

From what I see from the test up to now it is more than full time... you have to click on each one individually to see just his pay rate...

[bitmeat]

How is it different from Open Transactions with Smart Contracts?

Not familiar with OT and their Smart Contracts. However, Ripple's proposal is using a secure sandbox that allows you to write in any programming language you please, is a very good move from practical stand point.

Also, not sure if OT allows Smart Contracts to run offline by Smart Oracles. There are some really good pieces in this whitepaper and I would love to see what Bitshares is planning for Smart Contracts.

I'm not a huge fan of the Bitcoin scripting and escrow as it currently stands. We need something more innovative and easier for developers to get involved. What Ripple's whitepaper proposes I think is a step in the right direction.

[bytemaster]

We are putting more and more pressure on voting. What are the incentives to vote again?

I don't mind expecting delegates to provide price feeds because it's a simple task to do and is easy to verify they are doing it.  It requires similar competencies as writing blocks: reliably perform a simple task with great up-time.  Either they are doing it or they are not and it's easy to see which ones are.  So voting is easy and if a couple delegates are messing up it's not the end of the world because the others pick up the slack until they are removed.

I share your concern with regard to the "soft approach" as I think it is expecting a lot out of the voting process.  You are now expecting delegates to all make good "judgement calls" about selectively excluding transactions and then expecting voters to judge their judgement... this makes me nervous.

The incentives to vote are similar to shareholders of any company.  But voting in our system is easier; you can do it with a couple mouse clicks.  Info/data to make good decisions will be readily available.  (contrast this with people standing in line to vote in a presidential election, ostensibly the only incentive is the 1 in a million chance that you are the deciding vote between corrupt politician A vs corrupt politician B.)

I hope voting does not turn into full time job!

I don't think it will... I think people will only come out to vote when there is a problem and there is no reason for there to be problems all the time.

[bytemaster]

This is where I think something like Ethereum's Turing complete scripting might be useful. But as much as I like the idea, I think forcing everyone to execute code is an overkill. If you make groups of delegates promise to run a certain script however this becomes very interesting.

UPDATE: Holy Shit, Ripple just released a paper that proposes exactly that. Bravo! Love the secure code integration with NaCl as well.

https://ripple.com/blog/smart-oracles-building-business-logic-with-smart-contracts/

I think this kicks Ethereum's butt 1000x times over!!!

How is it different from Open Transactions with Smart Contracts?

[Simeon II]

We are putting more and more pressure on voting. What are the incentives to vote again?

I don't mind expecting delegates to provide price feeds because it's a simple task to do and is easy to verify they are doing it.  It requires similar competencies as writing blocks: reliably perform a simple task with great up-time.  Either they are doing it or they are not and it's easy to see which ones are.  So voting is easy and if a couple delegates are messing up it's not the end of the world because the others pick up the slack until they are removed.

I share your concern with regard to the "soft approach" as I think it is expecting a lot out of the voting process.  You are now expecting delegates to all make good "judgement calls" about selectively excluding transactions and then expecting voters to judge their judgement... this makes me nervous.

The incentives to vote are similar to shareholders of any company.  But voting in our system is easier; you can do it with a couple mouse clicks.  Info/data to make good decisions will be readily available.  (contrast this with people standing in line to vote in a presidential election, ostensibly the only incentive is the 1 in a million chance that you are the deciding vote between corrupt politician A vs corrupt politician B.)

I hope voting does not turn into full time job!

[Agent86]

We are putting more and more pressure on voting. What are the incentives to vote again?

I don't mind expecting delegates to provide price feeds because it's a simple task to do and is easy to verify they are doing it.  It requires similar competencies as writing blocks: reliably perform a simple task with great up-time.  Either they are doing it or they are not and it's easy to see which ones are.  So voting is easy and if a couple delegates are messing up it's not the end of the world because the others pick up the slack until they are removed.

I share your concern with regard to the "soft approach" as I think it is expecting a lot out of the voting process.  You are now expecting delegates to all make good "judgement calls" about selectively excluding transactions and then expecting voters to judge their judgement... this makes me nervous.

The incentives to vote are similar to shareholders of any company.  But voting in our system is easier; you can do it with a couple mouse clicks.  Info/data to make good decisions will be readily available.  (contrast this with people standing in line to vote in a presidential election, ostensibly the only incentive is the 1 in a million chance that you are the deciding vote between corrupt politician A vs corrupt politician B.)

[CLains]

This feels like,



We are putting more and more pressure on voting. What are the incentives to vote again?

[bitmeat]

This is where I think something like Ethereum's Turing complete scripting might be useful. But as much as I like the idea, I think forcing everyone to execute code is an overkill. If you make groups of delegates promise to run a certain script however this becomes very interesting.

UPDATE: Holy Shit, Ripple just released a paper that proposes exactly that. Bravo! Love the secure code integration with NaCl as well.

https://ripple.com/blog/smart-oracles-building-business-logic-with-smart-contracts/

I think this kicks Ethereum's butt 1000x times over!!!

[bitmeat]

Right. That's how I understood the hybrid: 1) 50% is enforced by the block chain, smaller % is just the delegate itself,
Then 2) custom filtering is the same thing - just on local delegate level.

Edit: 1) will prevent massive abuse, 2) will only slow it down unless community eliminates all delegates causing trouble

[toast]

BTW by the current proposal you would *not* be able to have "even 1 delegate get it in" if the range is enforced at the blockchain level from the median a specific delegate feed.

[toast]

Yeah I think you have a great point. Our transactions are really easy to parse so it would not even be hard. I bet BM could add it in an hour. Anything in the pending list must be explicitly "approved".

[bitmeat]

Yes, because we may need to be able to quickly change the criteria, we may find that sometimes feeds contain bad data that needs to be filtered, exchanges go down, etc. etc.
For that I prefer to have multiple feeds and be able to say with confidence - this a very good price approximation.

But I see what you are saying - this is brainstorming, and if you decide to go that route, it will be in the RPC, since it is how everything else works.

So then a hybrid model as BM proposed would work:

1) Limit fluctuations to 50% range in 24 hour period (or less decided by the delegate)
2) Additionally allow delegates to exclude transactions based on their own criteria via RPC - I see BM's point that all it takes is 1 delegate to still be able to get their transactions in. But I think that should make it a bit harder to manipulate the market.

I think 2) is still good to have even if you don't see value in it initially. Imagine we experience some abuse, we might be able to very quickly deploy a patch and recommend community only vote for delegates having such and such filter in their system, until this is resolved. The most responsive and flexible delegates will win the community's hearts.

[toast]

toast, I'm not sure the current RPC interface allows for "selectively include transactions in the next block I'm forging"

Right, I'm saying, if you are allowed to enter price ranges for selectively including transactions at all (like in the proposal), then it will be available via RPC.
I guess from this response what you were saying is that you should be able to look at an entire transaction and choose to include/not include by your own rules. That is a good idea. But in any case, the "price range" criterion would still be a first-class element with its own call because the blockchain needs to compute the median of all the inputs.